One of the things that discouraged me from Front-end Web Development is JavaScript weirdness. It just has too many pitfalls and it's very hard to debug for a newcomer unless you study a proper JS course that tells you precisely all of these traps before you get burned. I've never found a programming language that didn't behave like I expected it on first touch, except for JS.
I am fully aware TypeScript exists, and there are transpilers where the syntax (modern ECMAScript) and rules are more appropriate to current times, but these aren't "native" of the browser. You must still transpile to the hazardous old JS. I know transpilers avoid many of these pitfalls, but I cannot avoid feeling like I'm building a skyscraper in quicksand.
The hard thing about talking about this exact topic it's that I'm sure my comment will trigger negatively a ton of developers, because talking about JS like this it's going to feel like I've insulted a cult. Let me be clear this is not my intention. I come from the static-typed programming languages world, so I have a preference for my programming to be the most correct.
WASM to me provides this solid foundation, if only (big IF) we manage to create a browser where the main execution virtual machine is not a JS one. I've dreamed of a browser that supports multiple stacks, instead of the HTML/CSS/JS monopoly. For instance, why'd be too hard to think about something like HTML/CSS/Python?[0]
JS has been a discourager to me career-wise, and I'm doing great in Back-end Web Dev, but I'm pretty sure I'm not the only one feeling this way about it. The web should be more accessible in this sense.
--
[0]: I am aware of the existence of Brython: https://brython.info/, but it's not my point, that is still Python-over-JS.
I think WASM will win. I've been using JavaScript for 25+ years, and I just wrote a SPA using Rust/WASM using the Leptos framework: https://github.com/leptos-rs/leptos, and now I don't want to go back to JavaScript. Cargo is a superior package manager, with Cargo I might actually be able to let me my project sit for a year or two and go back and build to a working runtime without having to do a lot of dependency updates (good luck doing that with NPM). Rust has a solid type system, and with the borrow checker along with pattern exhaustive matching I can write something that I know is solid and will be difficult to break. There is no need to have multiple stages build pipeline running through Babel and Webpack which need to be properly configured; simply compile Rust to the WASM target and that is it. The WASM bundle is also likely to be smaller than a corresponding JavaScript bundle. Additionally, with Rust it is easier to do low-level stuff in the client efficiently such as feature extraction from image binaries. Also, the application I wrote with WASM is faster than a similar app I wrote in React, although I attribute that mostly to the fact that Leptos does not use a virtual DOM as React does.
> I'm sure my comment will trigger negatively a ton of developers, because talking about JS like this it's going to feel like I've insulted a cult.
Just FYI this line of argument is called “poisoning the well”. Definition from Wikipedia:
> a type of informal fallacy where adverse information about a target is preemptively presented to an audience, with the intention of discrediting or ridiculing something that the target person is about to say.
It is not conductive to a reasoned discourse about a technical topic.
That's not poisoning the well. That would be something like "if you disagree with this it's because you've drunk the kool-aid of the web development cult, so your opinion is biased and therefore invalid". Something along those lines.
Although it was poorly phrased, what GP meant to say is that they weren't trying to intentionally offend anyone's sensibilities, they were just expressing their sincere opinion on a subject.
“Triggered” implies an emotional or irrational overreaction to some stimulus.
Describing your opponents as a “cult” also implies that they are non rational.
The GP described opposition to his argument, before it was presented, as coming from triggered members of a cult.
If this is not poisoning the well, what changes to his argument need to be present for it to cross over the line?
I started my programming life with Delphi and C++ (pre-C++11), and when Delphi IDE became too bloated, I jumped to Python 3.x and didn't take it too seriously until Python 3.6 onwards.
Python is even worse than than js. Worse package management, worst static typing feature. I also work in cpp space and I would rank large python code base one the worst to read with
It's not about crossing a line. For it to be poisoning the well it would need to have a characteristic that it simply doesn't have. At no point does the comment attempt to present its detractor's opinions as inherently invalid or worthy of less consideration.
What it literally says is "it's going to feel like I've insulted a cult". It's not a very idiomatic sentence, which to me suggests the writer is not a native English speaker, so we need to interpret more liberally.
>my comment will trigger negatively a ton of developers, because talking about JS like this it's going to feel like I've insulted a cult. Let me be clear this is not my intention.
The salient points are:
* A lot of developer may take offense to these comments.
* "Because it's like I've insulted a cult" -> "Because it's like I'm killing the sacred cow." -> "Because it's like I'm trying to be intentionally offensive about something that's off-limits."
* This is not their intention.
If you take into account the entire paragraph I think the intent is quite clear. "If you take offense to my comments please keep in mind that I'm not trying to be intentionally offensive, I'm just expressing my personal opinion." I'll grant you that it's somewhat clumsily communicated, but that's not that surprising if ivanmontillam is not a native speaker. I think you latched on too strongly to specific words, instead of taking in the general message.
I’m surprised this rethorical trick is so hard to recognize. It is as old as the hills and you will hear it from people from conspiracy nuts to priests, salesmen to politicians. So it is a good thing to understand and be aware of.
The crux is the speaker preventatively discredit any objection. In this case by suggesting they are irrational and emotonal.
“People will complain/get angry/be triggered by my theory X because theory Y is a dogma/cult/holy cow/religion/what they have been told to believe by mainstream media” - the point is of course that an objections to theory X might be perfectly resonable and fact based. Objections will tend to be defensive (“its not a cult, it is mathematically proven that…”) making them seem weaker.
If you want continue discussing this then please address the points I made rather than insisting on the same point I already addressed. If you won't then I'll simply stop responding and assume you're just acting in bad faith.
I would advocate for making browsers run Typescript, but WASM is just another compiler, just like Typescript. Whatever you're afraid of by using transpilers is much worse to debug and resolve once you've compiled it to a blob of binary code. If you can trust the Python interpreter, you can trust the Typescript transpiler. Things become a little complicated to debug when you're stuck dealing with crap like IE11 or various older Safari versions, but we're not living in 2010 anymore.
Javascript is terribly inconvenient and has tons of weird edge cases ("semicolons are optional except for these three edge cases", scope switching through using, the unpredictable type conversions) but the rules aren't that hard to write a transpiler for. Transpiling another language into JS will probably leave some optimisations on the table (by reimplementating methods in a way another language expects rather than calling the native Javascript API) but at least it has the normal API to rely on.
WASM is like Docker; it works on my machine, I can't get it to work on your machine, so we'll ship half of my machine and call it even. You're shipping standard libraries and JSON parsers to a browser as if you're pushing code to a bare metal server.
Javascript isn't a hard language to learn and neither are HTML or CSS. What I see many WASM people want to do is write browser code without ever needing to learn how the browser works. That's a terrible idea that will only end in either bloat or broken abstractions. "Let's make backend devs do frontend" is how we ended up with Java applets everywhere, which barely worked inside the context of a desktop browser, let alone on touch screens and phones.
There's a reason "native" desktop development has become "run an outdated copy of Chrome with some OS glue", and it's that web development is easy compared to native frontend development, especially if you target multiple platforms. WASM isn't going to turn backend developers into frontend developers overnight, you'll be stuck learning new frameworks and barely usable tooling regardless.
Just use JS, it's inconvenient but much a much better option than the proposed alternatives.
> I am fully aware TypeScript exists, and there are transpilers where the syntax (modern ECMAScript) and rules are more appropriate to current times, but these aren't "native" of the browser. You must still transpile to the hazardous old JS.
I fully understand the reluctance or just sheer annoyance of having to set up a toolchain just to end up with JavaScript. I've written an absurd amount of JavaScript since 1995. And yes, it is quirky, and awkward, and at times seemed downright ridiculous. ES6 at least was somewhat of a paradigm shift towards normalcy. Granted, JavaScript was created "in 10 days" and then simply became the de facto language of the web.
But after I started working with TypeScript, and enforcing linting rules through ESLint, and working in a proper IDE for it like VSCode, there is simply no going back. And it's not just the development that is so much better. With tools like webpack you also easily get tree-shaking, bundling, and minification, which are all good things for the users.
For very small sites with a single developer, sure you can just write JavaScript and call it a day. But anything even slightly beyond that and I would take the small amount of time to setup a build environment. It's not that difficult, and once it's set up properly it should stay out of your way and help tremendously.
I'm full stack lead on an enterprise Angular project that happens to require all of this stuff, but I would use it going forward for many less complex, non-SPA projects as well.
After 20+ years I don't necessarily loathe working on the front-end anymore.
That's not to say I didn't have to be pulled kicking and screaming into this world at first, while yelling "get off my lawn!". That may have been the case.
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).
For me, the huge missing link (that is fortunately being worked on!) is being able to (in a performant way) have a good answer for "host code wants to do some blocking operation, WASM should suspend during the operation".
This _should_ be gotten thanks to work on stack switching in WASM. As of the most recent working group meeting on this [0], it seems like V8 has made a good amount of progress on this. They published a thing back in January[1] on this, and hopefully if things go well and this is available across WASM engines then there will be one less "JS-ism" (everything async) that causes issues for transpilation.
Another feature (like WASM itself) which will probably be misused to create pages that are less usable and responsive than before. There are very good reasons why the language of the web is non-blocking.
I think you are misunderstanding things. This makes it easier for WASM-compiled programs to favor non-blocking mechanisms when being compiled. It's just that the source language might express this without an async layer.
The fact is right now if the source language has a notion of blocking calls, the when compiled to a non-blocking target like WASM it currently has to do a bunch of tricks that outright makes things slower. WIth these improvements, those "blocking calls" can properly end up non-blocking at the JS layer, matching what we all know computers can do.
JS stuff is non-blocking because of the original sin of Javascript (we have to execute all the JS before we can render a page, since there can be some document.body = ... nonsense in there). This is incidental to the programming model, and not some deeper truth about how things should be programmed.
Case in point: non-blocking `async` code in Javascript ends up sometimes turning into blocking code for performance reasons in specific cases (when awaiting an already completed promise, notably). Jumping in and out of an event loop isn't exactly efficient either.
It's applies for many programming groups. Those like to live in their realm, one where that their language is the greatest and thou can't be spoken negative about.
Just try mentioning C++ to a bunch of Go programmers or Python to a bunch of Rust programmers.
Not to say there isn't crossover but it's all ironic really, as most languages were crafted from C.
Python running well in WASM requires WASM to be more like a virtual machine (as in JVM, not KVM) and less like ASM. WASM is headed that way, with things like GC. But then you also need direct DOM integration. And even if you have both of those working well, Python's runtime and stdlib are pretty large, and if everyone picks a different version of Python they want to run, there's no economy of scale. Couple that with browsers all killing off the advantage of shared libraries in a CDN via cache partitions. It feels like the road to all of that working reasonably well in all situations is pretty long.
It's done currently in Pyodide: Python with DOM integration running with WASM. Minimal application with stdlib is around 5.5MB after compression now. Not small but still manageable depending on the use case.
Still I agree with your other comments, and in particular not being able to share caches in the browser is very unfortunate (but understandable).
Yes, it works...but it puts python at a big disadvantage in terms of size and performance. The DOM integration, for example, works, but isn't what it could be if WASM had more direct support for it.
I Dont get what you mean. Why is it better to use rust or go or whatever to write react like code templating, reactive or htmlx than it is to use typescript for the same.
Typescript is ok overall and the various frameworks / libraries used to generate a browser elements are really to my simple take not so much a language workaround than the best some very smart people have envisioned to build/update browser elements
Well maybe in another language react hooks wouldn’t be so quirky
> I've dreamed of a browser that supports multiple stacks, instead of the HTML/CSS/JS monopoly.
These existed. You could have used VBScript instead of JavaScript (Internet Explorer). Or, perhaps, you might have wanted to go all the way in the other direction, and use JavaScript syntax for your stylesheets, instead of CSS (Netscape Navigator, JavaScript Style Sheets aka JSSS). As for HTML, it might be possible to use pure XML styled directly with CSS or something like XML-FO, without having a XSLT which transforms it into HTML, but I don't know which browsers support or have supported that.
To be clear: the context of this is a comment that "I've never found a programming language that didn't behave like I expected it on first touch, except for JS", and this quiz includes things like "0.1 + 0.2 === 0.3", which raises a few questions:
Since this has nothing to do with JS per se and is a standard example to showcase the counterintuitiveness of IEEE 754 doubles, then does this mean that you have never worked with another language that uses IEEE 754 doubles? (And in what other languages do you find yourself typing "===", i.e. what would motivate you to type it out "on first touch", anyway—rather than "==", that is?)
The quiz is filled with other examples like "+!![]". Can you briefly explain what intent/expected behavior is associated with the mindset a decision to type this out in a program and how JS violates those expectations and would therefore would be better if only it could be changed?
This one gets trotted out every time someone wants to demonstrate how terrible JavaScript is. You can do many of the same stupid things in many other languages too, and most of the examples in that quiz are pretty contrived.
Do you have some real-life examples of things you've personally encountered, rather than crazy examples that no-one would actually write?
Today I'm wrangling with null versus undefined in TypeScript and making a bunch of changes just to deal with that. I know there is a semantic difference between the two but in practice most people use them interchangeably. It's simply unnecessary to have two ways of representing nothingness when most languages simply have `null`, or even eschew it altogether by making nullability sound, via option types as in Rust, Haskell, or OCaml.
I don't think the question "will WASM win?" is about JS vs other languages. In my mind it's about the web as a platform versus "apps".
WASM will be used in cases when performance and correctness is worth the extra effort. Libraries, components, etc. Js will glue it all together, like the Python of the web.
> There is now a generation of developers equating front-end with web.
I'd go further than that. There is now a generation of developers equating all of Software Development with Web.
The irony? They don't think their web browser, code editors, IDEs, operating systems, etc. are also software that someone developed. For them, it's like firmware that just magically appeared.
The way to spot these developers is everything is a request and a response. Anything involving a stream or pushing becomes radically difficult and will be smushed into the request/response framework.
I completely agree with all of this in every way having written a hell of a lot of front end code over the last 25 years. Apart from the WASM bit.
As a somewhat extremist on this front, I'd rather "the web" was still Gopher that shifted nice PDFs generated in LaTeX and 80 column formatted text files. And email was plain text only. And leave the rest to native apps on whatever platform you happen to like.
Citation needed for not behaving like you expect on first touch. I very very much doubt that most people's first touch of writing javascript included writing contrived syntacical-gotchyas like `+!!NaN * "" - - [,]` (example 25 on jsiswierd.com)... unless of course they are perl coders :)
Yes there are a few weird things around true/false evaluations and other syntax "gotchyas", but they take at most 5 minutes to grok the ones that actually come up in normal day-to-day coding, and many of the other things that people like to flag up (like scope in blocks/functions) are often the same in statically typed compiled languages too - there was a blog post from golang just recently about a "common mistake" around scoping of variables in loops etc for example (sorry cant find link). Don't even get me started on Python's weirdness.
What I am saying is there are many ways to shoot yourself in the foot in any language - you'll "get burned" in anything that you don't really understand. First-touch of rust without really knowing the language that well? First-touch of c++ without really knowing the language that well? Have fun not getting burned with those until you have studied a proper rust/c++ course that tells you precisely all of the traps. It turns out that you need to know about a programming language to use it effectively.
And for what it is worth, modern ECMAScript does not need a transpiler - it executes directly in the browser without any molestation. Typescript requires transpilation to javascript before execution, but you can get a long way without typescript if you want to without sacrificing too much besides types (and tooling these days for standard ECMAScript is excellent)
I think that maybe perhaps you are confusing javascript with browser-based frameworks like React? React and NPM are a total dumpster fire of awfulness, but they are not javascript.
I'd encourage you to give modern, native ECMAScript another go.
Where I see this as a huge deal is for plug-in development. For finl, I was looking at the possibility of incorporating an interpreter for JavaScript or Python or Lua. Instead, I can create bindings for WASM and get a sandboxed environment for people to write their own extensions. There will be some packaging tools that I’ll want to provide (the idea being that a user specifies something like
\LoadExtension{yoyodyne:csv-reader:1.0}
to bring in an extension and if there isn’t a local copy of the extension, it will fetch it from a repository, and I’ll want to bundle a bunch of stuff into a standard ZIP file layout (so that documentation, etc. will be easily fetched).
The list of languages that can compile to WASM increases on a regular basis and it seems by far the best route for plugin handling in a greenfield project.
I work on a project for building such plug-in systems. We have a wide variety of languages supported https://extism.org/
> and I’ll want to bundle a bunch of stuff into a standard ZIP file layout (so that documentation, etc. will be easily fetched
I've always, thought it would be cool if Wasm runtimes had a generic supported format for this. Kind of like a Java JAR. But of course, you can implement a custom version for application pretty easily.
Yes, on a related note Neovim just got support for WASM plugins and apparently WASM is 100% faster than Lua (neovim's default plugin language runtime) for this use case according to the author. So now plugins in any language that can be compiled to WASM are possible.
It is a reasonable big deal in the niche of computation intensive applications.
It would be an huge deal or revolution if it could perform faster on plain DOM manipulation. By now, plain Javascript is faster than WASM [0].
That's because all WASM's DOM manipulation must go through the Javascript engine and many browsers do JIT compilation on Javascript.
Edit: be aware that the article has a more interesting discussion on WASM on the server side, as a replacement of technologies such as Docker/containers, Java Virtual Machine and .Net.
Just days ago I was rewriting some matrix math operations for our game from C to WASM SIMD, only for most of them to barely tie the original performance (where for reference a crappy x86 SIMD routine gives me 3x to 5x).
That's not something you'd use for "computationally intensive" applications. Frankly this shit has been around for years and the major implementations still suck.
As for servers, it's insane to pretend you don't know what your server's CPU is and run your crap in what's essentially a handicapped JVM. Made up solutions for made up problems.
The problem with just moving hot routines over to Wasm is that you pay overhead every time you cross the Wasm boundary. The success stories I’ve heard with Wasm typically involve writing the entire computational core and renderer in Wasm, to minimize the amount that the boundary is crossed.
We don't jump a WASM/JS boundry, the entire game is written in C/C++ - we only jump to JS once at the end of each game frame when it comes time to render, so we do all WebGL calls from JS at once.
What I did was rewrite a chunk of our matrix math library, previously written in C, directly into WASM with the shiny new SIMD operations.
Rewriting a naive 4x4 matrix multiplication with SIMD gains you 3x to 4x on on x86 (with the algorithm from the answer in [1]), and a direct translation of that using the WASM SIMD instructions gains you nothing on Chrome.
On Firefox the WASM SIMD is 20-30% faster than naive multiplication, which is not much, but it's something. The issue is that on Chrome the WASM version is dead even with the scalar implementation, and to be honest I care a lot more about performance on Chrome than on Firefox.
I agree with your first sentence, although I believe that niche is really small, so I am entirely unconvinced as to the benefits of WASM.
I am an author of a large ClojureScript app, which sometimes does need to do intensive computation. In my experience, the performance of compiled ClojureScript (it uses the Google Closure compiler in "advanced" mode, so the code is really optimized) is not a problem at all. What is a major issue is DOM manipulation: any time you touch the DOM, you run into slowdowns of two orders of magnitude. And that can't be magically waved away by WASM.
In my case, if I had a ClojureScript->WASM compiler, it would likely provide me with an overall perceptible app performance gain in the 5%-10% range, while introducing a whole range of interesting bugs and issues. Not something I'd like to use.
It would enable any language to simply render their own UI and handle things like accessibility with their own accessibility based DOM that just handles the accessibility parts rather than the entire logic of the app. I believe this is what Flutter does.
This means shipping an entire UI framework as part of the web app onto a computer that already is running multiple UI frameworks.
For example on macOS with Chrome, you’ll have Flutter running on Chromium running on AppKit. All of these provide text layout engines, compositors, 2D and 3D graphics, widget hierarchies, scripting languages… Hundreds of megabytes of redundant stuff loaded in memory to run some typically basic Flutter app.
I know, we can’t magically have native binaries delivered on the web (that was ActiveX and it was bad). But it somehow boggles the mind that this is what we ended up with.
I swear to god, if shipping an entire renderer with every web page or all becomes the norm I will just ship WINE and a win32 executable instead of writing normal web pages. If we're going to move to bloated renders everywhere I may as well use write my code for the de facto standard cross-platform native application API.
It is what Makepad is working on in an interesting way using Wasm and Rust. They have created a Figma-like DSL and a good code separation with the logic behind it. You can edit UI's of in-production apps, and they are bundling an editor for that. Accessibility is an issue, and the project are looking to offer proper support there. In their video linked on the README they run the conference slides on Makepad with live apps embedded and running at 120 fps.
> and handle things like accessibility with their own accessibility based DOM that just handles the accessibility
just is doing as much heavy lifting as simply before it.
> I believe this is what Flutter does.
Flutter "just" "simply" have a trillion-dollar company sponsoring their project that came out of internal power struggles. And they have "just" "simply" been working on it for 6 years, and currently has 11 thousand issues in their repository.
Well, that's why I use Flutter rather than some other community-led project in another language, like I see in Rust like Slint, because it's quite a big task to redo a lot of this work for WASM.
Yes, see how "simply" and "just" quickly became "I will only use code from a trillian-dollar corporation because it's neither 'simple' nor 'just' to build a proper UI framework"
Sure, maybe I shouldn't have used those words, but my point was that it will enable a lot more flexibility for people who want to write apps across platforms and with their own preferred language instead of Javascript, because it will all compile down to WASM, as well as stopping people from bemoaning the slowness of Electron, or shipping an entire browser per app. Instead, one ships the app to the browser.
It makes writing the desktop apps easier, instead of using a separate framework for the web and another one for the desktop (which costs engineering time and money), or, again, shipping an entire browser per app (which saves engineering time and money but is a bad experience for the end user). You can't escape this complexity, there's no way around it if you want to make cross platform apps.
Now if you just want to make a website or webapp (with no intention of making it cross platform), stick with the DOM, it's not going anywhere.
You're still going to ship basically an entire browser per every app in the browser. Where do you think the new glorious UI for your app is going to come from with WASM?
Why would you ship an entire browser per app? Not sure what you mean, you just ship the application code. On desktop you use the native language code, or if you really want, a native WASM runtime that exists outside of the browser, such as Wasmer or Wasmtime.
Yes, you'd need to ship the entire app. Per every web app per every user.
So, for example. The currently featured app in iOS app store is Plane Finder. It weights 99 MB. [1]
So your proposal now is to ship those 99MB to every user of the web app written in WASM. However bloated we think modern web apps are, they are not even close to these numbers.
So you're sating that users complain that they have to download hundreds of egs of Electron per each app, so your proposal is... to download hundreds of megs of app over the browser anyway.
No, that is not my (or most people's) complaint about Electron. The main complaint is that Electron is slow, and takes up obscene amounts of memory. RAM, not ROM, is the issue.
In contrast, I can have native performance via WASM, even if the binary size is large (it will get smaller over time, but even then, most people don't really care about binary size, they care about speed).
But I definitely don't want to load 100s of MBs for web apps. And compiled wasm cache in browsers isn't unlimited, so it will get purged, and you'll have to re-download apps again.
Do you really believe that browser makers will not implement optimizations if we start getting pure WASM apps? They will add long term storage of the app binary, auto updates via diffs, data streaming, etc. Think of them as desktop apps, but they just run in the browser instead.
Why not just use desktop apps you ask? Well, people apparently don't like desktop apps, they want to work in the browser, so we have come to this roundabout way, using WASM.
I think you are missing what I'm saying. At the end of the day after this WASM business gets settled, the browser will just be the runtime for WASM apps. Nothing will be stored "in the browser," it will be stored on the user's file system, so I'm not sure why you say browsers won't have "unlimited storage," they'll be able to access as much storage as they need, same as downloading a desktop or mobile app.
When WASM becomes popular enough, browsers will indeed implement streaming and diff update optimizations, just as HTTP 2/3 does today for DOM based sites and applications. Browsers will become the unified runtime for WASM apps, so they will support the common operations and optimizations for such apps.
> People do want to use desktop apps. Instead of actual desktop apps we get shitty web apps running on Electron.
Yes, that is my point. WASM will make these apps fast because they are actually compiled rather than be interpreted by the JS JIT as well as shipping an entire browser per app.
I am honestly not sure what you're arguing for. You talk about shitty Electron apps, which I agree with, but then don't seem to have a solution, which in my case is WASM apps on the browser or via a runtime like Wasmtime. What is it that you actually want?
Well, plain JS is faster than JS Frameworks as well. And in comparison with them WASM (e.g. Dioxus or Leptos) aren't that much slower, if at all.
Solid is at 1.09
Dioxus 1.14 - wasm
Leptos 1.18 - wasm
Angular 1.62
React 1.64
Now, that's just DOM manipulation.
Any real app, especially ones where performance matters will have a huge shift towards computation that's not DOM related, even if the app is not computationally extensive.
> It is a reasonable big deal in the niche of computation intensive applications.
For a very narrow definition of "computation intensive applications" where definition is "speeding up some parts of some workloads in some situations on web pages"
A WASM-powered virtual DOM with painting privileges seems all but ascertained given the general direction Mozilla and other interested parties are taking the environment. Include the bubble/capture phases and you’re completely there.
In the beginning, there were incompatible microprocessors, so p-code was widely deployed to avoid having to write the same Pascal compiler over and over on every platform, but it was slow because it was interpreted, but even worse was that it tended to crash.
Later, the Java VM was created, to avoid rewriting the same code over on every platform, but it was slow because it was interpreted, but thanks to JIT, that was pretty much taken care of. The main problem then became the fact that it, like ActiveX before it (which wasn't cross-platform), got general access to the file system, and could never really be safely used.
It remains to be seen if WASM/WASI retain their commitment to capability based security, which is at this point the main selling point. There have now been fast cross platform systems, but this is the first that builds in capabilities, and doesn't give general access to the file system.
Analogy #1 - We need such a system... it's like power in a home... with a circuit breaker, and the promise that you're only going to get 15 amps, not all of the power of the grid, flowing to anything you plug in.
Analogy #2 - It's like cash in a wallet, you decide how much to hand over to an untrusted partner in a transaction. You should be able to decide what files/folders to hand to a program, and know it won't get anything more than that.
Analogy #3 - The IBM PC XT with twin floppy disks was the most secure general purpose computer of its time, and still is. You had control over your data, full and transparent control, because you decided what the allowable side effects were when you decided what disks to let it access, and also if they were read-only or writeable. You can't do that today.
WASI is adding APIs to access all manners of native OS APIs. WASM in the browser is still reasonably secure because it can only do some basic memory operations (until someone decides to put the filesystem and networking API directly into the WASM engine) with Javascript wrapped around it to call actual browser APIs, but the "run WASM anywhere" tooling is quickly turning WASM into the next JVM.
I'm a fan of the concept of WASM as an isolated runtime you can safely embed into any application, basically allowing you to load and execute untrusted code if you have to, but the people driving WASM adoption are quickly expanding the attack surface to the point I don't trust such a setup anymore.
Giving WASM/WASI full access to the file system is about as smart as having unprotected, unfused, 12,500 volt 3 phase outlets in the home. I can just imagine someone here saying "NIPSCO has it across the street, why shouldn't I be able to get all the power from the grid, right?"
I also deliberately left out the phase change that was caused by IBM including 1401 Emulation in System 360. Before that, everyone rewrote their programs every time a new machine came out, because it was expected it would be incompatible with the old one, so we have a ton of code still running that wasn't expected to last more than 10 years when it was written, in the late 1950s, early 1960s.
WASM itself is likely to be successful in some niches, the industry has a know-how for bytecode VM's and integration with LLVM will make it stick for a long while. My bet are computation kernels for web, and porting whole native apps to web browsers via emscripten.
WASI is probably doomed to fail, so far it was proven to be challenging to make "write once run everywhere" API, for example it's difficult to abstract over epoll vs IOCP vs io_uring without reinventing libuv, but making a standard out of libuv API will make adopting any platform changes too slow, because of losing control over the implementation of the API. Having a single standard implementation where the industry is collaborating might be a better way, similar to how .NET is an abstraction over platform API.
How is any of that a "big deal" though? We've been compiling arbitrary code to Javascript for years now.
I'm all for WASM but it seems more on the level of a new processor generation or faster RAM than something revolutionary. I'm sure it took a lot of hard work by smart people, but for most of us it's an implementation detail.
You should read about the creation of Figma. Some applications require a certain level of performance or they just don’t have much value prop. WASM made figma possible
Figma existed before WASM was enabled in browsers so clearly that's not true. They claim WASM improved their load times by 3x, which is a lot, but enough to make the difference between viable and not? I doubt it.
Say what? WebSQL was an experiment that ended up being replaced by indexeddb- it has been deprecated ever since, and was never part of the web standards.
It’s telling that despite IndexedDB being around forever people would still rather download an entire SQLite runtime than use it. A deeply unsatisfying API.
If I remember correctly, the main argument against web sql was that it really was just SQLite disguised as a web standard. I.e. there was a single implementation which defined the spec: SQLite. Every browser implementation relied on it.
In retrospect, with the chrome monoculture we have today, this seems like a silly argument but at the time it was a legitimate concern.
We didn’t need wasm to compile to the web for decades prior. Having a target closer to machine code is good, but not revolutionary. Same for Photoshop on the web tbh. Who is even using this?
Figma is built using WASM, sees significant benefit from it, and is pretty popular.
But absolutely there are a lot of of less demanding web applications out there that don’t need this. And in the case of Figma, it’s the core of the application that uses WASM, with the more webby UI bits outside of it for all the devex reasons you’d expect.
In truth it’s a medium deal in the sense that it enables use cases that simply aren’t feasible without it, but is arguably irrelevant for most “conventional” web dev problems.
In that vein I’d argue it is more relevant for use cases that currently aren’t on the web at all versus as an improvement for those that are.
People bring up Figma in almost any discussion related to WebAssembly. I tried to dig into this and understand why they chose this, what kind of benefit they are getting from this and how it compares to alternatives. Turns out that there is no comparison in performance because the alternative (doing everything in JS) was never done, and the choice of going WebAssembly is more due to their history and stack than anything else. In other words, if they rewrote the whole thing with modern JavaScript ecosystem (e.g. TypeScript with strict typing, typed array), it is unclear that the product would be any worse than the current implementation, because nobody ever tried that.
Therefore, "Figma is built on WebAssembly so WebAssembly is good" is weak argument.
I can’t stand Figma, it’s limited, slow and in general, demonstrating nothing at all for its wasm use so that’s kind in support of my point. Something like Figma would get a lot more performance out of using WebGL. Which is only accessible through JS, and the emscripten bindings for it go through JS calls. So WASM is kind of a dead weight in this scenario.
The company was last valued at $20B so they are doing something right.
They are using WebGL. Using WebGL from WebAssembly has some nice advantages; with Wasm you can use languages that are more accommodating to the sort of densely-packed data that you need to send to GPU buffers.
Accommodating how? Everything goes through JS, what they share is basically an ArrayBuffer (if we're talking command buffers) which you can build directly in JS with the same JIT backend that powers WASM. I went through your article but it doesn't describe how is WASM more "accomodating" to this.
One way or another, the command buffers are an encoding process. They're not WASM code nor JS code, they're GPU code. You need to build them from one platform for another platform. There's no any direct correspondence between WASM and WebGPU, let alone WebGL.
Accommodating in the sense that in a language where you control the memory layout of objects, you don’t have to explicitly do an explicit encoding step, you can just specify a memory layout that the GPU can understand. This makes it a lot nicer to work with in my experience.
You could create a JS object with accessor functions that stores an offset, but the object itself still takes up heap space. In Rust, it would just be a (typed) pointer to the position in the buffer and wouldn't require an allocation.
Sure, but it was meant to refute a pretty weak point that basically boiled down to “I don’t like it so it’s bad”. Enough people do like it and find it fast, and while I can match anecdotes, pointing out the success of the company seemed more compelling.
You’re asking who is using Photoshop on the web? A lot of people. Like there’s a ton of people using Office 365 in a browser rather than the native app.
HN loves to shit on webapps and honestly with very good reason but the reality is that for a lot of people a cloud-based app they can use on absolutely any computer (or, often, phone/tablet) they can get their hands on is a huge boon.
Absolutely any computer/phone/tablet has the concept of applications.
Web apps remove initial friction of installation, and for big apps not even that much because you still need to download it and run it. But they also pay up this gain, with huge interest, for every single second you use the app. This is not benefitting the users. The bottom line is dire.
However removing initial friction is all about getting your foot in the door. It's like selling a printer under cost and then you get them with the ink. Get them the first drug dose free, and then you get them when they're dependent. Offer a cheap design, and then you destroy them with the manufacturing.
A story as old as the world, of which this "web megaapp" model is a tiny microcosm of. The web is an excellent platform for small to medium apps. Photoshop is gigantic. And Figma and the other rest of its ilk are absolutely insufferable and I'm saying this as a webdev. I would be significantly happier if these products did NOT exist.
Heck if we took out WASM and these kind of products went away I'd consider it a net positive.
You can also run the same build when there's no OS fragmentation. Say all Windows machines run the same build. All iPhones run the same build (well not quite, but let's say they automated and hid the builds very efficiently on the App Store, zero effort). All in all, builds are not a problem. If they're a problem, it's a symptom of a fragmented, immature ecosystem, which indeed many Linux/BSD distros continue to be, in the big picture.
However none of this matters. Because we have Java and countless other cross-platform runtimes. WASM is at best just another variation on the same theme thrown in the same pool. I definitely see how one could justify WASM hype by saying all the things will be WASM because it's so sandboxed and multiplatform. But that's the engine of all hype cycles. Truth is it likely won't happen, because WASM is nothing new and nothing unique. That niche is filled with solutions already.
We could theorize everyone will have a WASM compiler backend because it runs in browsers, therefore it'll become more useful on servers as you have compiler backend for everything to WASM. However YOU yourself said the web is not the most interesting place for WASM. So what will supposedly drive the WASM ecosystem, that makes it interesting (the web) isn't interesting, but it has to be interesting so the server use of WASM becomes more interesting. Quite the chicken egg problem there. Might work, might not.
I lived through a period on the web when every language had a JS compiler backend. You could compile Java to JS, Delphi to JS, C# to JS and so on. Maybe some of those solutions still exist in some half-dead form, but they're largely abandoned, because people realized the best language to write JS in... is JS. This is also why TypeScript has such success, because it's JavaScript itself (but with types).
For WASM we can argue there's no such pressure to "write JS in JS" but there's just very little value for it, outside the nerd realm of "OMG assembly on the web". I know why Google wants it. It wants it because it indexes the web, and puts ads on the web, and so therefore it wants everything to be the web, because then it means Google can index and put ads on everything. That's good for them, but not for anyone else. Downloading and running hundreds of MB of code for an app like Photoshop, or whatever, over the web is an absolutely miserable experience. Not to mention the HCI input capabilities and OS services available to the app, which are understandably limited in a browser.
> All in all, builds are not a problem. If they're a problem, it's a symptom of a fragmented, immature ecosystem, which indeed many Linux/BSD distros continue to be, in the big picture.
Can you give an example of how builds are a problem due to Linux/BSD distros?
Maybe, but there's either a problem with builds, which makes WASM a potentially exciting solution to them, or there isn't, and therefore the subject is not relevant to WASM in this thread.
For the web and other use cases where it is embedded in another program (e.g. sandboxed plugins, other places where Lua or similar would've gone previously), I think yes. But I really don't see something like WASI or WASM servers sticking around, especially because it still has a noticeable performance penalty compared to native (can't source this right now, need to sleep)
Plenty of WASM advocates act ad if we haven't had endless attempts at since the 1960's.
Also doing kubernetes with WASM containers must be a bad joke, when comparing how managing Websphere 5 in 2005 was so much easier.
On the browser side, it is a convoluted experience versus using Flash/Code Alchemy, Java Applets, Silverlight, with Blazor/Flutter being the only ones that somehow come close to how it used to be 15 years ago.
> On the browser side, it is a convoluted experience versus using Flash/Code Alchemy, Java Applets, Silverlight, with Blazor/Flutter being the only ones that somehow come close to how it used to be 15 years ago.
Two (very?) significant distinctions though:
- wasm actually try to be an open standard
- through WASI it will attempt to be a first-class VM, with typed (though wit), direct access to all web APIs and the DOM
You are comparing an open, non-proprietary compile target to a closed ecosystem.
Admittedly, WASM is making slow progress (much to it due to Google actively/passively sabotaging it) but it is the closest we have got to a universal compile target. In particular, the combination with Rust could be a game changer and make whole categories of DSLs obsolete.
It also has the potential to open FE work for people which categorically refuse to work with the mess that is the JS ecosystem.
Got any examples of Google sabotaging WASM? First I have heard of this. I thought Apple was kind of since they seem to adopt some things somewhat slow or not at all.
Google is supporting WASM heavily, e.g. with their Android and Flutter teams both working hard on WASM support. They require Wasm GC, which the Chrome team has already implemented and Firefox is not far behind.
We all (Mozilla/Google/Microsoft/Apple) announced consensus for the WebAssembly MVP on February 28, 2017. Mozilla and Google shipped on-by-default in March, Apple in September, and Microsoft in October.
> Admittedly, WASM is making slow progress (much to it due to Google actively/passively sabotaging it)
Since Google use Browsers as their app and as distribuition platform, I always thought that anything that made browsers easier to target vs native apps was a win for them.
> Also doing kubernetes with WASM containers must be a bad joke, when comparing how managing Websphere 5 in 2005 was so much easier.
Yeah, I really don't get the value add of WASM here. If you are doing rust, then why not do a scratch container natively compiled? It's the same experience with half the effort.
You can do the same with most programming languages.
That's not why those things died, though. They died because smartphones stopped supporting them, and that combined with advancements in JS engine speed were all it took to get brother vendors to scrap the buggy, security-hole-ridden plugin ecosystem.
WASM should hopefully not be bad from a security perspective, but the up-front performance penalty of early demos in downloading megabytes for hello world was painful.
More purpose-fit, smaller modules ought to be broadly useful but I'll not be holding my breath. Anything that needs to take over a canvas probably isn't going to be widely adopted outside of some niche things like visual design tools or the occasional game.
>> the up-front performance penalty of early demos in downloading megabytes for hello world was painful.
> Megabytes are certainly an exaggeration, see 285.4 KB for Leptos
Those early demos were certainly quite large. I don't think that I found any early demo of WASM to be under a megabyte, for sometimes quite trivial things.
Flash and Java Applets both owned a rectangle of the screen. Wasm interacts with the page just like JS does. So in contrast to Flash and Java, Wasm fits in with semantic web content to the same extent that JS does.
Sure, but presumably the ones that “don’t fit in semantic web content” is a reference to the ones that rendered a portion of the page in Java, otherwise the same could be said about JavaScript.
As you can read in the various comments on here, that's also the model many WASM fans are going for.
Google Docs switched to rendering a full screen canvas rather than using the DOM, and Flutter/Compose do the exact same thing.
WASM is very much heading in the direction of owning a rectangle on the screen. Plus, Java and Flash embeds could also call Javascript callbacks while leveraging the improved performance of their native plugins.
Google Docs doesn’t use Wasm, from what I can tell. The move towards using canvas/gl/webgpu over DOM for performance is orthogonal to using Wasm. They go together nicely, but if you’re worried about DOM being replaced, Docs is a good example of how that will happen with or without Wasm.
Another pattern I’ve seen is to render DOM on top of a canvas, with UI elements done in the DOM, and high-performance graphics on the canvas. This seems to be a good balance. https://x.com/paulgb/status/1688919428740816896?s=46
It doesn't. Any interaction with the page happens through a JS bridge.
> Wasm fits in with semantic web content to the same extent that JS does.
It doesn't. It's a VM that runs side by side and only has a tiny window into the rest of the browser through arrays of integers passed between it and Javascript.
> Any interaction with the page happens through a JS bridge.
Right. The point I’m trying to make is that Wasm can only interact with the user through those JS APIs. This is in direct contrast to Java/Flash, which could directly render on the screen with an API that bypassed the browser’s JS layer.
I'm sorry, are you telling me there will be more work needed for achieving the same thing that could have been achieved using plain HTML, CSS and JS?
Are you telling me I will need to print more invoices and sell more training?
Don't threaten me with a good time. I'll fork a wasm lib make a few changes rename it and put it on my CV. That's how the webdev world has been working for over a decade now. Oh I'l also misuse some design patterns and other plausible sounding "engineering" practices to make it look cool.
> Are you telling me I will need to print more invoices and sell more training?
Push the boundary too hard (as an industry) and I'm pretty sure we'll go back to the dark ages of desktop apps. I miss Delphi so much sometimes!
> I'm sorry, are you telling me there will be more work needed for achieving the same thing that could have been achieved using plain HTML, CSS and JS?
I also never understood why junior Web Devs prefer to write a ton of React code, when there are obscure frameworks that have a Qt-like API. Consider this Qooxdoo[0] code:
var win = new qx.ui.window.Window("First Window");
win.setWidth(300);
win.setHeight(200);
win.setShowMinimize(false);
this.getRoot().add(win, {left:20, top:20});
win.open();
Painfully constructing UIs one line at a time is, well, painful. The whole DOM API is like that, and people have been trying to get away from it since at least jQuery.
The issue is when this kind of code builds up and no one other than people who consume copious amounts of various numbing drugs can maintain or read it. Not sustainable.
The code that needs a single imperative line for every single thing builds up into incomprehensible mess much quicker, and is quickly abstracted away into function calls not dissimilar to jQuery or even React.
I wanted to build a basic local tool for managing a bunch of linux fine tuning parameters and a little screen where i can see the status of various things. I am lazy and didnt to do more than just click buttons (not even press the arrow key on a console to run a history command).
After considering electron for a split second, even with no framework, I legit went for Gambas.
I drew my UI, added event handlers, compiled it and that was the end of it. Easier than faffing around with the bloat of react, vue, node or electron.
I'm kind of afraid of this. When it gets DOM and drawing abilities, People are gonna build SO many things of varying levels of quality, from scratch, that probably could have been done with existing JS frameworks, don't work well with browser features, require learning 583 languages to work on anything, etc.
It will be amazing for compute heavy stuff in the browser I'd imagine. Cross platform assembly is a super cool idea. If they can get it right at least we might have something besides a container that runs anywhere.
I'm just not sure I want them to mess with JS/HTML based UI just when it was really getting awesome and declarative was becoming standard... And since web devs like. Making stuff harder than it needs to be they might...
WASM may live up to its promise when they finally fix js/dom interop. Looks like it's indefinitely postponed though. so we are stuck with ungodly glue calling between it and JavaScript (which is unavoidable if you want to do much with it), incredibly hacky.
They should've stuck with "this is crossplatform bytecode for the web", and it would've flourished there. Instead, now it's "designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications." [1]
Servers! Applications! Tigers! Lions! Oh my!
And it's not particularly good, or effective, or performant at any of those.
I do music programming and it's a huge deal. I am able to run my domain model in a WASM embedded Scheme interpreter, enabling me to reuse code from other computer music projects (Scheme for Max, Common Music, etc). I have a C++ worklet running regular C++ DSP code so i can use anything from that world. And I've made a sample accurate scheduler that can drive the main thread from a worklet (of course like any block rendering system, it has a vector of samples of jitter, but long term it stays as accurate as the sample clock).
Getting all this to work was ... laborious. The debugging situation for worklets is pretty painful at the moment... it's more like writing microcontroller code than normal desktop. But that will improve, and being able to do it all in the browser such that the guts of my work can be reused across browsers, Max, or stand alone C++ is huge for me.
I think WASM will really take off when we get proper browser API access direct from WASM. Right now the passing back and forth to the JS host adds a lot of work.
Another point I haven't seen mentioned much: WASM (in theory, and not including some modern extensions) has perfect, cross-platform, cross-architecture determinism. It's niche but I think it's very interesting.
For example, I've toyed with the idea of creating a game which runs its logic/simulation entirely in WASM with the only input being the controller/keyboard inputs. That way you can create perfectly reproducable replays which could be used for racing games or timed platform games similar to Mario Maker. Then your leaderboard of best times can be properly verified (not accounting for manufactured/edited replays similar to TASs, Tool Assisted Speedruns). You could take it a step further and include previous versions of the game simulation WASM to get backwards replay compatibility, which is also uncommon in games.
This is the killer use-case outside of the web. Embedding untrusted/semi-trusted code into a bigger application or runtime and exposing a specific API to it.
While it's definitely interesting, I do wonder to what extent WASM threatens the open web even more than the DRM battles of the past, perhaps in non-obvious ways. I'm the past, one of the ways many a frontend dev has picked up tricks was simply by reading the JavaScript for a site they liked. That can be made harder by obfuscation but, even then, a prettyfier can make things generally intelligible.
That exchange of knowledge was possible because a) for all it's warts, JavaScript became the standard for everyone in the field and b) the only way to publish your work was to publish the source (at least a derivative). WASM blows away both of those assumptions and takes us in a direction more similar to desktop software, where you may have a copy of the binary but may not even (easily) determine which language it was written in.
I've been a Chrome OS user for a decade. I no longer worry about the OS, files, or versions. This is great. What we do need is the ability to build the UX locally outside the confines of the browser outside of the existing OS.
The idea that files can share user space with other files without explicit permission always felt off.
I judge things by how they affect me right now. Right now it is not a big deal. As a web developer I haven’t had a need for it and don’t anticipate a need for it any time in the near future. If I need to use it at some point in the future, maybe it will be a big deal.
"If it's not a big deal now it's not a big deal now, and if it's a big deal in the future then it will be a big deal in the future" is not adding as much to the conversation as you think it is.
The point of HN is in large part about thinking about the future and not just look about how things are just "right now". There is no point discussing the impact that things have right now, we can just measure it.
But it’s not new. It’s been around for years. And I’m not really aware of any real uses on the web.
Other people in these comments have mentioned using it as an extension mechanism to other applications. That’s nice.
But what browsers use it internally? What popular JS/TS libraries? What big websites?
It seems Figma does, but I had to Google to find that.
It’s an interesting idea, but it feels a bit like VRML or something else so far. “It’s going to take off, just give it time.”
Some things will. Some won’t. But WASM doesn’t seem to provide enough above JS to overcome the “we can just use JS” hurdle for the vast majority of uses so far.
It's not what you need, it's what you want but just don't know it yet. Use Rust/WASM and you get a superior package manager in Cargo. Rust gets you a solid type system that's built in instead of an add-on like TypeScript or Flow, and there is no need for a complicated build pipeline with Babel and WebPack, just a single compile target. Overall, I find working with Rust/WASM to be a better developer experience the working with the NPM/Js ecosystem.
Web (site) developers will likely never have to learn Wasm if they don’t want to. But people are increase shipping regular application software to the browser as if it’s an OS. Technically you could say the developers of these apps are “web developers”, but the stack is increasingly diverging from the stack a web (site) developer would need to care about: Wasm, WebGPU, OPFS, etc.
I worry that WASM will make it a LOT easier to DRM web content, even making things like copying text difficult.
This will have a detrimental effect on third party tools and plugins like accessibility tools and ad blockers.
True, you can already do this with canvas & plain JS, but more obfuscation will make everything worse.
Eventually we won't be able to browse even the simplest websites without executing JS(wasm).
That being said, I'm all for making things run faster. But I doubt it will actually benefit users in the long run.
Web companies will just run more ads/tracking/AI Learning on peoples machines, making things slow again.
Is WASM really incresing efficiency in the browser? Apart from avoiding garbage collection, I think in terms of performance there's little advantage. JS is incredibly fast nowadays.
But I also don't think it diminishes WASM's value on the web. It will allow us to drop JS for good, at last.
"For example, Python has become the quick, easy way for people to work with machine learning programs – thank you, PyTorch. But you can't simply drop these programs into WASM in a runtime and expect them to work. The problem is that you also need many third-party dependencies, which aren't there yet."
Yes you can, ONNX. Yeah, it's not _literally Pytorch_. But it takes about 10 minutes.
Doesn't it make sense (for control freaks, at least) to load a WASM kickstarter into the browser and then get a handle to the DOM and go to work creating the UI ? Or is this already being done ?
One of the things that discouraged me from Front-end Web Development is JavaScript weirdness. It just has too many pitfalls and it's very hard to debug for a newcomer unless you study a proper JS course that tells you precisely all of these traps before you get burned. I've never found a programming language that didn't behave like I expected it on first touch, except for JS.
I am fully aware TypeScript exists, and there are transpilers where the syntax (modern ECMAScript) and rules are more appropriate to current times, but these aren't "native" of the browser. You must still transpile to the hazardous old JS. I know transpilers avoid many of these pitfalls, but I cannot avoid feeling like I'm building a skyscraper in quicksand.
The hard thing about talking about this exact topic it's that I'm sure my comment will trigger negatively a ton of developers, because talking about JS like this it's going to feel like I've insulted a cult. Let me be clear this is not my intention. I come from the static-typed programming languages world, so I have a preference for my programming to be the most correct.
WASM to me provides this solid foundation, if only (big IF) we manage to create a browser where the main execution virtual machine is not a JS one. I've dreamed of a browser that supports multiple stacks, instead of the HTML/CSS/JS monopoly. For instance, why'd be too hard to think about something like HTML/CSS/Python?[0]
JS has been a discourager to me career-wise, and I'm doing great in Back-end Web Dev, but I'm pretty sure I'm not the only one feeling this way about it. The web should be more accessible in this sense.
--
[0]: I am aware of the existence of Brython: https://brython.info/, but it's not my point, that is still Python-over-JS.