The web had this before briefly. Back in the 90s and 00s, some people just wanted to use Flash. They treated the web browser like it was just a way to run executables in a window.
Nothing worked right. Bookmarks, search engines, command-line tools, user preferences for font size, user scripts, view source, right-click menus, ad blockers, auto-translations, user stylesheets, assistive tools, bookmarklets, deep links… you name it. The more conscientious developers tried to reinvent some of this stuff on top of their own system, but it never worked quite right.
One of the main strengths of the architecture of the WWW is that it isn’t merely a mechanism to ship executable code. It uses the Principle of Least Power, which ensures that you don’t have to execute code to understand what’s on the page. And a huge proportion of the utility of the web is derived from that principle.
This is exactly how Flutter (now) works on web - the browser loads a JS/WASM blob, and your app renders everything to a canvas - and you're right, almost everything you mention is problematic.
There is a time and a place for that paradigm, but it's niche. The lack of SEO alone is usually enough to stop it in its tracks.
The goal isn't the wholesale replacement of html webpages. I have a traditional website for SEO and such that links to my Flutter game app on the same domain. It's exactly what the parent described: a way to ship executable code. A lot of features supported for websites don't work, sure. But that's not the point. It's a single build that practically any user on the planet can execute without needing to install something.
The idea that an app distribution method needs to natively support every feature and analysis method that works for a website is nonsense. You don't expect all that from every app on the play store, for instance. The browser isn't just for visiting html websites anymore. It's also the app distribution method with the widest reach.
On your specific complaints: it's easy to make your screens have different urls. An app that doesn't is built by a novice or lazy developer.
Skipping frames while scrolling is a fair complaint. In my experience, flutter is performant enough but always just a little short of the performance I'd like. Definitely an area that could use improvement.
Flutter even had a DOM renderer which should in theory have fixed approximately all the issues (I don’t know for sure, I never knowingly encountered anything using it), but they’ve killed it off fairly recently, doubling down on the fundamentally unfixable direction that is the pure-canvas approach.
Flutter is unique because it is a cross platform canvas renderer with huge number of components built on top. Sort of, there are libs like QT but nobody wants to deal with C++ for GUI apps, and even the bindings leak C++isms last time I checked.
Rendering Flutter to DOM sounds like a huge effort bound to fail on some level - just use React and React native if you are leaning in that direction. Im sure Flutter can add some shims to get basic stuff like navigation working to be more web like.
That gives you a distinct accessibility tree in the DOM, which is kinda dumb as an approach. One of the reasons for going pure-canvas on the web was supposed to be performance (I don’t think it was ever true, though—only if comparing with a bad DOM implementation), and if you have to enable this accessibility DOM, you’re guaranteeing you’re doing double work. And no, on the web you can’t just do it when you need it: you can’t poll if it’s needed. All you can do in that case is to present screen reader users with a “this page is currently empty, press this button to unbreak it” button. (Aside: I’ve seen that done once. And the button was broken.)
But the problems we’re talking about are far broader than “does my screen reader work”. Do my links work properly—Ctrl+Click, middle-click, long press, hover? (This one is fixable with only mild compromise. Those that follow are not.) Does my text render correctly? Can I select it and use my browser’s context menu or other similar tools? Does content scroll properly, at correct rates, with correct inertia, without jank or at least a frame’s latency? It’s these sorts of things that Flutter’s pure-canvas approach cannot fix, and they affect, in smaller ways, a lot more people.
I’ve written more specifically about the problems here on HN quite a few times. Search and you’ll find ’em. I really should get down to writing a detailed article about it all at some point… it’s been quite a few years.
No, performance and fidelity are definitely better with the canvas renderers, especially skwasm.
Flutter is very inspired by React, but instead of React which does tree diffing to minimize rebuilds, Flutter tries to make rebuilds as cheap as possible instead - for example through its single pass layout algorithm.
The issue is that this doesn't map well to the DOM.
You can't rebuild cheaply on the DOM because you'd be constantly updating the DOM. And you don't profit from your simpler layout, because you have to implement it in JavaScript and use absolute positioning on all DOM Elements to lay them out.
I do agree that this all absolutely sucks for websites, but if you're building an App that is supposed to run in the browser like Rive or Figma, where you're going to override all click handlers anyways, or where where what you're rendering would be too much for the DOM, Flutter Web is pretty ok.
Fair. If that's the deciding factor on whether you use a computer program, that's your prerogative. I assume, then, that every app on your phone allows you to select every bit of text in it?
Cool. Was hoping to discuss the different expectations we have for a program obtained through a web browser than one obtained through an app store, but I guess downvoting is easier. ¯\_(ツ)_/¯
I'm sure this is tried (I've done it myself), but a hybrid approach would take best of both worlds; heavy rendering on a canvas, the rest as SVG/DOM elements.
Even this relation can be inverted: to speed up SVG interactions, I pre-render complex path and text elements at a sufficient resolution, which are shown during transitions/user interactions, but replaced with the SVG original elements once the render loop settles down again.
> But the problems we’re talking about are far broader
No. You're fundamentally misunderstanding the broadness of the web platform.
On a broad platform even niche use cases are common. If I'm developing an application that will be used by 50 users then none of your concerns are relevant. I know my user base and I know what I need to achieve.
If compiling to WebAssembly and using canvas makes the most sense then that's what I'm going to do, especially if it means I can make use of existing business logic.
It is precisely the broadness of the web platform that makes this possible.
I'm ignorant on this - but are there browser APIs that make it possible for the dev to integrate testing and accessibility tools, such as screen readers?
If not, this sounds like a major oversight, and basically kills accessibility dead in these software and makes testing pretty painful.
Hasn't SEO been dead for like 10 years? It's not as if there's a search engine you can get to the first page on without paying, so why waste ad dollars on stuffing SEO garbage in your page and chasing the algorithm when you can just buy ads, if that's what you need? And does anyone find anything anymore by doing generic web searches anyway?
It sucks if you are non-profit working on subjects like drug abuse. Or anything that is considered "difficult" for our ad-overlords and thus all the relevant keywords are against ToS.
Not sure what nonprofits you're referring to, but most drug searches are SEO spammed with godawful websites that contain tons of misinformation while reputable sources that actually promote harm reduction like erowid are pushed down.
The difference between now and then is that people back then wanted bookmarks, search engines, CLIs, user preferences, user scripts, view source, right-click menus, ad blockers, auto-translations, user stylesheets, assistive tools, bookmarklets, deep links and so forth. While some of us still do, the great mass of web users now just want TV on their smartphones: they want an attention-consumption device to distract them from real life.
Flash never took over because a lot of us then wanted our computers to work for us; Javascript and the read-only web are succeeding because so many now don’t mind being farmed for their attention.
I launch Chrome with a bunch of flags to disable security and have a bunch of client scripts to override websites. I'm this close from creating my own browser based on Chromium
I'm not sure why it can't be both. Given the current walled environment of app stores, web pages are a much better way to ship apps across platforms. That doesn't have to detract from the native function of www. Should you make your client's website an inaccessible blob of interpreted bytecode in 2025? Probably not. But can you embed an awesome game inside it with some weird custom UI? Why not!
No, that definitely wasn’t the case. Things that worked fine as Flash on a Windows machine could render weird on a Mac or Linux. They definitely claimed this though.
It's 2025 and most apps do not match the OS they run on. What would you even want apps to match on Windows? There are different styles depending on what you build with (Win32/Forms, WPF, UWP, etc).
I've never understood this "every program on my device should look like the same company designed it" mentality.
Nothing against using the pre-built ui components provided by the OS, but looking down on a developer that decides to use something else? Just weird to me. A checkbox is a checkbox, it really doesn't matter whether App A's checkboxes look identical to App B.
Now, if App A's checkboxes look different than App A's other checkboxes, then I'll complain.
It's mental overhead; if App A's checkboxs look different than the ones in App B, then I have to switch that mental context every time I switch windows. If everything uses the same controls, then that consistency means users don't have to think about the controls.
WHich was... only windows computers since Flash barely worked on Macs or Linux, and never properly made it to mobile, where it was also a complete battery drain when it did in fact do things... sometimes.
I have different memories from before 2012. Flex apps I built were used on all 3 and worked flawlessly in AIR. Looked and behaved exactly the same everywhere. Indeed, though, barely made to mobile. But Nokia N95 was pretty cool.
Eh.. lots of projects targeted mobile app stores by authoring in Flash and using the GPU accelerated stuff. Starling was a semi-blessed framework. Worked perfectly well, no battery drain. Lots of "native" apps were authored that way (and still are, you see the same approach with Unity etc.)
Browser plugins could have been fixed to catch up, the VM itself wasn't the problem in terms of drain
Not my recollection at all. Adobe invested almost 0 effort in getting their runtime working on non-x86 platforms. It was pathetic, honestly, how many years passed before they had any kind of passable implementation there.
Adobe Flex was interesting and not awful. The problem was the runtime.
While some of this is true, some of it is not (deep links worked fine, there was a brief time where hidden html was encouraged and worked just as well for search engines to pick up, etc.)
More to the point though- Flash didn't shine as a regular website thing (Adobe people used Dreamweaver for that, if anything). It was a game/application development tool. Most of the time you didn't need any of these web-friendly things, same way you'd expect every game to have a different menu system.
It was an awesome time for innovation and creative thinking. Not everything is a flex box. I miss those days
I agree with everything you said but at the back of my mind is the knowledge that the previous Flash ecosystem was capable of an experience we still don’t see today, despite its many downsides.
I don’t want public facing web sites to use stuff like this, or Flutter. But some intranet internal tool… eh, fine.
> The web had this before briefly. Back in the 90s and 00s, some people just wanted to use Flash.
WebAssembly is different. WebAssembly brings every language to the web. Flash didn't.
WebAssembly can render to canvas and enable applications that compile to desktop, mobile, and the web. UI libraries like Avalonia do this: https://avaloniaui.net/
DOM access goes via JavaScript glue code for now. Eventually WebAssembly will get direct DOM access.
You can decide if you're making more of an application or more of a webpage. If you're making more of an application then why not just render to canvas with WebAssembly? And if you're making more of a webpage then why not have WebAssembly manipulate the DOM instead of JavaScript?
And for non-web uses, WebAssembly can be used in a plugin framework such as Extism:
To this day, with exception of maybe PlayCanvas, there are hardly any tools that can match the same developer experience for WebGL, almost 15 years later.
Because of Steve Jobs, followed by Chrome NaCL, superseded by PNaCL, that Mozzilla refused to adopt pushing asmjs instead, and having everyone to agree with WebAssembly, still a shadow of Flash developer tooling experience today.
And for what, now that Firefox is mostly irrelevant and is Google for all practical purposes calling the shots on the Web and related standards.
Don't mistake technical capabilities with political games.
If one man, on a whim, could destroy Flash then Flash deserved to die.
> And for what
For a royalty free platform that everyone is free to implement. No one wanted to be beholden to a proprietary platform they'd have to license from Adobe.
Ever heard about all those ChromeOS features that Safari is not supporting and how PWAs are a failure?
How is that WebGL 2.0 experience going on iOS?
Ever wondered why after a decade there is hardly any WebGL game that can match any serious game done with OpenGL ES.3.0 on mobile phones, starting with the famous Infinity Blade?
> WebAssembly is different. WebAssembly brings every language to the web. Flash didn't.
The problem with Flash was not that it only supported a single language. The problem with Flash is that it opted out of the web architecture because they only wanted your browser window to be a surface for an executable to draw into.
> But WebAssembly applications can also manipulate the DOM like JavaScript.
Flash could do that too. Virtually nobody bothered.
> The problem with Flash is that it opted out of the web architecture
WebAssembly doesn't. WebAssembly is part of the web's architecture. It has been for 8 years. You've doubtless run WebAssembly without even realizing it.
I know how WebAssembly works. You don’t need to explain it to me.
Take a look at the article. It’s specifically advocating for:
> So throw out all the web standards. Make a browser that just runs WASM blobs, and gives them a surface to use
And no, WebAssembly isn’t different. I just opened one of the examples you provided and tried to right-click to inspect element. Nothing happened. When I inspected the source a different way, all I found was an SVG for the logo and a JavaScript file to load the binary. When I inspected the DOM, all I found was a `<canvas>` the executable code draws into.
This is exactly what I was complaining about:
> The problem with Flash is that it opted out of the web architecture because they only wanted your browser window to be a surface for an executable to draw into.
> And no, WebAssembly isn’t different. I just opened one of the examples you provided and tried to right-click to inspect element. Nothing happened. When I inspected the source a different way, all I found was an SVG for the logo and a JavaScript file to load the binary. When I inspected the DOM, all I found was a `<canvas>` the executable code draws into.
What does that have to do with running the application? What user is going to inspect the elements of a web page? No end user will. Developers will, but that's got nothing to do with running the application.
You can always go ahead and disassemble the .wasm file just like any other executable format. Here are some tools: https://github.com/WebAssembly/wabt
If you're worried about understanding how an application works, remember that most of it is on the server side anyway. You won't have access to that. And if anything, WebAssembly puts more of it on the client side.
It’s formally part of the web’s architecture, but it is bolted on and violates the fundamental principles underlying the web’s architecture. It’s much like a worse JavaScript in that way.
The issue isn't the scripting language, it's having a common interface for users, especially for those who can't use standard browsers. Rendering the application yourself will break every accessibility tool that relies on being able to interact with a programmatic view of the website.
…and yet we still do not have the streamlined authoring experience we had with Flash. The stuff you show is just a crappier way to write boring GUIs with some other language for which you need to download the runtime. Flash let many more people create far more fun stuff than any Web standard ever did.
People forget that Flash also brought C/C++ to the web at some point, but besides some flashy demos, nobody really cared.
The problem is that all this choice creates fragmentation, you have dozens of platforms within a platform on top of another platform. Web APIs and Javascript may suck in many ways, but at least the are a common denominator.
This is a great point... the fragmentation and the steep learning curves for each stack (and constantly needing to be on top of breaking changes deeper in the stack) all amplify each other and make it much more difficult for amateur designers to build and ship something. Back in flash days, I knew lots of cartoonists and graphic artists who could build interactive experiences on their own that they wanted to put out there. That basically does not happen at all now.
I'm pretty sure Flash (Stage3D) was also the first way to leverage a GPU on the web... for those of us who wanted to go a bit deeper...
Hi noduerme, I'm the guy who wrote the original 'Kaos'. I stumbled upon the discussion about it, and have no idea how to contact you besides commenting here...
> So there are only 2 web browser engines, and it seems likely there will soon only be 1, and making a whole new web browser from the ground up is effectively impossible because the browsers vendors have weaponized web standards complexity against any newcomers. Maybe eventually someone will succeed and there will be 2 again. Best case. What a situation.
The premise of this article seems completely wrong.
Chromium, Safari, Firefox. And a longtail of half implemented alternatives. But the point is that there are 3 independent browser engines that are fairly widely used. They also have their own indepenedent javascript and WASM implementations. There are a few non browser based WASM implementations in addition to that. As standards go, that's a pretty widely implemented one. There are some people working stubbornly on completely new browser engines even. The standards are in better shape they've ever been since the inception on the web. HTML 5 is way better defined than most of its predecessors.
If everybody was like this, we'd all be using Internet Explorer. Firefox would never have gained any traction. Chrome would have flopped and Google would have killed it. Apple would have given up on Safari. None of those things happened. Because we are not all passively whining on the sidelines about how things used to be better while not lifting a finger to do anything about it.
The "weaponization of complexity" is real—modern web standards are an endless labyrinth of APIs, performance optimizations, and security requirements. Large players like Google have the resources to dictate how the web evolves, while any newcomer faces insurmountable hurdles in achieving compatibility, security, and speed. Even major tech companies have tried and failed (e.g., Microsoft ditching EdgeHTML for Chromium).
Can anyone do anything about it? Google’s control is inevitable. No one can meaningfully compete with Google in the long run. Keeping up with compatibility alone is a full-time job for massive teams—which is why even Microsoft gave up on EdgeHTML and switched to Chromium.
You put the blame on Google but isn't it your fault, people who get excited every time a new feature gets added to web standards, and developers who use it? Like CSS masonry, or WebRTC, or web components with shadow DOM? Features like this get lot of upvotes here.
This is the truth of it: if people chose Firefox, or another alternative, over Chrome then Google would have less power to impose its will on the web. This would be a good thing.
Google’s power on the web doesn’t simply come from having lots of money and resources - see, as examples, any of the multitude of Google’s failures and shuttered products - but mostly comes from its reach.
“Everybody” uses Chrome. If that were no longer true, progress on the web could return to a more open an collaborative model.
Anyone can help that happen simply by switching to Firefox, as I did four or five years ago.
I never used Chrome much. I think I jumped from IE5 to Firefox. IE6 only for testing web apps.
Frankly nearly everything has been working well in Firefox for a long time. The only two sources of problems are:
1) Long tail experimental sites that use or want to demonstrate some new technology. I find most of them on the home page of HN.
2) Myself and the security/privacy plugins I use. They break some web pages, especially ecommerce and payment workflows. I either go hunting for the correct combination of permissions in uMatrix (I would become crazy soon if I used uBlock Origin for that) or I use that very site in Chrome and the close it. Major ecommerce sites don't have any problem. The long tail ones are weirder in their choice of third parties. However that's an issue that any browser would have, it's not because of Firefox.
How much of Edge switching to Chromium was a way for MS to shoot themselves in the foot and focus monopoly discussions on Google instead of themselves?
With the way that AI is unfolding right now, this might be an outdated problem fairly soon. In 2026 if you can just tell your AI to build a new full-featured browser before you go to sleep, you might have something in the morning.
AI might be heading towards a situation where you can "tell it to build a full featured browser".
But this narrative is naive at best, and frankly, getting annoying too. Especially because it gets repeated by people who know even less about "programming" than those who start this idea in the first place.
That AI cannot maintain this browser. It cannot monitor and fix performance issues. It won't be able to refactor stuff when the umpteenth web-api changes or lands. It cannot architecture the modules so that it can actually do this maintainance either.
Generative AI is fantastic at generating stuff. It's terrible at maintaining, changing, tweaking. It's even worse at understanding what you mean with "It must have want a way to disable cookie popups" because that's both ambiguous, and actually the wrong instruction to begin with - for example.
We must stop repeating "AI will be able to program our software for us very soon" because "programming software" is very little about churning out new code. As every programmer with a few years under their belt will know.
What AI is good at, though, is enabling those programmers to be far more effective, efficient. To lower the barrier of entry. etc. But I'm 101% confident that no AI will "write a full-featured browser" that will continue to run for over half a month and/or one OS update.
I mean, the goal is to get it to a state where it can do those things. There are benchmarks for autonomously resolving issues that are being hill-climbed as we speak: https://www.swebench.com/
I don't know how far away it is, but never say never.
Yes, Donald Trump can, because these are all American companies. If he pushes the rest of the world hard enough, the amount of will and the amount of resource that will be mobilized to get out from under the thumb of U.S. tech domination will be something none of us has ever seen in their lifetimes.
The "weaponization of complexity" as you call it is simply "work is done by those who show up".
Google, Microsoft, Mozilla, Apple, etc took the horribly dastardly approach of "participating" and then "doing the work".
The horror.
Microsoft gave up because it wasn't worth it when someone else was willing to do the work. It was not something that was adding value to them by them doing it themselves anymore.
It's hilarious to try to pain this as some evil dastardly thing where they badly tried to keep up and just failed because it's just so hard and costly vs something where it just wasn't worth them paying for because they didn't derive enough value from it.
Remind me which earnings call it was where they were saying "you know, we are going to issue rough q4 guidance because we think it's going to be really hard to implement these next 3 CSS features"
The cost of keeping up for them, even now, if they started again, would be a rounding error in any MS VP's overall equity refresh budget (IE the money they are giving out in stock per year to employees in their org). So please, let's not pretend it's too "hard" or "expensive" for them.
In the end, the world is 99% built by those who show up and do it. That's how this "weaponization of complexity" happened - people showed up and tried to solve problems. The world evolved. They tried to keep moving forward as that happened.
If you think you can do it better, or that it doesn't need to be this complex, or whatever, awesome. show up and do it, like everyone else did.
The world has never been built by those throwing rocks from the sidelines, no matter how much they want it to be, and no matter how much they try to paint the hard problem-solving work of others as "weaponization of complexity".
Calling it that is just plain lazy. Almost all improvements and backwards compatibility shims make it harder for someone else to implement from scratch. That's because the primary goal is usually to help users.
I mean, why stop with the web with this argument?
How come the Go folks weaponized the Go language by adding generics? By making it harder for me to implement my own, they've weaponized it against me!
I can't believe nobody has stopped their dastardly deeds.
I think the "weaponization of complexity" claim can only be understood in relation to the "gimping browsers to protect the App Store" counter claim.
The situation is far more complex than three browser engines competing on a level playing field. "Showing up" is not even possible on iOS. And Firefox is funded by the maker of Chrome.
I think all of this rhetoric that browser vendors use against each other has to be seen against the backdrop of their respective business models.
Money and resource are not the problem nor the reason microsoft gave up on their own browser engine. Same as why they gave up on mobile.
No reasonable amount of engineering resources would have made a dent in the problem.
What OP is calling "weaponization of complexity" is just the asymmetry of effort required between new comers and entrenched players.
You would have to be naive to think that google would just open their arms and kumbaya with microsoft to do the "hard work"
We have seen this played out in any industry in history.
Sometime hard work is not enough and it's easy to abuse dominant position to grid lock a market.
The rest of your post frankly sounds like someone who is drunk on the usual company cooliad.
> The end goal is to help user
No. The end goal is to make money. Sometime it requires helping user, other time a bunch of anti competitive ( forcing android oem to prevent meaningful forks)and anti consumer (like playing hard ball with ad blockers) BS.
>The world has never been built by those throwing rocks from the sidelines, no matter how much they want it to be, and no matter how much they try to paint the hard problem-solving work of others as "weaponization of complexity
So much wrong with this. And is just a strawman.
OP is not saying that it's not hard problem solving. The point is the solution achieved is self serving and sucks for the rest of us.
> In the end, the world is 99% built by those who show up and do it. That's how this "weaponization of complexity" happened - people showed up and tried to solve problems. The world evolved. They tried to keep moving forward as that happened.
This reads like a semi-incoherent essay from someone who doesn't really understand what complexity is and has a chip on their shoulder about something completely unrelated to the topic at hand.
Yeah and coming from someone with so much experience and industry knowledge as dannybee i find that perspective very puzzling.
Just painting the situation as well google have influence because they work the hardest is just bizare. Having been in some standard / comity meetings. Everyone in those room work very hard... but someone hard work is not enough
> Chromium, Safari, Firefox. And a longtail of half implemented alternatives. But the point is that there are 3 independent browser engines that are fairly widely used.
Come on, you can't say that with a straight face.
Safari exists because Apple has a monopoly on iOS traffic, and therefore an financially significant portion of mobile traffic. As soon as their rigid fingers are pried loose of that (which we're seeing the beginnings of), that's gone.
Firefox is great, and I use it, but it has an insignificant market share.
The "longtail of half implemented alternatives" are by definition not alternatives.
Firefox only exists because Google needs an alternative to pretend its not a part of a duopoly. That alternative doesn't have to be Firefox tbh. They could stop sponsoring and choose any of the thousands of alternatives. Similarly Safari exists because Apple has exclusive control of what goes in iPhones. If it is ever forced by legislation to open it up to other browsers, it will lose some of that control. I don't think it will ever be forced to fully open though. I expect apple to make it so only a select number of entities can afford to release a true Safari competitor.
I switched to Safari from Chrome on MacOS and never looked back. Way faster and kinder to battery. Also, it doesn’t push Google or any other login onto me.
Look at the market share. And look at how much breakage report there is with Firefox vs. Chrome or Safari (not to say the return of "this website works better with Chrome" disclaimers, as if we were back to IE6).
There's a lot of websites that break for me on Firefox. Most examples are things like small businesses contact forms... I also had trouble with a kitchen design website. I can't remember what it was, but one just showed me a blank page unless I was on a Chrome-based browser.
half the time it's my choice of security settings and not Firefox. So... IMO %$#^% it - if a site doesn't support firefox I'm strongly disinclined to load up chrome to use it. There are lots of sites and lots of businesses.
The issue I first think about if HTML goes away and the web is WASM blobs instead is text. Accessibility, rendering, all the different languages. The amount of code in the browsers making HTML accessible and working in all languages is enormous. If we are going in that direction, we at least need a standard library handling this, so that we don’t take a big step back to the times of Flash.
I know it's a rant, but it makes no sense. The web is complex, but for 90% of the web I can still manipulate the DOM - even in apps which use frameworks like React. The ability to manipulate the DOM makes the internet so much more pleasant than otherwise - a world without ad blockers would be quite bad.
Rendering on to a surface would be bad for everyone. Tbh, I think the web is doing great. I am among those (perhaps a minority) who think that web apps should occupy space which is currently held by native apps; even at the cost of complexity and new APIs.
You can also do what I did in https://exaequos.com: implement Wayland in WASM and Javascript. The browser is the compositor. And your browser is your computer…
You can already do this. You don't need a special browser. This approach always sounds great until you consider how native input, text selection, copy-paste, etc. behave on mobile. Not to mention accessibility, screen readers, and so on.
My first thoughts exactly. How do you prevent this from turning into what we had with flash if you don't provide the framework to build the UI components.
Turning the web into what we had with flash except for the many security issues seems to be the way things are headed. Not that I'm happy about it, but more and more web applications are going that route.
The design behind WASM helps keep this iteration of Macromedia/Flash/Java/ActiveX stay quite secure, at least until people start adding the extra APIs that a certain subset of WASM enthusiasts trying to turn WASM into another JVM are going for.
> and making a whole new web browser from the ground up is effectively impossible because the browsers vendors have weaponized web standards complexity against any newcomers
I would argue the exact opposite. Web standards have steadily increased in quality. The web has become much less quirky over the years and you no longer need to emulate broken browsers in order to get a functional browsing experience.
Building a web browser is hard, but it's not impossible. Just look at how much progress Ladybird has made in a year. If Ladybird isn't an existence proof I don't know what would qualify.
Our industry as a whole is way too willing to put up with broken software for literal decades because building a better version is believed to be impossible. And that's how we end up squandering endless (volunteer) resources to marginally improve old projects that essentially have no future.
We can have a better future, but only if we choose to build it. As Henry Ford said: "Whether you think you can, or you think you can't – you're right."
Exactly, impossible is what Google, Apple and Microsoft (and Mozilla) want you to believe - and they do everything to make it happen with more and more, ever more irrelevant APIs. And people believed them for a decade now.
Very happy that Ladybird doesn't believe the monopolists propaganda.
Part of the beauty of the (current) WWW is that last W: the web. By design, everything is (or at least "can/should be") interlinked and scripting/computation is a layer on top of that. (See Fielding's thesis.[1]) Inverting to opaque WASM blobs as the information layer seems like throwing all that out.
Sure, WASM could still simulate interlinking -- because it's so general -- but that generality also imposes an implementation bar. Who's going to write an HTML renderer in WASM just so they can get links to work how they used to? If someone comes up with some simpler WASM-linking solution, how long will it be before there are 15 competing simpler solutions which are all mutually incompatible?
> So there are only 2 web browser engines, and it seems likely there will soon only be 1, and making a whole new web browser from the ground up is effectively impossible because the browsers vendors have weaponized web standards complexity against any newcomers
Ladybird seems to be thriving. Sure, they themselves only plan on releasing a beta version next year, but still.
What's internet explorer's market share? Answer: way less than a percent at this point because current market shares are no guarantee about future ones.
Chrome is the new Internet Explorer. It successfully replaced it. Only to start sharing most of the qualities that were the reason for Internet Explorer to fail in the market. And there was a web before Internet Explorer as well.
Chrome once started at 0% market share. Displacing the dominant browser has been done before. It can be done again.
Web pages that only worked with Internet Explorer did not age very well. Companies ended up spending a lot on needing to replace those. Making a webapp that only works with Chrome is at this point seriously misguided. If only for the simple reason that you can forget about IOS compatibility if you do (as long as Apple keeps a death grip on the app stores, there will be no chromium based HTML rendering on IOS).
>Displacing the dominant browser has been done before. It can be done again.
Why? You skim over all the things that make the present and the future different from the past. The size of the audience is not the same, the size of companies and engineering teams is not the same, the hatred against Microsft was always sky-high... It is not the same battle , it is not even the same battlefield.
People complain about Google killing projects that have only a few hundred million users, but then claim Firefox is dead at single digit market share because that's… 150 million users.
>But it has made a lot of progress in a relatively short time.
That's always the case at the beginning. And then it stalls. That's exactly the gripe with fast-moving web standards: the churn kills browser diversity by exhaustion.
Go one step further and run the browser in ring 0 with minimal overhead. Rely on the security guarantees from WebAssembly and the runtime sandbox for memory protections. Throw out the rest of the OS too.
On the set up: First, there are 3 major engines, and even if Gecko dies there will be two. Second, both users and developers want a more capable web. Don't blame browser vendors for giving it to them. The web is wildly successful because of its continued evolution, and if it stopped evolving, native mobile apps would have beaten the web back even more.
WASM could indeed make for a simple, yet powerful, web-like platform, and I hope to see this! But a lot of the new web capabilities would still need to be there. All of the I/O bits of the modern web: networking protocols, GPU, USB, MIDI, local storage, filesystem, etc. WASM doesn't make the need for that go away. Those things still need to be there as WASI services or similar.
And I hope that such a WASM-based browser would not throw out a markup document completely. Flutter did this and it just isn't the web anymore. Documents and links are critical to being able to build useful services on top of the web.
I want to keep the web web-like, not just have Flutter but WASM instead of Dart.
> WASM could indeed make for a simple, yet powerful, web-like platform, and I hope to see this!
Careful what you wish for. WASM-rendered pages could spell the end of ad-blockers and other extensions that modify or read page content. You'll have only binary blobs being downloaded rendering something on a canvas surface.
That is in theory already possible today, also just with obfuscated js blobs.
But the way the ad networks work, is that they do dynamic content loading. So knowing where the ads are coming from and just blocking those lists will continue to work also in WASM.
But indeed, modifying the content specifically, when all you have is a canvas, will be close to impossible.
I think the point is that there is opportunity for splitting the browser in multiple components with a defined interaction surface. Have a component deal with network interaction, another with playing media, another with text layout. This way subprojects are more manageable for a small player.
It was a rich, interactive, streaming vector file format with a gorgeous and tiny code execution engine. It was an incredible time of creative exploration with many thousands of people figuring out how to make beautiful and ugly and funny and sad things and share them with each other.
Steve took this from us 18 years ago because it clearly threatened his ability to enclose the entire application ecosystem, control who can and can't publish, and charge a 30% tax against every dollar spent on the internet.
Please note: Many of the very same people who shit all over Flash as some proprietary, ethical violation, happily tap away on their iOS devices, sending billions of dollars to Tim.
Of course I'm not talking about you, it's those other people over there.
That's something I was thinking a lot about back when I was working on Servo. Wasm + a protocol to talk to WebRender (expose display lists [0] to the wasm runtime). Some sort of "mini web", a minimal runtime that would do just enough that most web APIs could be re-implemented and shipped from the webpage directly. The DOM, the CSS parser, the layout engine, … could just be shipped as wasm modules.
Kind of defeat the purpose of view-source, but nowadays, it's a lost battle already.
And I didn't think too much about sandboxing, accessibility, network or whatnot. Just a fun idea…
I'm personally hoping for Ladybird and Servo to eventually grow into usable browsers. Ladybird is making faster progress on actually delivering a browser to end users, but if Servo gains foothold in the embeddable use case it should help them gain more stakeholders with an interest in keeping development moving forward.
For a very long time, I was pissed at "the web" being abused by heavier and heavier "apps" instead of staying "websites" and keeping "desktop apps".
Now I am starting to think that this is maybe just a super inefficient way to improve the technology for desktop apps: after years and a shit load of money put into running apps in the browser, maybe the end technology will just end up being used for desktop apps. And going through the browser will just have been a detour.
ElectronJS, Tauri... as if there was a realisation that actually, we want desktop apps, but unfortunately we invested in web tech, so we recycle it however we can.
Not sure if that makes sense, but that's how I feel. I liked desktop app, I'd be happy if it all cycled back to proper desktop apps.
The main argument against it seems to be that a browser forces standards - while really the the strength of this approach is that standards will naturally evolve, rather than forced by 2-3 companies
WebAssembly is explicitly a new native plugin like API but cross browser, standardized , and with lessons learned for complexity and security.
You can see it skimming the WebAssembly high level design goals: https://webassembly.org/docs/high-level-goals/. Many of them directly address limitations of past web content plugin systems.
Last time I looked, you still can't touch the DOM without a JavaScript shim. You can't use it to write "normal" client-side web applications without hacks and workarounds.
IOW, it's a VM-style environment that pretty much lives on its own and completely ignores the elephant in the room: that it's running inside a browser that deals predominantly in HTML and CSS.
Sometimes I wonder whether having the document-based-web and application-web in one place a good thing or bad.
Ideally the document based web would require only a subset of standards (html, css, and javascript) and should be much simpler to implement a browser. Then anything more complex could just "Open in an app runner environment".
But then of course since the application-web subsumes the document based one, there is no necessity for vast majority of people to ever care about the pure documents. Maybe gemini people were right and we need a completely different protocol.
I think your "app runner environment" is just turning JS on. It's interesting to think about what if scripts weren't allowed to run by default, but that ship has well and truly sailed.
Who do you think would benefit from having two webs, and how?
You've missed Firefox's marketshare inching towards irrelevance, its revenue - "charitable" donations from competitors worried about monopoly lawsuits that can stop at any time - in freefall, and more and more websites not working with anything other than Safari or Chrome.
I proposed a similar idea (before WASM was a thing) in 2015 on the W3 TAG mailing list, where I simply said why can't the site owners tell the user's browser what browser engine, including specialized ones, should be loaded to render and interact with their site/app. It was dismissed with idiots from the browser vendors saying it's impossible because of ABI compatibility etc. I kid you not, 10 years ago, and then someone from Meta tweeted the same idea 2 years later (the guy behind Slick Carousel) when WASM was a thing, but he did not specify WASM, and I told him that I had brought it up, too. This is not a new idea, but I'm glad to see renewed interest and WASM as the way to do it.
The Content-Type header tells your Firefox 3 browser whether to use the HTML rendering engine, the XHTML rendering engine, the XUL rendering engine, or the Adobe Flash rendering engine. Is that what you mean?
No, that does not solve the problem of the Google monopoly. Not a fixed set contained within one browser engine, but the browser engine itself, like Webkit vs some other engine vs some specialized engines. If your engine-host browser does not have a give engine or specific version of an engine it downloads it and caches it. WASM/Wayland makes the idea feasible, loading lightweight WASM modules.
The author implies the hardest part is HTML+CSS rendering + a JS engine. You still have to implement all of the IO and permissions etc, which I'd argue is still pretty hard. I'm a bit sceptic about this approach.
Why is he writing that there are only 2 browser engines, soon to be down to 1? I thought there were three (Webkit, Blink, Gecko). I assume the "soon to be" part is referring to the expected demise of Gecko?
It's nice to throw around ideas like this sometimes, but the reality is if a new browser is not compatible with 99.9% of existing web content, nobody will use it.
The absolute lack of professionalism among most web developers—many of whom are essentially glorified framework developers, barely understanding what they’re doing—is what led us here. This, combined with a complete disregard for web standards and the W3C (dismissed as too consensual, too European, and too slow of an approach), created the perfect shit-storm.
Google insists on pushing its own "standards". And other browser vendors are criticized for being slow to conform to these non-standards. The result? A web cluttered with pointless animations, devoid of cross-browser compatibility, and drowning in superficial bells and whistles.
And the irony? It’s boring. Every website looks the same.
If you’re not testing across browsers and engines (including non-Chromium ones), you’re not building for the web. You’re shipping Chrome-specific extensions that happen to use HTTP. You are not a developer, you are a plumber, and an incompetent one. Good plumbers are so damn rare.
Well, I don't know about that being relevant [0], but at least it isn't blatantly offensive to the concept of providing information like this proposal is.
this might be in the way of alan kay's core idea, sending messages with interpreters. if we want to go all the way of the snowcrash pipe dream, then imagining objects with programs thrown around is more realistic than making it somehow work with html. on the other hand, in brings back bad memories of flash silverlight, java applets, that almost destroyed the open web. there is a beauty in easy-to-read text rather than binary blobs.
Might work as an application delivery platform but most web content is text
WASM blobs will make the web harder to index, link around, that doesn’t require a compile step, has a built in security model and all the other things that made the web easy to develop for and helped it to grow.
Can you imagine HN delivered as a WASM blob it would be awful…
P.S. How many people really understand canvas?
A WASM engine would end up having to implement some form of of markup renderer which we already have in the browser
In the context of a discussion about websites becoming binary blobs of WASM code that make it essentially impossible to block ads on, the choice will be to use a site and see adverts or not to use that site. I'm saying that we should make the choice not to use a site that displays ads. It will require some sacrifices (or, more likely in my opinion, spending some money for some subscriptions.)
My take would be starting with WAI-ARIA, or create a new standard with similar goal and keep the standard minimal and single-purpose. We are heading into the era of AI driven UI anyway.
Browsers are dead anyway ... Most people visit Google, AI chat, fb, instagram and TikTok.
For devs, it's same + HN & github.
The point is that it's less than 15 websites (at least the top level ones), not counting where they take you to next!
What's coming is a malleable OS that runs natively + in the browser ! probably uses WASM and that breaks the barriers between apps.
I need to build one to show my point.
It seems most people here are concerned about the readability of web content. Text is already gone with SPAs and React. The only reason we still have an index-able web is because of Google and websites still want to get indexed and ranked. In fact, I'd say Wasm is probably better for text since now you have to provide text in a raw format (ie: JSON) for it to be linked/indexed which is much better than trying to crawl incomprehensible HTML.
I'd say the biggest bottleneck for WASM adoption is the current "establishment" of computing. In order to serve a simple web application, you need an Operating System, Networking stack, a Web Server, a language interpreter, etc... With WASM, all of this disappears and get abstracted away behind a single (or few) solutions. Instead of paying for a full virtual machine to process a few web requests that sits idly for 90% of the time, you only pay for CPU time when your worker is computing stuff (Durable Objects).
There is little incentive for the industry as a whole to move to this model since the end user is the one who is paying for all of this compute. Maybe the Chinese will figure this out and finally push toward that direction.
They do, but anyone trying to see how a Website works will find the developer tools as usable as with any browser plugin, unless they have the right plugins installed, and running the developer build.
The web had this before briefly. Back in the 90s and 00s, some people just wanted to use Flash. They treated the web browser like it was just a way to run executables in a window.
Nothing worked right. Bookmarks, search engines, command-line tools, user preferences for font size, user scripts, view source, right-click menus, ad blockers, auto-translations, user stylesheets, assistive tools, bookmarklets, deep links… you name it. The more conscientious developers tried to reinvent some of this stuff on top of their own system, but it never worked quite right.
One of the main strengths of the architecture of the WWW is that it isn’t merely a mechanism to ship executable code. It uses the Principle of Least Power, which ensures that you don’t have to execute code to understand what’s on the page. And a huge proportion of the utility of the web is derived from that principle.
https://www.w3.org/DesignIssues/Principles.html#PLP
If you only see the web as a way to ship no-install executables to people, you’re missing out on basically everything that makes the web what it is.
This is exactly how Flutter (now) works on web - the browser loads a JS/WASM blob, and your app renders everything to a canvas - and you're right, almost everything you mention is problematic.
There is a time and a place for that paradigm, but it's niche. The lack of SEO alone is usually enough to stop it in its tracks.
Wow, they still render to canvas? That's terrible. Just looked at this website: https://payamzahedi.com/toastification/
Feels janky just when scrolling. This is supposed to be the future?
Last time I used a flutter app they didn't even update the url for different screens.
The goal isn't the wholesale replacement of html webpages. I have a traditional website for SEO and such that links to my Flutter game app on the same domain. It's exactly what the parent described: a way to ship executable code. A lot of features supported for websites don't work, sure. But that's not the point. It's a single build that practically any user on the planet can execute without needing to install something.
The idea that an app distribution method needs to natively support every feature and analysis method that works for a website is nonsense. You don't expect all that from every app on the play store, for instance. The browser isn't just for visiting html websites anymore. It's also the app distribution method with the widest reach.
On your specific complaints: it's easy to make your screens have different urls. An app that doesn't is built by a novice or lazy developer.
Skipping frames while scrolling is a fair complaint. In my experience, flutter is performant enough but always just a little short of the performance I'd like. Definitely an area that could use improvement.
Flutter even had a DOM renderer which should in theory have fixed approximately all the issues (I don’t know for sure, I never knowingly encountered anything using it), but they’ve killed it off fairly recently, doubling down on the fundamentally unfixable direction that is the pure-canvas approach.
Flutter is unique because it is a cross platform canvas renderer with huge number of components built on top. Sort of, there are libs like QT but nobody wants to deal with C++ for GUI apps, and even the bindings leak C++isms last time I checked.
Rendering Flutter to DOM sounds like a huge effort bound to fail on some level - just use React and React native if you are leaning in that direction. Im sure Flutter can add some shims to get basic stuff like navigation working to be more web like.
They still seem to have something, from this page: https://docs.flutter.dev/ui/accessibility-and-internationali...
* Inspect the HTML tree containing the ARIA attributes generated by Flutter.
Wouldn't that help with SEO as well?
That gives you a distinct accessibility tree in the DOM, which is kinda dumb as an approach. One of the reasons for going pure-canvas on the web was supposed to be performance (I don’t think it was ever true, though—only if comparing with a bad DOM implementation), and if you have to enable this accessibility DOM, you’re guaranteeing you’re doing double work. And no, on the web you can’t just do it when you need it: you can’t poll if it’s needed. All you can do in that case is to present screen reader users with a “this page is currently empty, press this button to unbreak it” button. (Aside: I’ve seen that done once. And the button was broken.)
But the problems we’re talking about are far broader than “does my screen reader work”. Do my links work properly—Ctrl+Click, middle-click, long press, hover? (This one is fixable with only mild compromise. Those that follow are not.) Does my text render correctly? Can I select it and use my browser’s context menu or other similar tools? Does content scroll properly, at correct rates, with correct inertia, without jank or at least a frame’s latency? It’s these sorts of things that Flutter’s pure-canvas approach cannot fix, and they affect, in smaller ways, a lot more people.
I’ve written more specifically about the problems here on HN quite a few times. Search and you’ll find ’em. I really should get down to writing a detailed article about it all at some point… it’s been quite a few years.
No, performance and fidelity are definitely better with the canvas renderers, especially skwasm. Flutter is very inspired by React, but instead of React which does tree diffing to minimize rebuilds, Flutter tries to make rebuilds as cheap as possible instead - for example through its single pass layout algorithm. The issue is that this doesn't map well to the DOM. You can't rebuild cheaply on the DOM because you'd be constantly updating the DOM. And you don't profit from your simpler layout, because you have to implement it in JavaScript and use absolute positioning on all DOM Elements to lay them out.
I do agree that this all absolutely sucks for websites, but if you're building an App that is supposed to run in the browser like Rive or Figma, where you're going to override all click handlers anyways, or where where what you're rendering would be too much for the DOM, Flutter Web is pretty ok.
I went and loaded up the flutter web demo on my iPhone 15 Pro https://flutter.github.io/samples/web/material_3_demo/
In addition to the pitfalls mentioned like being unable to select text, every interaction including scrolling is noticeably laggy and dropping frames.
> unable to select text
Because of this alone I would not use.
It's just not the default. As the developer, it's trivial to make text selectable.
I meant it as an user.
Fair. If that's the deciding factor on whether you use a computer program, that's your prerogative. I assume, then, that every app on your phone allows you to select every bit of text in it?
Cool. Was hoping to discuss the different expectations we have for a program obtained through a web browser than one obtained through an app store, but I guess downvoting is easier. ¯\_(ツ)_/¯
Wow, you weren't kidding: same phone and it feels like I'm using a 15-year-old Android. That's rough.
I'm sure this is tried (I've done it myself), but a hybrid approach would take best of both worlds; heavy rendering on a canvas, the rest as SVG/DOM elements.
Even this relation can be inverted: to speed up SVG interactions, I pre-render complex path and text elements at a sufficient resolution, which are shown during transitions/user interactions, but replaced with the SVG original elements once the render loop settles down again.
> But the problems we’re talking about are far broader
No. You're fundamentally misunderstanding the broadness of the web platform.
On a broad platform even niche use cases are common. If I'm developing an application that will be used by 50 users then none of your concerns are relevant. I know my user base and I know what I need to achieve.
If compiling to WebAssembly and using canvas makes the most sense then that's what I'm going to do, especially if it means I can make use of existing business logic.
It is precisely the broadness of the web platform that makes this possible.
Yeah, the strategic direction of flutter feels like the famous "embrace, extend, extinguish" approach. All the big companies prefer walled gardens.
I'm ignorant on this - but are there browser APIs that make it possible for the dev to integrate testing and accessibility tools, such as screen readers?
If not, this sounds like a major oversight, and basically kills accessibility dead in these software and makes testing pretty painful.
Yes, browsers expose APIs to accessibility tools
Hasn't SEO been dead for like 10 years? It's not as if there's a search engine you can get to the first page on without paying, so why waste ad dollars on stuffing SEO garbage in your page and chasing the algorithm when you can just buy ads, if that's what you need? And does anyone find anything anymore by doing generic web searches anyway?
It sucks if you are non-profit working on subjects like drug abuse. Or anything that is considered "difficult" for our ad-overlords and thus all the relevant keywords are against ToS.
Not sure what nonprofits you're referring to, but most drug searches are SEO spammed with godawful websites that contain tons of misinformation while reputable sources that actually promote harm reduction like erowid are pushed down.
I was excited about Compose Multiplatform Web too, until I realized it also does this : everything in a canvas
We have this back, thanks to WebGL/WebGPU/WebAssembly I can have all my beloved plugins back.
https://opensilver.net
https://cheerpj.com/
https://cheerpj.com/cheerpj-applet-runner/
https://leaningtech.com/cheerpx-for-flash/
And on top,
https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...
https://flutter.dev/multi-platform/web
https://unity.com/solutions/web
https://playcanvas.com/
This is the only place where I am actually happy about WebAssembly's existence.
The difference between now and then is that people back then wanted bookmarks, search engines, CLIs, user preferences, user scripts, view source, right-click menus, ad blockers, auto-translations, user stylesheets, assistive tools, bookmarklets, deep links and so forth. While some of us still do, the great mass of web users now just want TV on their smartphones: they want an attention-consumption device to distract them from real life.
Flash never took over because a lot of us then wanted our computers to work for us; Javascript and the read-only web are succeeding because so many now don’t mind being farmed for their attention.
I launch Chrome with a bunch of flags to disable security and have a bunch of client scripts to override websites. I'm this close from creating my own browser based on Chromium
Can you share more about your setup?
People still want all those things.
I'm not sure why it can't be both. Given the current walled environment of app stores, web pages are a much better way to ship apps across platforms. That doesn't have to detract from the native function of www. Should you make your client's website an inaccessible blob of interpreted bytecode in 2025? Probably not. But can you embed an awesome game inside it with some weird custom UI? Why not!
> Nothing worked right.
One thing worked right: the app looked the same and acted the same everywhere where it could run.
No, that definitely wasn’t the case. Things that worked fine as Flash on a Windows machine could render weird on a Mac or Linux. They definitely claimed this though.
Adobe Flex and AIR were two of the best technologies I ever worked with.
That’s a bug, not a feature. Apps should match the OS they’re running on.
It's 2025 and most apps do not match the OS they run on. What would you even want apps to match on Windows? There are different styles depending on what you build with (Win32/Forms, WPF, UWP, etc).
I'm painfully aware. Modern apps are mostly terrible.
I don't know or care what apps would match on Windows. I don't use Windows. On the systems I do use, I want apps to look like they fit in.
I've never understood this "every program on my device should look like the same company designed it" mentality.
Nothing against using the pre-built ui components provided by the OS, but looking down on a developer that decides to use something else? Just weird to me. A checkbox is a checkbox, it really doesn't matter whether App A's checkboxes look identical to App B.
Now, if App A's checkboxes look different than App A's other checkboxes, then I'll complain.
It's mental overhead; if App A's checkboxs look different than the ones in App B, then I have to switch that mental context every time I switch windows. If everything uses the same controls, then that consistency means users don't have to think about the controls.
It was a feature for me. Especially in the Flex 3 era, and when AIR came out. That was truly magical period of time.
WHich was... only windows computers since Flash barely worked on Macs or Linux, and never properly made it to mobile, where it was also a complete battery drain when it did in fact do things... sometimes.
I have different memories from before 2012. Flex apps I built were used on all 3 and worked flawlessly in AIR. Looked and behaved exactly the same everywhere. Indeed, though, barely made to mobile. But Nokia N95 was pretty cool.
What was the process of installing AIR like on Linux?
Eh.. lots of projects targeted mobile app stores by authoring in Flash and using the GPU accelerated stuff. Starling was a semi-blessed framework. Worked perfectly well, no battery drain. Lots of "native" apps were authored that way (and still are, you see the same approach with Unity etc.)
Browser plugins could have been fixed to catch up, the VM itself wasn't the problem in terms of drain
Not my recollection at all. Adobe invested almost 0 effort in getting their runtime working on non-x86 platforms. It was pathetic, honestly, how many years passed before they had any kind of passable implementation there.
Adobe Flex was interesting and not awful. The problem was the runtime.
And the company behind it. Who remains awful.
While some of this is true, some of it is not (deep links worked fine, there was a brief time where hidden html was encouraged and worked just as well for search engines to pick up, etc.)
More to the point though- Flash didn't shine as a regular website thing (Adobe people used Dreamweaver for that, if anything). It was a game/application development tool. Most of the time you didn't need any of these web-friendly things, same way you'd expect every game to have a different menu system.
It was an awesome time for innovation and creative thinking. Not everything is a flex box. I miss those days
www should be split in documents and apps it is horrible that we mutilate html, css and js to make a document language work for application.
And I bet competent developers can create a GUI framework that is more accessible then the div soup that the SPAs use today.
I agree with everything you said but at the back of my mind is the knowledge that the previous Flash ecosystem was capable of an experience we still don’t see today, despite its many downsides.
I don’t want public facing web sites to use stuff like this, or Flutter. But some intranet internal tool… eh, fine.
> The web had this before briefly. Back in the 90s and 00s, some people just wanted to use Flash.
WebAssembly is different. WebAssembly brings every language to the web. Flash didn't.
WebAssembly can render to canvas and enable applications that compile to desktop, mobile, and the web. UI libraries like Avalonia do this: https://avaloniaui.net/
For example, here's C# implementation of Visual Basic 6 compiled to WebAssembly https://bandysc.github.io/AvaloniaVisualBasic6/ and source https://github.com/BAndysc/AvaloniaVisualBasic6
And a Solitaire demo https://solitaire.xaml.live/ and source https://github.com/AvaloniaUI/Solitaire
But WebAssembly applications can also manipulate the DOM like JavaScript. Example frameworks that do this:
- https://www.leptos.dev/
- https://dioxuslabs.com/
- https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...
DOM access goes via JavaScript glue code for now. Eventually WebAssembly will get direct DOM access.
You can decide if you're making more of an application or more of a webpage. If you're making more of an application then why not just render to canvas with WebAssembly? And if you're making more of a webpage then why not have WebAssembly manipulate the DOM instead of JavaScript?
And for non-web uses, WebAssembly can be used in a plugin framework such as Extism:
https://extism.org/
Wrong, Flash was in the process of doing exactly that.
https://adobe-flash.github.io/crossbridge/
Before asm2js was even an idea, Unreal compiled to Flash via CrossBridge.
https://www.youtube.com/watch?v=xzyCTt5KLKU
https://www.youtube.com/watch?v=ZmZS7B1pLWg
To this day, with exception of maybe PlayCanvas, there are hardly any tools that can match the same developer experience for WebGL, almost 15 years later.
> Wrong, Flash was in the process of doing exactly that.
Except it didn't succeed at it. And Flash is long dead now.
WebAssembly is here today and supports more languages than Flash ever did.
Because of Steve Jobs, followed by Chrome NaCL, superseded by PNaCL, that Mozzilla refused to adopt pushing asmjs instead, and having everyone to agree with WebAssembly, still a shadow of Flash developer tooling experience today.
And for what, now that Firefox is mostly irrelevant and is Google for all practical purposes calling the shots on the Web and related standards.
Don't mistake technical capabilities with political games.
> Because of Steve Jobs
If one man, on a whim, could destroy Flash then Flash deserved to die.
> And for what
For a royalty free platform that everyone is free to implement. No one wanted to be beholden to a proprietary platform they'd have to license from Adobe.
That man closed the Apple ecosystem doors on Flash, naturally he was not alone, he had an horde of followers.
It remains to be seen how much royalty free Chrome remains, Web is now ChromeOS, with exception of a little Gaulish village called iOS.
> That man closed the Apple ecosystem doors on Flash
Which is exactly the point, isn't it. Adobe's business model around Flash was so fragile that he could do it.
He couldn't do it to the web.
Ever heard about all those ChromeOS features that Safari is not supporting and how PWAs are a failure?
How is that WebGL 2.0 experience going on iOS?
Ever wondered why after a decade there is hardly any WebGL game that can match any serious game done with OpenGL ES.3.0 on mobile phones, starting with the famous Infinity Blade?
> WebAssembly is different. WebAssembly brings every language to the web. Flash didn't.
The problem with Flash was not that it only supported a single language. The problem with Flash is that it opted out of the web architecture because they only wanted your browser window to be a surface for an executable to draw into.
> But WebAssembly applications can also manipulate the DOM like JavaScript.
Flash could do that too. Virtually nobody bothered.
> The problem with Flash is that it opted out of the web architecture
WebAssembly doesn't. WebAssembly is part of the web's architecture. It has been for 8 years. You've doubtless run WebAssembly without even realizing it.
Google Sheets for example uses WebAssembly: https://web.dev/case-studies/google-sheets-wasmgc
Amazon Prime Video uses WebAssembly: https://www.amazon.science/blog/how-prime-video-updates-its-...
> Flash could do that too. Virtually nobody bothered.
But virtually somebody is bothering with WebAssembly.
I know how WebAssembly works. You don’t need to explain it to me.
Take a look at the article. It’s specifically advocating for:
> So throw out all the web standards. Make a browser that just runs WASM blobs, and gives them a surface to use
And no, WebAssembly isn’t different. I just opened one of the examples you provided and tried to right-click to inspect element. Nothing happened. When I inspected the source a different way, all I found was an SVG for the logo and a JavaScript file to load the binary. When I inspected the DOM, all I found was a `<canvas>` the executable code draws into.
This is exactly what I was complaining about:
> The problem with Flash is that it opted out of the web architecture because they only wanted your browser window to be a surface for an executable to draw into.
> And no, WebAssembly isn’t different. I just opened one of the examples you provided and tried to right-click to inspect element. Nothing happened. When I inspected the source a different way, all I found was an SVG for the logo and a JavaScript file to load the binary. When I inspected the DOM, all I found was a `<canvas>` the executable code draws into.
What does that have to do with running the application? What user is going to inspect the elements of a web page? No end user will. Developers will, but that's got nothing to do with running the application.
You can always go ahead and disassemble the .wasm file just like any other executable format. Here are some tools: https://github.com/WebAssembly/wabt
If you're worried about understanding how an application works, remember that most of it is on the server side anyway. You won't have access to that. And if anything, WebAssembly puts more of it on the client side.
> WebAssembly is part of the web's architecture.
It’s formally part of the web’s architecture, but it is bolted on and violates the fundamental principles underlying the web’s architecture. It’s much like a worse JavaScript in that way.
> it is bolted on
WebAssembly is no more bolted on than JavaScript is and JavaScript has been part of the web for 29 years.
> violates the fundamental principles underlying the web’s architecture.
Which ones?
The issue isn't the scripting language, it's having a common interface for users, especially for those who can't use standard browsers. Rendering the application yourself will break every accessibility tool that relies on being able to interact with a programmatic view of the website.
…and yet we still do not have the streamlined authoring experience we had with Flash. The stuff you show is just a crappier way to write boring GUIs with some other language for which you need to download the runtime. Flash let many more people create far more fun stuff than any Web standard ever did.
People forget that Flash also brought C/C++ to the web at some point, but besides some flashy demos, nobody really cared.
The problem is that all this choice creates fragmentation, you have dozens of platforms within a platform on top of another platform. Web APIs and Javascript may suck in many ways, but at least the are a common denominator.
This is a great point... the fragmentation and the steep learning curves for each stack (and constantly needing to be on top of breaking changes deeper in the stack) all amplify each other and make it much more difficult for amateur designers to build and ship something. Back in flash days, I knew lots of cartoonists and graphic artists who could build interactive experiences on their own that they wanted to put out there. That basically does not happen at all now.
I'm pretty sure Flash (Stage3D) was also the first way to leverage a GPU on the web... for those of us who wanted to go a bit deeper...
Second try:
Hi noduerme, I'm the guy who wrote the original 'Kaos'. I stumbled upon the discussion about it, and have no idea how to contact you besides commenting here...
Any way I can message you?
> and yet we still do not have the streamlined authoring experience we had with Flash.
Uno for example has a visual designer: https://platform.uno/hot-design/
> The problem is that all this choice creates fragmentation
That's not a problem. Build things the way you want in the language you want.
> So there are only 2 web browser engines, and it seems likely there will soon only be 1, and making a whole new web browser from the ground up is effectively impossible because the browsers vendors have weaponized web standards complexity against any newcomers. Maybe eventually someone will succeed and there will be 2 again. Best case. What a situation.
The premise of this article seems completely wrong.
Chromium, Safari, Firefox. And a longtail of half implemented alternatives. But the point is that there are 3 independent browser engines that are fairly widely used. They also have their own indepenedent javascript and WASM implementations. There are a few non browser based WASM implementations in addition to that. As standards go, that's a pretty widely implemented one. There are some people working stubbornly on completely new browser engines even. The standards are in better shape they've ever been since the inception on the web. HTML 5 is way better defined than most of its predecessors.
If everybody was like this, we'd all be using Internet Explorer. Firefox would never have gained any traction. Chrome would have flopped and Google would have killed it. Apple would have given up on Safari. None of those things happened. Because we are not all passively whining on the sidelines about how things used to be better while not lifting a finger to do anything about it.
The "weaponization of complexity" is real—modern web standards are an endless labyrinth of APIs, performance optimizations, and security requirements. Large players like Google have the resources to dictate how the web evolves, while any newcomer faces insurmountable hurdles in achieving compatibility, security, and speed. Even major tech companies have tried and failed (e.g., Microsoft ditching EdgeHTML for Chromium).
Can anyone do anything about it? Google’s control is inevitable. No one can meaningfully compete with Google in the long run. Keeping up with compatibility alone is a full-time job for massive teams—which is why even Microsoft gave up on EdgeHTML and switched to Chromium.
You put the blame on Google but isn't it your fault, people who get excited every time a new feature gets added to web standards, and developers who use it? Like CSS masonry, or WebRTC, or web components with shadow DOM? Features like this get lot of upvotes here.
This is the truth of it: if people chose Firefox, or another alternative, over Chrome then Google would have less power to impose its will on the web. This would be a good thing.
Google’s power on the web doesn’t simply come from having lots of money and resources - see, as examples, any of the multitude of Google’s failures and shuttered products - but mostly comes from its reach.
“Everybody” uses Chrome. If that were no longer true, progress on the web could return to a more open an collaborative model.
Anyone can help that happen simply by switching to Firefox, as I did four or five years ago.
I never used Chrome much. I think I jumped from IE5 to Firefox. IE6 only for testing web apps.
Frankly nearly everything has been working well in Firefox for a long time. The only two sources of problems are:
1) Long tail experimental sites that use or want to demonstrate some new technology. I find most of them on the home page of HN.
2) Myself and the security/privacy plugins I use. They break some web pages, especially ecommerce and payment workflows. I either go hunting for the correct combination of permissions in uMatrix (I would become crazy soon if I used uBlock Origin for that) or I use that very site in Chrome and the close it. Major ecommerce sites don't have any problem. The long tail ones are weirder in their choice of third parties. However that's an issue that any browser would have, it's not because of Firefox.
How much of Edge switching to Chromium was a way for MS to shoot themselves in the foot and focus monopoly discussions on Google instead of themselves?
With the way that AI is unfolding right now, this might be an outdated problem fairly soon. In 2026 if you can just tell your AI to build a new full-featured browser before you go to sleep, you might have something in the morning.
AI might be heading towards a situation where you can "tell it to build a full featured browser".
But this narrative is naive at best, and frankly, getting annoying too. Especially because it gets repeated by people who know even less about "programming" than those who start this idea in the first place.
That AI cannot maintain this browser. It cannot monitor and fix performance issues. It won't be able to refactor stuff when the umpteenth web-api changes or lands. It cannot architecture the modules so that it can actually do this maintainance either.
Generative AI is fantastic at generating stuff. It's terrible at maintaining, changing, tweaking. It's even worse at understanding what you mean with "It must have want a way to disable cookie popups" because that's both ambiguous, and actually the wrong instruction to begin with - for example.
We must stop repeating "AI will be able to program our software for us very soon" because "programming software" is very little about churning out new code. As every programmer with a few years under their belt will know.
What AI is good at, though, is enabling those programmers to be far more effective, efficient. To lower the barrier of entry. etc. But I'm 101% confident that no AI will "write a full-featured browser" that will continue to run for over half a month and/or one OS update.
What is the fundamental limitation that prevents AI from ever doing the maintenance tasks that you mentioned?
Current AI cannot, of course, but the trajectory seems to be that it will be able to do such things better & faster than any human can.
I mean, the goal is to get it to a state where it can do those things. There are benchmarks for autonomously resolving issues that are being hill-climbed as we speak: https://www.swebench.com/
I don't know how far away it is, but never say never.
> Can anyone do anything about it?
Yes, Donald Trump can, because these are all American companies. If he pushes the rest of the world hard enough, the amount of will and the amount of resource that will be mobilized to get out from under the thumb of U.S. tech domination will be something none of us has ever seen in their lifetimes.
The "weaponization of complexity" as you call it is simply "work is done by those who show up".
Google, Microsoft, Mozilla, Apple, etc took the horribly dastardly approach of "participating" and then "doing the work".
The horror.
Microsoft gave up because it wasn't worth it when someone else was willing to do the work. It was not something that was adding value to them by them doing it themselves anymore.
It's hilarious to try to pain this as some evil dastardly thing where they badly tried to keep up and just failed because it's just so hard and costly vs something where it just wasn't worth them paying for because they didn't derive enough value from it.
Remind me which earnings call it was where they were saying "you know, we are going to issue rough q4 guidance because we think it's going to be really hard to implement these next 3 CSS features"
The cost of keeping up for them, even now, if they started again, would be a rounding error in any MS VP's overall equity refresh budget (IE the money they are giving out in stock per year to employees in their org). So please, let's not pretend it's too "hard" or "expensive" for them.
In the end, the world is 99% built by those who show up and do it. That's how this "weaponization of complexity" happened - people showed up and tried to solve problems. The world evolved. They tried to keep moving forward as that happened.
If you think you can do it better, or that it doesn't need to be this complex, or whatever, awesome. show up and do it, like everyone else did.
The world has never been built by those throwing rocks from the sidelines, no matter how much they want it to be, and no matter how much they try to paint the hard problem-solving work of others as "weaponization of complexity".
Calling it that is just plain lazy. Almost all improvements and backwards compatibility shims make it harder for someone else to implement from scratch. That's because the primary goal is usually to help users.
I mean, why stop with the web with this argument?
How come the Go folks weaponized the Go language by adding generics? By making it harder for me to implement my own, they've weaponized it against me!
I can't believe nobody has stopped their dastardly deeds.
I think the "weaponization of complexity" claim can only be understood in relation to the "gimping browsers to protect the App Store" counter claim.
The situation is far more complex than three browser engines competing on a level playing field. "Showing up" is not even possible on iOS. And Firefox is funded by the maker of Chrome.
I think all of this rhetoric that browser vendors use against each other has to be seen against the backdrop of their respective business models.
Money and resource are not the problem nor the reason microsoft gave up on their own browser engine. Same as why they gave up on mobile.
No reasonable amount of engineering resources would have made a dent in the problem. What OP is calling "weaponization of complexity" is just the asymmetry of effort required between new comers and entrenched players.
You would have to be naive to think that google would just open their arms and kumbaya with microsoft to do the "hard work"
We have seen this played out in any industry in history. Sometime hard work is not enough and it's easy to abuse dominant position to grid lock a market.
The rest of your post frankly sounds like someone who is drunk on the usual company cooliad.
> The end goal is to help user
No. The end goal is to make money. Sometime it requires helping user, other time a bunch of anti competitive ( forcing android oem to prevent meaningful forks)and anti consumer (like playing hard ball with ad blockers) BS.
>The world has never been built by those throwing rocks from the sidelines, no matter how much they want it to be, and no matter how much they try to paint the hard problem-solving work of others as "weaponization of complexity
So much wrong with this. And is just a strawman. OP is not saying that it's not hard problem solving. The point is the solution achieved is self serving and sucks for the rest of us.
> In the end, the world is 99% built by those who show up and do it. That's how this "weaponization of complexity" happened - people showed up and tried to solve problems. The world evolved. They tried to keep moving forward as that happened.
Yeah no. History disagree with you
This reads like a semi-incoherent essay from someone who doesn't really understand what complexity is and has a chip on their shoulder about something completely unrelated to the topic at hand.
Yeah and coming from someone with so much experience and industry knowledge as dannybee i find that perspective very puzzling.
Just painting the situation as well google have influence because they work the hardest is just bizare. Having been in some standard / comity meetings. Everyone in those room work very hard... but someone hard work is not enough
> Chromium, Safari, Firefox. And a longtail of half implemented alternatives. But the point is that there are 3 independent browser engines that are fairly widely used.
Come on, you can't say that with a straight face.
Safari exists because Apple has a monopoly on iOS traffic, and therefore an financially significant portion of mobile traffic. As soon as their rigid fingers are pried loose of that (which we're seeing the beginnings of), that's gone.
Firefox is great, and I use it, but it has an insignificant market share.
The "longtail of half implemented alternatives" are by definition not alternatives.
Firefox only exists because Google needs an alternative to pretend its not a part of a duopoly. That alternative doesn't have to be Firefox tbh. They could stop sponsoring and choose any of the thousands of alternatives. Similarly Safari exists because Apple has exclusive control of what goes in iPhones. If it is ever forced by legislation to open it up to other browsers, it will lose some of that control. I don't think it will ever be forced to fully open though. I expect apple to make it so only a select number of entities can afford to release a true Safari competitor.
I switched to Safari from Chrome on MacOS and never looked back. Way faster and kinder to battery. Also, it doesn’t push Google or any other login onto me.
>As soon as their rigid fingers are pried loose of that (which we're seeing the beginnings of), that's gone.
It would be rather ironic if that leads to less browser choice and us all being slightly worse off.
Look at the market share. And look at how much breakage report there is with Firefox vs. Chrome or Safari (not to say the return of "this website works better with Chrome" disclaimers, as if we were back to IE6).
Do you have a source for real world sites broken? It’s extremely rare for me and I exclusively use Safari and Firefox.
There's a lot of websites that break for me on Firefox. Most examples are things like small businesses contact forms... I also had trouble with a kitchen design website. I can't remember what it was, but one just showed me a blank page unless I was on a Chrome-based browser.
half the time it's my choice of security settings and not Firefox. So... IMO %$#^% it - if a site doesn't support firefox I'm strongly disinclined to load up chrome to use it. There are lots of sites and lots of businesses.
Snyk and a few other corpo sites I have to use for work
When I use porkbun in Firefox, it hangs and has to be kill -9'ed.
I use Porkbun all the time with no issues. Probably an extension you’re using.
The issue I first think about if HTML goes away and the web is WASM blobs instead is text. Accessibility, rendering, all the different languages. The amount of code in the browsers making HTML accessible and working in all languages is enormous. If we are going in that direction, we at least need a standard library handling this, so that we don’t take a big step back to the times of Flash.
I was thinking the same until they mentioned "WASI components" for using HTML. I'd still prefer HTML first though
I know it's a rant, but it makes no sense. The web is complex, but for 90% of the web I can still manipulate the DOM - even in apps which use frameworks like React. The ability to manipulate the DOM makes the internet so much more pleasant than otherwise - a world without ad blockers would be quite bad.
Rendering on to a surface would be bad for everyone. Tbh, I think the web is doing great. I am among those (perhaps a minority) who think that web apps should occupy space which is currently held by native apps; even at the cost of complexity and new APIs.
You can also do what I did in https://exaequos.com: implement Wayland in WASM and Javascript. The browser is the compositor. And your browser is your computer…
That's very nice, thanks.
Wow! Thanks for sharing this!
Feel free to give your opinion or ask questions
You can already do this. You don't need a special browser. This approach always sounds great until you consider how native input, text selection, copy-paste, etc. behave on mobile. Not to mention accessibility, screen readers, and so on.
My first thoughts exactly. How do you prevent this from turning into what we had with flash if you don't provide the framework to build the UI components.
Turning the web into what we had with flash except for the many security issues seems to be the way things are headed. Not that I'm happy about it, but more and more web applications are going that route.
The design behind WASM helps keep this iteration of Macromedia/Flash/Java/ActiveX stay quite secure, at least until people start adding the extra APIs that a certain subset of WASM enthusiasts trying to turn WASM into another JVM are going for.
> and making a whole new web browser from the ground up is effectively impossible because the browsers vendors have weaponized web standards complexity against any newcomers
I would argue the exact opposite. Web standards have steadily increased in quality. The web has become much less quirky over the years and you no longer need to emulate broken browsers in order to get a functional browsing experience.
Building a web browser is hard, but it's not impossible. Just look at how much progress Ladybird has made in a year. If Ladybird isn't an existence proof I don't know what would qualify.
Our industry as a whole is way too willing to put up with broken software for literal decades because building a better version is believed to be impossible. And that's how we end up squandering endless (volunteer) resources to marginally improve old projects that essentially have no future.
We can have a better future, but only if we choose to build it. As Henry Ford said: "Whether you think you can, or you think you can't – you're right."
Exactly, impossible is what Google, Apple and Microsoft (and Mozilla) want you to believe - and they do everything to make it happen with more and more, ever more irrelevant APIs. And people believed them for a decade now.
Very happy that Ladybird doesn't believe the monopolists propaganda.
Part of the beauty of the (current) WWW is that last W: the web. By design, everything is (or at least "can/should be") interlinked and scripting/computation is a layer on top of that. (See Fielding's thesis.[1]) Inverting to opaque WASM blobs as the information layer seems like throwing all that out.
Sure, WASM could still simulate interlinking -- because it's so general -- but that generality also imposes an implementation bar. Who's going to write an HTML renderer in WASM just so they can get links to work how they used to? If someone comes up with some simpler WASM-linking solution, how long will it be before there are 15 competing simpler solutions which are all mutually incompatible?
[1]: https://ics.uci.edu/~fielding/pubs/dissertation/fielding_dis...
Funny to read this:
> So there are only 2 web browser engines, and it seems likely there will soon only be 1, and making a whole new web browser from the ground up is effectively impossible because the browsers vendors have weaponized web standards complexity against any newcomers
Ladybird seems to be thriving. Sure, they themselves only plan on releasing a beta version next year, but still.
And it's even on the Hacker News frontpage right now! https://github.com/LadybirdBrowser/ladybird
What is ladybug's marketshare? Does it work flawlessly with "This webpage works better with Chrome" webpages?
It is not even mentioned on https://caniuse.com/?search=web%20components
What's internet explorer's market share? Answer: way less than a percent at this point because current market shares are no guarantee about future ones.
Chrome is the new Internet Explorer. It successfully replaced it. Only to start sharing most of the qualities that were the reason for Internet Explorer to fail in the market. And there was a web before Internet Explorer as well.
Chrome once started at 0% market share. Displacing the dominant browser has been done before. It can be done again.
Web pages that only worked with Internet Explorer did not age very well. Companies ended up spending a lot on needing to replace those. Making a webapp that only works with Chrome is at this point seriously misguided. If only for the simple reason that you can forget about IOS compatibility if you do (as long as Apple keeps a death grip on the app stores, there will be no chromium based HTML rendering on IOS).
>Displacing the dominant browser has been done before. It can be done again.
Why? You skim over all the things that make the present and the future different from the past. The size of the audience is not the same, the size of companies and engineering teams is not the same, the hatred against Microsft was always sky-high... It is not the same battle , it is not even the same battlefield.
I spend a lot of time on the internet and try to avoid the socials, so I visit a healthy variety of websites of all kinds.
But I never encountered a single "works better with chrome" message. Am I missing something?
I see those messages all the time on Google websites and web apps.
It was a thing before Chrome/WebKit became the "only" browser. People mention Firefox but last time I checked its market share is in the single digit.
People complain about Google killing projects that have only a few hundred million users, but then claim Firefox is dead at single digit market share because that's… 150 million users.
It's not really meant for end users currently. Your only option is to build from source. But it has made a lot of progress in a relatively short time.
>But it has made a lot of progress in a relatively short time.
That's always the case at the beginning. And then it stalls. That's exactly the gripe with fast-moving web standards: the churn kills browser diversity by exhaustion.
"Does it work flawlessly"
"they themselves only plan on releasing a beta version next year"
Go one step further and run the browser in ring 0 with minimal overhead. Rely on the security guarantees from WebAssembly and the runtime sandbox for memory protections. Throw out the rest of the OS too.
We seem to be on track for the 2035 timeline in https://www.destroyallsoftware.com/talks/the-birth-and-death....
This post is so wrong and right at the same time.
On the set up: First, there are 3 major engines, and even if Gecko dies there will be two. Second, both users and developers want a more capable web. Don't blame browser vendors for giving it to them. The web is wildly successful because of its continued evolution, and if it stopped evolving, native mobile apps would have beaten the web back even more.
WASM could indeed make for a simple, yet powerful, web-like platform, and I hope to see this! But a lot of the new web capabilities would still need to be there. All of the I/O bits of the modern web: networking protocols, GPU, USB, MIDI, local storage, filesystem, etc. WASM doesn't make the need for that go away. Those things still need to be there as WASI services or similar.
And I hope that such a WASM-based browser would not throw out a markup document completely. Flutter did this and it just isn't the web anymore. Documents and links are critical to being able to build useful services on top of the web.
I want to keep the web web-like, not just have Flutter but WASM instead of Dart.
> WASM could indeed make for a simple, yet powerful, web-like platform, and I hope to see this!
Careful what you wish for. WASM-rendered pages could spell the end of ad-blockers and other extensions that modify or read page content. You'll have only binary blobs being downloaded rendering something on a canvas surface.
That is in theory already possible today, also just with obfuscated js blobs.
But the way the ad networks work, is that they do dynamic content loading. So knowing where the ads are coming from and just blocking those lists will continue to work also in WASM.
But indeed, modifying the content specifically, when all you have is a canvas, will be close to impossible.
I think the point is that there is opportunity for splitting the browser in multiple components with a defined interaction surface. Have a component deal with network interaction, another with playing media, another with text layout. This way subprojects are more manageable for a small player.
We had this 20 years ago.
It was a rich, interactive, streaming vector file format with a gorgeous and tiny code execution engine. It was an incredible time of creative exploration with many thousands of people figuring out how to make beautiful and ugly and funny and sad things and share them with each other.
Steve took this from us 18 years ago because it clearly threatened his ability to enclose the entire application ecosystem, control who can and can't publish, and charge a 30% tax against every dollar spent on the internet.
Please note: Many of the very same people who shit all over Flash as some proprietary, ethical violation, happily tap away on their iOS devices, sending billions of dollars to Tim.
Of course I'm not talking about you, it's those other people over there.
That's something I was thinking a lot about back when I was working on Servo. Wasm + a protocol to talk to WebRender (expose display lists [0] to the wasm runtime). Some sort of "mini web", a minimal runtime that would do just enough that most web APIs could be re-implemented and shipped from the webpage directly. The DOM, the CSS parser, the layout engine, … could just be shipped as wasm modules.
Kind of defeat the purpose of view-source, but nowadays, it's a lost battle already.
And I didn't think too much about sandboxing, accessibility, network or whatnot. Just a fun idea…
[0]: https://github.com/servo/webrender/blob/c4bd5b47d8f5cd684334...
Similar to hixie's https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC...
We would then get some WASM blob that only works on a signed Google browser.
I'm personally hoping for Ladybird and Servo to eventually grow into usable browsers. Ladybird is making faster progress on actually delivering a browser to end users, but if Servo gains foothold in the embeddable use case it should help them gain more stakeholders with an interest in keeping development moving forward.
For a very long time, I was pissed at "the web" being abused by heavier and heavier "apps" instead of staying "websites" and keeping "desktop apps".
Now I am starting to think that this is maybe just a super inefficient way to improve the technology for desktop apps: after years and a shit load of money put into running apps in the browser, maybe the end technology will just end up being used for desktop apps. And going through the browser will just have been a detour.
ElectronJS, Tauri... as if there was a realisation that actually, we want desktop apps, but unfortunately we invested in web tech, so we recycle it however we can.
Not sure if that makes sense, but that's how I feel. I liked desktop app, I'd be happy if it all cycled back to proper desktop apps.
Your comment reminded me of https://en.wikipedia.org/wiki/Joli_OS.
Been arguing for this for years now https://news.ycombinator.com/item?id=33415400
The main argument against it seems to be that a browser forces standards - while really the the strength of this approach is that standards will naturally evolve, rather than forced by 2-3 companies
Ha, I floated the same idea in a random HN comment a few months ago.
https://news.ycombinator.com/item?id=40756196
Every day we get closer to reinventing the Java applet.
Again.
WebAssembly is explicitly a new native plugin like API but cross browser, standardized , and with lessons learned for complexity and security.
You can see it skimming the WebAssembly high level design goals: https://webassembly.org/docs/high-level-goals/. Many of them directly address limitations of past web content plugin systems.
Last time I looked, you still can't touch the DOM without a JavaScript shim. You can't use it to write "normal" client-side web applications without hacks and workarounds.
IOW, it's a VM-style environment that pretty much lives on its own and completely ignores the elephant in the room: that it's running inside a browser that deals predominantly in HTML and CSS.
Just like Java Applets, Flash, ...
[dead]
Sometimes I wonder whether having the document-based-web and application-web in one place a good thing or bad.
Ideally the document based web would require only a subset of standards (html, css, and javascript) and should be much simpler to implement a browser. Then anything more complex could just "Open in an app runner environment".
But then of course since the application-web subsumes the document based one, there is no necessity for vast majority of people to ever care about the pure documents. Maybe gemini people were right and we need a completely different protocol.
I think your "app runner environment" is just turning JS on. It's interesting to think about what if scripts weren't allowed to run by default, but that ship has well and truly sailed.
Who do you think would benefit from having two webs, and how?
> it seems likely there will soon only be 1
What have I missed, will Firefox adopt Webkit?
You've missed Firefox's marketshare inching towards irrelevance, its revenue - "charitable" donations from competitors worried about monopoly lawsuits that can stop at any time - in freefall, and more and more websites not working with anything other than Safari or Chrome.
https://news.ycombinator.com/item?id=43200065
I proposed a similar idea (before WASM was a thing) in 2015 on the W3 TAG mailing list, where I simply said why can't the site owners tell the user's browser what browser engine, including specialized ones, should be loaded to render and interact with their site/app. It was dismissed with idiots from the browser vendors saying it's impossible because of ABI compatibility etc. I kid you not, 10 years ago, and then someone from Meta tweeted the same idea 2 years later (the guy behind Slick Carousel) when WASM was a thing, but he did not specify WASM, and I told him that I had brought it up, too. This is not a new idea, but I'm glad to see renewed interest and WASM as the way to do it.
The Content-Type header tells your Firefox 3 browser whether to use the HTML rendering engine, the XHTML rendering engine, the XUL rendering engine, or the Adobe Flash rendering engine. Is that what you mean?
No, that does not solve the problem of the Google monopoly. Not a fixed set contained within one browser engine, but the browser engine itself, like Webkit vs some other engine vs some specialized engines. If your engine-host browser does not have a give engine or specific version of an engine it downloads it and caches it. WASM/Wayland makes the idea feasible, loading lightweight WASM modules.
https://github.com/runvnc/tersenet
The author implies the hardest part is HTML+CSS rendering + a JS engine. You still have to implement all of the IO and permissions etc, which I'd argue is still pretty hard. I'm a bit sceptic about this approach.
Why is he writing that there are only 2 browser engines, soon to be down to 1? I thought there were three (Webkit, Blink, Gecko). I assume the "soon to be" part is referring to the expected demise of Gecko?
Would this break all existing HTML websites? That seems pretty untenable.
It's nice to throw around ideas like this sometimes, but the reality is if a new browser is not compatible with 99.9% of existing web content, nobody will use it.
The absolute lack of professionalism among most web developers—many of whom are essentially glorified framework developers, barely understanding what they’re doing—is what led us here. This, combined with a complete disregard for web standards and the W3C (dismissed as too consensual, too European, and too slow of an approach), created the perfect shit-storm.
Google insists on pushing its own "standards". And other browser vendors are criticized for being slow to conform to these non-standards. The result? A web cluttered with pointless animations, devoid of cross-browser compatibility, and drowning in superficial bells and whistles.
And the irony? It’s boring. Every website looks the same.
If you’re not testing across browsers and engines (including non-Chromium ones), you’re not building for the web. You’re shipping Chrome-specific extensions that happen to use HTTP. You are not a developer, you are a plumber, and an incompetent one. Good plumbers are so damn rare.
Someone tell him that web is about data, not apps. A markdown only web has much more chances to be relevant than this.
Well, I don't know about that being relevant [0], but at least it isn't blatantly offensive to the concept of providing information like this proposal is.
[0]: https://en.wikipedia.org/wiki/Gemini_(protocol)
this might be in the way of alan kay's core idea, sending messages with interpreters. if we want to go all the way of the snowcrash pipe dream, then imagining objects with programs thrown around is more realistic than making it somehow work with html. on the other hand, in brings back bad memories of flash silverlight, java applets, that almost destroyed the open web. there is a beauty in easy-to-read text rather than binary blobs.
Might work as an application delivery platform but most web content is text
WASM blobs will make the web harder to index, link around, that doesn’t require a compile step, has a built in security model and all the other things that made the web easy to develop for and helped it to grow.
Can you imagine HN delivered as a WASM blob it would be awful…
P.S. How many people really understand canvas?
A WASM engine would end up having to implement some form of of markup renderer which we already have in the browser
I couldn't agree more with this sentiment
There's only two browser engines? Which two? Blink, WebKit, or Gecko?
Those who don't remember OpenDoc and Cyberdog might want to get reading.
Time to go back to Lynx ;)
This sounds like flash all over again.
> no HTML, no javascript, no CSS. Just HTTP of WASM blobs. This is where the web browser is going eventually anyway
Uh, hm, I think this critical assertion requires some justification.
Why would anyone want this? Is the author evil or just stupid?
Java applets are back wohoo.
yeah, maybe, but I fear ad blocking would be much harder.
The most effective ad blocker is choosing not to use websites that display ads. That won't ever change.
Insightful, which search engine do you use? Where do you buy things online? How do you keep in touch with relatives?
If your answers are "Kagi, no online purchases (or reviews), phone calls" sure... But it's not the world we live in
In the context of a discussion about websites becoming binary blobs of WASM code that make it essentially impossible to block ads on, the choice will be to use a site and see adverts or not to use that site. I'm saying that we should make the choice not to use a site that displays ads. It will require some sacrifices (or, more likely in my opinion, spending some money for some subscriptions.)
My take would be starting with WAI-ARIA, or create a new standard with similar goal and keep the standard minimal and single-purpose. We are heading into the era of AI driven UI anyway.
Browsers are dead anyway ... Most people visit Google, AI chat, fb, instagram and TikTok. For devs, it's same + HN & github. The point is that it's less than 15 websites (at least the top level ones), not counting where they take you to next!
What's coming is a malleable OS that runs natively + in the browser ! probably uses WASM and that breaks the barriers between apps. I need to build one to show my point.
[dead]
[dead]
It seems most people here are concerned about the readability of web content. Text is already gone with SPAs and React. The only reason we still have an index-able web is because of Google and websites still want to get indexed and ranked. In fact, I'd say Wasm is probably better for text since now you have to provide text in a raw format (ie: JSON) for it to be linked/indexed which is much better than trying to crawl incomprehensible HTML.
I'd say the biggest bottleneck for WASM adoption is the current "establishment" of computing. In order to serve a simple web application, you need an Operating System, Networking stack, a Web Server, a language interpreter, etc... With WASM, all of this disappears and get abstracted away behind a single (or few) solutions. Instead of paying for a full virtual machine to process a few web requests that sits idly for 90% of the time, you only pay for CPU time when your worker is computing stuff (Durable Objects).
There is little incentive for the industry as a whole to move to this model since the end user is the one who is paying for all of this compute. Maybe the Chinese will figure this out and finally push toward that direction.
What do you mean that Text is already gone? SPAs and React render plain HTML.
Inside the browser but the code is gibberish/chunked and the HTML is not there until the component is mounted.
They do, but anyone trying to see how a Website works will find the developer tools as usable as with any browser plugin, unless they have the right plugins installed, and running the developer build.