The potential of Kotlin/WASM(seb.deleuze.fr)
seb.deleuze.fr
The potential of Kotlin/WASM
https://seb.deleuze.fr/the-huge-potential-of-kotlin-wasm/
7 comments
Yet most of kotlin standard library is still functions extensions to Java package classes (jvm), if you filter out the function listing in the kotlin website to only implementations common across targets (Common tag), there is very little to be usable.
It's increasingly a full stack language. I would say increasingly more so than javascript since it actually compiles down to native. So, you can use it in the browser, in the jvm, with node.js (not a great fit but it works), on edge networks or in lambda functions (with the native compiler or soon wasm), or on mobile devices.
The main things holding kotlin native back have been the compiler and the library ecosystem. The compiler has been making a lot of progress over the last two years. And the library ecosystem has a growing number of high quality multi platform libraries. So, there's less need for wheel reinvention.
Long term, given enough interest, it could start competing with Rust and Go for system programming type things. Right now, that's probably the weakest area for Kotlin but that is mostly because of the relatively immature library ecosystem around Kotlin native for this. IMHO the language actually fills a nice gap between Rust and Go. Easier than Rust, a bit more high level than Go. So far, Jetbrains seems more interested in mobile than in other use cases for kotlin native though.
Finally, Kotlin is actually a nice fit for data science jobs as well. Nicer than python to use for this and a bit less esoteric than things like Julia or R. There are some interesting libraries for Kotlin for this. But like with native this is all relatively immature and a bit niche at this point.
Some interesting things you might not be aware off:
- multi platform compose is a thing and as of recent releases it has an experimental IOS target as well. So, you can build desktop, android, web, and IOS capable applications now with using Kotlin. Unfortunately Desktop compose still depends on the JVM instead of using the native compiler. So, there's now a third alternative emerging next to Flutter and React Native for cross platform UI.
- ktor server can now be used with the native compiler. So you now have two ways of producing native binaries for ktor via graal and the kotlin native compiler. Great for use with e.g. lambda functions as well.
- kotlin scripting (KTS) is pretty nice and you can use it in more places than just Gradle. It works in Jupyter for example. Or you can generate github actions with it (we do this via krzema12/github-workflows-kt).
- you can plugin wasm to kotlin (and lots of other languages) via extism.org. Haven't tried this but looks intriguing.
The main things holding kotlin native back have been the compiler and the library ecosystem. The compiler has been making a lot of progress over the last two years. And the library ecosystem has a growing number of high quality multi platform libraries. So, there's less need for wheel reinvention.
Long term, given enough interest, it could start competing with Rust and Go for system programming type things. Right now, that's probably the weakest area for Kotlin but that is mostly because of the relatively immature library ecosystem around Kotlin native for this. IMHO the language actually fills a nice gap between Rust and Go. Easier than Rust, a bit more high level than Go. So far, Jetbrains seems more interested in mobile than in other use cases for kotlin native though.
Finally, Kotlin is actually a nice fit for data science jobs as well. Nicer than python to use for this and a bit less esoteric than things like Julia or R. There are some interesting libraries for Kotlin for this. But like with native this is all relatively immature and a bit niche at this point.
Some interesting things you might not be aware off:
- multi platform compose is a thing and as of recent releases it has an experimental IOS target as well. So, you can build desktop, android, web, and IOS capable applications now with using Kotlin. Unfortunately Desktop compose still depends on the JVM instead of using the native compiler. So, there's now a third alternative emerging next to Flutter and React Native for cross platform UI.
- ktor server can now be used with the native compiler. So you now have two ways of producing native binaries for ktor via graal and the kotlin native compiler. Great for use with e.g. lambda functions as well.
- kotlin scripting (KTS) is pretty nice and you can use it in more places than just Gradle. It works in Jupyter for example. Or you can generate github actions with it (we do this via krzema12/github-workflows-kt).
- you can plugin wasm to kotlin (and lots of other languages) via extism.org. Haven't tried this but looks intriguing.
> Finally, Kotlin is actually a nice fit for data science jobs as well. Nicer than python to use for this and a bit less esoteric than things like Julia or R.
Julia and R are esoteric? For Data Science? Also, Kotlin would be relatively low on the list of languages I would use for DS. F# is higher.
Julia and R are esoteric? For Data Science? Also, Kotlin would be relatively low on the list of languages I would use for DS. F# is higher.
For normal programmers I mean. I know lots of programmers. None of which specialize in Julia or R. They are specialist tools. Python is more a language for generalists. Which is why it is so popular in this space. Kotlin fits more in that category.
Yes please, backend people (and compiler folks) be united to try to catch up with the latest wasm proposals, we are pretty close now (also waiting for the 'stringref'). The future is treating DOM stuff as system thingy, so we can stop (except those who want to stay) writing JS/TS on the logic part. I'm optimistic we will have a better mental heath on developing web frontend in near future.
This new blog post explores the huge potential of Kotlin/Wasm and how WasmGC, WASI, WebAssembly Component Model and warg repositories could change how we develop applications.
Hello world is 1.5 MB but compiled surprisingly fast: less than a second (with grade running, couldn't test konanc -target wasm yet?)
That's much better compilation time than kotlin/native:wasm
Wasm types are currently inaccessible in JS and you can't feed js objects into wasm, hopefully that will change...
That's much better compilation time than kotlin/native:wasm
Wasm types are currently inaccessible in JS and you can't feed js objects into wasm, hopefully that will change...
Hello world with production artifact and Binaryen optimization produces a 128K Wasm file for now for https://github.com/vmware-labs/wasm-languages/tree/main/kotl..., but the Kotlin/Wasm team has not tracked those data points recently so there are likely footprint regressions to fix. The size should be even smaller. They are going to have a look and also to enable Binaryen by default for production artifacts.
nice + thanks
> But WebAssembly becomes even more interesting when you take another perspective. What if Compose for Web, the multiplatform incarnation of Jetpack Compose used on Android, would leverage Kotlin/Wasm instead of Kotlin/JS to perform pixel-perfect Canvas based rendering?
It would not really be very web like. It'd be more like Flash or a Java Applet. User extensions would all be broken.
This is a new thing coming people. Now that we have wasm, the native-app folks are super jazzed about not only switching programming langauges, but getting rid of HTML and the DOM. The plan goes: we're replacing structure markup & hypertext of webapps with just-a-bunch-of-pixels, big canvases, that are purely computational constructs. Declarative information is getting blown up by imperative processes; this is how native apps are having their revenge against webapps. I have yet to see how any of this actually empowers or helps users: it seems like a huge downgrade, done purely to give developers alternative options. Maybe the experiences really are vastly better, maybe what we make is categorically different once we have this tech! But I really have a hard time (given what creativity we've had & seeing how quickly bootcamp folks come in & get hacking on the DOM) believing the DOM is really so horrible that it justified de-internet-izing the web & that turning it into a motion picture machine is warranted (as anything more than early exploration).
The web starts with the HTML/DOM, and has been our computing world's greatest, most universal tower of Babel[1] that has held. I'm curious (and admittedly pretty terrified) to see who is happier/winners when we bring down the higher-level system, & treat it like a low level interface, like a big Canvas, like what was happening with Flash & Applets. Two other recent examples beyond Kotlin/Compose: Flutter/CanvasKit (which I commented on & got a reply from the lead about on these topics[2]), and Hixie's "Towards a Modern Web Stack"[3].
[1] https://unwindprotect.com/tower-of-babel https://news.ycombinator.com/item?id=34695638
[2] https://news.ycombinator.com/item?id=34527980
[3] https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC... https://news.ycombinator.com/item?id=34612696
It would not really be very web like. It'd be more like Flash or a Java Applet. User extensions would all be broken.
This is a new thing coming people. Now that we have wasm, the native-app folks are super jazzed about not only switching programming langauges, but getting rid of HTML and the DOM. The plan goes: we're replacing structure markup & hypertext of webapps with just-a-bunch-of-pixels, big canvases, that are purely computational constructs. Declarative information is getting blown up by imperative processes; this is how native apps are having their revenge against webapps. I have yet to see how any of this actually empowers or helps users: it seems like a huge downgrade, done purely to give developers alternative options. Maybe the experiences really are vastly better, maybe what we make is categorically different once we have this tech! But I really have a hard time (given what creativity we've had & seeing how quickly bootcamp folks come in & get hacking on the DOM) believing the DOM is really so horrible that it justified de-internet-izing the web & that turning it into a motion picture machine is warranted (as anything more than early exploration).
The web starts with the HTML/DOM, and has been our computing world's greatest, most universal tower of Babel[1] that has held. I'm curious (and admittedly pretty terrified) to see who is happier/winners when we bring down the higher-level system, & treat it like a low level interface, like a big Canvas, like what was happening with Flash & Applets. Two other recent examples beyond Kotlin/Compose: Flutter/CanvasKit (which I commented on & got a reply from the lead about on these topics[2]), and Hixie's "Towards a Modern Web Stack"[3].
[1] https://unwindprotect.com/tower-of-babel https://news.ycombinator.com/item?id=34695638
[2] https://news.ycombinator.com/item?id=34527980
[3] https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC... https://news.ycombinator.com/item?id=34612696
One thing I don't see discussed much is how much users are empowered by being able to inspect the JavaScript that is sent to their machine. I can inspect every line of code before it executes. I can look at exactly what data is being stored client side and modify it if I wish. The client side of apps are forced to be open source. Every major browser has excellent developer tools built in that allows us to do this. I'm not sure how much of this will be taken away by WASM. Or if it will hinder my ability to prevent exfiltration of my private data.
Minified JS and backend APIs foil this. You download a dozen blobs of junk that all calls back to an app server for its persistence. If you could save the JS you get from gmail or google docs and host it locally I'd be convinced, but we both know that's impossible.
This is posed as a pretty heavy counter, "[X] foils this," but it's only been to degrees so far, and the extent we've gone is radically different where we're headed. Certainly hacking modern webapps isn't always the most fun, but often it can be! Even if the app in question is pretty shitty & mean about how they distribute their bundles.
Backend APIs have often been one of the webs best points, not it's hinderances, in terms of explorability. Certainly it conceals what happens behind the scenes, but the "single page app" model leaves an intrepid DevTool user with at least as much power as whatever the webapps inbuilt capabilities are, and far less handcuffs. Huge numbers of sites have "unofficial" clients, since it's so stupidly easy to open devtools, look at network traffic, and write some instrumentation/alter stuff around a little and see what you get. Since the normal app behavior has to transit a network barrier, and that's quite visible, it very quickly lights up & shows the interface. Where-as in many native apps, state is just latent in the process, suffused everywhere, & deeply murky & unclear. There's a lot we don't know, but there's also so much clarity that the front-end/back-end client/server split has given us, that computing typically hasn't had.
Less web-ish things can be problematic. Folks who just open websockets & start speaking TCP protocols aren't very "web" (even though they use a tool the web happens to have). GraphQL is maybe somewhere inbetween: there's still enough regular evidence/it kind of fits the form, but everything is a little different & normal webdev tools need a lot of extra help to do ok. GraphQL is a partial stray from the core webdev path (for example, it doesn't use URLs for endpoint nor it's content).
Ideally everyone should ship source maps. But there's a lot of negative behaviors against this, mostly for no real good cause. Just turning on the pretty-printer for the mangled/uglified source code, & debugging some DOM events is often enough to figure out what a thing does pretty quickly, to get into the architecture pretty easily, even when it is all minified. Often the minification is only partial, only extends so far, as we talk to data sources & storage; we can start to see properties & json that look regular, that give us meaning & clues. Minification mainly serves the users, by being very mildly smaller than compression; rarely is it an active defense again comprehension, and rarely is that active defense effective; everything is too much the same, the patterns are all common, the platform is all normal.
How close or how far we stray from Babel matters. "The platform is all normal" is being put to the sword by these upstarts, with amazing zeal & excitement. There are absolutely going to be tons of good normal not too wild webassembly codebases out there that at least leave the web platform as primary, that are advanced & not javascript but are at least web-like, and that'll be a bit harder to understand & decrypt & learn about (to perform natural science on). Understanding these is going to require a more advanced capability. It'll feel a bit more like breaking out Ghidra & wandering in (https://github.com/NationalSecurityAgency/ghidra), than DevTools, even with the most minified websites we have today.
But there are also going to be countless new virtualizing universes of compute that simply do not care at all, that are micosms until themselves: Inland Empires, as Disco Elysium characterized. The level of Ghidra disassembly skills required to get anywhere is going to be expontentially higher in many wasm realms.
Wasm is a big turning point, is definitely a fall of Babel. Others have pointed out & absolutely right, many many wasm users will still embrace the web platform, it's higher level "text/html" mime-type underpinning, it's apis. Wasm will amplify the challenge, even here. Right now there's a ton of glue-code projects- Rust's wasm-bindgen is a big glue-maker, and simply wrapping our heads around the multi-verse of code-spaces running, wasm-bindgen bridging us between page space and wasm code space, is going to be an intense new experience, but in many cases it will be fine & managable. DevTools will help. Hopefully source-maps come into vogue somehow. But there will also be uncountable infinite reaches of virtualization, where people are just off doing something entirely different & else, where disassembly requires understanding mountains of virtual machine & rendering engines to get anywhere, where nothing makes sense, and reason & natural science & understandability of the world about us is truly lost.
There are challenges today, but it's overall ok, and tomorrow looks harder, but there's still lots of room for hope, but there are also spreading reaches of dark, where it's likely understanding what happens will converge with impossibility. The web today is murky, but in no way resembles that darkening. We've been exploring lands around Babel for a long time, but there are some quite severe marches into the far beyond, and in some ways, yea, I am excited to see what folks make when unconstrained, but the understandability of the universe about us also ranks high in my priorities, and the web still has a stunning truthfulness & earnest & directness far far surpassing anything else available in computing that is notable & alive (if maybe not exactly well), and I want to see that espoused & embraced if we do want to explore reaches beyond (and I don't see that value anywhere else presently).
Backend APIs have often been one of the webs best points, not it's hinderances, in terms of explorability. Certainly it conceals what happens behind the scenes, but the "single page app" model leaves an intrepid DevTool user with at least as much power as whatever the webapps inbuilt capabilities are, and far less handcuffs. Huge numbers of sites have "unofficial" clients, since it's so stupidly easy to open devtools, look at network traffic, and write some instrumentation/alter stuff around a little and see what you get. Since the normal app behavior has to transit a network barrier, and that's quite visible, it very quickly lights up & shows the interface. Where-as in many native apps, state is just latent in the process, suffused everywhere, & deeply murky & unclear. There's a lot we don't know, but there's also so much clarity that the front-end/back-end client/server split has given us, that computing typically hasn't had.
Less web-ish things can be problematic. Folks who just open websockets & start speaking TCP protocols aren't very "web" (even though they use a tool the web happens to have). GraphQL is maybe somewhere inbetween: there's still enough regular evidence/it kind of fits the form, but everything is a little different & normal webdev tools need a lot of extra help to do ok. GraphQL is a partial stray from the core webdev path (for example, it doesn't use URLs for endpoint nor it's content).
Ideally everyone should ship source maps. But there's a lot of negative behaviors against this, mostly for no real good cause. Just turning on the pretty-printer for the mangled/uglified source code, & debugging some DOM events is often enough to figure out what a thing does pretty quickly, to get into the architecture pretty easily, even when it is all minified. Often the minification is only partial, only extends so far, as we talk to data sources & storage; we can start to see properties & json that look regular, that give us meaning & clues. Minification mainly serves the users, by being very mildly smaller than compression; rarely is it an active defense again comprehension, and rarely is that active defense effective; everything is too much the same, the patterns are all common, the platform is all normal.
How close or how far we stray from Babel matters. "The platform is all normal" is being put to the sword by these upstarts, with amazing zeal & excitement. There are absolutely going to be tons of good normal not too wild webassembly codebases out there that at least leave the web platform as primary, that are advanced & not javascript but are at least web-like, and that'll be a bit harder to understand & decrypt & learn about (to perform natural science on). Understanding these is going to require a more advanced capability. It'll feel a bit more like breaking out Ghidra & wandering in (https://github.com/NationalSecurityAgency/ghidra), than DevTools, even with the most minified websites we have today.
But there are also going to be countless new virtualizing universes of compute that simply do not care at all, that are micosms until themselves: Inland Empires, as Disco Elysium characterized. The level of Ghidra disassembly skills required to get anywhere is going to be expontentially higher in many wasm realms.
Wasm is a big turning point, is definitely a fall of Babel. Others have pointed out & absolutely right, many many wasm users will still embrace the web platform, it's higher level "text/html" mime-type underpinning, it's apis. Wasm will amplify the challenge, even here. Right now there's a ton of glue-code projects- Rust's wasm-bindgen is a big glue-maker, and simply wrapping our heads around the multi-verse of code-spaces running, wasm-bindgen bridging us between page space and wasm code space, is going to be an intense new experience, but in many cases it will be fine & managable. DevTools will help. Hopefully source-maps come into vogue somehow. But there will also be uncountable infinite reaches of virtualization, where people are just off doing something entirely different & else, where disassembly requires understanding mountains of virtual machine & rendering engines to get anywhere, where nothing makes sense, and reason & natural science & understandability of the world about us is truly lost.
There are challenges today, but it's overall ok, and tomorrow looks harder, but there's still lots of room for hope, but there are also spreading reaches of dark, where it's likely understanding what happens will converge with impossibility. The web today is murky, but in no way resembles that darkening. We've been exploring lands around Babel for a long time, but there are some quite severe marches into the far beyond, and in some ways, yea, I am excited to see what folks make when unconstrained, but the understandability of the universe about us also ranks high in my priorities, and the web still has a stunning truthfulness & earnest & directness far far surpassing anything else available in computing that is notable & alive (if maybe not exactly well), and I want to see that espoused & embraced if we do want to explore reaches beyond (and I don't see that value anywhere else presently).
I fail to see how some compiled, minified js is any better than wasm code.
The difference between having, say, C++ code where the variable names are scrambled versus having assembly seems vastly different to me. And that parallel seems 100% accurate here. JS may be minified but you still are reading the cide that was written, where-as no one seriously authors wasm; it's a lower level (virtual) machine.
And it's worse. Because wasm is a separate process, so now there's multiple things to debug & learn. Tools like wasm-bindgen generate complex glue code to bridge wasm and the host/js side. The wasm-verse brings a ton of new challenges to legibility.
Learning minified bundled js codebases can be daunting at first, but it's ultimately js, most often built with normal-ish stacks, and the code usually shows it's nature pretty quickly after setting some DOM event breakpoints. It's nowhere near the joy of view source, but it's not bad.
Notably Chrome m111 just turned on pretty printing by default, so the first couple milliseconds of opening the debugger should be significantly less overwhelming. You used to have to know to press the prettify button.
And it's worse. Because wasm is a separate process, so now there's multiple things to debug & learn. Tools like wasm-bindgen generate complex glue code to bridge wasm and the host/js side. The wasm-verse brings a ton of new challenges to legibility.
Learning minified bundled js codebases can be daunting at first, but it's ultimately js, most often built with normal-ish stacks, and the code usually shows it's nature pretty quickly after setting some DOM event breakpoints. It's nowhere near the joy of view source, but it's not bad.
Notably Chrome m111 just turned on pretty printing by default, so the first couple milliseconds of opening the debugger should be significantly less overwhelming. You used to have to know to press the prettify button.
Thanks for writing. I've not really thought about it before, but you're pretty correct in your analysis. For example, I followed through the links to a flutter demo [1] and you get something that looks like a standard web page but you can't select the text, because it's rendered on a canvas. This is taking away a really important aspect of control that we currently have over our browser experience. I can see this being used to force us to view ads that we can no longer block, prevent us writing extensions that modify the view as we like, etc.
[1] https://flutter-forward-demos.web.app/#/
[1] https://flutter-forward-demos.web.app/#/
What does it really offer? Performance and flexibility? It will probably continue to be a niche for really specific high performance applications but the DOM will always exist as long as 99% of the internet is just viewing or uploading text/images/videos.
The amount of experience and knowledge that has gone into fixing edge cases like accessibility, viewports, cross-browser support, security, etc. makes any kind of 'pure wasm' app a nightmare to maintain.
The amount of experience and knowledge that has gone into fixing edge cases like accessibility, viewports, cross-browser support, security, etc. makes any kind of 'pure wasm' app a nightmare to maintain.
> What does it really offer?
While it really is bad, it offers things that need to be reimplemented by everyone from scratch if they go with Canvas, WebGL or WebGPU such as:
- accessibility
- text rendering (including proper font rendering, LTR text, multilanguage text, text selection etc.)
- even smaller things like tabindex
While it really is bad, it offers things that need to be reimplemented by everyone from scratch if they go with Canvas, WebGL or WebGPU such as:
- accessibility
- text rendering (including proper font rendering, LTR text, multilanguage text, text selection etc.)
- even smaller things like tabindex
Not everyone, only the frameworks that matter.
Qt, Uno, Blazor, Flutter,...
Get ready for the revenge of plugins.
Qt, Uno, Blazor, Flutter,...
Get ready for the revenge of plugins.
Blazor notably is not supplanting the page/dom/GUI at this point, afaik. Their main target has been HTML/DOM/CSS. The new "Blazor United"[1] push adds a lot more wasm/ is kind of a Combining Mecha of technologies, but still is an actual mime-type text/html app system. Microsoft was lucky/smart/right-place-right-time or some combo, & snapped up Steve Sanderson after his great Knockout framework & he's been helping them keep the compass oriented since, & giving demos/leading the way. Microsoft has done well trying to play nicely in the fold, build trust, rather than redefine/reshape/dominate/exploit the web, which has been a good move imo.
It amazing to me how much the phrase "pixel perfect" seems to excite most of the crowd you cite. Notably absent on Qt's site but basically implied. Uno, Flutter, Kotlin's Compose pitch... it's in the headline pitches, is the top bullet point, and I'm not really sure what it says to me. Is that level of absolutist & total top-down control an objective for computers & our human infosphere?
[1] https://visualstudiomagazine.com/articles/2023/02/03/blazor-... https://news.ycombinator.com/item?id=34645558
It amazing to me how much the phrase "pixel perfect" seems to excite most of the crowd you cite. Notably absent on Qt's site but basically implied. Uno, Flutter, Kotlin's Compose pitch... it's in the headline pitches, is the top bullet point, and I'm not really sure what it says to me. Is that level of absolutist & total top-down control an objective for computers & our human infosphere?
[1] https://visualstudiomagazine.com/articles/2023/02/03/blazor-... https://news.ycombinator.com/item?id=34645558
The web does not start with the DOM, that was exposed later when web devs started insisting on being able to do things not possible with HTML+CSS directly.
And yes, some native devs are looking at wasm as "it's just a big canvas with its own bytecode interpreter and access to 95% of the system API that I need". There's one and only one reason for that: the simplicitly of distributing software to users when it is "in the browser".
I don't want a DOM when I'm porting my DAW to the browser, and I'm pretty sure you don't me to use that way either.
And yes, some native devs are looking at wasm as "it's just a big canvas with its own bytecode interpreter and access to 95% of the system API that I need". There's one and only one reason for that: the simplicitly of distributing software to users when it is "in the browser".
I don't want a DOM when I'm porting my DAW to the browser, and I'm pretty sure you don't me to use that way either.
> I don't want a DOM when I'm porting my DAW to the browser, and I'm pretty sure you don't me to use that way either.
Actually we do want you to use the DOM. Use the DOM for everything except the parts that are highly graphical, i.e. rendering waveforms where it makes sense to use cavas. Most of a DAW is just normal controls and we want those to be accessible, readable, and potentially extendable.
Actually we do want you to use the DOM. Use the DOM for everything except the parts that are highly graphical, i.e. rendering waveforms where it makes sense to use cavas. Most of a DAW is just normal controls and we want those to be accessible, readable, and potentially extendable.
normal controls? they might look like normal controls, but they frequently do not act like it. trivial example: tri-state buttons. the UI interaction model for most audio app controls is typically a lot richer than is found in desktop and web development. a more major issue: MVC confusion, which is hard enough in native. Example: dragging something in the UI, but the model is too heavyweight to update directly, which requires the UI to no longer represent the model (for a while, at least).
As for the waveforms, those are just images too (they have to be, to make rendering efficient enough, even for native).
Apple understood the differences: almost none of their creative software (for desktop) is written using standard Apple toolkits (and no, it's not just because they purchased Logic from Emagic and Emagic had been bad).
As for the waveforms, those are just images too (they have to be, to make rendering efficient enough, even for native).
Apple understood the differences: almost none of their creative software (for desktop) is written using standard Apple toolkits (and no, it's not just because they purchased Logic from Emagic and Emagic had been bad).
A tri-state button is hardly an unusual design to find in web software
You're right, but I wouldn't really consider this sort of thing to be a "normal control". I get that you can implement it "only" with HTML+CSS+JS, which is probably better than as a canvas thing, but there's really no basic concept for such a thing without JS hacking, at least not as far as I could tell.
Yes what you say is true and lamentable, although I don't consider using JS to be hacking it up. At this point JS is really embedded in the model of the web rather than just a sprinkle on the top.
I had hopes for webcomponents. They do work OKish, but it's harder to make and distribute a webcomponent than make a similar thing in React and that sucks.
So yah, I can see your view, but I'm still not OK with the idea of canvas based apps replacing DOM ones. I think its like the old macromedia flash model, a part of the app you cannot interactive with the same, no text selection if the dev decides to not implement that, no content blocking so we'll get ads shoved down our throat again, poorer accessibility, closed frameworks. All that kind of jazz.
I had hopes for webcomponents. They do work OKish, but it's harder to make and distribute a webcomponent than make a similar thing in React and that sucks.
So yah, I can see your view, but I'm still not OK with the idea of canvas based apps replacing DOM ones. I think its like the old macromedia flash model, a part of the app you cannot interactive with the same, no text selection if the dev decides to not implement that, no content blocking so we'll get ads shoved down our throat again, poorer accessibility, closed frameworks. All that kind of jazz.
Well, I've spent 23 years developing an open source, cross-platform DAW, and so my interest in such things has nothing to do with ads or any of that stuff.
But yes, that's certainly is a risk of creating a mostly non-viewable VM inside the browser, even if that does effectively create a new platform for development that will ultimately have little or nothing to do with traditional webdev.
But yes, that's certainly is a risk of creating a mostly non-viewable VM inside the browser, even if that does effectively create a new platform for development that will ultimately have little or nothing to do with traditional webdev.
As mentioned in the post, one of the big wins for a lot of web developers is freedom from Javascript. It doesn't necessarily mean throwing out the DOM by default.
Compose for Web has a DOM toolkit as well as one that renders to Canvas. The Canvas toolkit lets you share code with Android and desktop JVM via the Compose UI libraries. The DOM toolkit renders to DOM nodes with its own API and minimal widget library.
Having worked on a multiplatform Compose project, I would recommend rendering to platform-native UI if possible. Compose feels like a weird Electron UI on desktop, and it doesn't fit in with the native look and feel. The code reuse aspect is tempting, but you will be plumbing tons of glue interfaces for anything more intensive than a to-do app.
Compose itself is fantastic, and it's general enough to target a wide array of native UIs with different execution paradigms.
Having worked on a multiplatform Compose project, I would recommend rendering to platform-native UI if possible. Compose feels like a weird Electron UI on desktop, and it doesn't fit in with the native look and feel. The code reuse aspect is tempting, but you will be plumbing tons of glue interfaces for anything more intensive than a to-do app.
Compose itself is fantastic, and it's general enough to target a wide array of native UIs with different execution paradigms.
This feels like a good development! I hope devs actually do opt to relinquish "pixel-perfect" control (as this post & numerous other projects cite) for "text/html" intercompatibility; it's unknown atm. Im not really conviced projects even have to give up that much control/exactness to have a html/dom render target... it's heartening to hear at least one native world framework even bother to try & fit in, especially given how low it feels the lift should be. Good report! Thanks! But it does still seem contrary to the spirit of this post; Im glad to hear there's better/more respectfully positioned attempt, very glad, but the danger still seems ultra-real.
For most of the similar frameworks exploring making the web a target, there is zero interest or care in "text/html". Flutter, Qt, Uno: they come bearing no gifts, no respect, simply seeing the web's very lowest levels as an efficiently accessible delivery target they can exploit, & they have zero compunctions about ignoring the 99.9999% of the web stack that all other sites use in favor of the low level graphical interfaces.
For most of the similar frameworks exploring making the web a target, there is zero interest or care in "text/html". Flutter, Qt, Uno: they come bearing no gifts, no respect, simply seeing the web's very lowest levels as an efficiently accessible delivery target they can exploit, & they have zero compunctions about ignoring the 99.9999% of the web stack that all other sites use in favor of the low level graphical interfaces.
fwiw, for one mainstream example the Blazor .NET stack is very much about using the DOM, HTML, and full set of browser APIs, not about creating a special VM+canvas sandbox where accessibility tools and ad-blockers can't reach. There are definitely big companies out there who see an impervious sandbox as a feature, but a lot of WASM-targeting technologies are not that and we should be encouraging those developers to keep enhancing the web.
This is indeed a very important point, and I care deeply about that.
For Compose for Web, there has been I think a lot of debate to decide if the Web rendering should be Canvas or DOM based. At least for now, it seems the official support is focusing on Canvas rendering for pixel-perfect rendering, and it already works with Koltin/Wasm, see https://twitter.com/bashorov/status/1625437131706363904. This choice is probably driven by Kotlin current mobile app main use case.
But via community-driven project like https://github.com/varabyte/kobweb or https://github.com/mpetuska/kmdc, Compose for Web can also be a good Web citizen and perform DOM based rendering.
For Compose for Web, there has been I think a lot of debate to decide if the Web rendering should be Canvas or DOM based. At least for now, it seems the official support is focusing on Canvas rendering for pixel-perfect rendering, and it already works with Koltin/Wasm, see https://twitter.com/bashorov/status/1625437131706363904. This choice is probably driven by Kotlin current mobile app main use case.
But via community-driven project like https://github.com/varabyte/kobweb or https://github.com/mpetuska/kmdc, Compose for Web can also be a good Web citizen and perform DOM based rendering.
> This is a new thing coming people.
What? The canvas is not new, you've been able to dump the DOM and make canvas-only UI for many years.
The "new thing" is just improved code sharing if you are making a canvas-y thing for multiple platforms. And letting people use their preferred language if not JavaScript.
What? The canvas is not new, you've been able to dump the DOM and make canvas-only UI for many years.
The "new thing" is just improved code sharing if you are making a canvas-y thing for multiple platforms. And letting people use their preferred language if not JavaScript.
This defense that Canvas exists therefore replacing high level shared web constructs used for nearly ALL interaction on the web with the lowest possible level thing the web has (pixels) seems to spring up a lot.
It doesn't seem like much of a defense to me, that a graphical target used to enable WebGL and generative graphics to exists- to enable some creative options- doesn't seem to imply it's good to replace all structured hypertext markup with pixels.
Google Sheets and Figma are the only two webapps I can name that rebuilt with heavy Canvas components, and Sheets getting rid of DOM broke a ton of crafty web extensions/userscripts & pissed a lot of people off. Sheets is also mostly HTML still, except the spreadsheet itself, because it means people's tools & extensions for many things still work & because it's a fine technology for developing almost all webapps in.
It doesn't seem like much of a defense to me, that a graphical target used to enable WebGL and generative graphics to exists- to enable some creative options- doesn't seem to imply it's good to replace all structured hypertext markup with pixels.
Google Sheets and Figma are the only two webapps I can name that rebuilt with heavy Canvas components, and Sheets getting rid of DOM broke a ton of crafty web extensions/userscripts & pissed a lot of people off. Sheets is also mostly HTML still, except the spreadsheet itself, because it means people's tools & extensions for many things still work & because it's a fine technology for developing almost all webapps in.
As someone that enjoyed Flash tooling, I welcome the plugins revenge.
10 years were more than enough to ship comparable tooling.
It was the browser makers that opened the pandora box, by providing the tooling to get our plugins back.
10 years were more than enough to ship comparable tooling.
It was the browser makers that opened the pandora box, by providing the tooling to get our plugins back.
I don't know if anyone else had the idea yet, but I would love to use Kotlin with Svelte on the frontend.
I would love to see a Svelte-like frontend framework natively designed for Kotlin/Wasm, not necessarily another Kotlin to JavaScript binding that feels like a second class citizen.
At some point someone will figure out the wire up between the reactive part (thing like "signal") on wasm side and and propagate changes to the effect side to render DOM nodes.
It's been exciting to watch the development of the new K2 compiler and Frontend-IR format
Kotlin is no longer just a JVM language, but more like a frontend with targets that now span everything from JVM bytecode, JavaScript, native code with Kotlin Native, and WASM
I'm really excited to see what the future holds for Kotlin and WASM in particular