Folks are surprised to learn I put as much, or more, blame for the terrible state of frontend today on browsers as I do the JS community.
-
Folks are surprised to learn I put as much, or more, blame for the terrible state of frontend today on browsers as I do the JS community.
Browser vendors failed to put their money where their mouths have been on performance, paving endless open fields to create induced demand with every JS engine tweak, rarely stopping to ask if what they have done has actually lifted the average.
Also, the last 15 years of neutered engine competition (thanks, iOS) has lowered vendor ambition for the platform.
-
The last point is really insidious: Apple and the Android team really, *really* wanted to keep the web from disrupting the cozy mobile duopoly, and through interlocking and reinforcing moats have made it nearly impossible for the web to break out and challenge the app store and native frameworks.
This is working-as-intended. Apple's attempt to kill PWAs earlier this year showed intent, and the fallback position they've taken since (that they don't have to open them up) is indefensible.
-
Alex Russellreplied to Alex Russell last edited by [email protected]
Because competitors know they can't ship new features to the wealthy developers and decision-makers that use iOS products with their badges on the bonnet, the incentive to deliver new capabilities to developers on other platforms deflates.
Again, for Apple, this is working-as-intended. And they don't even have to put that much of a thumb on the scale. All they have to do is to "just ask questions" in standards conversations; muddy the waters in public and defuse progress in private.
-
Alex Russellreplied to Alex Russell last edited by [email protected]
Apple understands that the web is a reach platform, and that its Achilles heel is a failure to deliver everywhere. Maintaining a hard cap on web capabilities is strategic.
If developers could just build a compelling PWA experience from a single code-base, they wouldn't need Apple's distribution channel, which would mean they wouldn't need to pay Apple taxes.
And this is why Apple's fighting @owa tooth and nail, going as far as to fund astroturf "developer" groups and mislead regulators.
-
@owa But I'm sure that Apple spending more to defeat browser engine choice than to engage with developers [1], while materially misleading regulators [2] and leaving critical features in a totally broken state [3] and failing to keep pace in general [4] is just a giant misunderstanding. Could happen at any megacorp that makes $20BN/yr skimming off the web!
[3]: https://webventures.rejh.nl/blog/2024/web-push-ios-one-year/
-
Alex Russellreplied to Alex Russell last edited by [email protected]
@owa All of this adds up to an assumption by competitors that Apple isn't up for expanding the web to solve important needs that come from frequent developer requests. The *massive* gap in capabilities that Cupertino maintains is just as apparent in DOM and HTML as in advanced features. They *still* won't implement `is`, and `elementInternals` was trench warfare.
It's painful to really push on expanding HTML and web capabilities because Apple will fight it at every step. And everyone knows it.
-
@owa So if you want a future where HTML doesn't suck and where the warts in Web Components get ironed out and where we might be able to take on platform-backed data binding or SVG-custom-elements, then you need to support @owa.
Apple has continually demonstrated that it is functionally anti-web, including up to the present moment. The only solution is true competition.
I wish it wasn't so.
-
@slightlyoff @owa I learned of element internals like three days ago. Can you elaborate a little on that. I only know the surface of it, that it's important for forms. Is it key for many things?
-
@slightlyoff hold on, are you suggesting that the profit-seeking monopoly browser-owners transparently enshitifying everything else they own before our very eyes might be to blame for the internet also being shit?
I dunno man, sounds a bit far-fetched...
-
@morganm @owa Form participation, default ARIA roles, and a growing set of lifecycle additions.
https://developer.mozilla.org/en-US/docs/Web/API/ElementInternals
-
@nottrobin Hard to believe, I know.
-
@slightlyoff I'm intrigued by
> Browser vendors failed to put their money where their mouths have been on performance, paving endless open fields to create induced demand with every JS engine tweak, rarely stopping to ask if what they have done has actually lifted the average.
I can buy that more performance in part induces software bloat, not exclusive to JS but I guess well measured there. In what sense have browser vendors failed to put money...should they have spent LESS on JS engine perf?
-
@mlinksva I don't think you could convince me that we should be spend less on JS engine work -- there's a huge backlog of projects to do that will materially improve real-world apps -- but browser vendors have been *incredibly* gunshy about putting limits on what sites can "spend". Proposals like this one got visceral push-back:
GitHub - slightlyoff/never_slow_mode: Never-Slow Mode (a.k.a. Slightly-Fast Mode)
Never-Slow Mode (a.k.a. Slightly-Fast Mode). Contribute to slightlyoff/never_slow_mode development by creating an account on GitHub.
GitHub (github.com)
The result has been a lack of constraint, leading to outcomes that now disadvantage those with lower-end devices, which is most of the market.
-
@mlinksva There are many related projects we could be doing, and instead there has been massive investment in some dubious areas (entropy reduction work that will not meaningfully impact fingerprintability, etc.) and a great deal of energy misspent on supporting the worst sorts of ad formats. We can set limits and respect user choice more effectively in all these areas.