Hacker News Reader

I have been down this road. I've explained this almost two decades ago, I've enjoyed the quiet vacation from actively promoting the benefits of an open web, but will explain everything again if need be. I hope we escape again.

Web developers should absolutely be a responsible party here. If other parties eschew their responsibility, this does not excuse web developers from being correct about their trade.

What does being correct about their trade mean? In this instance, it means making sure users aren't locked in one browser, allowing for the browser landscape to remain competitive, because it leads to a better future. If I may use an example from the last time we did this dance, it means not using ActiveX plugins, because it ultimately leads to a local optimum and stagnation on the web.

The web is our common lake, a common good. We all have a duty to protect it.

I must ask, why should we (web developers) be the responsible for making everything work with every browser?

Because if we don't are we really "web" developers or are we Chrome developers.

literally the same thing as asking application-oriented developers to code and test their apps for every major compiler out there.

Back in the 'olden days' we used to do that too. Some developers would claim their program ran on "Unix" when all they'd actually tested with was GCC on Linux. Sure, sometime it worked or other Unix platforms out of the box and sometimes it could be made to work, but it was still a "Linux" app, and 'we' did complain about that too (and got promptly ignored by a lot of developers who felt just like you do).

And to confess my own 'sins' the web app I'm currently working on is officially Chrome only, and it makes my life so much easier, so I'll admit I'm part of the problem.

What web developers should be doing is testing for features, not UA-sniffing. In this case, to the extent known, it appears that Skype for "web" functions on Firefox and Safari without any issues, if you change the UA. (It would also be nice if web sites provided graceful degradation if features are not available, but that doesn't even appear to be necessary here.)

Also, as others have pointed out, do you really want to live with a Chrome-only monopoly? For instance, do you value having a full-featured Adblocker? Recently, Chrome was considering withdrawing some of the extension APIs needed for one (they've since partially, though AFAIK not completely backtracked). I won't pretend to have an insight into Google's internal politics, but I think it's plausible that the existence of a privacy-friendly alternative such as Firefox (apart from obviously being valuable in itself for its users) discourages Google from being too privacy-hostile for fear of users eventually getting fed up and switching (or it provides an argument for the Google engineers, the vast majority of whom want to be user-friendly, for resisting introducing more egregious privacy violations).

> It's literally the same thing as asking application-oriented developers to code and test their apps for every major compiler out there.

Not at all, the build step is not supposed to be done by the user in the native world. A more apt comparison would be that outside the occasional hiccup, video games run on all GPU, you do not see e.g. AMD-only games.

> There are standards

Most of the problems IME stem from web developers not thoroughly following the standard, but rather implementing a “it works on my Chrome, so it should work everywhere”.

> why should we (web developers) be the responsible for making everything work with every browser?

You do whatever you want. But if you propose a service, expect potential users either to leave or complain if it does not work on their setup.

I see games that are only for 1 OS. And most of the games won't behave the same way running on AMD than on NVIDIA. Also, most of the games require at least XYZ version of DirectX. So, yeah, I'd say your argument is kind of flawed.

And sure, I'll do whatever I want, or whatever my limited time allows me to do. And if that means supporting only the browser with major quota (like games running only on Windows, because that's what has major quota; using your argument), so be it.

Nobody's saying you can't do whatever you want. Pissing on the common lake is, in the short-term, better. What everyone is pointing to is the long-term effects, which are really so obvious you can only ignore with conscious effort.

> And most of the games won't behave the same way running on AMD than on NVIDIA.

I see you must not have played a lot of games recently – granted, you will notice some problems form time to time, but they are rather the exception (and often fixed by post-launch drivers updates) than the norm.

> Also, most of the games require at least XYZ version of DirectX

Also, most of webapps require at least version XYZ of browser ABC. What is your point exactly, that developers use new features of APIs/libraries?

> that's what has major quota; using your argument

No it's not my argument. In my argument, Windows + DirectX is a standard akin to the web standards, and this standard is implemented by multiple controller makers, GPU founders, screen producers, etc.

Thankfully, I can play Il-2 or Rainbow 6 as well with my GTX1070 and ASUS than my friend with is Vega GPU & LG screen.

> What is your point exactly, that developers use new features of APIs/libraries?

Exactly. We use whatever new standard makes our live easier. If Firefox or Edge don't support that standard (because they are always lagging behind), there's not much we can do (except going the hard way and implementing workarounds for each browser, which is a no-no most of the time, because of lack of manpower/time). "My website requires Flex support" is pretty much the equivalent of "My game requires DirectX 11".

I think the issue is that developers will go around glitches and bugs of Chrome because that's what they use, but won't do the same for Firefox. Or even will literally code to Chrome's glitches and not really support the standard way, which would have worked in Firefox. There are also things like Google putting invisible div over YouTube, which breaks Firefox rendering optimisations but not Chrome's ones.

The invisible div broke scanout compositing on Edge, not Firefox.

> It's literally the same thing as asking application-oriented developers to code and test their apps for every major compiler out there.

No, the end user is not usually in control of their compiler. It's closer to making sure thatthe program works on every screen size or OS you're targeting, because these are the thing the user controls directly.

> We can't be the responsible for making every webpage compatible with every browser.

Not directly. You can do that by coding to the standards that all browsers support. To extend the compiler analogy, if your customer is in control of their own compiler, then you don't code to MSVC or GCC, but you code to C89 or C++03, knowing that the standards-compliant compilers are able to support that. The burden is definitely on the coder there.

You might argue that you need the newest standard, and then I agree that part of the responsibility is on the browser vendor, but I still hope that you're going to implement graceful fallback.

+15 year? Where have you been when everybody standardized on IE6 and this was a bad thing?

I thought it is new generation that reinvents the wheel but it seems I'm mistaken.

Sure. But you're missing a point here. IE6 was bad because it didn't follow any standards. You had to, literally, "code the IE6 way".

Chrome on the other hand is starting to be a problem because it's too damn fast at implementing new stuff (which are accepted as standard). Web-developers then start using those new features and the code they write suddenly doesn't work on other browsers, because those browser just don't support those new features yet.

That's why we got webpack. That's why we got babel and polyfills. And that's why frontend development sucks a lot lately. Because you have the choice of doing X the easy and fast way, that currently works only with Chrome, because no other browser implemented that yet. Or, you can do it the hard and slow way, that works with all browsers.

And this is not something that I'm pulling out of thin air. This has been discussed several times here, in HN.

A standard is only a standard when there is more than one implementation. Chrome DRM or Chrome RTC are no better than ActiveX, except for hindsight (_now_ it is obvious ActiveX is crap).

The central point is avoiding lock-in, with the long term objective of maintaining a competitive browser landscape. Code for one browser, and we'll be collectively screwed when Chrome development reaches Google Reader status.

A standard is whatever goes into https://html.spec.whatwg.org . Period.

CSS Flex is a standard. If Konqueror, Firefox, Edge, or whatever other browser doesn't support it (I know they support it now, but that wasn't the case 2 or 3 years ago), it's not any of my business. I'll keep using Flex because it's an accepted standard. And my webpages will work on any browser that supports that standard. If that means that my website works only on Webkit-based browsers, well, then that's really not up to me to fix, isn't it? That is something that the people behind other browsers should fix, by implementing "Flex".

This is just the latest iteration of the age old "fix your code" vs "no, fix your compiler" argument.

it's not any of my business.

So what is your business?

You're obviously correct about the problem, and I don't think anyone is denying that targeting Chrome only is a lot easier than targeting "works with all browsers". The point is that if 'we' want to call ourselves "web developers" then we probably should be doing things the "hard and slow way, that works with all browsers".

The problem is deeper than you imply. It's not just standards, at least not for everyone. I'm currently replacing a website that was developed several years ago that does not work on Firefox.

It is nothing special. It's your standard CRUD app. Not even an SPA. From what I can tell the tech they use is all at least 5 years old.

They obviously never even checked to see if it worked in Firefox. It should work in Firefox. There is no excuse for it not to.

If you are actually analyzing your featureset and saying "I could really use these new standards Firefox doesn't support", that's one thing. If you are just coding whatever and seeing it works in Chrome and calling it a day, you aren't coding to a standard, you are coding to whatever happens to work in Chrome.

> Chrome on the other hand is starting to be a problem because it's too damn fast at implementing new stuff

Are Chrome devs implementing new standards after they become standards, or are Chrome representatives turning Chrome features into standards?

Hey just wanted to say I really appreciate your comments. I came looking for content like this, and I have grown tired of HN's blind "moral" stance against Chrome lately.

No the new generation always repeats the same mistakes and even loves the idea of repeating them.

At some point google can just follow whatever standards it wants and then no browser except chrome will ever get it right.