While JavaScript is a terrible language, WASM will lead to web apps being less transparent, less “discoverable”, because the executable format is binaries instead of source code.
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.
I'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.
There 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:
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.
You’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.
Accessibility 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.
I agree that HTML is not a good UI framework, but I’d be worried that it’ll get even worse with WASM cook-your-own. It’s certainly debatable how much is needed to be “good enough”, but I’d be surprised if it weren’t a downgrade from the standard of native desktop apps. And that’s not a UI future I’d want to live in, as a user.
> 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.
> 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.
I 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.
Steve 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.
> 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?
Nah - 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.
It was widely established fact at the time that Flash was a bug-ridden resource-hungry hog. Which was fine for desktop, but not for the severely underpowered mobile devices of the day.
I mean, it's not ancient history. It only happened 10 years ago.
Nah, now you are re-writing history. Flash apps could be very lean and mean or they could be resource hogs - depending on the amount of bling one put in. They could be used to develop sophisticated, lean apps using a very productive toolchain. They were an extraordinary danger to the Apple apps paradigm. And they thus needed to be terminated with extreme prejudice.
And the fact was that Steve Jobs had a history and long habit of forcing walled gardens on consumers - something well known in that era.
Of-course most of this depends on whether you had personal experience developing productive flash apps and whether one suffers from the Apple propaganda effect - where Apple's position is King and all other positions are null and void. I happen to see the latter quite often on HN.
Troupo is citing facts, you're citing incentives/habits. While incentives are powerful and those habits have been borne out repeatedly by Apple, one of you has the clearly more documented argument. To be convincing, you need to demonstrate that Apple chose to deprecate Flash to help establish a walled garden. You've shown that they'd probably _want_ to, but that's still one step away.
Aah..you are asking for documented, formal evidence. Unless someone leaks the trove of internals e-mails at Apple of the years before the previous decade, one isn't going to get this. Adobe was a competitor after all. Quite a high barrier for an argument that favours Apple.
Anything 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.
There's lots of times in my work when I will read minified JS code to debug a stack trace. Using the "Pretty Print" option it's not too bad. So I'm glad it's there.
Also transparency is not just about humans reading it, it's also about automatic scanning of the source, and in some cases automatic modification of the JS (for browser extensions or code analysis or etc). Those are useful things that are drastically harder using WASM.
I don't understand why people always feel this is bad.
The times when people "hacked" the JS of the websites they visited are long gone, and for nearly all web applications (which is what WASM is useful for, as opposed to simple websites) the code is already completely unreadable (even if it were not minified, I mean, you would probably need to spend weeks understanding what it's doing for non-trivial stuff)... it's even illegal today to alter websites you visit to use "hidden" features, depending on your jurisdiction.
Besides, WASM is not going to displace JS, it will just give people an option to achieve things they couldn't with JS alone.
> The times when people "hacked" the JS of the websites they visited are long gone, and for nearly all web applications (which is what WASM is useful for, as opposed to simple websites) the code is already completely unreadable
This is an overly narrow and ungenerous interpretation of the criticism here. Frequently JS can be close to unreadable after minification (and even then, that's still only "frequently", "can", and "close"), but the anatomy of the page is as manipulable as it's ever been through standardized interfaces (DOM). Browser extensions and other features baked into browsers that depend on this ability to fiddle with or read e.g. form controls are ubiquitous. Flutter (or Flash) rendering a blob of pixels to a canvas destroys this. We'd never have gotten tabbed browsing or popout picture-in-picture videos with native playback controls or password managers or AdBlock Plus and uBlock Origin if executing opaque SWFs and Silverlight bundles were gating users' access to Web apps.
(Worth pointing out that there's nothing really "Web" about them at that point, either—only through a dubious transitive argument involving the fact that the thing they're executing in has traditionally been called a Web browser).
> This is an overly narrow and ungenerous interpretation of the criticism here.
What? No it's not. It seems to me you completely misunderstand WASM by saying "the anatomy of the page is as manipulable as it's ever been through standardized interfaces (DOM)" as that's clearly unchanged with WASM! WASM doesn't even have access to the DOM yet, so literally WASM uses the same JS code browser extensions do.
I think they're talking about replacing the DOM entirely with a canvas based renderer through WASM, as Flutter and other WASM based UI frameworks like Slint do.
> All software is open source if you care to look hard!
Not really, because open source has a definition and that definition refers to the form that the software was authored in.
In addition, there are homomorphic encryption methods which make it possible to completely obfuscate the SW function, practically speaking. You don't even have to go that far, just look at a typical LLM network.
(As an aside, I think it would be funny if someone implemented a game where Minecraft-like crafting functionality would be implemented through a one-way hash function. So no one could look up the recipes in the source code. Or an adventure game which would hash the input command and the world state to decode the resulting progress.)
> Not really, because open source has a definition and that definition refers to the form that the software was authored in.
Well, yeah I was referring to reverse engineering it.
> ...which make it possible to completely obfuscate the SW function, practically speaking.
"Practically speaking" is the keyword here. Given enough resources (time and money), anyone with enough skills can find out how any software works and re-implement it, even if the original source code is lost.
The main premise here is that the CPU has to be able to see the instructions to execute them. If the CPU can see them, I, as a reverse engineer, certainly can.
> (As an aside, I think it would be funny if someone implemented a game where Minecraft-like crafting functionality would be implemented through a one-way hash function. So no one could look up the recipes in the source code.)
Though I'm not clearly seeing why is that a challenge. From a security standpoint, browser security and compartmentalization is very strong. From a learning standpoint, many wheels will be reinvented (but that's true today even in a JS world, just check out npm registry).
