Hacker News Reader

Comment by alexandernst | Hacker News Reader

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.

View on 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?

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.

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".

Reply on news.ycombinator.com