←back to thread

1034 points deryilz | 1 comments | | HN request time: 0s | source
Show context
al_borland ◴[] No.44545060[source]
Even if bigs exists to work around what Google is doing, that isn’t the right way forward. If people don’t agree with Google move, the only correct course of action is to ditch Chrome (and all Chromium browsers). Hit them where it hurts and take away their monopoly over the future direction of the web.
replies(26): >>44545103 #>>44545185 #>>44545382 #>>44545931 #>>44545951 #>>44546164 #>>44546522 #>>44546599 #>>44546664 #>>44546763 #>>44547531 #>>44548200 #>>44548246 #>>44548399 #>>44548418 #>>44548820 #>>44549698 #>>44550098 #>>44550599 #>>44551061 #>>44551130 #>>44551663 #>>44553615 #>>44554220 #>>44556476 #>>44571602 #
pjmlp ◴[] No.44545382[source]
A monopoly achieved thanks to everyone that forgot about IE lesson, and instead of learning Web standards, rather ships Chrome alongside their application.
replies(9): >>44546061 #>>44546268 #>>44546519 #>>44546556 #>>44546560 #>>44546615 #>>44546764 #>>44549899 #>>44550943 #
azangru ◴[] No.44546615[source]
> instead of learning Web standards, rather ships Chrome alongside their application

I am confused.

- The "shipping Chrome alongside their application" part seems to refer to Electron; but Electron is hardly guilty of what is described in the article.

- The "learning web standards" bit seems to impune web developers; but how are they guilty of the Chrome monopoly? If anything, they are guilty of shipping react apps instead of learning web standards; but react apps work equally well (or poorly) in all major browsers.

- Finally, how is Chrome incompatible with web standards? It is one of the best implementer of them.

replies(4): >>44547181 #>>44547228 #>>44547237 #>>44551418 #
quacksilver ◴[] No.44547237[source]
Devs, particularly those with pressure to ship or who don't know better, unfortunately see 'it works in Chrome' as 'it works', even if it is a quirk of Chrome that causes it to work, or if they use Chrome related hacks that break compatibility with other browsers to get it to work in Chrome.

- Sometimes the standards don't define some exact behavior and it is left for the browser implementer to come up with. Chrome implements it one way and other browsers implement it the other way. Both are compatible with the standards.

- Sometimes the app contains errors, but certain permissive behaviors of Chrome mean it works ok and the app is shipped. The developers work around the guesses that Chrome makes and cobble the app together. (there may be a load of warnings in the console). Other browsers don't make the same guesses so the app is shipped in a state that it will only work on Chrome.

- Sometimes Chrome (or mobile Safari) specific APIs or functions are used as people don't know any better.

- Some security / WAF / anti-bot software relies on Chrome specific JavaScript quirks (that there may be no standards for) and thinks that the user using Firefox or another browser that isn't Chrome or iOS safari is a bot and blocks them.

In many ways, Chrome is the new IE, through no fault of Google or the authors of other browsers.

replies(2): >>44548295 #>>44552037 #
js4ever ◴[] No.44552037{3}[source]
No, Safari is the new IE, nothing works on it, it's full of bugs and Apple is actively preventing web standards to move on. Do you remember how much Apple prevented web apps to be a thing by blocking web push, and breaking most things if run in PWA mode?

Apple are by far the worst offender and I can't wait for Safari to die

replies(1): >>44552207 #
1. srcreigh ◴[] No.44552207{4}[source]
It’s death by a million papercuts with safari.

I made a reader app for learning languages. Wiktionary has audio for a word. Playing the file over web URL works fine, but when I add caching to play from cached audio blob, safari sometimes delays the audio by 0.5-15 seconds. Works fine on every other browser.

It’s infuriating and it can’t be unintentional.