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

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

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

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

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.

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.

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

This will age poorly

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.

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

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

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 would love a time where I no longer need to use JS for the frontend. I hate JS

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.

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

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

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

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

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.

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

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.

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

CPS - continuation passing style, I assume

Comparing apples to oranges

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.

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.

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

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

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.

Why the Scheme hate?

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!

Shout out to Leptos!

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

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.

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

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.

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

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.

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

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

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

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

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.

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.

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

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

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.

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?

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.

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.

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.

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

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.

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.

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.

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

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.

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

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

That's some retro looking blog post

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.

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

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.

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

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.

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.

Pyodide, Python with the scikit stack etc. in the browser, is a decent success story for WASM. If you can deal with the startup latency, you do get full DOM access, and it's easy to animate matplotlib stuff and do heavy duty numpy stuff like pytorch client side.

I'm working on a blazor application right now, I think the title is wrong!!!

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.

It’s used plenty on the 3D/WebXR side (: rapier physics for example

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

how about Blazor ?

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.

13:14 - because if you do tree-shaking on your prose, you end up with the words that are exactly the right word for what you're trying to say, when you know them. 😉 13:17 - to elide is to leave something out, by removing it -- like if I strike -out some needless extra- words, I have elided them.

Why not just let webassembly use certain trusted libraries you installed in your machine so if you already have a 400MB Python install it will use that and only have to download the 10-50 KB code. Also why not have a HPL (High-level processor) that can do stuff like hashing, hashtable lookups, resizing arrays, going through pointers very quickly, very quickly.

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.

WASM has utility as a target platform even if tree-shaking isn't done thoroughly to keep result binaries small

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

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.

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.

I think wasm on the server will be a thing. JS Frameworks will ship their renderers as wasm. Thus any backend framework can render Vue, svelte etc.

I like wasm on the backend side. Its pretty neat to pull in a highly optimized rust module or entire library for speeding up the otherwise adequate node backend.

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

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

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.

Great points, but as somone who specialized on pagespeed opitmization for CMS like wordpress or shopify. People dont a S about preformance. I think wasm will never be main stream because finding devs who know wasm well is just more expensive and most project owners will see no cost benefit in letting backend devs avoid writting js.

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

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

Makes me remember when I naively tried pyodide to bring pandas to the web for compat with a django app we had at IBM, 20MBs is the *baseline* good read, thanks for the vid

UE 5 back on the web?????? Sources?

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.

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

Thing is, tree shaking was a problem before WASM. Before bundling, JS libraries usually exported a giant object with the entire api hanging off it as methods. With bundlers and ESM coming into the picture, that culture has changed and now people are able to import what they need from libraries instead of importing the entire thing. None of these compiled languages were created with the Javascript ecosystem in mind, obviously. There are probably some languages out there that are better candidates for targeting WASM than others. There could also be new languages created just for the purpose of compiling to WASM, that would be interesting

5:07 You bombed out your bundler video?, so you bungled it then? Even with bun? or one of the bunch? Bummer!

The one use-case for WASM that seems most interesting to me currently is durable computing - like what Golem is doing.

You know the only language I ever needed on the web that I absolutely could not just use as a service, was in a HIPAA environment we wanted to be able to run some R code, but because of the data privacy issues, the large size of the data set and the and the sorta of disposable nature of the action we expected the need for this tool to be for... it was just nixed, because we couldn't get it to work, our customers would have had zero issues downloading a 50mb wasm file, (corporate network) but didn't want to have to create a new secure data store and go through the documentation process for this new end point, auditing etc.... if we could do it all on the client processing this 2gb of data or so with R in a browser even if it were ungodly slow... it could have been viable tool.

I like WASM cuz now i can finally use a decent language for coding. Not forced to use javascript etc. For .NET having the full power of .NET in your browser? That's sick! But i'm not doing web projects atm, i'm sure there are drawbacks. Also i think WASM is probably a lot harder to learn for beginners than basic html / js / css. You have to understand the basics before you start with WASM and then you already have a job coding in JS.