Until we have an OS that is literally just a web browser and does nothing except run PWAs and open web pages, that line of thought won't make sense.

Unfortunate, that they didn't include Edge in the Browser feature coverage comparison list.

The author seems to predicate his arguments on the assumption that "the web needs to be the development platform of choice" or something like that? I feel like I kept asking "why does the web need to do all these things" while reading the article; it feels like the author just assumes that a maximalist web platform is desirable? That having everything authored on/for the web is a forgone conclusion?

and I probably don’t want my normal browser being able to access arbitrary USB devices

It has a permission check, just like location access, microphone access, webcam access, etc.

I guess there's a blurry line between an "application" and a web site. But, generally, for open source applications, I'd rather them be native. Preferably, the applications would actually be native (e.g. Qt, GTK, Jetpack Compose, etc).

The author just push LLM nonsense. PWA's are great for field app where internet is scarce and without the need to rely on google to keep side loading possible. Not to mention the nightmare if you even want to deploy the side loaded app to a fleet of phone without needing to use google play store to publish it as an internal app.

Do you prefer to have everything as a native application then?

I've noticed a lot of consumer embedded products have been using PWAs for flashing and configuring devices (Meshtastic, Meshcore, Betaflight, am32 configurator, etc). I have to open Chromium to use them because they don't work with my normal browser (and I probably don't want my normal browser being able to access arbitrary USB devices).

Publisher targets 85% Chrome, other browsers send Chrome user agent as a workaround, Publisher now sees 95% Chrome. 🫠

And they usually don't really give a shit in the first place about the website at all, the primary target is the app.

if its just a basic marketing website, why default to react at all?

I worked in software development. There are browsers that are tested, and "recommended" and ones that are left to rot. the bigger a company is, the less they give a shit

I don't doubt your explanation, but it's tragic and backwards. It would make sense that a WordPress recipe blog wouldn't be developed with smaller browsers in mind. But 5% of Instagram's traffic is a gigantic amount of traffic, worth catering to. Wouldn't it be the big websites that have both the budget and the motivation to make their sites work across browsers?

Call me a luddite, but I think if I were the website director I'd be saying "If you have to do something special to make it work in Browser X vs Browser Y, you're getting too fancy, you don't need that crap."

Tldr: the big sites only target functionality for chrome due to market share, and if the other browsers don't want the shitty reputation, they have to do this

viewBox="0 0 $svg_width $svg_height"

The y co-ordinate is harder. The algorithm is: Find the height of the SVG.

Why is the viewBox using parameters?

SVG stands for scalable vector graphics. Let it scale.

viewBox can serve as a native baseline area coordinate system. Put width and height on the SVG or let it render in its container instead of misusing the viewBox for size and it will scale just fine. No?

Easier to link directly to the different sizes, probably, done like this, too

I like how it is simple and powerful !

For what it's worth, the Popover documentation is very explicit that <dialog> is the only right tool for the job when you want a modal:

• modal, meaning that while a popover is being shown, the rest of the page is rendered non-interactive until the popover is actioned in some way (for example an important choice is made).

• non-modal, meaning that the rest of the page can be interacted with while the popover is being shown.

Popovers created using the Popover API are always non-modal. If you want to create a modal popover, a <dialog> element is the right way to go.

Both examples have the same behavior for me on firefox mobile. So their solution isn't universal for all browsers :(

This looks great. Thanks for the link!

It wasn't a switch per se. The same people that used to get the RSS feeds continue to get them, but as atom.

All subscribers may see more content for this feed in their reader, but they won't have to change anything on their end, in order to continue getting the feed.

Why did they switch?

If they already have RSS and see traffic from it, I'm surprised they replace instead of introducing an alternative.

The article doesn't make it clear, so I guess the guy mentioned has a saying in the development of the RSS standards?

If so, and if it gets to pass, hopefully it doesn't remind Google (for Youtube) and Reddit that they have native RSS feeds. I get a strong impression they'd ax the function to keep users even further in their walled gardens.

A good old inspiration source. 😃

If only anyone could have foreseen all of these things happening 🙄

Still, credit to the author for actually admitting it all. That takes courage.