
Web Browsers Need to Stop - caution
https://drewdevault.com/2020/08/13/Web-browsers-need-to-stop.html
======
SquareWheel
That's a high density of bad opinions.

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.

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.

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.

"No one wants AMP. Google knows it, you know it, I know it."

Someone reads too much Hacker News. Escape this bubble and you'll find very
different opinions on "sites with the lightning bolt".

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

------
jaredcwhite
There are a few valid points of discussion buried somewhere in this largely
nonsensical rant.

These are, I believe:

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

* Google exercising undue control over the open web. (Also a huge problem IMHO.)

* Mozilla imploding being pretty bad for the web.

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

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.

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

What we should standardize is a lowlevel code representation + a set of
sandboxed APIs. That's all we need.

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.

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.

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

------
bccdee
I think that article expresses a generally good opinion in the worst way
possible.

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.

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.

But this article seems almost allergic to actual solutions. It is intent on
blaming all the wrong people without proposing any real answers.

Look at this bit:

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

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?

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

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.

 _Continued on my blog because I wound up writing more than I expected:_
[https://www.blackcap.site/posts/google_wont_stop/](https://www.blackcap.site/posts/google_wont_stop/)

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

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.

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 _some_ coordinate based ability, but it's too inconsistent,
especially for text.)

