Earlier quoted context omitted.
> 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…
The potential of Kotlin/WASM
21–30 of 46 posts
Re: The potential of Kotlin/WASM
#22That'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...
Re: The potential of Kotlin/WASM
#23Earlier quoted context omitted.
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…
A tri-state button is hardly an unusual design to find in web software
Re: The potential of Kotlin/WASM
#24> 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'…
Re: The potential of Kotlin/WASM
#25Earlier quoted context omitted.
> 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.
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
Re: The potential of Kotlin/WASM
#26Earlier quoted context omitted.
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'…
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.
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).
Re: The potential of Kotlin/WASM
#27Earlier quoted context omitted.
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.
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.
Re: The potential of Kotlin/WASM
#28Thank 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
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.
Re: The potential of Kotlin/WASM
#29> 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…
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.
Re: The potential of Kotlin/WASM
#30Earlier quoted context omitted.
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…
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.