A specialized programming language for 3D geometry generation + manipulation called Geoscript as well as a Shadertoy-inspired web app for building stuff with it: https://3d.ameo.design/geotoy
There have been lots of cool technical challenges through the whole process of building this, and a very nice variety of different kinds of work.
I'm working towards using the outputs from this language to build out levels and assets for a browser-based game I've been dabbling with over the past few years.
It seems to me that Wasm largely succeeded and meets most/all of the goals for when it was created. The article backs this up by listing the many niches in which its found support, and I personally have deployed dozens of projects (both personal and professional) that use Wasm as a core component.
I''m personally a big fan of Wasm; it has been one of my favorite technologies ever since the first time I called malloc from the JS console when experimenting with an early version of Emscripten. Modern JS engines can be almost miraculously fast, but Wasm still offers the best performance and much higher levels of control over what's actually running on the CPU. I've written about this in the past.
The only way it really fell short is in the way that a lot of people were predicting that it would become a sort of total replacement for JS+HTML+CSS for building web apps. In this regard, I'd have to agree. It could be the continued lack of DOM bindings that have been considered a key missing piece for several years now, or maybe something else or more fundamental.
I've tried out some of the Wasm-powered web frameworks like Yew and not found them to provide an improvement for me at all. It just feels like an awkwardly bolted-on layer on top of JS and CSS without adding any new patterns or capabilities. Like you still have to keep all of the underlying semantics of the way JS events work, you still have to keep the whole DOM and HTML element system, and you also have to deal with all the new stuff the framework introduces on top of that.
Things may be different with other frameworks like Blazor which I've not tried, but I just find myself wanting to write JS instead. I openly admit that it might just be my deep experience and comfort building web apps using React or Svelte though.
Anyway, I strongly feel that Wasm is a successful technology. It's probably in a lot more places than you think, silently doing its job behind the scenes. That, to me, is a hallmark of success for something like Wasm.
The article seems to evaluate Wasm as it were a framework upon which apps are built. It's not that, it's an orthogonal technology allowing CPU optimisations and reuse of native code in the browser. Against that expectation, it has been a huge success despite not yet reaching bare-metal levels of performance and energy efficiency.
One such example: audio time stretch in the browser based upon a C++ library [1]. There is no way that if this were implemented in JS that it could deliver (a) similar performance or (b) source code portability to native apps.
FWIW the native and WASM versions of my home computer emulators are within about 5% of each other (on an ARM Mac), e.g. more or less 'measuring noise':
Maybe the emulator code is particularly WASM friendly ... it's mostly bit twiddling on 64-bit integers with very little regular integer math (except incrementing counters) and relatively few memory load/stores.
I'd have to take a contrary view on that. It'll take some time for the technologies to be developed, but ultimately managed JIT compilation has the potential to exceed native compiled speeds. It'll be a fun journey getting there though.
The initial order-of-magnitude jump in perf that JITs provided took us from the 5-2x overhead for managed runtimes down to some (1 + delta)x. That was driven by runtime type inference combined with a type-aware JIT compiler.
I expect that there's another significant, but smaller perf jump that we haven't really plumbed out - mostly to be gained from dynamic _value_ inference that's sensitive to _transient_ meta-stability in values flowing through the program.
Basically you can gather actual values flowing through code at runtime, look for patterns, and then inline / type-specialize those by deriving runtime types that are _tighter_ than the annotated types.
I think there's a reasonable amount of juice left in combining those techniques with partial specialization and JIT compilation, and that should get us over the hump from "slightly slower than native" to "slightly faster than native".
I get it's an outlier viewpoint though. Whenever I hear "managed jitcode will never be as fast as native", I interpret that as a friendly bet :)
> JIT compilation has the potential to exceed native compiled speeds
The battlecry of Java developers riding their tortoises.
Don’t we have decades of real-world experience showing native code almost always performs better?
For most things it doesn’t matter, but it always rubs me the wrong way when people mention this about JIT since it almost never works that way in the real world (you can look at web framework benchmarks as an easy example)
It's not that surprising to people who are old enough to have lived through the "reality" of "interpreted languages will never be faster than about 2x compiled languages".
The idea that an absurdly dynamic language like JS, where all objects are arbitrary property bags with prototypical dependency chains that are runtime mutable, would execute at a tech budget under 2x raw performance was just a matter of fact impossibility.
Until it wasn't. And the technology reason it ended up happening was research that was done in the 80s.
It's not surprising to me that it hasn't happened yet. This stuff is not easy to engineer and implement. Even the research isn't really there yet. Most of the modern dynamic language JIT ideas which came to the fore in the mid 200X's were directly adapting research work on Self from about two decades prior.
Dynamic runtime optimization isn't too hot in research right now, and it never was to be honest. Most of the language theory folks tend to lean more in the type theory direction.
The industry attention too has shifted away. Browsers were cutting edge a while back and there was a lot of investment in core research tech associated with that, but that's shifting more to the AI space now.
Overall the market value prop and the landscape for it just doesn't quite exist yet. Hard things are hard.
You nailed it -- the tech enabling JS to match native speed was Self research from the 80s, adapted two decades later. Let me fill in some specifics from people whose papers I highly recommend, and who I've asked questions of and had interesting discussions with!
Vanessa Freudenberg [1], Craig Latta [2], Dave Ungar [3], Dan Ingalls, and Alan Kay had some great historical and fresh insights. Vanessa passed recently -- here's a thread where we discussed these exact issues:
Vanessa had this exactly right. I asked her what she thought of using WASM with its new GC support for her SqueakJS [1] Smalltalk VM.
Everyone keeps asking why we don't just target WebAssembly instead of JavaScript. Vanessa's answer -- backed by real systems, not thought experiments -- was: why would you throw away the best dynamic runtime ever built?
To understand why, you need to know where V8 came from -- and it's not where JavaScript came from.
David Ungar and Randall B. Smith created Self [3] in 1986. Self was radical, but the radicalism was in service of simplicity: no classes, just objects with slots. Objects delegate to parent objects -- multiple parents, dynamically added and removed at runtime. That's it.
The Self team -- Ungar, Craig Chambers, Urs Hoelzle, Lars Bak -- invented most of what makes dynamic languages fast: maps (hidden classes), polymorphic inline caches, adaptive optimization, dynamic deoptimization [4], on-stack replacement. Hoelzle's 1992 deoptimization paper blew my mind -- they delivered simplicity AND performance AND debugging.
That team built Strongtalk [5] (high-performance Smalltalk), got acquired by Sun and built HotSpot (why Java got fast), then Lars Bak went to Google and built V8 [6] (why JavaScript got fast). Same playbook: hidden classes, inline caching, tiered compilation. Self's legacy is inside every browser engine.
Brendan Eich claims JavaScript was inspired by Self. This is an exaggeration based on a deep misunderstanding that borders on insult. The whole point of Self was simplicity -- objects with slots, multiple parents, dynamic delegation, everything just another object.
JavaScript took "prototypes" and made them harder than classes: __proto__ vs .prototype (two different things that sound the same), constructor functions you must call with "new" (forget it and "this" binds wrong -- silent corruption), only one constructor per prototype, single inheritance only. And of course == -- type coercion so broken you need a separate === operator to get actual equality. Brendan has a pattern of not understanding equality.
The ES6 "class" syntax was basically an admission that the prototype model was too confusing for anyone to use correctly. They bolted classes back on top -- but it's just syntax sugar over the same broken constructor/prototype mess underneath. Twenty years to arrive back at what Smalltalk had in 1980, except worse.
Self's simplicity was the point. JavaScript's prototype system is more complicated than classes, not less. It's prototype theater. The engines are brilliant -- Self's legacy. The language design fumbled the thing it claimed to borrow.
Vanessa Freudenberg worked for over two decades on live, self-supporting systems [9]. She contributed to Squeak EToys, Scratch, and Lively. She was co-founder of Croquet Corp and principal engineer of the Teatime client/server architecture that makes Croquet's replicated computation work. She brought Alan Kay's vision of computing into browsers and multiplayer worlds.
SqueakJS [7] was her masterpiece -- a bit-compatible Squeak/Smalltalk VM written entirely in JavaScript. Not a port, not a subset -- the real thing, running in your browser, with the image, the debugger, the inspector, live all the way down. It received the Dynamic Languages Symposium Most Notable Paper Award in 2024, ten years after publication [1].
The genius of her approach was the garbage collection integration. It amazed me how she pulled a rabbit out of a hat -- representing Squeak objects as plain JavaScript objects and cooperating with the host GC instead of fighting it. Most VM implementations end up with two garbage collectors in a knife fight over the heap. She made them cooperate through a hybrid scheme that allowed Squeak object enumeration without a dedicated object table. No dueling collectors. Just leverage the machinery you've already paid for.
But it wasn't just technical cleverness -- it was philosophy. She wrote:
"I just love coding and debugging in a dynamic high-level language. The only thing we could potentially gain from WASM is speed, but we would lose a lot in readability, flexibility, and to be honest, fun."
"I'd much rather make the SqueakJS JIT produce code that the JavaScript JIT can optimize well. That would potentially give us more speed than even WASM."
Her guiding principle: do as little as necessary to leverage the enormous engineering achievements in modern JS runtimes [8]. Structure your generated code so the host JIT can optimize it. Don't fight the platform -- ride it.
She was clear-eyed about WASM: yes, it helps for tight inner loops like BitBlt. But for the VM as a whole? You gain some speed and lose readability, flexibility, debuggability, and joy. Bad trade.
This wasn't conservatism. It was confidence.
Vanessa understood that JS-the-engine isn't the enemy -- it's the substrate. Work with it instead of against it, and you can go faster than "native" while keeping the system alive and humane. Keep the debugger working. Keep the image snapshotable. Keep programming joyful. Vanessa knew that, and proved it!
Yeah I've heard this my whole career, and while it sounds great it's been long enough that we'd be able to list some major examples by now.
What are the real world chances that a) one's compiled code benefits strongly from runtime data flow analysis AND b) no one did that analysis at the compilation stage?
Some sort of crazy off label use is the only situation I think qualifies and that's not enough.
Compiled Lua vs LuaJIT is a major example imho, but maybe it's not especially pertinent given the looseness of the Lua language. I do think it demonstrates that the concept that it is possible to have a tighter type-system at runtime than at compile time (that can in turn result in real performant benefits) is a sound concept, however.
The major Javascript engines already have the concept of a type system that applies at runtime. Their JITs will learn the 'shapes' of objects that commonly go through hot-path functions and will JIT against those with appropriate bailout paths to slower dynamic implementations in case a value with an unexpected 'shape' ends up being used instead.
There's a lot of lore you pick up with Javascript when you start getting into serious optimization with it; and one of the first things you learn in that area is to avoid changing the shapes of your objects because it invalidates JIT assumptions and results in your code running slower -- even though it's 100% valid Javascript.
Totally agree on js, but it doesn't have the same easy same-language comparison that you get from compiled Lua vs LuaJIT. Although I suppose you could pre-compile JavaScript to a binary with eg QuickJS but I don't think this is as apples-to-apples comparison as compiled Lua to LuaJIT.
Any optimizations discovered at runtime by a JIT can also be applied to precompiled code. The precompiled code is then not spending runtime cycles looking for patterns, or only doing so in the minimally necessary way. So for projects which are maximally sensitive to performance, native will always be capable of outperforming JIT.
It's then just a matter of how your team values runtime performance vs other considerations such as workflow, binary portability, etc. Virtually all projects have an acceptable range of these competing values, which is where JIT shines, in giving you almost all of the performance with much better dev economics.
I think you can capture that constraint as "anything that requires finely deterministic high performance is out of reach of JIT-compiled outputs".
Obviously JITting means you'll have a compiler executing sometimes along with the program which implies a runtime by construction, and some notion of warmup to get to a steady state.
Where I think there's probably untapped opportunity is in identifying these meta-stable situations in program execution. My expectation is that there are execution "modes" that cluster together more finely than static typing would allow you to infer. This would apply to runtimes like wasm too - where the modes of execution would be characterized by the actual clusters of numeric values flowing to different code locations and influencing different code-paths to pick different control flows.
You're right that on the balance of things, trying to say.. allocate registers at runtime will necessarily allow for less optimization scope than doing it prior.
But, if you can be clever enough to identify, at runtime, preferred code-paths with higher resolution than what (generic) PGO allows (because now you can respond to temporal changes in those code-path profiles), then you can actually eliminate entire codepaths from the compiler's consideration. That tends to greatly affect the register pressure (for the better).
It might be interesting just to profile some wasm executions of common programs. If there are transient clusterings of control flow paths that manifest during execution. It'd be a fun exercise...
Why? My only guess is that the instructions don't match x86 instructions well (way too few Wasm instructions) and the runtime doesn't have enough time to compile them to x86 instructions as well as, say, GCC could.
> It could be the continued lack of DOM bindings that have been considered a key missing piece for several years now, or maybe something else or more fundamental.
No, it is NOT "something else or more fundamental" - it is most certainly the lack of proper, performant access to the DOM without having to use crazy, slow hacks. Do that and frontend web-apps will throw JS into the gutter within a decade.
Let's not go into that for the millionth time and instead perhaps ask yourself why is TS wildly successful and even before that everyone was trying to use anything-but-js.
Ok, that's fair. My goal with this question wasn't to open a can of worms. But whenever I see a strong averse reaction to JS, I assume that the person hasn't tried using _modern_ JS.
> why is TS wildly successful
From my perspective, it stops me from making stupid mistakes, improves autocomplete, and adds more explicitness to the code, which is incredibly beneficial for large teams and big projects. But I don't think that answers my original question, because if you strip away the types, it's JS.
> even before that everyone was trying to use anything-but-js
Because JS used to suck a lot more, but it sucks a lot less now.
>From my perspective, it stops me from making stupid mistakes, improves autocomplete, and adds more explicitness to the code, which is incredibly beneficial for large teams and big projects. But I don't think that answers my original question, because if you strip away the types, it's JS.
I think it sort of does answer that - if js was not an awful language, there would be no need for TS, even if TS just a band-aid. Even better, if browsers provided a compile target, bytecode/vm spec or whatever instead of a very bad language everyone has to use, we would be spared of close to three decades of evolving tooling that is trying to remedy that bad decision.
> I think it sort of does answer that - if js was not an awful language, there would be no need for TS.
Eh, I disagree. For me, this statement is the equivalent of saying "if Python was not an awful language, there would be no need for mypy" or "if Ruby was not such an awful language, there would be no need for Sorbet". I don't think mypy or Sorbet improves the underlying languages; they just add some additional DX to prevent those aforementioned stupid mistakes.
I wasn't trying to be disingenuous when I asked what was wrong with JS. You've now referred to it as "awful" and "very bad". I have used other programming languages pretty extensively, and JS seems fine to me. When I asked you why it was bad, you hand-waved it away, saying "let's not go into that for the millionth time". When I see statements like that, I immediately think "oh, so this person is just jumping on the bandwagon without providing objective reasons for why this language is bad". If you think that JS is bad and awful, fine, that's your opinion. But whenever I have a negative opinion on something and I'm presented with compelling evidence to the contrary, I re-evaluate my reasons for why I think it's bad and possibly change my mind.
At the end of the day, if you want to hate on JS and hope for a browser compile target that lets you use any other language than JS to build web apps, that's your prerogative. I was a web dev for almost 10 years, and I've seen the improvements to the language and ecosystem over time. So whenever I encounter the "LoL Js SuCkS" mindset, it grinds my gears a little bit.
> For me, this statement is the equivalent of saying "if Python was not an awful language, there would be no need for mypy"
This analogy breaks down because if Python does not fit your preferences or the needs of your project, you can use any other language. You can't do this for JS if you have to write for the browser. Well technically you can transpile but that is leaky so in some capacity it still will be JS. And that is the issue.
> I wasn't trying to be disingenuous when I asked what was wrong with JS.
I'm just tired after decades of this. I will gladly use any language I have ever used profesionally instead of JS (so no VB please, but give me Perl, Tcl, Java, PHP, C, whatever). Just yesterday there was this: https://news.ycombinator.com/item?id=46589658
I have seen the improvements too. And the language is getting better, but by now the whole ecosystem including TS and all frameworks is hopelessly infected. And I don't even see the meaning of giving concrete examples because it's just so overwhelmingly frustrating I wouldn't know where to begin or end.
I'm not sure if this is meant to be snarky or if you're saying that the languages you listed have improved over time. If you're being snarky, you've proven my point by saying several random programming languages are better than JS while providing zero justification.
It's a complement to my other answer to you (about your Q on why ppl would not want to learn/use js and would prefer WASM if there was FastDOM ==> because not everyone wants to be multilingual): I was listing a few languages that people are confortable with and would rather use through WASM than learning idiomatic JS/TS ( it's easy to learn the syntax, it takes practice to learn the idiomatic way).
And yes, I do meant that my listed have gotten better, just like JS/TS.
As for why not comp/transpiling to JS? it is my impression that WASM was born out of that ( Compiled to subset of js (asm.js)) and it's an evolution of compiling to JS.
Ah, my bad. I apologize if I came off as too aggressive. I know these comment threads can get heated.
As far as the comp/transpiling thing, I was referring to something like ScalaJS, ClojureScript, Kotlin/JS, etc. I'll admit that the JS output isn't always pretty, but it's still JS. I think that compiling to a Wasm module is different than transpiling, because Wasm is more of a black box.
I think it's fine to ship a `.wasm` file that does some kind of computation and complements the app. But I think shipping a `.wasm` file that builds your UI is like using a drill to install a nail: technically, you could do it, but it's harder, slower, and you'll probably end up damaging something or hurting yourself.
I don't mean to split hairs here, but considering the wording of "throw something in the gutter", I would argue that "hate" isn't really too far off the mark.
> Wasm with 'fast' DOM manipulation opens the door to every language compiling to wasm to be used to build a web app that renders HTML.
This was never the goal of Wasm. To quote this article [1]:
> What should be relevant for working software developers is not, "Can I write pure Wasm and have direct access to the DOM while avoiding touching any JavaScript ever?" Instead, the question should be, "Can I build my C#/Go/Python library/app into my website so it runs with good performance?"
Swap out "pure Wasm" with <your programming language> and the point still stands. If you really want to use one language to do everything, I'm pretty sure just about every popular programming language has a way of transpiling to JS.
Wasm is essentially a CPU in the browser. It's very barebones in terms of its capabilities. The DOM API is pretty beefy, so adding DOM support to Wasm would be a massive undertaking. So why add all that complexity when you already have a perfectly capable mechanism for interacting with the DOM?
That "perfectly capable mechanism" is one-off JS glue code, which is so cumbersome that approximately nobody actually uses it even though it's been an option for at least 6 years. It would be silly to mistake that for a satisfactory solution.
From my (outsider) perspective, I think the main roadblock atm is standardizing the component model, which would open the door to WIT translations for all the web APIs, which would then allow browsers to implement support for those worlds into browser engines directly, perhaps with some JS pollyfill during the transition. Some people really don't like how slowly component model standardization has progressed, hence all the various glue solutions, but the component model is basically just the best glue solution and it's important to get it right for all the various languages and environments they want to support.
I think maybe you misunderstood what I meant. When I said "perfectly capable mechanism", I meant building the app in JS/TS and leveraging Wasm for additional functionality in your language of choice. I'm also not sure if the "one-off JS glue code" you're referring to is the JS file that languages like Go or tools like Emscripten spit out to get Wasm to work with your app, or the WebAssembly Web API specifically. I would agree that the former is a bit of a dumpster fire.
There's not some conspiracy that's stopped it from happening. Nobody, anywhere, has ever said "DOM access from WASM isn't allowed". It's not a matter of 'allow', it's a matter of capability.
There's a lot of prerequisites for DOM access from WASM that need to be built first before there can be usable DOM access from within WASM, and those are steadily being built and added to the WASM specification. Things like value references, typed object support, and GC support.
I never thought that it would be a promising approach to build entire web apps using wasm. You don't just have to make it possible to interact with the DOM. You also have to have the right high level language to do this kind of DOM interaction and application logic. JS isn't bad for that purpose and it would probably take a lot to find something that is much better (which compiles to WASM instead of js, like ts and svelte do).
The only real avenue for js-free web applications would be to completely abandon the browser rendering path and have everything render into a canvas. There are experiments to use UI toolkits designed for the desktop. But even that I see more of a niche solution and unlikely to become very widely used. HTML/css/js have become the lingua franca of UI development and they are taking over desktop applications as well. Why should that trend reverse?
> completely abandon the browser rendering path and have everything render into a canvas
Yeah, go ahead and trash the little bit of accessibility we still have. <canvas> by itself already asks webdevs to shit on people with visual disabilities. But getting rid of the DOM (for vague reasons) would really nail the coffin of these pesky blind users. After all, why should they be able to use anything on the internet?
This, and AI making webdevs consider to obfuscate things for scraping reasons, and Microsoft Recall making devs play with the idea of obfuscating OS-level access to their (privacy-sensitive) apps, which in essence would also trash accessibility, are the new nightmares that will haunt me for the next few years.
Maybe that's not the dominant mindset anymore, but I for one would love to use a language that's actually built for functional/reactive programming instead of inventing half-baked JavaScript dialects for that purpose. Elm was a language in that spirit, but it never felt complete.
Makes me sad that PureScript doesn't have more adoption, not that I'm surprised. It's orders of magnitude better than Elm and even improves upon Haskell in some meaningful ways (row polymorphism).
> Things may be different with other frameworks like Blazor which I've not tried, but I just find myself wanting to write JS instead.
Blazor WASM probably is among the best approaches to what is possible with WASM today, for better and worse. C# is a great language to write domain code in. A lot of companies like C# for their backends so you get same-language sharing between backend and frontend. The Razor syntax is among the better somewhat type-safe template languages in the wild, with reasonably good IDE support. C# was designed with FFI in mind (as compared to Java and some other languages) so JS imports and exports fit reasonably well in C#; the boundaries aren't too hairy.
That said, C# by itself isn't always that big of leap from Typescript. C# has better pattern matching today, but overall the languages feel like step-brothers and in general the overhead of shipping an entire .NET CLR, most of the BCL, and your C# code as web assembly is a lot more than just writing things more vanilla in Typescript. You can also push C# more functional with libraries like LanguageExt (though you also fight the reasons to pick C# by doing so as so many engineers don't think LanguageExt feels enough like C# to justify using C#).
I'm curious to try Bolero [0] as F# would be a more interesting jump/reason for WASM, but I don't think I could sell it to engineering teams at my day job. (Especially as it can't use Razor syntax, because Razor is pretty deeply tied to C# syntax, and has its own very different template languages.)
With WASM not having easy direct access to the DOM, Blazor's renderer is basically what you would expect it to be: it tosses simple objects over to a tiny Virtual DOM renderer on the JS side. It has most of the advantages and disadvantages of just using something like React or Preact directly, but obviously a smaller body of existing performance optimizations. Blazor's Virtual DOM has relatively great performance given the WASM to JS and back data management and overhead concerns, but it's still not going to out-compete hand written Vanilla JS any time soon.
I found Blazor WASM to be extremely helpful if you have to start from the opposite side of the spectrum. I was working in a self-proclaimed gov agency "Microsoft Shop" whose head of development was adamantly opposed to any sort of JS-driven web app development, but kept accepting requesting apps that fit perfectly into the SPA model. .NET 6 released a few months after I started and with it came a huge amount of progress with Blazor WASM. I had plenty of experience with Vue and Typescript, so Blazor WASM and C# mapped really easily to my existing model of how to build. That similarity also made it easy to onboard new grads who had experience in web dev but weren't familiar with C#. After enough evangelizing, we built a critical mass of projects leveraging Blazor WASM to convince leadership to reconsider his position on Typescript. I can't say enough nice things about the work Steve Sanderson has done to bring Blazor to the public.
This misses a hugely important advantage of C# in Blazor WASM (beyond the IMO obvious fact of the huge superiority of C# vs. JS/Typescript) - namely, the ability to use an enormous number of NuGet packages in your browser page. And that covers a very broad range of capability.
> The only way it really fell short is in the way that a lot of people were predicting that it would become a sort of total replacement for JS+HTML+CSS for building web apps.
Agreed and I’m personally glad progress on that hasn’t moved quickly. My biggest fear with WASM is that even the simplest web site would end up needing to download a multi MB Python runtime just because the author didn’t want to use JS!
The sad reality is that the slowness very often comes from the DOM, not from JavaScript. Don’t get me wrong, there could be improvements, e.g. VDOM diffing would be a cinch with tuples and records, but ultimately you have to interact with the DOM at some point.
> It could be the continued lack of DOM bindings that have been considered a key missing piece for several years now, or maybe something else or more fundamental.
More fundamentally, every front end developer uses more or less the same JS language (Typescript included) and every module is more or less interoperable. As WASM is a compilation target, every developer could be using a different language and different tools and libraries. One of them could have reached critical mass but there is a huge incumbent (JS) that shadows everything else. So special purpose parts of web apps can be written in one of those other languages but there still is a JS front end between them and the user and GUIs can be huge apps. It looks like a system targeted to optimizations.
And for the backend, if one writes Rust or any other compiled language that can target WASM, why compiling to WASM and not to native code?
> The only way it really fell short is in the way that a lot of people were predicting that it would become a sort of total replacement for JS+HTML+CSS for building web apps.
I for one hope that doesn't happen anytime soon. YouTube or Spotify could theoretically switch to Wasm drawing to a canvas right now (with a lot of development effort), but that would make the things that are currently possible thanks to the DOM (scraping, ad blockers etc.) harder or impossible.
> DOM (scraping, ad blockers etc.) harder or impossible.
This is a cat mouse fight, and Facebook already does some ultra-shady stuff like rendering a word as a list of randomly ordered divs for each character, and only using CSS to display in a readable way.
But it can't be made impossible, at the worst case we can always just capture the screen and use an AI to recognize ads, wasting a lot of energy. The same is true for cheating in video games and many forms of online integrity problems - I can just hire a good player who would play in my place, and no technology could recognize that.
I can't speak for FB. But I know a local (non-US) real estate company which does crap like this (they also love to disable right click and detect when browser tools are open and programmatically close the tab/page when that happens), and they're not paying much. I'm guessing it's double of minimum wage, which isn't high here.
Perhaps require monitoring of the arm muscle electrical signals, build a profile, match the readings to the game actions and check that the profile matches the advertised player
You are probably right. What will happen is that ad-blocker people will indirectly kill accessibility. That would make a lot of sense in this world. Its a reoccuring pattern. Spam killed a part of accessibility indirectly via CAPTCHA. And "it is my god-given right to block ads of free services I use" people will indirectly finally kill accessibility for good, now that we have <canvas>.
Yes, however I reject the idea that a full WASM app would be strictly worse for accessibility in the long term. Native UI frameworks do have accessibility APIs and browsers could implement something similar.
So far, huge rewrites/rearchitecturings typically worsened the end user experience from an a11y POV. I even know people personally who have lost their job of 20 years because their employer decided to redo their IT, "accidentally" leaving the disabled employee behind. It is naiv to think a big rewrite will NOT make things much worse for years.
At work we’re incrementally rewriting a legacy Javascript Electron application in Blazor / C# WASM. The biggest issue we’ve run into as far as WASM interop goes is that it is not really possible to pass objects between WASM and JS. It requires some form of serialization to JSON or a different blittable format. Since the data we work with in the application is quite large, this has caused some headaches.
But why are you? Unless it requires interfacing with a JS library or some JS operation on the DOM, the goal of a Blazor app is to write in C#, not JS. What's your JS code doing that it requires passing C# objects to it? (That said, Blazor supports JS Interop, see https://dev.to/rasheedmozaffar/intro-to-js-interop-in-blazor...)
X used yew and rust to rebuild their client and had success in that they are dealing with lots of heavy lifting where these tools start to show their value for large scale products.
For most products its immense overkill, for a lot of stuff even react is total overkill where htmx is a better choice.
It won't ever replace anything, because most folks don't understand the tech. I've no other way to explain this except to present this question: which is more popular, ASM, or literally any other higher level language (C, C++, etc.)?
Compilers, languages, and frameworks were built for ease of use for the end developer specifically so that any type of ASM would be avoided. Web technologies/frameworks along with Operating system APIs, etc. were a FURTHER level of abstraction. WASM has it's place, just the same as ASM has it's place. Trying to replace React with x86 ASM sounds foolish, does it not? The same goes for WASM. Why?
WASM is designed for situations where performant, low latency compute is needed, along with low level control, etc. Even IF they integrated DOM, very few would use it. Most of today's developers don't even know ASM for any platform, and they aren't about to learn it. They want to be productive, not rewrite basic stuff.
I mean shoot, as much as I dislike the AI bubble (AI/LLMs are great, corporate america is the issue), it is SHOWING what people want, which most of us already knew people wanted: we want to automate out the boring stuff and focus on the hard stuff.
My perspective on this is that maybe Tailwind Labs shouldn't have been a for-profit business, or at least not one of the size that it grew to be.
I was reading a writeup on this history of Tailwind[1] made by Adam Wathan (who created Tailwind).
It seems like he was working on a variety of different business ideas including "Reddit meets Pinterest meets Twitter" and "a developer-focused, webhook-driven checkout platform". He created the basis of Tailwind just to help him build these projects, but it kept getting attention when he would post about his progress building them online.
Here's an important quote from the doc:
"Now at this point I had zero intention of maintaining any sort of open-source CSS framework. It didn’t even occur to me that what I had been building would even be interesting to anyone. But stream after stream, people were always asking about the CSS"
It seems like Adam's main goal was to start a software business, and Tailwind just happened to get popular and became what he pivoted his efforts into. There's obviously nothing wrong with wanting to start a business, but trying to take an open-source CSS framework and turn it into a multi-million dollar business feels unnatural and very difficult to maintain long-term.
To his credit, he did pull it off. He built a seemingly quite successful business and hired a sizable team, and apparently made a decent amount of revenue along the way.
But now, for AI reasons or otherwise, that business is struggling and failing to sustain the scale it was before. To me, it seems like the business is more or less completely separate from the open-source Tailwind project itself. It's, as far as I can understand, a business that sells templates and components built with Tailwind, and it uses Tailwind's popularity to bootstrap customers and sales.
If it were me who ended up building Tailwind, there's no way I would have pursued turning it into a big business. Maybe I would have tried some kind of consulting style, where I'd offer my time to companies evaluating or integrating Tailwind.
Now that Tailwind is getting hundreds of thousands (millions?) of dollars a year in sponsorships, it feels weird to have this for-profit business on the side at the same time.
Maybe it's just my own sensibilities and worldview, but I feel like Tailwind should just be what it is: an extremely popular and successful open-source CSS framework.
I don’t understand this conclusion. Why shouldn’t it be a business? Doesn’t it create value? Hasn’t the nature of being a business led to far more maturity and growth in a FOSS offering than if it had been a side project? Just because it can’t afford 8 full time salaries now doesn’t declare it a failure. Your conclusion is that value should be created without any capture.
It wasn’t venture scale and never intended to be venture scale. By any metric you have, it’s a very successful business and has made its creators independent and wealthy as you pointed out.
I agree this is your worldview warping your perception. But I’d argue we need far more tailwinds and far less whatever else is going on. It captured millions in value - but it generated tens, or hundreds of millions, or more. And essentially gave it away for free.
I think a better conclusion is that it’s a flawed business model. In which case, I’d agree - this didn’t come out of nowhere. The product created (TailwindUI) was divorced from the value created (tailwindcss). Perhaps there was a better way to align the two. But they should be celebrated for not squeezing the ecosystem, not vilified. Our society has somewhat perverse incentives.
Ok but the original Github issue involved a community contributor complaining that the core devs have no bandwidth to review/accept PRs. If it's not a business, then the core devs have to rely on spare time, which is scarcer than paid-by-business time. You can't have it both ways. If it's not a business, PRs being left to rot becomes the norm.
Was curious to read this, but then the massive full-page ugly-on-purpose AI-generated NFT-looking banner image at the top of the page turned my stomach to the point where there's no way I'd even consider it - even if the article isn't AI-generated (which it probably is).
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
In my experience, it's usually the database that gives out first. It's often a shared database, or one running on overprovisioned hardware.
The kinds of sites that go down when receiving unexpected traffic are usually built in such a way where they're making multiple DB requests to render each page. Or they have a dozen poorly configured perf-expensive WordPress plugins running. Or likely all of the above
That's not to say performance doesn't matter anymore or that blog posts on niche topics don't matter anymore.
It's more that there are 30 opponents on all sides fighting to minimize the impact of this kind of post. CPUs are still getting faster even now despite Moore's law being dead. The business or career impact of choosing between an associative list vs hashmap in a garbage-collected language like Guile Scheme is so minimal that it's hard to quantify.
If it's in a hot enough path that it matters, it's likely that there are at least 3 things you can do within 20 minutes of work (or 5 minutes of GPU time) that will solve the problem as effectively or better.
I remember the very specific period of time when blog posts talking about functional programming for React developers were en vogue. You can speed up you Scheme app by 15%, or you can build and deploy a completely new service from scratch in Node.JS in the same amount of time.
It used to feel like code had some kind of meaning or value. Now, it's just an artifact produced as a side effect of work. But that's been a trend for a decade or so now, AI is just the latest (and most significant) iteration of it.
Sounds like the difference between code as a craft versus artifact and product. Actually not even product, it's the inner guts of a product that most people don't need to care about, and increasingly just machine generated so it's not even meant to be read by humans. Write-only code of the post-programming era.
Professional software has always aspired to be an industrial process, like OOP and Agile, as a collective endeavor to produce code of decent quality that works reliably, to achieve business goals. Any aesthetic satisfaction or philosophical insights are a byproduct, nice to have, but not the main point.
Code as a craft is a niche for experts and researchers, for hobbyists and amateurs. The miniscule performance improvement gained from choosing an array or hashmap is insignificant in most situations, other than maybe resource-constrained contexts like embedded programming, retro computers, games, competitions.
But, thinking over it, code as a craft still has a healthy subculture of people across older and younger generations. Perhaps it's up to the older ones who remember the good ol' days of respectable craftsmanship ("craftspersonship") to promote and encourage others to carry on the tradition.
Or is that not even worth doing anymore with language models pumping out vibe-coded slop? Will programmers be relegated to reviewing and fixing such mass-produced code? Yes, probably. But no, of course it's worth preserving and evolving the culture of computer science and software development, maybe it's more important than ever to keep the flame of human spirit and imagination alive, supported by machine intelligence rather than replaced.
I'm working on a DSL and browser-based playground for procedural 3D geometry called Geotoy: https://3d.ameo.design/geotoy
It's largely finished and functional, and I'm now focused on polish and adding additional builtin functions to expand its capabilities. I've been integrating different geometry libraries and kernels as well as writing some of my own.
I've been stress-testing it by building out different scenes from movies or little pieces of buildings on Google Maps street view - finding the sharp edges and missing pieces in the tool.
My hope is for Geotoy to be a relatively easy-to-learn tool and I've invested significantly in good docs, tutorials, and other resources. Now my goal is to ensure it's something worth using for other people.
Svelte is definitely still my favorite way to build web apps in 2025.
I wasn't (and still am not) the biggest fan of the new Runes syntax, but I've gotten used to it, and it doesn't really hurt my productivity or get in my way that much.
There's definitely an ecosystem gap compared to React, but there are still lots of really good components and frameworks out there. For example, there's a native Svelte version of IBM's Carbon Design[1] which I've used and found to be very high-quality.
And as for arguments that React will keep winning due to LLMs not having enough corpus to learn less-popular frameworks, I've anecdotally had good success with using LLMs to edit and generate Svelte code. There are occasionally some issues (like it generating pre-runes syntax or using deprecated stuff like stores) but it works well enough to be useful, and definitely better than I expected.
You might be happy to hear that we're releasing a new version of the Svelte Society website to make it easier to find packages and other resources. We're currently migrating data and fixing bugs but if you want to give it a whirl you can find it here https://prod.sveltesociety.dev until we switch it over to the root domain.
The main takeaway from this for me is that SQLite’s query planner seems to be pretty limited. It’s reliant on stuff like the order in which WHERE conditions are specified, isn’t able to use multiple indexes in queries in many cases, bails out to scans when a variety of different operations show up in queries, etc.
It might be the case that SQLite has a simpler or less sophisticated query planner than other databases like Postgres or MariaDB, but in my experience those DBs struggle a lot with good querying planning as well. I’ve spent many hours in the past with issues like Postgres suddenly starting to ignore an index entirely because its computed table data distribution statistics got out of balance, or having to add manual annotations to MariaDB queries like STRAIGHT_JOIN in order to get a query to run faster.
I’m guessing that this is a really hard problem since it doesn’t seem to be really “solved” by any major DB vendor I’ve seen. A lot of modern DB engines like Clickhouse tend to just work around this problem by being so fast at full table scans that they don’t even need any sophisticated indexing set up at all.
> The main takeaway from this for me is that SQLite’s query planner seems to be pretty limited.
This doesn't appear to be true at all.
The order of WHERE conditions does not matter; the order of columns in an index does.
Everything you're describing is pretty much just how indexes fundamentally work in all databases. Which is why you're saying it hasn't been "solved" by anyone.
Indexes aren't magic -- if you understand how they work as a tree, it becomes very clear what can be optimized and what can't.
It is true that occasionally query planners get it wrong, but it's also often the case that your query was written in a non-obvious way that is equivalent in terms of its formal results, but is not idiomatic -- and making it more idiomatic means the query planner can more easily understand which indexes to use where.
(copying my reply from the other comment that said the same thing as you)
The order of conditions in a WHERE definitely does matter, especially in cases where the conditions are on non-indexed columns or there are CPU-intensive search operations like regex, string ops, etc.
I just ran this test locally with a table I created that has 50 million rows:
```
» time sqlite3 test.db "select count() from test WHERE a != 'a' AND a != 'b' AND a != 'c' AND a != 'd' AND b != 'c' AND d != 'd' AND e != 'f' AND f = 'g'"
sqlite3 test.db 5.50s user 0.72s system 99% cpu 6.225 total
» time sqlite3 test.db "select count() from test WHERE f = 'g' AND a != 'a' AND a != 'b' AND a != 'c' AND a != 'd' AND b != 'c' AND d != 'd' AND e != 'f'"
sqlite3 test.db 1.51s user 0.72s system 99% cpu 2.231 total
```
The only difference is swapping the `f = 'g'` condition from last to first. That condition never matches in this query, so it's able to fail fast and skip all of the work of checking the other conditions.
Sorry, I should have clarified -- the order of WHERE conditions doesn't matter for whether an index is utilized. I thought that was the context of the original comment, but now I realize maybe it was unclear.
Yes, of course you can skip evaluating other conditions if an AND fails and that can affect speed. So that's the same as most programming languages.
> A lot of modern DB engines like Clickhouse tend to just work around this problem by being so fast at full table scans that they don’t even need any sophisticated indexing set up at all.
There's only so much you can do with this approach due how to the algorithmic complexity scales as more joins are added. At some points you'll need some additional data structures to speed things up, though they not be indexes in name (e.g. materialized views)
Clickhouse isn’t fast at table scans, it’s just columnar. Indexes are basically a maintained transform from row storage to column storage; columnar databases are essentially already “indexed” by their nature (and they auto-apply some additional indexes on top, like zone maps). It’s only fast for table-scans in the sense that you probably aren’t doing a select * from table, so it’s only iterating over a few columns of data, whereas SQLite would end up iterating over literally everything — a table-scan doesn’t really mean the same thing between the two (a columnar database’s worst fear is selecting every column; a row-base database wants to avoid selecting every row)
Their problem is instead that getting back to a row, even within a table, is essentially a join. Which is why they fundamentally suck at point lookups, and they strongly favor analytic queries that largely work column-wise.
Columnar databases are not "already "indexed"". Their advantage instead comes from their ability to only load the relevant parts of rows when doing scans.
They’re indexed in the sense that they’re already halfway to the structure of an index — which is why they’re happy to toss indexes on top arbitrarily, instead of demanding the user to manage a minimum subset.
What does it even mean to be "halfway" to the structure of an index? Do they allow filtering a subset of rows with a complexity that's less than linear in the total number of rows or not?
A row-based index is a column-wise copy of the data, with mechanisms to skip forward during scanning. You maintain a separate copy of the column to support this, making indexes expensive, and thus the DBA is asked to maintain a minimal subset.
A columnar database’s index is simply laid out on top of the column data. If the column is the key, then it’s sorted by definition, and no index is really required outside of maybe a zone map, because you can binary search. A non-key column gets a zone map / skip index laid out on top, which is cheap to maintain… because it’s already a column-wise slice of the data.
You don’t often add indexes to an OLAP system because every column is indexed by default — because it’s cheap to maintain, because you don’t need a separate column-wise copy of the data because it’s already a column-wise copy of the data.
> A non-key column gets a zone map / skip index laid out on top, which is cheap to maintain… because it’s already a column-wise slice of the data.
I don't see how that's different from storing a traditional index. You can't just lay it on top of the column, because the column is stored in a different order than what the index wants.
Zonemap / skip indexes don’t require sorting, still provide significantly improved searching over full tablescans, and typically applied to every column by default. Sorting is even better, just at the cost of a second copy of the dataset.
In a row-based rdbms, any indexing whatsoever is a copy of the column-data, so you might as well store it sorted every time. It’s not inherent to the definition.
That's still a separate index though, no? It's not intrinsic in the column storage itself, although I guess it works best with it if you end up having to do a full-scan of the column section anyway.
> Sorting is even better, just at the cost of a second copy of the dataset.
> ...
> In a row-based rdbms, any indexing whatsoever is a copy of the column-data
I’m not saying columnar databases don’t have indexes, I’m saying that they get to have indexes for cheap (and importantly: without maintaining a separate copy of the data being indexed), to the point that every column is indexed by definition. It’s a separate data structure, but it’s not a separate db object exposed to the user — it’s just part of the definition
> So the same thing, no?
Consider it as like: for a given filtered-query, a row-based storage is doing a table-scan if no index exists. There is no middle ground. Say 0% value or 100%.
A columnar database’s baseline is a decent index, and if there’s a sorted index then even better. Say 60% value vs 100%.
The relative importance of having a separate, explicit, sorted index is much lower in a columnar database, because the baseline is different. (Although maintaining extra sorted indexes is a columnar database is much more expensive — you basically have to keep a second copy of the entire table sorted on the new key(s))
It definitely does matter, especially in cases where the conditions are on non-indexed columns or there are CPU-intensive search operations like regex, string ops, etc.
I just ran this test locally with a table I created that has 50 million rows:
```
» time sqlite3 test.db "select count() from test WHERE a != 'a' AND a != 'b' AND a != 'c' AND a != 'd' AND b != 'c' AND d != 'd' AND e != 'f' AND f = 'g'"
sqlite3 test.db 5.50s user 0.72s system 99% cpu 6.225 total
» time sqlite3 test.db "select count() from test WHERE f = 'g' AND a != 'a' AND a != 'b' AND a != 'c' AND a != 'd' AND b != 'c' AND d != 'd' AND e != 'f'"
sqlite3 test.db 1.51s user 0.72s system 99% cpu 2.231 total
```
The only difference is swapping the `f = 'g'` condition from last to first. That condition never matches in this query, so it's able to fail fast and skip all of the work of checking the other conditions.
There have been lots of cool technical challenges through the whole process of building this, and a very nice variety of different kinds of work.
I'm working towards using the outputs from this language to build out levels and assets for a browser-based game I've been dabbling with over the past few years.
reply