Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

web.dev is a resource for learning how to write code for Chrome.

There are entire articles about Chrome-only "standards" with barely a footnote about how controversial the standards are and that e.g. Mozilla considers them harmful on their standards positions site: https://web.dev/signed-exchanges/ https://docs.google.com/document/d/1ha00dSGKmjoEh2mRiG8FIA5s...

web.dev itself should be considered harmful. It is not impartial, and does not equip web developers with a good understanding of what is currently supported in a range of modern rendering/JS engines in 2023. A rendering engine monoculture is a bad thing for everyone and that's what resources like this one are encouraging.



Mozilla prioritizes security far more than possibility, and that's been an extremely sad thing to see. If a user "installs" a PWA, that app should have some chance to have something at least semi-competitive with a native app. But Mozilla is terrified, sells a story about how horrible it would be, how apocalyptic having ambient light sensors or midi or webusb support would be. Mozilla has become proud of being anti-featureful.

There's room for disagreement about what the future of the web should look like. A ton of people are incredibly loud about not wanting the web to grow, have opinions that the existing organic growth is all bad and horrible & the worst thig that's happened to computing. I happen to disagree, but I recognize that desire, and I think factoring in the tension here is important.

What's immensely important to me in talking about a site like web.dev is recognizing what is represented now. If there were other progressive browsers that were interested in trying & expanding, your caution would perhaps be deserved. Web.dev could be an unfair mono-culture. But right now there's no second peer that actually wants to expand the web. So web.dev is fine, represents the only voice of hope and possibility the world wide web has. No one else is playing that game, alas.


PWA is one of the worst ideas in the history of the web.

It is something that only Google could love because they can hire 1000 people to build a Rube Goldberg machine to do the most trivial things.

Push notifications? No thanks. We all get too much spam. It’s bad enough that it spams you with a spamification popup even if you say ‘Spam? No thanks!’

That whole service worker thing is insane, particularly considering there is no completely reliable storage service for the front end. The more you know about http the more you know there are edge cases that can and will bite you. Back in the late 1990s there were systems like Netscape Netcaster that worked with the caching mechanism built into the browser and despite having complete access to the browser code, Google went ahead anyway and built a Rube Goldberg machine that makes you build a Rube Goldberg machine if you want to try to build an application that tries to work offline.

Then when users say ‘No Thanks!’ and the industry says ‘No Thanks!’ the monopolist Google says they are being oppressed.


Here's a basic feature that seems to be unimplemented by Google, how can we change the URL for what we see on the "new tab" screen on Chrome?


That is a matter of the chrome around the page. It has nothing to do with the web platform & web page's capabilities.

There are definitely WebExtensions that give you what you want. The extensibility of the user agent is a supreme superpower that is almost entirely absent in the rest of computing.


I'd be happy for you to point me towards them, I don't believe they exist.

They do exist for Firefox.


A mono-browser-engine culture is no more harmful than a mono-kernel culture. It's worked great for Linux (despite the existence of POSIX) and work likely work great for browsers too.

Unfortunately there is too much meat on the bone and commercial interests would never cede that power to a community effort like Linux.

Browsers could still be dime a dozen but with a shared engine core we could have results instead of bickering over standards and implementation differences.


yes it is, we've already seen this with the retiring of webmanifest v2. a kernel is less commercially interesting, and doesn't allow you to screw over your users for personal gain in the same way.


That wouldn't happen under community leadership ala Linux.

Linux pretty much never breaks userspace.

Instead what you are seeing is the exact problem of overriding commercial interests and no restraint on individual parties because they all have their own little fiefdom to rule over.

A single browser engine wouldn't be the problem, it would be a great boon in many ways. The problem has been and remains that there is too much commercial bullshit getting pushed down into the browser engine rather than being matters of porcelain exactly because there is so much resistance to a fully FLOSS core.

Apple and Google are both to blame here for different reasons. Apple wants browser engines to mostly suck, especially on iOS. Google wants browser engines to be good but not be capable of restricting telemetry or blocking adverts.

However neither of those concerns require having their own engine, proof being that they were both able to share Webkit for a period of time.

Mozilla isn't blameless in this. They push the whole standardisation angle in a desperate plea for relevance while wasting resources on non-browser projects. Their efforts to "protect standardisation" cost us things like WebSQL, created a massive rift during the HTML5 and XHTML years and resulted in relentless addition of complexity.

I'm not saying they haven't done good, if anything I think Mozilla generally speaking has done the most good but they too have contributed to the clusterfuck.

Ironically MS has done very little wrong since the IE10 days, they basically threw in the towel and just use Blink now which is good (minus Google doing shitty things with it).

If we could end up in a place where Blink is developed in a similar way to Linux that -would- be good. It's generally the most advanced engine would be easiest to adapt the Webkit improvements that Safari has made and is already used in many other browser porcelains.

I don't see a way there yet but my point isn't that a path exists but that an end point potentially exists.

Google Bad, etc is true but if that could be fixed a mono-engine situation would be drastically better overall. Waste less time, less incompatibility problems, better web for everyone. (which is why Apple would never be on board but whatever).


WebSQL, like a lot of the stuff Google pushes, wasn't a standard. It was an implementation. And one that raised a lot of questions, like will it track with SQLite or be frozen in time except for security fixes?

With only a single implementation there are risks, like everyone gets owned by the same bug or oversight. In nature mono crops can be devastated by a single virus or invasive species.


Exactly. Linux isn't a standard, it's an implementation and that comes with many benefits. Some downsides also like you noted but generally speaking more good than bad.

I prefer a world where we can have WebSQL over a world where it's killed because Mozilla says that we need to build a new implementation of SQLite just because standardisation.

Obviously lots of people feel differently but my opinion is that standards don't really matter that much when every browser chooses to implement each standard slightly differently.


well, the web needs to be backwards compatible, basically indefinitely, once something has been around long enough to proliferate. so it's generally troubling to just pull in some third party library and go "I call it WebSQL", because you can't make any guarantees about how it will change, whether project policies will change, or if it will be abandoned entirely. For something to be a part of web standards places constaints on that thing, permanently. And I would wager to say that SQLite never agreed to or promised to those constraints, they are their own project and have enough to worry about. So it got the axe.


To add to this, Linus is obsessive about not breaking userspace




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: