[HN Gopher] The potential of Kotlin/WASM
___________________________________________________________________
The potential of Kotlin/WASM
Author : bouiaw
Score : 36 points
Date : 2023-02-13 20:18 UTC (2 hours ago)
(HTM) web link (seb.deleuze.fr)
(TXT) w3m dump (seb.deleuze.fr)
| bouiaw wrote:
| 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.
| rektide wrote:
| > _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
| pjmlp wrote:
| 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.
| PaulDavisThe1st wrote:
| 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.
| Jaygles wrote:
| 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.
| kevingadd wrote:
| 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.
| brianslp wrote:
| > 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.
| rektide wrote:
| 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.
| cgh wrote:
| 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.
| ericmcer wrote:
| 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.
| dmitriid wrote:
| > 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
| pjmlp wrote:
| Not everyone, only the frameworks that matter.
|
| Qt, Uno, Blazor, Flutter,...
|
| Get ready for the revenge of plugins.
| jemmyw wrote:
| 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/#/
| slim wrote:
| disappointed that gilles.deleuze.fr does not get you anywhere
| gavinray wrote:
| Thank you for the work on KoWasm
|
| 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
| flykespice wrote:
| 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.
| brianslp wrote:
| Due to the nature of being a frontend-for-everything I think
| it's best to keep the stdlib's platform-specific
| functionality minimal.
___________________________________________________________________
(page generated 2023-02-13 23:01 UTC)