Why WebAssembly Can't Win

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/a...
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏

[@peesem]

first video i've seen from theo where he isn't constipated in the thumbnail

[@everyhandletaken]

😂

[@BleedingDryTheHeart]

😂

[@danmm13]

I pressed back to look at the thumbnail, and I must say, he does look surprisingly relieved.

[@reyariass]

It’s 1am when he uploaded, probably took a dookie

[@ganeshkale9665]

Bro waited this long to say that

[@LiveErrors]

It's not like JavaScript can win either, JavaScript isn't even compatible with JavaScript

[@sidma6488]

oof

[@ShrirajHegde]

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.

[@thedreamingtechie]

Real 💀😅

[@timvw01]

😂😂🎉

[@LtdJorge]

JavaScript !== JavaScript

[@msclrhd]

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.

[@ElliotGuy-tp4si]

.NET CLR*.. CRT is the C/C++ standard library

[@johnpekkala6941]

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.

[@StupidusMaximusTheFirst]

this ^^

[@Makefile_dot_in]

> 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.

[@mgord9518]

WASM is not a subset of JS, it's an entirely different language with its own runtime

[@TankEnMate]

It is difficult to get a man to understand something, when his salary depends on his not understanding it.

[@C15-w4e]

damn,this is super on point. Well done. Do you know any company structures that were successful in fighting this flaw?

[@TankEnMate]

@@C15-w4e Sure, the "accepted" way to adapt to Innovator's Dilemma (Clayton Christensen) is to have a two track management stream; one track is to sustain what is working now, and the second track is to develop innovative responses to the status quo. Then comes the hard bit, when to cannibalise the status quo and go all in on the innovation. Obviously less enlightened managers in the sustainment stream will constantly try to undermine any threatening innovation. And the overly enthusiastic managers in the innovation stream will see panaceas in whatever they are working on. Let the games begin!

[@PLay1Lets]

@@C15-w4e its capitalism. we go make a new organisation with better understanding.

[@TorpedoBench]

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.

[@s-mo]

I guess that counts as "Limited success" these days.

[@bilza2023]

what ????????????????????????

[@vectorlua8081]

"This looks like a math thing, I'm not smart enough for that, I'm a JavaScript Dev" rofl.

[@_skyyskater]

I came here to write this comment LMAOOO I feel attacked

[@the-sides]

me af

[@privacyvalued4134]

In other words, he doesn't know how to write real software.

[@inujung8224]

@@privacyvalued4134 he knows. he is just joking. he had been working with other languages before he was a javascript dev.

[@snk-js]

@@privacyvalued4134 I am a javascript developer am I agree

[@AmirHosseinHonardust]

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.

[@Mr_Yeah]

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.

[@AmirHosseinHonardust]

@@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.

[@Mr_Yeah]

@@AmirHosseinHonardust Same

[@julesjacobs1]

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 KZbinrs 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!!!".

[@loutishduke4146]

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

[@MC_DarkMaster]

We're also using Blazor for very different projects. Which application do you work on with Blazor?

[@loutishduke4146]

@@MC_DarkMaster Remote Desktop control through browser, application streaming, and systems control sort of stuff; not the most intensive, not the lightest

[@Kane0123]

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.

[@loutishduke4146]

@@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

[@enriquellerena4779]

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.

[@Heater-v1.0.0]

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.

[@canadiannomad4088]

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.

[@xybersurfer]

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

[@Heater-v1.0.0]

@@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.

[@canadiannomad4088]

​@@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.

[@Hexanitrobenzene]

@@Heater-v1.0.0 "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." I'm quite sure even then it can be engineered to download it once and reuse it whenever needed.

[@cherubin7th]

WASM is held back by insisting that it being forced into the JS madness.

[@BlackwaterEl1te]

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.

[@slebetman]

To be fair, JS is a lot more sane than assembly. Especially x86 assembly. And people still buy Intel and AMD powered CPUs

[@sonicjoy2002]

@@BlackwaterEl1te Yeah, I think DOM api is the way to go.

[@Kane0123]

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.

[@TankEnMate]

@@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.

[@sortof3337]

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.

[@SeanJMay]

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.

[@proosee]

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.

[@ky3ow]

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?

[@michaelfrieze]

@@ky3owthey didn’t actually read the article or watch the video.

[@diadetediotedio6918]

​@@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.

[@VivekYadav-ds8oz]

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)

[@SeanJMay]

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.

[@diadetediotedio6918]

@@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

[@SeanJMay]

@@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

[@autohmae]

@@diadetediotedio6918 maybe because the user can see it's slow to load, so they just give up ?

[@Milan____]

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.

[@roccociccone597]

I would love a time where I no longer need to use JS for the frontend. I hate JS

[@monad_tcp]

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

[@monad_tcp]

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.

[@gmodrules123456789]

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.

[@monad_tcp]

@@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.

[@simpleprogrammingcodes]

Yeah, Scheme would be much better.

[@thurston04]

Wasm has been huge for me. I use rocket and dioxus in rust and the dev experience is amazing

[@williamheckman4597]

You should make some videos!

[@kai-.-man]

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?

[@thurston04]

@@kai-.-man I've never tried leptos honestly

[@snwdn]

@@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.

[@DonAlonzo]

Dioxus is amazing. WASM is fantastic.

[@clashgamers4072]

This will age poorly

[@moonskined]

Why

[@jacobgreenfield2684]

@@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.

[@benaloney]

WASM has been supported in Chrome for 7 years.... and you could still compile it to raw JS before then....

[@brawlgammer4424]

@@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.

[@SeanJMay]

@@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.

[@soverain]

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.

[@ymi_yugy3133]

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

[@CryZe92]

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)

[@andy_lamax]

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

[@Dhalucario]

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.

[@SeanJMay]

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?

[@marioprawirosudiro7301]

@@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.

[@SeanJMay]

@@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.

[@duartecunhaleao]

It's just a click bait title... which isn’t really supported by the content of the video...

[@phizc]

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..

[@joestevenson5568]

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.

[@user-om5es2zp7k]

Many people forgetting WASM allows many languages to used in browsers, instead of just being limited to just javascript

[@_____case]

Oh shit, another hot take from Theo that will probably age poorly.

[@_____case]

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.

[@SeanJMay]

@@_____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.

[@TurtleKwitty]

Theo speedran this one; it doesnt even need to age to be poor it's a poor take from the start XD

[@s-mo]

Will? Thing can be labeled "this aged poorly" after exactly 1 views. It’s a talent.

[@CamaradaArdi]

"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"

[@miroslavhoudek7085]

It has always been an important feature of DOM, that family comes first.

[@benaloney]

"It's about family" - Vin Diesel (DOM Advocate)

[@ark_knight]

@@benaloney (Family lover)

[@jaredsmith5826]

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.

[@OCTAGRAM]

JS has very weak time of existence tracking. It's hard to manage resources in JS

[@retakenroots]

I build a PS1 emulator in pure JS and found out that if you program JS in a C style it tends to perform better. Writing a recompiler is JS relatively easy as you can generate functions on the fly. Have written tons of C, C++ in my days but nowadays only JS because for 95% of the use-cases it is sufficient. I have played with WASM but still do not see the benifit

[@bugged1212]

Javascript has language/job security built into the way it is designed.

[@PerryWagle]

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.

[@simpleprogrammingcodes]

I hope it replaces Javascript in the future.

[@Hexanitrobenzene]

A 3D printer for domain specific languages :)

[@joaopedrodeamorimpaula8965]

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...

[@NuncNuncNuncNunc]

CPS - continuation passing style, I assume

[@stevenhe3462]

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.

[@brennan123]

Why the Scheme hate?

[@simpleprogrammingcodes]

Nobody hates Scheme. It's an awesome language.

[@Dominaer]

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.

[@everyhandletaken]

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"

[@RemizZ]

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.

[@Burity28]

Actually, Google tried to make an alternative to JS, Dart, the language used in the flutter framework. Dart uses a virtual machine that compile to native JS to make web apps before web assembly existed, but it was never embraced by the web dev community

[@dodrian]

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.

[@omiraclx]

Comparing apples to oranges

[@beauremus]

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!

[@davidmartensson273]

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.

[@De-Panther]

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.

[@davidsiewert8649]

tldr: WASM is dead and will be the next 3-5 years for general web dev (only exceptions being audio/video/graphic processing editors)

[@chris-pee]

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

[@Nikoline_The_Great]

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.

[@xelaxander]

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.

[@vsolyomi]

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...

[@kanoaika]

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).

[@ArneBab]

"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.

[@be1tube]

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.

[@oznerol256]

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.

[@bigpod]

@@oznerol256 that is already done but sadly using standard browser caching rules, i use blazor(c# wasm) for perosnal stuff and everything for my personal sites i have is cached on i belive per site basis and it loads super fast after first time after update which takes a bit as it downloads

[@simonhartley9158]

Shout out to Leptos!

[@SelfMadeSystem]

it seems like haskell/ocaml/etc. type languages could be exceptional with tree shaking in regard to their use of pattern matching

[@hoople212]

why did i just waste 3 minutes of my life watching a guy read an articleto me i could have read myself...

[@stephenjames2951]

Our PDF library uses wasm, which aligns with your statement about image processing.

[@CoolestPossibleName]

WASM is still at an early stage.

[@_mosesb]

11:00 There are actually pretty good Python UI libraries out there like Kivy with Kivymd, PyQT5, Pyside and so on.

[@ethnicstyledotca]

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.

[@alexandrecolautoneto7374]

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?

[@protocol6]

I thought the tree shaking analogy was about shaking out the ripe stuff that you actually want. It's a common way of harvesting certain fruits that are likely to fall off when you shake the branches. They have special machinery to do it now with nets and a big hydraulic claw that grabs and vibrates the trunk but people used to lay out blankets under the tree, climb it and shake the branches manually.

[@alexlohr7366]

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.

[@angelcaru]

Just because that doesn't exist doesn't mean you can't write it yourself.

[@alexlohr7366]

@@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.

[@angelcaru]

@@alexlohr7366 ...you can expose JS functions to WASM. How do you not know this?

[@alexlohr7366]

@@angelcaru but you cannot access objects from wasm, thus you always need some kind of (de)serialization, which slows things down.

[@angelcaru]

@@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.

[@Genuigr]

What do you think about WASM being used to run a whole Wordpress instance in your browser / client-side? Seems crazy to me.

[@Dhalucario]

Honestly it makes Wordpress Demos for Plugins/Themes great since you don't have to provide a server for that anymore.

[@yapet]

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.

[@Tekay37]

I also think wasm has some design flaws that just don't appeal to an average developer like me. When I was 16, one of the reasons I stopped learning C and C++ but went to PHP instead was because I hated header files with a passion and I just wanted to have the basic functionality available to me. I didn't want to be side-tracked with stuff that isn't directly connected with the features I wanted to implement. wasm brings back that hate for header files, because not only do I have to manually import every Javascript feature I want to use, I also have to manually import everything from the wasm file that I intend to use. The compiled wasm file should tell the browser everything it needs to know, so you can just use its functionality inside HTML and importing browser features into your language should be one line of code. For some reason they decided to make it more complicated for the developer and I think this is another aspect that is holding wasm back from being widely adopted.

[@godhandinfamous]

is the TLDR summary of this video mostly about the size of the code that's shipped?

[@xybersurfer]

yep

[@zebedie2]

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.

[@Waitwhat469]

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.

[@rikschaaf]

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.

[@KaitharVideo]

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.

[@doriphor]

Tear it all down. I want the web to be JIT C++ / Vulkan. No more DOM, no more CSS, no more JS

[@dorusie5]

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.

[@bigpod]

as someone who is in that world honestly docker containers are my prefered way of doing things becuase honestly if you know what know what tp do its easy to get WASM sizes with docker (actually going so far down to basically size of executable and dependancies plus whatever tools you want in there for debug(sh, ls and bits)

[@mayuinc]

WASM was designed to fix problems that shouldn't exist in the first place.

[@mikeyangyang8816]

I am have been making a end-to-end encrypted system for a while now (web app server and mobile apps). In browser apps, there is no other way to make extremely complex encryption algorithms work without c++. So I heavily use wasm modules to do that, and I sometimes store stuff in the linear memory of wasm that is controlled by c++ (way better than js ).

[@Nekroido]

Imma see where my journey with Avalonia UI go. They added WASM targetting not so long ago

[@markussuula1346]

I like these "reading an article" videos. Great balance between reading the article, trying to understand it or rephrasing and own opinions 👍🏻

[@isaactfa]

What an odd article. Shipping an entire Python repl is heavy? Who knew. wasm isn't used for DOM manipulation? Almost like there's no native DOM API for wasm yet. I for one think wasm is going to be an utter failure because building all of V8 for wasm and shipping it to your browser to execute your page's JavaScript isn't gonna be fast. How are Figma, Photoshop on the web, Photopea, etc. not proof that wasm is _already_ a success. Even if everyone decided tomorrow that no piece of performance critical code will ever need to be run in a browser ever again, having those apps on the web is incredible.

[@everyhandletaken]

That's some retro looking blog post

[@Haffi921]

background-color: "retro-pink";

[@DavidAlsh]

I'm hopeful we will get more functional access to the browser through wasm. I know you hate it but once you grit your teeth through the first couple weeks, Rust is kinda lit. Having the ability to throw threads threads at a problem and it be impossible to mess up is really awesome (and makes reviewing PRs so much easier). Unlike mobile apps, the performance of complex web apps today is heavily affected by the constraint of being on a single thread (don't talk to me about web workers) - I think that writing a web app in Rust would be friggin awesome. Will it ever be practical? Idk, wasm was announced in 2008 and we still can make a div without heavy glue code 🤷

[@blahblahblah118]

So I know very little about web stuff, I'm and old C coder so I could be way off here. But tree shaking seems like a dynamic language thing, and not really a WASM problem. If you were to just write code in a static language stuff like 'display' isn't possible so you can't have that issue to start with.

[@steve_jabz]

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.

[@3a146]

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.

[@victor-ling]

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.

[@trashhater9304]

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"

[@olafschluter706]

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.

[@bbqchickenrobot3]

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.

[@Verrisin]

TLDR: it's WASM, not WIL. WASM is just a shared "Assembly language". It's not supposed to do more optimizations than a CPU. - All optimizations done on assembly are meant to be about translating "intrinsics" into available instructions where possible. -- Now, maybe one day there will be _another_ layer, more optimizable, but that will be way more complex too.

[@Verrisin]

The whole point is that a DIFFERENT compiler, that specializes in producing fast ASM code, will produce ASM code that can run ANYWHERE, and is somewhat sandboxed. The optimizations are done by GCC / CLANG / Rust / whatever. They have nothing to do with WASM.

[@Verrisin]

the reason for GC in WASM, is PURELY so that wasm binaries do not need to bundle GC impl in each of them, and all share one that might even be very optimized. - the WORSE part is the FUNCTIONS TABLE - I have no idea how they will fully optimize that away...

[@Verrisin]

I am not even a big fan of WASM, I just know _what it is._ And that article completely misses that. - Calling that article good is ..

[@louisik1]

What's wrong with 2MB pages? What, are we writing for Voyager 1 and 2? :P The size thing we really need to be critical of is the clown like use of massive space (with 'coool' background images and 'slick' scrolling) between info the user really wants to get to quickly.

[@retakenroots]

Google for 64Kb demoscene video and then wonder why 2MB is big :)

[@cornheadahh]

As soon as I saw he was a scheme guy I knew every single one of his opinions is correct

[@Geosquare8128]

Emscripten is also lowkey a large reason why WASM hasn't been adopted. The way WASM compilation is documented/typically implemented implies you need to subscribe to Emscripten's clunky design choices which adds another roadblock to easy adoption

[@Diamonddrake]

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

[@itskishank]

so basically, non js langauges like python, go, c++ ex were never optimized for small binary/bundle sizes. hence, they're still not that feasible to be put on the web which demands small bundle sizes and fast loading.

[@seangwright]

.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

[@FrederikSchumacher]

You can go with some form of type annotation for tree-shaking, but that's not the only solution. As was noted, usage of code in dynamic languages only reveals itself during runtime and then only if all reachable code was actually reached. Kind of obvious really, that *static* analysis of *dynamic* code doesn't really work. I just find the conclusion "so it must become static" absolutely idiotic. Another way (other than type annotation) to reveal code usage, is leveraging unit testing or other runtime testing. This would allow the testing tool to track "used and reachable" code. Additionally, this means to compile code optimally, it also needs to be tested well. Sounds like a win-win to me.

[@Kazyek]

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.

[@hughmanwho]

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 :)

[@DurantePT]

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 KZbin, 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.

[@---..]

Seems odd to dismiss Rust (7:45) as having too large of modules based on examples from Go and Python (6:50) being 2+ MB, then be excited (12:30) for sub 1kb modules in scheme. Rust can do sub 1kb modules. I've gotten under 200 bytes uncompressed in my most minimal tests (author of lol-alloc here, see it git-hub for sizes of my minimal test rust app with different allocators, though you can make rust wasm apps without an allocator too ). The size or rust wasm code is a problem, but its not the runtime/lower limit that the problem as implied in this video, and not as bad as python or go.

[@Pythagoras1plus]

did everyone forget browsers have disk cache and can keep js bundles or wasm basically for a long time without redownloading?

[@lgsscout196]

As someone deploying a couple WASM applications done in Unity, current state of WASM is ages behind in maturity to be able to replace JS for common browser applications, but it shines when you want to deploy something that until now, browser could not handle, at least not handle well enough. Like, there is a couple JS libraries to render 3D or even entire games in browser, but any of them have the whole toolset of Unity or Unreal? Meanwhile, the performance of these sort of applications are pretty bad yet, compared to a standalone desktop deploy, but for clients that will never install the desktop version, the WASM version is something you can work with. And the whole tree-shaking thing could be good, but there is a downside that is browser integration. To tree-shake a WASM application you will need not just check if any function is used inside the application itself, but will need some sort of marking any function that is exposed to be keep even if not used internally. If not marked in some sort, it will turn in a game of guessing which parts of the code are really necessary, then in the end just throwing the towel and keeping everything. But the whole inner dependencies making a simple hello world have megabytes of size is really a crazy thing, that maybe need to be addressed by the tooling itself, or it will never be a reasonable size unless you have a huge application.

[@pawerobak6655]

Everything what you can do with React or Angular you can also do with Blazor. Also don't forget about Blazor Server model which does not exists in JavaScript framework. From my expierence JS frameworks were first on the market in the moment when we had no SPA competitor. Blazor was 5 years later. Now it is very difficult to make up for lost time even so that for .net backend developers is much faster to start with Blazor rather than with JavaScript framework.

[@user-ti5ce4hg1o]

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.

[@monad_tcp]

maybe we should go back to dumb terminals. wait, hear me out before. decompressing H.264 is incredibly fast and cheap on mobile devices for full-hd screens, why don't we just do remote access instead ? just send the keystrokes and touches and mouse buttons and get back an H.264 stream. its literally faster and cheaper to do that and just have a tag than most of the crap you receive by having 2MB of javascript, there will be some latency, but that can be solved by having some custom scrolling logic that does it locally. the hardware can be highly optimized just for that, and everything else is server side actual native applications, the applications don't ever work anymore offline, there's no point in having SPA applications.

[@coryfitz7012]

So, we will eventually get to the point where we have other language + WASM frequently in production, it's just not here yet

[@yeetyeet7070]

Gartner hype cycle is such clown shit

[@chrisbodley8958]

Web assembly is a great tool in my multi tool obsession. i used it to handle QR reading via web camera. I would prefer to use it selectively. Blazor is a bad Idea and I still have to rebuild the project to see changes. Hot reload doesn't work at all.

[@JH-pe3ro]

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.

[@PoetNoPoems]

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

[@heltengundersen]

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.