9 ms·
There's nothing transparent or discoverable about minified javascript for the average spaghetti ball code base for a typical SPA. Except for a small minority, m
by jillesvangurp 3y ago
There's nothing transparent or discoverable about minified javascript for the average spaghetti ball code base for a typical SPA. Except for a small minority, most web developers treat browser javascript as a compilation target.
WASM simply is a better compilation target. More general purpose, easier to optimize, more compact, can load incrementally, etc. If you are going to compile your code anyway, you might as well use a proper compilation target if you have the choice.
More generally, I think WASM is starting to challenge the whole "there can only be DOM/CSS/JS" thing that has held web developers back for two decades. It was fine when that was the only thing that worked but there's a reason mobile developers, game developers, etc. prefer native: the web sucks. There has always been this creative tension between what designers want and what the web can do. We used to have things like Flash, Shockwave, and Silverlight. HTML 5 has largely failed to replace those. We deprecated the plugins for security reasons. But we never got a decent replacement.
With WASM there's no good reason left to keep on preferring DOM/CSS/JS. It's there if you want to, but there are some alternatives now. In its current state, that still requires things like C++ and Rust.
But WASM is maturing rapidly. There are a bunch of things behind feature flags in browsers (like the new GC stuff) that will level the playing field once those flags get removed. From there, it's mainly a matter of UI frameworks and tool chains that need adapting. Jetbrains is actually targeting wasm with compose multi platform. It renders to a canvas. Currently experimental and it only works if you set some feature flags on your browser. But it allows for portable UI development with Compose and allows you to target Android, IOS (alpha release), Desktop (jvm), and soon Web via wasm with the same codebase. There are probably other UI stacks that might soon start targeting web. Blazor of course was an early adopter but it ships its own GC and that makes for a bit chunky apps. And of course there is a wasm based replacement for Flash.
HTML 5 is no longer the only game in town. It will have to compete on merit now instead of merely holding a de-facto monopoly.
- js8 3y agoDo you know of any good tutorials how to create a pure webassembly application that can run on Android?
- jillesvangurp 3y agoAnything that runs in chrome will run on chrome on Android as well. And possibly Safari on IOS (they drag their heels with implementing new wasm features). So no need for Android specific tutorials here.
- jeroenhd 3y agoI've used the Javascript debugger in Firefox to alter minified JS all the time. They can rename their methods all they want but without intentional obfuscation (in which case, fuck you) reading minified JS isn't really all that bad. Firefox even has some built-in detections of common web frameworks that work fine with most minified code. We're going to need a pretty advanced WASM decompiler suite built into the browser before I'll accept it as just as opaque as Javascript. I despise the WASM web application platform and its blatant <canvas> abuse. It's building a browser inside of a browser to save developers time, and every time web pages become slower and worse to use because of it. React (Native) did cross platform app+web development years ago without downloading several megabytes of executable blobs for every page you visit. WASM is just Java applets and Flash embeds, but invented for the fourth time. They have the same problems and will inevitably cause the same slowdown and headaches a few years from how. The only difference for developers is that you can now use Rust to write them and that your users can't turn off loading your binary blobs.
- cxr 3y ago> HTML 5 is no longer the only game in town. It will have to compete on merit now instead of merely holding a de-facto monopoly. Your position is that Flash didn't compete (and lose) on merit?
- jillesvangurp 3y agoSteve Jobs blocked it from the Apple Store because Apple didn't invent Flash and he just did not like anything from outside Apple. For the same reason, you can't use the Firefox or Chrome browser engines on IOS. You just have to use Safari. Even if you are Mozilla and you are shipping Firefox to the Apple store. And I guarantee you this isn't because Mozilla thinks Safari is the better browser engine. After that, security concerns lead to browsers eventually deprecating their plugin support. But it started with Flash getting a huge access denied on mobile, courtesy of Steve Jobs. So, Flash became a lot less popular after that and Apple and Google successfully transitioned a lot of that stuff to their native mobile SDKs. That's why you have lots of games on IOS and Android and not a whole lot on the web these days. HTML 5 is hopelessly clumsy for that sort of thing. A lot of the stuff people did with Flash is of course technically doable with HTML5 but mostly it seems designers shy away from doing those things because it's too hard. Wasm is going to open up a lot of native and mobile SDKs for the web. And the web of course also works on mobile. There might even come an end to Apple blocking non-safari browsers in their app store.
- troupo 3y ago> Steve Jobs blocked it from the Apple Store because Apple didn't invent Flash and he just did not like anything from outside Apple. Or... he blocked it because of all the actual reasons listed when Flash was blocked? And the same reasons why it was blocked on Android just a year or so later?
- lenkite 3y agoNah - both Apple and Google realized that Flash was a threat to their nice, walled gardens and ensured it died. You gottu have those chains secured tight.
- mike_hearn 3y agoThere are some specific technical issues with replacing DOM/CSS within the context of a web browser. I worked through a lot of them as a fun mental exercise some months ago, but didn't get all of them, and ended up concluding that you can't fix it because it's against the incentives of browser makers. You could make a new web-like thing though: https://docs.google.com/document/d/1oDBw4fWyRNug3_f5mXWdlgDI4J5AbxVWKEeYr6hscT8/edit?usp=sharing https://docs.google.com/document/d/1oDBw4fWyRNug3_f5mXWdlgDI... Some of the outstanding issues still to figure out: • Autofill. Users want browsers to be able to autofill/autocomplete things, but without that leaking personal data to sites unexpectedly (i.e. the content needs to look present but can only actually be present from the API perspective once the user has confirmed they want it). • Secure composition/iframes. Essential for anything with ads, social buttons and some other use cases. Yes, you can define ads as being out of scope but then a lot of people won't bother to learn your new framework because it will be less general. Ultimately, the technical problems are severe enough that WASM frameworks will be of limited use, quite possibly forever. It's just not in the interests of browser makers to disintermediate themselves like that. You can get a long way by blending DOM widgets with other stuff though.
- layer8 3y agoYou’d really need integration with OS APIs, for accessibility. Effectively, you need some sort of cross-platform UI framework, and we all (should) know that that’s highly nontrivial.
- mike_hearn 3y agoAccessibility isn't that hard for the common cases, and the DOM doesn't handle the uncommon cases anyway. There are x-platform UI frameworks out there. Making good ones is hard but again, HTML is not a good UI framework by any measure. Normally UI toolkits are compared based on the breadth and depth of their control library but HTML barely tries to compete in that realm. It prefers to focus on things like advanced typography.
- layer8 3y ago
- paulhodge 3y ago> More generally, I think WASM is starting to challenge the whole "there can only be DOM/CSS/JS" thing that has held web developers back for two decades. No one was held back, people keep choosing the web because it's consistently better. What I think is crazy is this drive to take something that is working great (the Web), and then jam in an approach that has already failed multiple times. We already tried several iterations of binary-heavy, non-transparent, non-searchable, non-web-native, second-ecosystem application platforms including Java Applets, Flash, Silverlight, etc. They had a chance and users rejected them. If you think the web sucks, then by all means, I encourage you to make a compelling alternative. If it really is better then people will use it. But maybe don't try to spoil the working recipe of HTML/CSS/JS, especially if you don't fully understand the reasons why it keeps winning.
- anononaut 3y agoI think this is a strong argument for the need for something like Applets, Flash, and Silverlight to be an open standard. I appreciate the argument you make, but I think the simple counter argument is the ability for the framework to be modified at the developers' collective whim rather than corporate concerns.
- troupo 3y ago> No one was held back, people keep choosing the web because it's consistently better. It's not consistently better. It's just marginally easier to develop simple things for. > They had a chance and users rejected them. Users rejected them because they were slow, bloated, and didn't play nice with a lot of things. Fast-forward to 2023, and users have embraced mobile apps (and not mobile web/PWA crap that we're told is about to get just as good as apps any time now). > If you think the web sucks, then by all means, I encourage you to make a compelling alternative. It's already there. It's called apps.