Could skija be used by JetBrains IDEs for faster rendering performance?
I wonder if this is a long term goal.
But I bet regarding this goal it would be easier to make jetbrains IDEs use electron.
I seems that jetbrains is porting jetpack compose to the desktop and that skija will be a dependency.
While jetpack compose will probably be nice and could become a decent cross platform GUI library,
the cold hard truth is that 1) nobody has the human resources to match the feature rich and optimization level of chromium/electron (just look at the commit count! This is the biggest open source project ever).
2) being cross platform except for the web is an unacceptable elephant in the room for most and explain with 1) the success of electron/ionic.
Kotlin can transpile to js/ts which is nice but do not enable seamless compatibility with js the same way typescript can.
Js is the biggest GUI/frontend ecosystem to exist.
Now that I explained the limitations of the current vision of jetbrains (building a semi cross platform gui library: jetpack compose) I would like to share an additional vision: the true revolution that await this century:
JetBrains needs to fork chromium and to incorporate into it graalVM. Such a fork could hence allow native Java and Kotlin support and could add DOM/browser methods bindings (either trough js or c++ / webIDL) in a way that webassembly could never do.
Such a project would bring the best of all worlds:
1) Keep the GUI engine with the most human resources since decades:
So maximum feature and optimization level which is mandatory for building rich competitive GUIs.
This should not be understated.
2) keep the security guarantees of the web (sandboxing, etc)
3) enable to use the best GUI engine with the kotlin (and java) ecosystem and "native" performance instead of transpiled js.
4) have true seamless compatibility with the js ecosystem contrary to kotlinjs: through graalVM state of the art polyglostism.
Once we have this, you would have built a breakthrough that would be unprecedented:
That would be the first time where we could be able to simultaneously use the state of the art GUI engine (chromium) with a state of the art programming language (Kotlin) instead of being stuck with javascript which is less expressive, performant, ergonomic and has a higher cognitive overhead. Today kotlinjs cannot seamlessly do that because In order to be seamless you need true js/ts compatibility the same way as Kotlin is compatible with Java. GraalVM (through a little bit of funding for maturation) polyglostism allows just that and would connect the two biggest software ecosystems in the world (so that would be two revolutionary breakthrough at once)
Once those two revolutionary breakthrough are achieved that is:
1) invest in graalVM JS in order to make it mature (the implementation is already decent)
2) port graalVM inside chromium
3) enable for the first time bindings of browser APIs to another language than js (Kotlin) (webassembly cannot do that and this is the exact reason it will not really reach mainstream)
Those bindings could be automated through webIDL, or through Kotlin native interop with C (as they exist to my knowledge both in C++ and in JS), or through wrappers (eventually with KotlinJS) but the most simple would be to just leverage once again graalVM compatibility between Js and Kotlin.
4) integrate this chromium fork into elektron
Once this is achieved you have built the successor of electron and therefore the first truly great cross platform GUI engine since the dawn of programming. That would make JetBrains shine in all developper circles as the hero we didn't know we wanted but the one we all needed to deliver us from JS mediocrity monopoly that inflict pain on deceloppers, on performance and on software poverty (not being able to reuse the brilliant Java ecosystem).
Once such a widespread success of "EleKtron" is achieved I bet that Chromium and other browsers developers would consider that after showing them the empirical evidence, that this GraalVM port would be actually an order of magnitude better webassembly (but does not obscolete webassembly for C/C++ at least not certainly) but would be the webBytecofe that truly used languages (high level ones) needs.
This Vision that I describe is arguably one of the biggest breakthrough awaiting the 21st century in programming. As explained above it would simultaneously solve extremely big problems and GraalVM has paved the way towards a solution to them. Unification of software platforms/ecosystems instead of reinventing the wheel is the big rational trends that factually save billions of human resources $ and allows qualitative synergies.
Microsoft among others is adopting the premises of this Vision:
E.g by migrating edge from a duplicated reimplementation of the web interfaces to improving a shared, universal implementation (chromium)
JetBrains is also one of the key enterprises to share the premises of the Vision: by understanding and striving for maximal compatibility between Kotlin and the JVM ecosystem.
The Vision that I have described is actually the consequence of pushing the boundaries of the JetBrains Vision!
I hope that you, engineers reading this, will talk about it internally at JetBrains and investigate if you will pursue your Vision.
Could skija be used by JetBrains IDEs for faster rendering performance? I wonder if this is a long term goal. But I bet regarding this goal it would be easier to make jetbrains IDEs use electron.
I seems that jetbrains is porting jetpack compose to the desktop and that skija will be a dependency. While jetpack compose will probably be nice and could become a decent cross platform GUI library, the cold hard truth is that 1) nobody has the human resources to match the feature rich and optimization level of chromium/electron (just look at the commit count! This is the biggest open source project ever). 2) being cross platform except for the web is an unacceptable elephant in the room for most and explain with 1) the success of electron/ionic.
Kotlin can transpile to js/ts which is nice but do not enable seamless compatibility with js the same way typescript can. Js is the biggest GUI/frontend ecosystem to exist. Now that I explained the limitations of the current vision of jetbrains (building a semi cross platform gui library: jetpack compose) I would like to share an additional vision: the true revolution that await this century:
JetBrains needs to fork chromium and to incorporate into it graalVM. Such a fork could hence allow native Java and Kotlin support and could add DOM/browser methods bindings (either trough js or c++ / webIDL) in a way that webassembly could never do. Such a project would bring the best of all worlds: 1) Keep the GUI engine with the most human resources since decades: So maximum feature and optimization level which is mandatory for building rich competitive GUIs. This should not be understated. 2) keep the security guarantees of the web (sandboxing, etc) 3) enable to use the best GUI engine with the kotlin (and java) ecosystem and "native" performance instead of transpiled js. 4) have true seamless compatibility with the js ecosystem contrary to kotlinjs: through graalVM state of the art polyglostism.
Once we have this, you would have built a breakthrough that would be unprecedented: That would be the first time where we could be able to simultaneously use the state of the art GUI engine (chromium) with a state of the art programming language (Kotlin) instead of being stuck with javascript which is less expressive, performant, ergonomic and has a higher cognitive overhead. Today kotlinjs cannot seamlessly do that because In order to be seamless you need true js/ts compatibility the same way as Kotlin is compatible with Java. GraalVM (through a little bit of funding for maturation) polyglostism allows just that and would connect the two biggest software ecosystems in the world (so that would be two revolutionary breakthrough at once) Once those two revolutionary breakthrough are achieved that is: 1) invest in graalVM JS in order to make it mature (the implementation is already decent) 2) port graalVM inside chromium 3) enable for the first time bindings of browser APIs to another language than js (Kotlin) (webassembly cannot do that and this is the exact reason it will not really reach mainstream) Those bindings could be automated through webIDL, or through Kotlin native interop with C (as they exist to my knowledge both in C++ and in JS), or through wrappers (eventually with KotlinJS) but the most simple would be to just leverage once again graalVM compatibility between Js and Kotlin. 4) integrate this chromium fork into elektron Once this is achieved you have built the successor of electron and therefore the first truly great cross platform GUI engine since the dawn of programming. That would make JetBrains shine in all developper circles as the hero we didn't know we wanted but the one we all needed to deliver us from JS mediocrity monopoly that inflict pain on deceloppers, on performance and on software poverty (not being able to reuse the brilliant Java ecosystem). Once such a widespread success of "EleKtron" is achieved I bet that Chromium and other browsers developers would consider that after showing them the empirical evidence, that this GraalVM port would be actually an order of magnitude better webassembly (but does not obscolete webassembly for C/C++ at least not certainly) but would be the webBytecofe that truly used languages (high level ones) needs.
This Vision that I describe is arguably one of the biggest breakthrough awaiting the 21st century in programming. As explained above it would simultaneously solve extremely big problems and GraalVM has paved the way towards a solution to them. Unification of software platforms/ecosystems instead of reinventing the wheel is the big rational trends that factually save billions of human resources $ and allows qualitative synergies. Microsoft among others is adopting the premises of this Vision: E.g by migrating edge from a duplicated reimplementation of the web interfaces to improving a shared, universal implementation (chromium) JetBrains is also one of the key enterprises to share the premises of the Vision: by understanding and striving for maximal compatibility between Kotlin and the JVM ecosystem. The Vision that I have described is actually the consequence of pushing the boundaries of the JetBrains Vision!
I hope that you, engineers reading this, will talk about it internally at JetBrains and investigate if you will pursue your Vision.