There are some people who see the web as a platform, and some people who see a web browser as a window for zero-install applications to draw into. There have always been people in the latter group who try to abstract everything away, but it does tend to discard pretty much everything that makes the web great.
A lot of what Next does/did _is_ leaning into web’s strengths. It was Next that made me declare image size beforehand, for example, drastically reducing layout jumps. It also made image optimization almost effortless, greatly improving load times for my websites. The web as a platform is a nice concept I would love to adopt more, but then I need to write some server-side code and I am completely on my own. Pushing the DX around the client/server boundary is one of the things that made Next great for me.
WebP is 15 years old, and Google cares about it less than anybody else. Pretty much everybody else supports WebP but Google can’t even be bothered adding support for it to Google Docs.
I would have hoped people would have been inoculated against the 'infrasound is harmful' nonsense when it was used as a complaint against wind turbines.
> Your premise that the browser implementation is faster and better is rarely true.
I know that they’ve optimised this as much as they can, but it still seems to catch pretty much everybody by surprise that every single instance of a web component with a shadow DOM needs the site’s CSS reset added to it individually (or just skip it and keep forgetting that things like box-sizing will be inconsistent with your non-shadow-DOM styles). There’s no way to say “here’s my default styles” that will work consistently across the whole page once you start using web components. And then you have the !important fights between the web component and its contents as well.
Even though it’s been standard practice amongst web developers for 15+ years, the people working on the web platform seem to mostly act like CSS resets aren’t a thing.
The tension is between two kinds of CSS users. The ones who want cascading style sheets, and the ones who want scoped style sheets. And sometimes even people who think they want scope find out they also want the cascade, and just wanted to scope a bit "at the end" (something the cascade can do anyway)
I find that developers add a CSS reset without thinking about it as if there is always a need. We never used resets. There was never a need. Typically we would set something according to the design anyway and starting with a reset was like slamming something against one wall only to throw it back to a different wall later.
They were a lot more necessary when each browser threw in fairly random sets of default styling. These days they've converged heavily on the same defaults.
The box-sizing property is another way of calculating element sizes but not the default way or the only way. Those of us who were adept at calculating the area sizes after years of doing so had no need for it. Those who are new to the game or can't figure it out use box-sizing.
The history here, as I understand it, was that they imagined you would use custom elements from multiple third parties, so any shared CSS definitions would cause breakages.
> there are only three platforms: Blink/V8; WebKit/JavaScriptCore; and Geko/SpiderMonkey.
You’re misunderstanding the terminology here. The platform being talked about is the World-Wide Web and you are listing three implementations of the client part of the platform.
I think you have the causality incorrect. There aren't fewer implementations because the standard is complicated; the standard is the product of the browser wars, when well-resourced browser implementors differentiated themselves by adding behavior to anemic/underspecified standards. Browser vendors did, to their credit, co-operatively add a lot of common/similar behavior and then work to standardize it--that's healthy standards growth. But a lot of the size of the standard is because they all wanted to add different capabilities to entice users.
A standard that's the product of feature competition between pre-existing nonstandardized behaviors is doomed to be huge. See also: AMQP, C++.
The browser wars are long gone, and there is no technical reason why the standards each browser added had to be complex per-use-case builtins instead of composable primitives.
In any case, that is what happened.
And now new projects like Ladybird take a decade to arrive, even with AI, because of the immense amount of stuff in the platform.
> standard that's the product of feature competition between pre-existing nonstandardized behaviors is doomed to be huge.
> The browser wars are long gone, and there is no technical reason why the standards each browser added had to be complex per-use-case builtins instead of composable primitives.
Browser vendors couldn't see the future. Each was doing their best to stand out from the crowd with limited budgets and schedules. Hence JS being as odd as it is.
With hindsight it's clear it could've been better. And now with today's mono-culture there is an opportunity to drop some of the legacy cruft and rethink a modern web. Or even just slimmer Electron-like solutions using an ideal subset as better primitives.
I really wish something like FirefoxOS had gained traction. Because unlike Android, it could make native apps so much more open an approachable. In theory at least.
Safari 16 is not a reasonable target for the vast majority of developers.
Apple tends to support older iPhones in newer versions of iOS, and iPhone users upgrade their software a lot. The most common target is the last two major versions because people using older versions are so rare. Every iPhone released in the last nine years can upgrade to iOS 16 to get Safari 16.
If it makes sense for you to spend time supporting 0.25% of users rather than spending that time on the other 99.75% of users, then support Safari 16. Everybody else should avoid incurring that opportunity cost.
Once upon a time, there was a golden age for devex, when “the platform”, i.e. Windows, was on-prem and Microsoft wanted everyone to be able to develop software for it and have it easy to set up and run. Thus, we got very nice toys like .NET and SQL Server, which is still the easiest, most batteries-included and hands-off database to this day. As much hate as Microsoft deservedly got and still gets, it’s hard to overstate what a miracle this alignment was. A corporation’s real, intrinsic, not just stated in marketing, but legitimate goals were to actually empower customers. When does that ever happen?
Of course, this had its own misaligned incentives: Microsoft didn’t own the web, so they were only interested in improving it strictly on Windows, so they put proprietary shit in their browser. Everybody saw that this was bad and a big long struggle ensued and finally Firefox came out on top.
But with the balance shifting in favor of the web, new incentive perversions arose. To sell cloud bullshit and lock people into their platforms, web companies obviously don’t want you to have a good time developing or hosting competing products, even just for yourself, so complexity exploded and any focus on developer and operations experience went out the window. They also don’t want anyone to be able to turn of Javascript or otherwise have much control via their “user agent”, so not only do they not care about advancing “progressive enhancement”, they’d probably prefer to get rid of it.
As quickly as Firefox saved the day, one of these companies came out with their own browser, and everybody saw that this was going to be a bad idea, but they ran TV ads, so everybody switched regardless.
Actually, developers were the first ones to switch, because they were promised cool new toys, lmao.
We should have rejected clouds and we should have rejected Chrome and with some luck we could this day be living in a paradise of on-prem toys and be the princes of our orgs. Well, probably not, but still.
That lets you bring up the picker, let the user pick any date, and then show an error message if they picked an unavailable one. It doesn’t let you show dates as unavailable in the picker or prevent the user from picking them.
> I just genuinely think WebComponents are a badly designed API that is weird and hard to use
This was exactly what sprang to mind as soon as I saw the title. I’ve been writing front-end code for over 25 years now, and exactly two things in that entire time have made me miserable enough to think about stopping: Internet Explorer 6 and web components. Every time I try to just “use the platform” it makes me miserable and I end up demotivated and stop working on whatever side project I chose to try again with. And I otherwise like the web platform! I’ve been building with it since there was nothing but the web platform. But web components kill my enthusiasm for it stone dead.
Even now in the age of agentic development, AI trips over all the same footguns in web components that humans do. It just seems like everybody involved has been adding to the standards with “yes, and…” without ever thinking about how it will be used by web developers in practice.
reply