Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The potential of Kotlin/WASM

seb.deleuze.fr

Post reply on HN
Print view View original

11–20 of 46 posts

Re: The potential of Kotlin/WASM

#11

Post by rektide »

brianslp wrote: post #9
rektide wrote: post #5

> 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 peopl…

> 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.

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.

Re: The potential of Kotlin/WASM

#12

Post by kevingadd »

rektide wrote: post #5

> 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 peopl…

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.

Re: The potential of Kotlin/WASM

#13

Post by cgh »

rektide wrote: post #5

> 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 peopl…

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.

Re: The potential of Kotlin/WASM

#14

Post by pjmlp »

dmitriid wrote: post #10
ericmcer wrote: post #7

Earlier quoted context omitted.

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 '…

> 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

Not everyone, only the frameworks that matter.

Qt, Uno, Blazor, Flutter,...

Get ready for the revenge of plugins.

Re: The potential of Kotlin/WASM

#15

Post by pjmlp »

rektide wrote: post #5

> 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 peopl…

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.

Re: The potential of Kotlin/WASM

#16

Post by Jaygles »

rektide wrote: post #5

> 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 peopl…

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.

Re: The potential of Kotlin/WASM

#17

Post by PaulDavisThe1st »

rektide wrote: post #5

> 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 peopl…

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.

Re: The potential of Kotlin/WASM

#18

Post by jemmyw »

rektide wrote: post #5

> 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 peopl…

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/#/

Re: The potential of Kotlin/WASM

#19

Post by jemmyw »

PaulDavisThe1st wrote: post #17
rektide wrote: post #5

> 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 peopl…

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 "i…

> 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.

Re: The potential of Kotlin/WASM

#20

Post by PaulDavisThe1st »

jemmyw wrote: post #19
PaulDavisThe1st wrote: post #17

Earlier quoted context omitted.

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 "i…

> 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.

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).

Post reply on HN