That's a high density of bad opinions.<p>The web can and should deprecate features as they're no longer needed, but stopping development on new features is obviously not going to happen.<p>The internet is not a store of plain-text documents. It's a platform for rich applications. It's moving further in that direction because both developers and consumers want it to.<p>WebUSB? I'm sorry, have you never heard of a Chromebook? Schools certainly have reason to read files from USB drives. Web browsers don't just run on Windows.<p>"No one wants AMP. Google knows it, you know it, I know it."<p>Someone reads too much Hacker News. Escape this bubble and you'll find very different opinions on "sites with the lightning bolt".
This article seems to be a rant with lots of random and unsubstantiated claims. The author is disappointed in the web and web browser vendors. Then there's a call for action to stop adding features, which will certainly not be answered given the quality of the article. People are free to write whatever they want on their own blog, but I'm not sure what this is doing on HN.
There are a few valid points of discussion buried somewhere in this largely nonsensical rant.<p>These are, I believe:<p>* Scope creep on what the web really is and what browsers should be allowed to do or not to do. I agree with this and the need to exercise caution in creating or adopting new specs.<p>* Google exercising undue control over the open web. (Also a huge problem IMHO.)<p>* Mozilla imploding being pretty bad for the web.
With or without WebComponents, with or without <insert feature X here>, the web is an horrible platform anyway. The web was never made to make UIs, it was made for documents and it's not even that great for that either.<p>The alien & legacy HTML language & the total incomprehensible mess of CSS rules/layout, the requirement to use JS and nothing else... Everything is a total mess.<p>Looking back, a big mistake of the web was drawing the line too high for the API. The web forced on us JS that nobody wants (and Typescript & Wasm is the proof of that). The web forced us to use CSS & HTML that nobody wants either (Figma and other design tools systems based on simple elements and constrains is the proof that too).<p>What we should standardize is a lowlevel code representation + a set of sandboxed APIs. That's all we need.<p>Wasm + Wasi seems to aim at that, yet they on Wasm side they insist on "how are we gonna make DOM accessible from Wasm ? how are we going to interop between JS and Wasm ?". I don't want the DOM, I don't want JS, I want none of that crap.<p>I hope that Native UIs compiled to Wasm+Webgl(or vulkan or webgpu or whatever we'll agree on) are the future for the web. So that we can write once and run everywhere decently fast.<p>When I see the speed of makepad.nl, the power of Godot Engine running in the browser and the simplicity of Figma & the Fidget framework it feels like prehistory that we are still making UIs and apps with JS&CSS&HTML
I think that article expresses a generally good opinion in the worst way possible.<p>It’s true that if Chrome becomes the only browser on the market, it’d lead to a very unhealthy monopoly situation. There’s an analogy to be drawn with Microsoft’s EEE strategy, except that instead of extending open software with proprietary APIs, Google is extending it with so many APIs that no one can ever build anything compatible.<p>For the web to remain an open and innovative platform, there need to be multiple competing browser engines. The more features Google adds to Chrome, the harder it becomes for Firefox to keep up, and the more impossible it becomes for anyone to build a new browser from scratch.<p>But this article seems almost allergic to actual solutions. It is intent on blaming all the wrong people without proposing any real answers.<p>Look at this bit:<p>> Mozilla just fired everyone relevant to focus on crap no one asked for like Pocket, and fad nonsense like a paid VPN service and virtual reality tech.<p>Of course they did – they had no choice. It takes money to build software. Pocket, even if it is “crap no one asked for,” is an opportunity to serve ads. “Fad nonsense” like paid VPNs actually make quite a bit of money these days. Mozilla makes Firefox, Servo, MDN, and Rust, and does it all for free. I love Mozilla for it, but this article seems to believe that all that is needed for this state of affairs to continue is… what, exactly?<p>> No layoffs or pay cuts at the management level, of course! It’s not like they’re responsible for these problems, it’s not like anyone’s fucking responsible for any of this, it’s not like the very idea of personal responsibility has been forgotten by both executives and engineers, no sir!<p>I totally support pay cuts for executives, but you can’t save 250 jobs like that, and “personal responsibility” alone can’t pay the bills. Not only does appealing to personal responsibility solve nothing, it distracts us from actual solutions by letting us blame individuals for the systemic reasons that our problems exist in the first place.<p><i>Continued on my blog because I wound up writing more than I expected:</i> <a href="https://www.blackcap.site/posts/google_wont_stop/" rel="nofollow">https://www.blackcap.site/posts/google_wont_stop/</a>
I generally tend to agree. The browser is becoming a terribly fat client, and the complexity and version/brand variations create a testing nightmare and moving targets that make the DLL Hell of the 90's almost look good in comparison.<p>To better manage the mess, perhaps break up the standards into 3 groups: 1) Art/games/entertainment, 2) Documents, and 3) CRUD/GUI for "productivity" work. We don't have a decent GUI-over-HTTP standard yet.<p>There also needs to be more coordinate-based options in the standard(s) so that the server can optionally control the layout flow instead of the client. Letting the client do it leads to the browser/brand combinatorial mess mentioned. If you can let the server do it, then you are dealing with only ONE layout engine instead of the many micro-variations we face with fat browsers. (Current HTML has <i>some</i> coordinate based ability, but it's too inconsistent, especially for text.)