WASM Wayland Web (WWW)
joeyh.name
joeyh.name
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.
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.
* Inspect the HTML tree containing the ARIA attributes generated by Flutter.
Wouldn't that help with SEO as well?
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.
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.
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.
In addition to the pitfalls mentioned like being unable to select text, every interaction including scrolling is noticeably laggy and dropping frames.
Because of this alone I would not use.
Additionally, see: https://news.ycombinator.com/item?id=43215065
The only way you can get the proper behaviour for these things on the web is to use actual DOM text. Some parts of it could in theory be made possible, but I doubt that anything meaningful will ever change—it’s too antithetical to the nature of the web.
Indeed, Flutter will never do everything "properly". But that's not its selling point. It doesn't need to, as long as the number of users reached from a multi-platform release outweighs the users lost because they were offended by a missing native feature. (Assuming you're not some massive company developing a parallel app for each platform)
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.
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.
If not, this sounds like a major oversight, and basically kills accessibility dead in these software and makes testing pretty painful.
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 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.
Context: I'm a product manager on the team.
Flutter or somethint similar maybe possibly perhaps might some day conceivably eventually rebuild enough platform that the major gaps and faults and chasms of it might be less terribly ruinous, but users will never have anywhere near as much agency. User scripting will always be at the extent the developer's enable it. Its terrible to think of the web denigrated to being as closed foreign and black box as regular apps are, would set back human conputing's one little tenous bridge of progress back immeasurably.
None the less, theres folks who believe the developer experience trumps all other concerns, and are still full steam ahead on canvas based systems. One of those people is Ian Hixie, former editor of the HTML specification, who authored what is sort of the manifesto of the canvas-based effort, Towards a Modern Stack,
https://news.ycombinator.com/item?id=34612696 https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC...
Plz plz no.
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
This is the only place where I am actually happy about WebAssembly's existence.
And I bet competent developers can create a GUI framework that is more accessible then the div soup that the SPAs use today.
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://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:
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.
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.
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...
Any way I can message you?
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.
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.
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.
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.
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?
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.
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.
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.
It remains to be seen how much royalty free Chrome remains, Web is now ChromeOS, with exception of a little Gaulish village called iOS.
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.
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?
WebGPU will make you happier.
One thing worked right: the app looked the same and acted the same everywhere where it could run.
Browser plugins could have been fixed to catch up, the VM itself wasn't the problem in terms of drain
Adobe Flex was interesting and not awful. The problem was the runtime.
And the company behind it. Who remains awful.
It took us good three years, it was eventually feature complete and used by 120 people on two local installations synchronised back then with Dropbox (hey, I didn’t know any better and it actually worked great over a hurricane m). We have replaced a home-grown COBOL app.
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.
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.
I don't understand why you'd be annoyed at different checkboxes within an app but not at different checkboxes between apps. Do you only ever use a single app? I constantly switch between many apps.
More importantly, having things behave the same makes everything much easier to use. If your checkboxes don't work the same way as the standard ones (and yes, this is a thing that happens) then that's a problem.
In addition to intentional behavior differences, you also have bugs. For an example close to my heart, Slack often loses its mind and destroys my input when I try to use the Undo functionality. This sort of bug would be impossible if they just used the standard UI widgets built into the OS, because the OS's widgets have competently implemented undo.
OS Widgets don't implement undo. Undo is inherently tied to app state and the developer is responsible for managing it. At most, the OS will give you an undo button/icon and you can use it to fit in visually.
Frankly, building a separate version of my app per platform to conform to your nativist standards is a huge waste of time. My UI will work across all target platforms. If you can't figure out interfaces that aren't straight out of an Apple/Microsoft design document, that's on you.
Have you actually built any native macOS apps? I have.
Sure, point taken. Native widgets might work differently than cross-platform ones. That said, there's no reason a cross-platform widget couldn't work identically to the native one.
Indeed, a platform's native widgets an effective way to give users a consistent style and functionality across apps from many developers.
Yet, as a one-man dev team, the cost of building a separate version for each platform is prohibitive. The choice is to disregard most platforms or disregard a small corner of the expectations each user has for apps on a given platform.
The choice was pretty obvious to me.
Ironically, out of the apps I use regularly, the ugly, misbehaving apps built with cross-platform frameworks are from big companies that could easily afford to do it right, like Slack. The apps I use that come from small indie developers are all native. I suppose this is down to competition. I tend to have a choice for those apps, so I can choose ones that work the way I like. For Slack, my choices are to use the app, use it on the web (same as using the app, more or less), or find a new job at a company that uses something else.
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.
Web technology: made either by and for tech. enthusiasts or techies who hate your guts.
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 don’t want public facing web sites to use stuff like this, or Flutter. But some intranet internal tool… eh, fine.
For apps, Canvas is the solution. For pages - DOM.
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.
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.
It would be rather ironic if that leads to less browser choice and us all being slightly worse off.
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.
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.
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.
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.
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 don't know how far away it is, but never say never.
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.
This requires a language that a human can give the specs in. A language that is both precise and unambiguous and understandable by humans. A... programming language?
And it requires AI to understand the effects of changes it makes. On many levels. "If I move this module behind an abstraction, will it make it easier to maintain? Does it touch performance? Would it open security issues?" Generative AI isn't good at reasoning in that way. Maybe other AI, but it seems hardly anyone is pouring substantial funding into areas other than "a bigger and smarter generator than the competition" currently.
From what I've seen, Grok 3 would be quite capable of inferring the effect of any change, at least at a high level. Have you used any of the recent models?
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.
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
But that's not actually the argument really being made here with any evidence. That would be a reasonable argument, but it's also always true - we are human, not robots, that's how humans work in any group setting. So it's not particularly interesting or particular to this that social and other things matter as much as pure technical merit or hard work.
But again, this isn't the argument the post makes. Instead, in this case, the argument being made is (basically) "Nobody in those rooms is operating in good faith, they are instead deliberately trying to make it harder for newcomers. They also only have any power at all through illegitimate means in the first place".
I do not believe any of this to be true.
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 literally makes no sense. What does it mean to have a high asymmetry but somehow, "no amount" can make a dent in the problem. The claim in the OP is about engineering effort, not about "it's hard to get people to want your product" or whatever.
So what exactly are you trying to say here?
"You would have to be naive to think that google would just open their arms and kumbaya with microsoft to do the "hard work""
I mean, i was there for Google, with plenty of others, and I know what we were thinking, because I was partially in charge of it? Please, tell me more about what I and others were thinking. Were you there? Do you have any data or evidence?
The naive thing is usually thinking people on the internet with no actual knowledge won't make up a history that suits their narrative.
"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."
Again, please produce evidence rather than conjecture. What actual first hand evidence are you presenting here? (IE not opinions of random internet people who were not involved in any way). There actually are some folks involved who have this view, but my experience is they are far outnumbered by those actually trying to help. But you haven't even gone so far as to provide evidence from one of these folks who does disagree with my view!
"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."
If so much is wrong with it, describe it. You've also now switched arguments from "no amount of engineering will make a dent" to "i don't like the solution they engineered". Which is it, exactly?
"Yeah no. History disagree with you"
Then, again, it should be really easy to produce evidence of this from folks involved. Where is it?
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.
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.
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.
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.
Not saying I like it, but I'm not surprised at the current state of the ecosystem.
All developers should understand basic web standards, particularly accessibility.
> 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
It is not even mentioned on https://caniuse.com/?search=web%20components
But I never encountered a single "works better with chrome" message. Am I missing something?
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.
"they themselves only plan on releasing a beta version next year"
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).
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 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."
Very happy that Ladybird doesn't believe the monopolists propaganda.
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...
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.
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.
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.
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
We seem to be on track for the 2035 timeline in https://www.destroyallsoftware.com/talks/the-birth-and-death....
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...
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.
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.
Again.
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.
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, ...
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.
Who do you think would benefit from having two webs, and how?
What have I missed, will Firefox adopt Webkit?
And there is a web+wasm stack using Wayland constructs for apps that run purely in the browser+compositor.
Incredibly cool work. Greenfield: https://github.com/udevbe/greenfield
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
If your answers are "Kagi, no online purchases (or reviews), phone calls" sure... But it's not the world we live in
Uh, hm, I think this critical assertion requires some justification.
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.
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.