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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
[+] [-] ivanmontillam|2 years ago|reply
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.
[+] [-] phil_kahrl|2 years ago|reply
[+] [-] bazoom42|2 years ago|reply
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.
[+] [-] jeroenhd|2 years ago|reply
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.
[+] [-] EMM_386|2 years ago|reply
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.
[+] [-] layer8|2 years ago|reply
[+] [-] rtpg|2 years ago|reply
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.
[0]: https://github.com/WebAssembly/meetings/blob/main/stack/2023...
[1]: https://v8.dev/blog/jspi
[+] [-] samsari|2 years ago|reply
What a completely unnecessary thing to say in the middle of an otherwise reasonable post.
[+] [-] tyingq|2 years ago|reply
[+] [-] zaphirplane|2 years ago|reply
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
[+] [-] cesarb|2 years ago|reply
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.
[+] [-] Tade0|2 years ago|reply
Can you share some examples?
[+] [-] geysersam|2 years ago|reply
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.
[+] [-] Dudester230602|2 years ago|reply
There is now a generation of developers equating front-end with web.
> ...but I'm pretty sure I'm not the only one feeling this way about it...
There are dozens of us!
[+] [-] FractalHQ|2 years ago|reply
[+] [-] baz00|2 years ago|reply
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.
WASM is basically Flash but less shit.
[+] [-] mattlondon|2 years ago|reply
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.
[+] [-] dhosek|2 years ago|reply
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.
[+] [-] diego_moita|2 years ago|reply
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.
[0] https://krausest.github.io/js-framework-benchmark/2023/table...
[+] [-] alexvitkov|2 years ago|reply
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.
[+] [-] jwr|2 years ago|reply
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.
[+] [-] satvikpendem|2 years ago|reply
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.
[+] [-] tcfhgj|2 years ago|reply
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.
[+] [-] troupo|2 years ago|reply
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"
[+] [-] dclowd9901|2 years ago|reply
[+] [-] mikewarot|2 years ago|reply
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.
[+] [-] dmytroi|2 years ago|reply
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.
[+] [-] CottonMcKnight|2 years ago|reply
(Feature-limited) Photoshop was ported to WASM in 2021.
https://web.dev/ps-on-the-web/
With the deprecation and imminent removal of WebSQL, the official (Google) recommendation for SQL-in-browser is WASM SQLite.
https://sqlite.org/wasm/doc/trunk/index.md
[+] [-] pjmlp|2 years ago|reply
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.
[+] [-] sebastianz|2 years ago|reply
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
[+] [-] DarkNova6|2 years ago|reply
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.
[+] [-] cogman10|2 years ago|reply
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.
[+] [-] goalieca|2 years ago|reply
The reminds me of java but with native web browser support instead of applets.
[+] [-] coffeebeqn|2 years ago|reply
[+] [-] intrasight|2 years ago|reply
[+] [-] paulddraper|2 years ago|reply
[+] [-] meindnoch|2 years ago|reply
[+] [-] gumballindie|2 years ago|reply
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.
[+] [-] DarkNova6|2 years ago|reply
[+] [-] eternityforest|2 years ago|reply
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...
[+] [-] singularity2001|2 years ago|reply
[+] [-] troupo|2 years ago|reply
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.
[1] https://webassembly.org
[+] [-] jalapenos|2 years ago|reply
I think for that reason wasm will win. Outsource your compute to your users.
[+] [-] iainctduncan|2 years ago|reply
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.
[+] [-] Kiuhrly|2 years ago|reply
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.
[+] [-] thecosmicfrog|2 years ago|reply
https://docs.flightsimulator.com/html/Programming_Tools/WASM...
[+] [-] JustLurking2022|2 years ago|reply
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.
[+] [-] pizzafeelsright|2 years ago|reply
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.
[+] [-] irrational|2 years ago|reply
[+] [-] greybox|2 years ago|reply
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.