Why WebAssembly Can't Win
Vložit
- čas přidán 18. 04. 2024
- Didn't expect an article about treeshaking to make me so anti WASM but here we are. Webassembly is great for specific use cases, but not for everything. In fact, it's not great for most things.
SOURCE
wingolog.org/archives/2023/11...
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏 - Věda a technologie
first video i've seen from theo where he isn't constipated in the thumbnail
😂
😂
I pressed back to look at the thumbnail, and I must say, he does look surprisingly relieved.
It’s 1am when he uploaded, probably took a dookie
Bro waited this long to say that
It's not like JavaScript can win either, JavaScript isn't even compatible with JavaScript
oof
Compiling Typescript to javascript is just a big brain move.
Are we afraid that JIT might do better with type information?😂
Browsers should absolutely support Typescript for better JIT compiler optimisation.
Real 💀😅
😂😂🎉
JavaScript !== JavaScript
"This looks like a math thing, I'm not smart enough for that, I'm a JavaScript Dev" rofl.
I came here to write this comment LMAOOO I feel attacked
me af
In other words, he doesn't know how to write real software.
@@privacyvalued4134 he knows. he is just joking. he had been working with other languages before he was a javascript dev.
@@privacyvalued4134 I am a javascript developer am I agree
My understanding of WebAssembly is that it was aimed at performance critial code (gaussiasn blur, FFTs, image/audio/video processing, etc.) that you wanted to access via JavaScript (e.g. if you are displaying an audio waveform on a canvas) so you can run it locally.
It was never meant to be a JavaScript/TypeScript replacement. It was designed as a way of describing machine code within a subset of JavaScript so a JavaScript engine could compile and run that locally within the browser. It's effectively a JVM or .NET CRT defined in JavaScript.
.NET CLR*.. CRT is the C/C++ standard library
Wasm is indeed more for doing things like deploy Unreal Engine 5 games to the web and make them have run performance more or less as if they were installed on your local machine. Native high performance but online and where size doesn't really matter cause Unreal 5 games are HUGE always sizewise anyways so a few extra megs of package data don't matter in this case. For ordinary web apps like Wordpress, webshops and similar non high performance applications raw performance like this is however less important and old school JS will do just fine with possibly more compact code and smaller package sizes to download to the browser.
this ^^
> It was designed as a way of describing machine code within a subset of JavaScript so a JavaScript engine could compile and run that locally within the browser. It's effectively a JVM or .NET CRT defined in JavaScript.
I think you might be confusing WASM with asm.js? I don't think you can describe WASM as a subset of JavaScript.
WASM is not a subset of JS, it's an entirely different language with its own runtime
It is difficult to get a man to understand something, when his salary depends on his not understanding it.
My favorite use of WASM is Ikea's kitchen builder. You can assemble a kitchen in 3D space, including cabinets, countertops, and appliances, and at the end, export the plan and a complete list of things to buy from your local warehouse. It's how I built my kitchen and was a genuinely fun experience.
I guess that counts as "Limited success" these days.
Wasm has been huge for me. I use rocket and dioxus in rust and the dev experience is amazing
You should make some videos!
I've been somewhat interested in Leptos for a while now, but when doing small projects, I've experienced the syntax as annoying and hard to work with. Did you try Leptos first before you settled for Dioxus or was it Dioxus from the start?
@@kai-.-man I've never tried leptos honestly
@@kai-.-man Try Yew, it is similar to React. The problem I had with Leptos is that it is really hard to work with large objects because every primitive that you want to update must have its own signal. Yew just runs a diff like React does, and it has a dead simple state management library called Yewdux which is easier to work with than Redux or Zustand. Where you really pay the price with Rust for web dev though is in iteration times. Even on a new laptop it takes a few seconds from saving to seeing the update in your browser.
It is weird to compare the success a 30 year old language that had monopoly over a full set of applications, with an amazing number of developers, with a target language that works on entirely different sets of models and is just recently receiving facilities it needs and still needing a bridge from the former language, and calling the latter a failure. Web assembly has been there for only 7 years. At this point in the life JavaScript, it didn't even have JQuery.
The web development community perhaps measures WASM with the same timeframes they measure JS libraries today and don't see the development speed their expectations require.
And then they conclude that after seven years, it's more or less a failure, not seeing things like the web in the past or the switch from Python 2 to 3, where the plan was to pull the plug of Python 2 after seven years, but then waited an additional five years, making it twelve.
I'd say let's give WASM five to seven more years. If the adoption rate will be still as low as today, yeah, then I don't see much more potential. But I doubt it'll be like that.
@@Mr_Yeah i do agree with them on it not being ready yet for the javascript-like adoption. I disagree that is not going to happen.
@@AmirHosseinHonardust Same
He is anti everything that is not what he currently uses. His opinion is uninformative because it is not based on anything other than that. If you view his video history this becomes quite clear. I don't think he necessarily believes it himself, it's just some cynical thing where he thinks hyping the things he uses and burying the things he doesn't use will be to his benefit.
Don't take CZcamsrs like him seriously lol. If a WASM-heavy SaaS company sponsors his next video, he won't hesitate to sing "WASM is the game changer!!!".
We actually use Blazor wasm for a pretty big UK-based application which is externally facing with a lot of success. But yeah - it didn’t have to be Blazor to do it, but it made sense with our existing skill tree
We're also using Blazor for very different projects. Which application do you work on with Blazor?
@@MC_DarkMaster Remote Desktop control through browser, application streaming, and systems control sort of stuff; not the most intensive, not the lightest
C# let’s go. Does Visual Studio/Code handle blazor well now? I remember the LSP sucking a year ago where I’d have errors everywhere but compiles and runs perfectly.
@@Kane0123 overall it’s up to standard, comparable with other LSPs for other languages at this point, Blazor WASM is the more under appreciated child for Microsoft; AFAIK using the latest VS version they still don’t even have proper scaffolding in place for Blazor outside of Server-Client pair
In code, for, time o time an update kills the lsp but it works alright
In visual studio it works very well but we needed license so we didn’t go with that.
Well, if only we could get to the DOM and other WEB browser API's directly from WASM. Then there would be no need to be dependent on Javascript. That is the missing ingredient.
I have to agree with you here. The fact that you can't have 100% WASM code access the DOM is just asinine at this point. They made WASM for performant code, but won't open the doors for people who just want an alternative to JS without jumping through (more) hoops. If it can't win, it is because such a basic use-case is ignored.
being able to call the DOM directly from WASM certainly seems necessary, but i don't think that will magically solve the problem of having to first download huge runtimes. it seems unrelated
@@xybersurfer There is no problem of having to download huge run-times with WASM. One writes ones code in C++ or C or Rust or such like.One compiles it to WASM, which is about the size of raw machine code. Then if WASM had all the DOM and browser API's exposed by the browser there is nothing extra to down load. Not even JS shims.
The issue of having to download huge run times only arises when you insist on using a language that needs a huge run time, like Python, Go, Java, etc.
@@xybersurfer Depends on your source language.. If you want to package the kitchen sink that is up to you.. but rust compiled to wasm can get pretty small if you don't add too much.
I have a Rust WASM application. It's overall ~500-600KB. That includes Dioxus (render library in Rust) and my code. Is that size really that bad? (I'm a backend guy with no frontend knoweldge, but even in my third world country internet speeds are more than capable enough to download this amt of data within half a second or less)
If it's an actual application, it's probably fine. If it is a website, several studies have shown that you start losing user attention after a few hundred milliseconds... including DNS resolution, handshake, download, parsing, et cetera.
If you want to make a game or an app or whatever in Rust, that's great. The user cares about getting a good experience with the functionality of the app. If they are browsing a website, they want to quickly see what they need to see and do what they need to do. That doesn't mean shipping 0 WASM, but it might mean shipping full apps (as regular browsable websites) is a bad idea, versus using WASM for number-crunching on those sites.
@@SeanJMay
"you start losing user attention after a few hundred milliseconds."
Bro, I'm sorry but what the frick? The median response time for humans to click on things is like 200-300ms, how exactly are you losing user attention before the user reaction even landed on the thing? If it is about like 900ms or 1s or more, maybe ok, but with less than 500ms it is hard to believe this is reasonable
@@diadetediotedio6918 look at the studies. Doesn't apply to just websites. The reason the entire dev industry in virtually all languages is moving to hot-reloading is because if you have to wait a half second to see changes, it measurably hampers enthusiasm with every compilation, and that puts a dent in productivity, because the mind wanders.
Studies even 5 years ago were measuring correlations of purchase/cta engagement between pages that were interactive (not just loaded, and painted, but usable) between
@@diadetediotedio6918 maybe because the user can see it's slow to load, so they just give up ?
OK, first, an average website is 5-13MB these days, including some very poorly written static pages. So 600kB is nothing.
Second, SeanJMay is... uh. I don't want to say wrong, but sorry buddy that interpretation is very far from accurate.
Latencies from around 100ms statistically make a small, but measurable difference in user satisfaction. This however mostly concerns UI interactions that are supposed to be instant. If your UI isn't snappy, people will be less likely to use your app or website. They will not "lose attention" in the sense that you would open another youtube tab just because clicking "confirm purchase" button on your shop took 100ms to render a confirmation page.
Also, common sense applies - difference from 700ms to 1000ms for first page load isn't that significant, difference from 1ms to 300ms on "Dismiss modal window" might be. 300ms lag in an FPS/MOBA game will make most players quit right away. The landscape always changes depending on what is the current industry standard.
Faster is better, of course. Snappy UI makes customers happier. However, if you have a monopoly... yk. Context is everything.
I would love a time where I no longer need to use JS for the frontend. I hate JS
I would love a time when there's no need for frontend anymore. Applications are divided by logical layers for convenience, not because of the technical debt of the stack. Go back to the n-layer (and being n=3) architecture of the 2000s
Imagine a desktop application: Photoshop, it doesn't have a "frontend", the entire thing is the application, there's no division between frontend/backend/logic. There are a lot of internal division, but none of them are related to running distributed applications over multiple machines, which is a moot point.
All because the web was misused for applications, thanks to AJAX, it was never meant to be that, it was for hyperlinked documents, not applications.
JS was a huge step backwards.
Abandoning win32 apps was a good idea. Most of them were awful and impossible to maintain.
Having a single application which acts as a universal “container” for a wide array of custom built UIs and apps was a good idea, and having them all written in a common language was also a good idea. Even having them regularly retrieve the latest version from the backend was also a very good idea.
This was originally what Java applets were.
To some extent, it’s also what Flash was.
But for some reason, oracle never fixed the problems with applets. So it just sort of rotted and became more vulnerable to exploits.
And so JS filled the gap, and basically copied applets verbatim. Except JS required significantly more bandwidth and processing power to achieve the same thing.
Honestly, the trend is toward treating JS apps as thick applications, which is what applets were designed to do. So maybe bringing back applets in some form would be better.
@@gmodrules123456789 Both things are true. Win32 is awful, but Javascript is also awful.
Using javascript as electron not to have to make desktop apps is double awful, because you have both worse of them.
A better alternative would be something like QT and Python.
Yeah, Scheme would be much better.
It has always been an important feature of DOM, that family comes first.
"It's about family" - Vin Diesel (DOM Advocate)
@@benaloney (Family lover)
This will age poorly
Why
@@moonskined WASM is a fantastic technology that really just needs better support and adoption. Both of which will come over time. Nobody is saying it'll replace JavaScript but it'll definitely complement it by adding the ability to actually do fast, efficient things and run code from systems programming languages with performance way better than JS, relatively close to on par with native code in some cases.
WASM has been supported in Chrome for 7 years.... and you could still compile it to raw JS before then....
@@jacobgreenfield2684 I agree with the rest of your take, except the part where you claim "nobody is saying it'll replace JavaScript".
There is a very loud group of WASM supporters whose daily task is to remind us why WASM will overtake JS.
@@jacobgreenfield2684 but that wasn't the point of the article. The point of the article is that shipping a 30MB binary to a mobile website, because your ... I dunno, graphing lib, written in C++ (to be suuuper fast), also carried along 50 dependencies that got compiled into said binary, and shipped to the client.
The complaint isn't that WASM is unviable, it's that most native build chains haven't had to be as lean as web build chains. Hence why the entire article was about how compilers for other languages need to start concerning themselves with tree shaking, and why that is a hard problem to solve in various languages.
WASM is held back by insisting that it being forced into the JS madness.
Yeah browser should give wasm direct DOM manipulation api to work with instead of having wasm jump in and out of javascript. Once those api/libs are in place give it a decade before saying wasm in the browser failed.
To be fair, JS is a lot more sane than assembly. Especially x86 assembly. And people still buy Intel and AMD powered CPUs
@@BlackwaterEl1te Yeah, I think DOM api is the way to go.
I love that we’re talking about needing to minimise the amount being sent to the browser, meanwhile loading any page on the entire web has 50 nonsense calls to every data broker on the planet.
@@slebetman JS needs assembly; JS -> JIT -> C++ -> assembly -> machine code. Just because you don't use it directly doesn't mean you don't use it indirectly. When someone produces hardware that can execute JS directly then you won't need assembly (as long as your operating system and browser are written in JS); i.e. it's not going to happen because no one is going to spend $2B+ to make it happen.
As Unity developers, we can deploy WebGL builds that compiles to wasm all day long. In fact that's exactly what we are doing for product configurators for clients. Unity is on its way to transition to WebGPU too, that should improve performance a lot.
WebAssembly has not yet failed, it still is in development 😂, we are still working on things like Worlds and The Component Model, Lets not forget the recent GC proposal being merged to allow many languages to target web assembly. Its way too early for this conclusion
I swear to god WASM and WASI are moving way too slow. Every time I wanna do anything with it seems like there is some RFC that does the thing I want but it's not in the standard yet.
But the problem isn't the WASM VM. The problem is shipping massive binaries to a website. The runtime isn't going to reduce the number of bytes sent over the wire, unless Chrome (and all other browsers) start shipping with a bunch of revisions of the most used libs for the most used languages, and work out a dynamic linking solution that's still browser-levels of safe.
Developers complain when an Electron app is written in JS, and is a 300mb download that is mostly just a portable Chrome install. Cool, but that's an installed application. What about a regular consumer website for buying shoes, that ships a 90mb Unity runtime, and all relevant libs, plus program code, or whatever, for desktop and mobile?
@@SeanJMay The problem is _absolutely_ the VM. If the runtime already exists _in_ the browser instead of being shipped along with the app code (like it's doing now), that'd cut a lot of that size down.
The libs used are irrelevant. Does Chrome "ship with a bunch of revisions of the most used libs" for JS? Of course not. The libs get bundled together and shipped along with the final code (or requested via CDN).
How they implement WASM at the moment is just all kinds of weird to me. The blueprint for a working common runtime is already present, multiple times even - the JVM, CLR, LLVM. I know they have a lot to consider, but it's not like this is a totally uncharted territory.
@@marioprawirosudiro7301 your argument is surreal. "If it already exists in the browser". How many versions of UE5 should already exist in the browser? How many versions of Unity should already exist in the browser? How many dlls for FFTs should already exist in the browser? How many versions of ffmpeg should already exist in the browser?
Does any of that make sense to you? Because I really don't want my Chrome installs to be 80gb.
It's just a click bait title... which isn’t really supported by the content of the video...
I think the problem is that browsers have been dragging their feet on WASM.
WASM shipped in 2017 as an MVP. I think many developers had an expectation that since the arduous process coming up with a standard that supplanted browser specific solutions like NaCI that progress would be made quickly. Many hoped for threads, SIMD, garbage collectors and browser APIs like DOM, canvas, WebGL without going through JS. To this day only threads has shipped.
Let's also not forget that when WASM was first entered the scene, that ES6 was still very new, Typescript quite niche and JS engines no where near as performant as today.
JS got a lot of love from both browsers and the ecosystem. WASM is held back by browsers and the ecosystem reflects that
SIMD + relaxed SIMD (relaxed not yet stable in Firefox or Safari) and GC (about to stabilize in Safari where it's still not stable) have shipped (among lots more proposals)
that article is kinda weak. That dude literally deleted comments and closed comments when he was getting roasted for shit take.
Wasm is used in lots of high performance applications in the web tech space. How do you think noise cancelling works? LMAO. Its making companies like Krisp, Picovoice, figma and many more possible. Web devs being outta their depth and complaining that the technology that they don't know about is not being used is the funniest shit ever. My boy theo is typescript andy and I love him for it, but you outta your depth here.
Shipping an FFT function is not the same as shipping the Unity runtime and included program code, to Nike, so that they can have rotating 3D shoes on the mobile website.
One is going to be a few kB. The other is going to be 90MB. Note the difference.
This is about WASM vs compilers, no one is saying that WASM is useless. I do think that WASM will take over eventually, but it's delusional that you can take toolchain from environment where the standard for read is over 100 MB/s for years to web, where we are limited by bandwidth.
did we read different articles? guy said that wasm isn't good at DOM heavy websites, which is majority of them, and stated `Wasm finds success in getting legacy C++ code to the web, and as a way to write new web-targetting Rust code. These are often tasks that JavaScript doesn’t do very well at, or which need a shared implementation between client and server deployments.`, wheres the shit take you seeing?
@@ky3owthey didn’t actually read the article or watch the video.
@@ky3ow
This is caused by . People see the title of the video and get pissed off. It is completely reasonable and if you don't want this kind of response generally you should just use titles that don't pass the wrong impressions.
i mean the creator of JS stated that he was trying to create a Scheme for the browser, so having actual Scheme running on the browser is just finally reaching Eich's goal...
Many people forgetting WASM allows many languages to used in browsers, instead of just being limited to just javascript
Oh shit, another hot take from Theo that will probably age poorly.
Hixie, the author of the HTML5 spec, wrote a document that proposed a path towards allowing .wasm files to be loaded directly in browsers with the necessary capabilities to paint pixels and access browser APIs.
That future is certainly possible, and would absolutely be a net-good for the entire software ecosystem.
@@_____case how does any of that address the challenges of the blog post, at all?
If you are shipping a 20MB binary, because of your app's massive dependency chain, and the lack of WASM dynamic linking, how, exactly will that make it a viable website replacement?
Like, if you decide to dynamically call into ffmpeg in your app, you've grown that binary by 150mb. On a website, that would be ludicrous.
Theo speedran this one; it doesnt even need to age to be poor it's a poor take from the start XD
Will?
Thing can be labeled "this aged poorly" after exactly 1 views. It’s a talent.
Scheme is worth mastering to a reasonable degree. Many things are way easier to do than in other programming languages. Don't write it off.
I hope it replaces Javascript in the future.
CPS - continuation passing style, I assume
Comparing apples to oranges
I worked on a WASM port of the SNES9x SNES emulator ~6 years ago. One of the bits I worked on was touch UI for mobile web (never was able to get sound working on mobile, but meh). It wasn't that hard to take a button or keyboard press and call a C++ function as a result to do controller input. But I *really* wouldn't want to have DOM Event -> C++ -> Update DOM, there just aren't that many use cases where JS is not a valid substitute for C++ in that flow.
JS has very weak time of existence tracking. It's hard to manage resources in JS
Well... Akshually, wasm can't win because it's not competing with JS and wasm dont want to replace it.
If people are trying to do everything in wasm including areas it was not design to of course it will have real issues.
Yeah exactly. People seem to think they want to write their next web application in C++, because blazingly fast 🤦🏻♂️
"It's 40ms faster & only took me 9 months longer to get it deployed.. winning"
13:14 to elide is to omit code that doesn't affect the behavior.
For example, if the code contains an "if ( false )" block, the block will provably never be used so it can be removed.
Admittedly a very simple example, but I hope it's shows what I mean..
Theo not even knowing what elision is really shows how he should probably just avoid talking about WASM - a standard designed for higly performant code and systems progreamming languages. Clearly isn't his area, the guy only uses typescript lol.
Javascript has language/job security built into the way it is designed.
The key advantage Javascript has is that its runtime is fully owned by the browser. Standard library, garbage collection, etc all already exists on the users machine, and all that needs to be shipped is the user code. Something like Go compiled for WebASM is then at a huge disadvantage size-wise as it needs to ship the runtime+libs along with the compiled code, including everything that article talked about.
Maybe a future WebASM spec (or extension) could include runtimes/standard libraries for more popular languages to interface with? It sort of defeats the point, but the alternative seems to be that languages with a runtime will be inherently disadvantaged. Though as you say, MicroPython possibly provides a way forward.
"A hello world in Go takes 2MB therefore the people that say that the future of the web is Rust don't know what they're talking about"
Because WASM needs to be small, it needs to be able to call on a rich ecosystem of standard functionality. This keeps everyone from reinventing and downloading the garbage collector or the "display" command except for some language-specific glue code.
This. If browsers came with standard libraries for WASM, the bundles could be much smaller.
Maybe dynamic libraries (like .dll or .so) could be distributed through CDNs and cached by the browser. If many websites use the same library, it would only be slow once per user.
The only way we can finally get rid of JS is if browser vendors start implementing a different language as an alternative to it. With all the frustrations, I'm actually surprised neither Google nor any other big browser/tech company has done it.
I got upset when I found out I couldn't use only wasm to author a web page, you still have to use javascript to make it happen. I was hoping something new was coming so we never had to touch JavaScript again.
"Is Guile the new Scheme?" - Guile is old and mostly niche, but getting more popular in recent years. Whiffle is just a test-system to test the whippet garbage collector that’s meant to replace the current garbage collector in Guile. And Wingo has professional experience working on the just in time Javascript compiler engines in browsers.
The reason Wasm is bad on display is because it actually cannot even talk to the DOM at all. WASM can only talk through messages to the calling JS runtime and js is required to both start and interact with wasm and will also do any dom manipulation.
This was because it made it much easier to create a stable sandbox and not having to have any browser specific api's in wasm, wasm runtime is the same on all browsers.
I think wasm was never intended to replace webpages as such, it was always intended for web applications, like photoshop, word, excel, ... and games.
But that is a more slow moving audience since targeting wasm is not just selecting a new target, it will require changes in how things are loaded and save and much much more.
The article notes that Go compiled to WASM is at least 2 MB, and Python around 20 MB.
But it fails to mention that Kotlin, which isn't a lower-level language, can compile down to 3 kB of WASM.
Of course adding dependencies is gonna increase that by a factor, but it's still pretty great.
edit: sorry, when the article came out, Kotlin couldn't do that
Why the Scheme hate?
Nobody hates Scheme. It's an awesome language.
why did i just waste 3 minutes of my life watching a guy read an articleto me i could have read myself...
I came in skeptical of the title, but I think the title is not what the article is about.
I don't think there's anything wrong with WASM. If there's an expectation that WASM conquer the web such that every page is using it, I agree that won't happen. That being said, some really impressive applications (not just web applications) work in the browser because of WASM. That alone should be seen as success.
I believe that there's an idea floating around that _web_ assembly is an unfortunate name. There's lots of potential here! Maybe not to replace WordPress sites, but as a common compile target that promises simple deployment.
I actually think the article is pretty good and makes good points, but there's expectations built in that I don't think were ever really the goal.
Thanks for the vid!
17:41 I‘m so done with Python‘s unsoundness. Everytime there’s a bug, you can’t tell by looking at the code wtf is happening. I have been fighting cloudpickle + pedantic all day. Turns out you can‘t f**##* pickle Pydantics data classes for reasons. Any f*#** library can do whatever the f*#** they want semantically, do some reflection, or monkey patch my code and break my linter. Good luck chasing obscure incompatibilities.
Correction about C# Garbage Collection - you can run a garbage collector in C# or utilize AOT to get around that.
Ahead-of-time (AOT) compilation is a technique in Blazor WebAssembly (WASM) that precompiles C# code into WebAssembly bytecode before it's sent to the browser. This allows the browser's WebAssembly engine to directly execute the C# code, instead of the Mono runtime interpreting it. AOT compilation can significantly improve runtime performance, especially for applications with a lot of C# code or those deployed over the internet.
Shout out to Leptos!
Maybe zig's big emphasis on directly controllable and flexible linking, lack of runtime polymorphism and custom allocation strategies might actually let it do well in the wasm world.
I like these "reading an article" videos. Great balance between reading the article, trying to understand it or rephrasing and own opinions 👍🏻
WebAssembly ultimately struggled to gain widespread adoption due to its lack of direct access to the Document Object Model (DOM). This limitation made WebAssembly cumbersome to use, as developers had to rely on JavaScript proxy functions to interact with the DOM, introducing an additional layer of complexity that hindered its adoption.
People are looking into wasm images to replace docker containers, which can often lead to 10x smaller containers (think 30mb instead of 300mb) and much shorter start-up times, making the FaaS pattern maybe finally a not completely terrible idea.
Only downside is that docker containers generally are very nice to work with because you can add a shell and other tools in your dev image and just inspect what is going on in the container when you're troubleshooting. Not sure how easy that would be with wasm containers.
WASM is not blowing up because most people cannot do C, C++, Rust, Zig, etc. and can only use toy languages like JS and Python. Ecosystem maters. Having many inexperienced developer using in your toy language ecosystem makes you grow much faster than if you have a handful of pros doing your sophisticated language.
Python having DOM as a UI layer is something that should just be upstreamed to main python. Big agree that it is not a problem. More like an opportunity
You know, this might actually be an advantage for languages like Java/Scala/Kotlin and C#, because they are STATICLY typed GC languages. The only risky area is with the use of reflection and proxies. I know Java already had code minimizers with the maven-shade-plugin and recently Java made big strides towards being natively compilable, where you only needed to add some hints for which pieces of code uses reflection and proxies. It brings down startup times for Spring Framework projects from 2s (sometimes even upto 20s) all the way down to 50 milliseconds! Kotlin is ahead of Java in this regard and has a whole Kotlin Multiplatform toolchain that allows for native compilation that can also target WAsm.
Another issue with it: I have not seen a single Demo which really runs on iOS.
I think the article really hits the nail on the head when it referenced garbage collection. The issue with WASM isn't a problem with WASM but a problem with the browsers. They point out that if you have to implement your own GC then WASM is not ideal, but now that it's starting to be built in to the browser it's much more viable. I feel this has to happen with more of the issues that are plaguing WASM. If every JS application also had to ship the entire JS runtime then we could point to it being inefficient too. However we don't, the browser has pre-shipped the JS runtime to every user's computer before they ever even visit your site. So as more and more of the issues come "presolved" in the browser we can start to really compare apples to apples.
What do you think about WASM being used to run a whole Wordpress instance in your browser / client-side? Seems crazy to me.
Honestly it makes Wordpress Demos for Plugins/Themes great since you don't have to provide a server for that anymore.
Honestly, not a bad idea. Makes starting up/exploring/testing super approachable. Just visit a static web page, and you’re off to the races.
But yeah, no-one’s arguing for running wordpress on end users devices.
Javascript developer meets the concept "compile to machine code". What could possibly go wrong? It is like learning C, C++ or Rust to improve performance-critical parts of a python program. Back to school for a year or so to be able to do that.
I think that is the problem of WASM: the frontend developers lack all the experience and knowledge to work with those languages that are able to deliver efficient WASM code, and that covers everything from understanding a new programming language with a lot of features not there in Javascript to the workflows and tools needed to really built a web page with WASM. Especially compared to Javascript any compiled language is a totally different beast seemingly from another planet. When Javascript developers find it difficult to apply Typescript to their (or their users) benefit that is telling enough. And it just starts with strong typing, it doesn't end there.
Author completely missed that tree shaking is referring to the branches that aren’t connected fall out when shook. This does happen when the wind shakes trees. Feel free to inspect my yard after a storm. Woosh
whenever you have access to a browser, you always also have access to the OS hosting the browser. Only Google would care about not being to spawn another process in the computing platform for their products.
"I love Rob's honesty, I just don't love his design decisions, his choices, his language or much else about him... But at least he's honest"
HEAR, HEAR LOL
Our PDF library uses wasm, which aligns with your statement about image processing.
it seems like haskell/ocaml/etc. type languages could be exceptional with tree shaking in regard to their use of pattern matching
WASM has utility as a target platform even if tree-shaking isn't done thoroughly to keep result binaries small
What's lacking is the bindings between the DOM or the JS API's and wasm, rust has overcome this sort of with wasm-bindgen, csharp probably has it's own implementation.
But what I suspect you'll end up with is Language (rust / csharp / JS) -> WASM (effectively a compiled IL or Intermediate Language) -> Browser
Compilers already remove things they don't need, all of the hacks done within javascript for building JS or TS to JS or removing uneeded code or implementing JS modules, is due to the way the language was originally designed, normal compilers have been doing this for a much longer period of time.
Those sizes and dependency reductions are needed in web and embedded for sure, but also super beneficial in cloud native space where you don't hard assume where a program is running, so size effects' startup times and scalability. There is also just the security piece in which large code trees mean more exploitable logic, which if you can reduce platform variability, means you can cut down the attack surface.
It seems like WASM the biggest hurdle is the fact that it has to bring with it all the stuff the browser is doing now for JS.
Wingo is really smart and I'm so glad he was involved with rewriting Guile. Scheme is my favorite language and he really modernized the Guile implementation of Scheme.
Rust WASM actually isn't terrible, the toolchain outputs way more compact stuff than Go. I have a chunk of code that takes a chunk of DSL text, parses it, processes it, and spits out an svg render... 185kB of wasm, a shade over 7kB autogened js wrapper, and a dozen lines of js to say "when this element content changes, pass content to the function and shove the result in that output element's innerHTML"
Part of it is that Rust was designed to target embedded platforms... you can compile for assorted ARM and microcontroller targets... I'd say they understand compact binaries.
is the TLDR summary of this video mostly about the size of the code that's shipped?
yep
As soon as I saw he was a scheme guy I knew every single one of his opinions is correct
why we are trying to run rust on a browser and run js on the server? where all the right tool for the job has gone?
Did anyone ever expect Wasm to be used for web frontend? It's not like frontend is computationally intensive. Wasm was born to replace ActionScript after the death of Flash. It does so with flying colors. But using it for anything other than a single component in a page doesn't make a great deal of sense.
That's some retro looking blog post
background-color: "retro-pink";
So, we will eventually get to the point where we have other language + WASM frequently in production, it's just not here yet
Everything was fine until the word scheme appeared, at which point I knew the rest of the article was going to be incomprehensible gibberish.
11:00 There are actually pretty good Python UI libraries out there like Kivy with Kivymd, PyQT5, Pyside and so on.
.NET has been making intentional improvements in space, which is called "trimming", (tree shaking) for several years
learn.microsoft.com/en-us/dotnet/core/deploying/trimming/trim-self-contained
Blazor is by far my favourite framework we use it for several webapplications, the people who say it sucks really need to describe why because I aint seeing it.
I rather use it than React or Angular
Our business moved our frontend from JS to WASM a year ago, and it's probably been the best architecture decision we've made in years.
WASM frontend UI libraries / using WASM for actual web pages / web apps development interacting with the DOM, will get better only when WASM will finally gain APIs for direct DOM manipulation, instead of having to pass to a JS context the DOM manipulation needing to be done and manipulate the DOM from javascript, which is currently the only possible way to do things and what all WASM frontend libraries currently do.
I can't believe this haven't been pushed harder yet, it's a much higher priority IMHO since it's what would allow to build interactive web apps that are more performant than the current JS ones, when writing the WASM in a low-level, performant, non-gc'ed language such as C/C++, Rust, Zig, etc. It should be priorized over GC because there really isn't much point in writing WASM in C# / Python / Go / other slow, gc'ed languages, as it wouldn't even be significantly faster than javascript anyways, and the only realistic real purpose would be for reusing code in situations where the backend or other key components are written in that language.
"This is a math thing. I am not smart enough for this. I am a JavaScript dev."
That kinda exposes why JAvascript is considered a mess and why it will be the lang to go for a good while for the mainstream web usage for many years yet (but I hope someday Python can be DOM-friendly)
The hype cycle isn't scientific or a real thing. Every attempt to try to find data that supports it has showed no significant correlation. It's just something podcast bros mention to try to sound smart. Brands generally hype their product in advertising, but that doesn't tell you whether or not the technology is actually going to be useful or impactful. If you just look at what it does and what it's application might affect, you'll make a better prediction.
I have about 5 production apps running Blazor in the browser, WASM specifically. I migrated a svelte app to a Blazor app too. Hopefully WASM does keep improving and spreading. We use very little javascript considering the apps aren't scary big but they are not small. Interesting video here, thanks
Actually,. WASM is still incomplete. There is a direct interface missing that allows to influence stuff like GL contexts, DOM, etc. directly from web assembly. Without that, WASM is still just another way to write very reduced workers for cetain loads with the added ability to have other languages compiled to it.
Just because that doesn't exist doesn't mean you can't write it yourself.
@@angelcaru in what context? As a JS Interface? Same issue. As a browser extension? Needs to be supported by the vendors or you can't do it. Write your own browser? Unlikely.
@@alexlohr7366 ...you can expose JS functions to WASM. How do you not know this?
@@angelcaru but you cannot access objects from wasm, thus you always need some kind of (de)serialization, which slows things down.
@@alexlohr7366 Or you could do what OS kernels do and return some sort of index (descriptor) into an array of DOM elements. Then your functions could operate on those descriptors.
did everyone forget browsers have disk cache and can keep js bundles or wasm basically for a long time without redownloading?
Though you're saying rust in the browser is not happening, while the blog post is focusing on dynamic programming languages problems because tree shaking is so difficult in those languages. In Rust this should not be so difficult, and a garbage collector (for example) is not needed.
WebAssembly is pretty successful for web games, as far as I can tell. All of the main engines such as Unity, Godot, Defold are heavily reliant on WASM for their HTML5 export. WebAssembly wasn't designed "to win", it's just another valuable tool in the box. Personally, I'm glad that it's possible to write games using Lua and C++ and have a bundle smaller than 2mb.
Wasn't the original concept for JS is just to put Scheme into the browser? Or was it a different lisp? If so, then after all those years, finally...
Yes, I believe you are correct. IRRC The original developer, Brenden Eich, was planning on basing it on Scheme and then some higher ups/marketing people in the company he was working for told them to make it look like Java because it was the hot new thing at the time (Sun was doing its big Java marketing push then). This is all despite the fact that Java was really the opposite of what the language needed to be.
tl;dr we end up with the situation we have today where JS is basically a completely different language squished into a mold and named to look like Java on the surface for marketing hype in the 1990s.
I would mention that there have already been various kinds of ports of Scheme and other lisps to the browser. The development of Hoot and WSAM are just the final pieces that they need to be able to become more than just alternate syntax and actually harness the full language as if it were the native scripting language for the web. Everything before has been basically cross compiling or one way compiling to WSAM (i.e. can execute but has no way to interact with the DOM and stuff--Hoot is working on FFIs and other stuff to actually integrate it into the larger environment).
I thought tree shaking was about shaking the ripe fruit off of the tree.
WASM is a tool. It's not here to replace JS, it's here to use where needed.
Native game engines like Unity and Godot use it when porting to web.
JS game engines use it when needed better performance for physics simulations or audio.
Same for graphical editing tools or Audio mixing tools.
And that's already large amount of content.
That's precisely what they're doing with .Net, they call it trimming
wasm just isn't done yet. it still lacks dom api and gc
and yes, they saying all the time that 'wasm isn't a replacement for js don't you worry little fella' was stupid move from the start
The argument seems to be that WASM is bad because it is a bad fit for languages that make it impossible to perform global static reachability analysis with any sort of accuracy, because in such cases it will blow up the shipped code package size. I feel like this argument doesn't necessarily support all the conclusions being drawn, and could be applied in reverse.
I was suggested this video randomly by CZcams, and I don't have any professional web background, but I have spent over a decade in C++ compiler research and engineering. To me it seems like people are currently trying to do things that have been pretty well understood for quite a long time already in e.g. C++ compilers in languages that make it much harder or even infeasible (this does not apply to Rust). Between that and the general maintenance and scaling issue of code written in dynamically typed languages -- which leads to retro-fitting additional static compilation steps such as in Typescript -- I think an alternative conclusion could be that people should consider languages which inherently support more in-depth static analysis. At least when building new software at larger scales or with more stringent latency or throughput requirements. If neither of those apply to some or even many web applications, then WASM wasn't and isn't needed for those "simple" use cases, but I wouldn't consider that a failure of WASM.
I really like the idea of WASM, being able to easily run other languages on the web instead of JavaScript. Sad to see it failing currently.
We use wasm at work to ship the backend config validation to the frontend. Makes life much easier, as we can give the user immediate feedback
Tree shaking is named after shaking trees, beautiful analogy
I'm working on a blazor application right now, I think the title is wrong!!!
I don't think I've ever seen this channel offer an original opinion - only reading / reacting to other, more experienced/knowledgeable posters.
Yeah “tree shaking” is also a thing in compiled languages (see dead code stripping, link-time optimizations, and so on). We use Wasm for the frontend and it allows us to share our core app code across 2 mobile platforms and web. The code size issues are a consideration but also becoming more of a consideration for compiler toolchain devs.
Wasm has some compelling utility, but it's not so much about the immediate frontend usecases - nobody wants to continue on with heavier and heavier Web pages - it's about the potential enabled by applying it as a protocol across the stack. One of the underlying issues with systems coding is that hardly anyone wants to attempt to untangle the deepest parts of the computing stack, and among those is the thing of...how to share and reuse code, in a sandboxed way, with some degree of modular permissiveness to access resources and I/O, like "access files" or "access the microphone". The answers we have right now are various forms of "build from source" or "a package maintainer does it" or "whatever monstrous thing Android has going on". Wasm with WASI adds another option - not a perfect all-cases panacea, but something that you could feasibly say, "yes, we could have an operating system start doing interesting things with this". And there are some efforts to explore that happening right now.
JS community asked WASM: "Wasm, you can replace JS because you are strong, or you are strong because you can replace JS?".
Stay proud WASM, you are strong.
So Theo asked WASM: "You will lose?".
WASM replied: "Nah i'd win"
I'm surprised they didn't implement malloc in wasm. Fast malloc that doesn't need to be downloaded would be preferred by most compilers... working on my own :)
Imma see where my journey with Avalonia UI go. They added WASM targetting not so long ago