Hacker News Reader

Comment by umvi | Hacker News Reader

> developers are increasingly shunning other browsers in their testing and bug-fixing routines. If it works as intended on Chrome, it’s ready to ship.

That's me. Sorry, but I just can't be bothered to support every browser's quirks. I check Firefox every once in a while, but really, I don't mind losing a few users if it means significantly less maintenance and testing for me.

It's like complaining that developers are increasingly shunning other OSes - if it works on Windows, it's ready to ship. Yet people do this all the time for video games and most Linux users understand that making a game that runs equally well on Windows and Linux and Mac is no simple task.

View on HN

Developing against Chrome is exactly "support every browser's quirks" instead of developing against the actual standards (usually Firefox has the truest implementation of which).

But as a web developer I don't necessarily care about standards. I want the page to work for as many users as possible. For the longest time this meant to support IE's way of doing things, now it means to support Chrome (unless you target Enterprise users).

Even if you develop for Chrome, Firefox and Edge you'll just end up building workarounds for all 3, not adhering strictly to the standard.

Sorry to break this to you, but as a web developer you should only care about standards, otherwise you have no standards.

The standards are a single source of truth for your production, if you build solely to a single browsers quirks (in this case Chrome) then those quirks can change at any time.

And if you build to the standards, it's possible that no actual browser implements them correctly.

And then what?

You wait for them to do so, and are vocal whenever this happens.

"Wait for them to do so" is an answer that guarantees your team will get passed over in favor of a team that brought a working product to market today, to solve real problems real users have.

> And if you build to the standards, it's possible that no actual browser implements them correctly.

> And then what?

Build to standards first, then accommodate quirks last.

Building to Chrome first is just building to its quirks, and totally forgetting about standards.

I'm not sure what the difference is. It's not like people learn HTML from Chrome's source code. They learn HTML from places like MDN, which document web standards.

"Write HTML, test on Chrome" - what people do in practice - seems to fit "build to standards first, accommodate quirks last" just as well as "build to Chrome first".

My standard is the browser ~95% of my users use. It's the only meaningful one.

I still fix FF bugs when they come in (it seems to be a bigger offender than IE recently) but developing for Chrome first is the only approach which makes business sense.

95%? I haven’t seen less than 20% mobile Safari on any site I’ve worked on in the last few years, and that’s not even including Edge / IE / Firefox and desktop Safari.

Our users are almost exclusively professionals working on Windows desktops. Probably a fairly unique situation but the point is standards are relative.

only true in american markets

I was actually talking about UK and Sweden (haven’t been to the US in 15 years).

what's the difference? these countries are basically american markets, everything west of belarus is kinda a software monoculture

You would have loved IE6 back in the day.

I get to mandate the browser the work system supports (which is Chrome because that was what the majority of users used when I started so I went with what would cause the least amount of pain) but every feature I rollout works with Chrome, Firefox and mobile Safari (I test all three).

It adds very little extra work with the advantage of surfacing edge cases/issues that might have bitten me even if it was just Chrome in the mix.

Also from a business risk point of view tying the entire platform to a capricious vendor is dangerous and I've been around long enough to remember the days of IE5 then 6.

Once bitten, twice shy.

This point of view is as ignorant of reality as the grammarians that say Webster's English is the only true English. Every standard is a three-edged sword: the spec, the intent behind the spec, and the practical application of the spec in the real world (which all-too-often, unfortunately, includes things like "Yeah, that's what the spec says, but then scammers realized you could exploit that to use people's browsers to mine Bitcoin or something, so no browser actually does that").

A web developer codes against real machines, not the imagined, idealized, and non-existent machines the specs describe.

If that were true then web developers would have never bothered supporting alternative browsers.

Regardless of browser matrices, it is the will of the developer to support the open web platform that made sure that Internet Explorer and thus Microsoft didn't own the web (browser) in the 2000s.

Anecdotally this point of view has done no harm to me and I'm not the only that shares it.

Web devs support multiple browsers for the same reason desktop and mobile software developers code against multiple operating systems: some of their customers prefer those systems, and when you ask a customer to switch their framework to support your product you risk they'll say "no."

The reason web developers care about those customers varies from dev to dev. Some believe there is value in a heterogeneous ecosystem of browser implementations. Some have a few high-value customers who refuse to switch (or, in the case of e.g. Microsoft, cannot switch because enterprise constraints are restricting what browser stack they're allowed to run).

But the point stands that when you support multiple browsers, you don't approach ideal user experience (in terms of performance and reliability) for all your customers by throwing your fingers in your ears and proclaiming "That browser is out of spec!" when you find a quirk---you do what you have to do to make your code run on, around, or in spite of the quirk.

The standards are the starting point for the code, that dosen't mean that a dev shouldn't then write code to support the quirks of the browsers.

Writing to support one browser first was exactly what got everyone down in the deep hole writing code for IE only to find that it didn't work the same in Firefox and Chrome early on.

Also the Dev should be well aware that anything they write to support quirks could well be invalid code such as IE conditional comments.

By your argument we should only need a single dictionary, Websters, because your language is real and not the imagined one people in other english places speak, Webster just happens to be the one that aligns closest to your usage of english.

I read comments like this all the time and I feel like I'm in a different world.

I just write standards compliant ES6 code, put it through a transpiler and some polyfills, and my code runs on every browser. I haven't had to think about which browser I'm targeting for years.

It's often the case that this works fine. When you get into corner cases (i.e. if you try to stretch what animation APIs can do or you start to need to care deeply about the performance constraints of flex layout), you start to need to care about how the browsers actually work.

... but you can (and I'd argue in a lot of cases, looking around at the overly-complicated sites on the web, should) write a lot of fully functional web pages by keeping to the standard and trusting it's good enough. We are no longer in the bad old days where IE and other browsers deviated significantly---most of the browsers today adhere closely to the spec, and in the places they don't, it's often more like one browser handles a nasty corner case better than another because the browser built an optimization in for a critical path your page layout cares about.

I'm tempted to say JS is not the biggest problem between browsers, but CSS... the fact that valid CSS code behaves differently and that it cannot be fixed without changing most of it. Not even mentioning if you actually need to change your DOM structure to make a layout work.

This is like an unpleasant blast from the past. It was wrong when web developers did this for IE, it's wrong now.

Chrome is the new IE?

safari is the new IE.

Edge is the new IE

So, Chrome is the new IE?

The new IE is the new IE.

ie. Chrome

was a joke..

> (usually Firefox has the truest implementation of which).

Is there an "objective" test for standards compliance these days, like the good ol' acid test was for the box model? I agree with this sentiment, but only anecdotally - I'd like to see something concrete to back it up.

Developers have never, in the history of the world, cared about standards. Nothing can be more blindingly obvious when strolling through history. You don't even have to look at the web. Look at SMTP, IMAP, you name it.

People don't write C++ and think about the standard, they write C++ and see if it compiles.

Should they operate this way? Of course not.

Are you going to change human psychology and cause this to happen anytime soon?

Nope.

If you want them to change, you'd have to provide a reason it matters, and very abstract long term notions of "goodness" are not gonna cut it for most developers, for better or worse.

Well, they care about standards when the consequences of _not_ caring about standards become painful in the ecosystem as a whole.

But if that gets fixed, they go back to not caring... until/unless the pain rises.

But in general I agree with you.

> People don't write C++ and think about the standard, they write C++ and see if it compiles.

Yep, you not just have to provide a _reason_, you have to provide tools that fit into workflow as efficiently as conveniently as that. (Ideally, that's a (in this case) compiler that's standard compliant!)

> It's like complaining that developers are increasingly shunning other OSes

Except that web apps are easy to make OS-agnostic and always have been[1]. If your webapp isn't, that is because you chose to make it that way, not for a technical reason.

Pretending that's OK because these other things have to be that way isn't going to convince anyone, but you can get away with that for enterprise-development or captive audiences. Just don't try to gaslight people. For me, I'm just going to close your site when it breaks and not come back. Seems that tradeoff works for you too, so that's good, at least.

[1] Sure, that thing that never caught on, and IE6. Thanks.

And this is why Chrome will win, become complacent, and a new browser will dethrone it like it did IE. Meanwhile, Firefox will continue to hover around the 10% mark or so.

Don't see Google pausing Chrome's development for 4 years like Internet Explorer.

I honestly don't remember what the last time was Chrome introduced some cool new feature in Chrome. Maybe the PDF reader?

PWA, WebComponents, File Access, Worklets and Houdini and everything else in HTML5/CSS3 still missing from ChromeOS are all being pushed by Chrome.

Aside from File Access, I haven't seen any of these. PWA is sometimes mentioned on HN but I've never seen one in the wild (I had to look up the term a few weeks ago). Worklets, WebComponents, and Houdini, I never heard of. I'm not the most in the loop person since I'm not a web developer, but you'd think the cool stuff gets at least mentioned, so going with that, the most recent progressive feature that comes to mind is still the PDF reader (other than general maintenance work to keep up with HTML5, which all browsers do, and which I assume MSIE was also doing in the 4 year period mentioned -- or CSS3 or whatever was hot back then).

Twitter and Starbucks mobile apps are PWAs.

Houdini allows for low level control of CSS rendering, basically it allows for creating CSS classes with our own paint methods, and in the process having lower level JavaScript concurrency using less resources than workers.

I don't see how those really benefit the end user.

Firefox has developed Container Tabs, First Party Isolation, integrated Tracking Blocker, an early alpha for a password manager, Screenshots, Firefox Sync, DNS over HTTP and eSNI, not to mention that Mozilla lets addons do much more with the browser so an addon can really change how your browser works instead of being severely limited in what it can do.

i'm a developer and i find it hard to give a shit about any of that, container tabs are cute but they end up breaking a lot of websites, the rest is not even a blip on my radar

as for addons changing how my browser works - no thanks, i'd rather have a consistently nice browser experience than have to re-install addons everywhere

If container tabs break your website, I suspect you're doing something shady with tracking. It does literally nothing but isolate cookies/storage/scripts.

Firebug was probably the only add-on I ever cared.

For everything else there are network protocols, native apps and scripting.

Blocking ads, should be done at the network layer.

Blocking ads can be done both on app and net layers. I use both piHole and uMatrix (and uBlock Origin on the phone), piHole eliminates the worst offenders already and the addons can make more direct modifications to traffic.

I've been doing web development for almost 20 years now and I've used Firefox as my primary browser since it was Phoenix and before that I used the Mozilla Communicator Suite and Navigator.

I may not be rolling the latest features like WebSockets but I very rarely come across incompatibilities anymore. IE remains the biggest issue and honestly a lot of those are removing hacks and workarounds on older sites as after about IE9 they started to catch up with support.

Most of the "incompatibilites" that I fix are actually when our Junior Devs are using CSS attributes incorrectly and they've hacked their code until Chrome mostly works. In this era of Bootstrap it's not uncommon for developers to just throw CSS at the problem and 99% of the time that's what's caused the issue in the first place.

The web is a global open standard platform for the free exchange of information. I would call it one of the great achievements of computing and mankind. To hear someone say "Meh I'd trade that to save myself a bit of effort" is deeply, deeply disappointing.

I encountered so many people like you in the early to mid 2000s, IE6 or bust.

15 years later and we're stuck with old corporate sites that require IE6 and activex.

The more things change, the more they stay the same.

Linux, macOS and Windows aren't variations of the same OS APIs.

You make it seem like the differences between firefox and chrome are HUGE. What quirks are these you've encountered that can be compared to the hardships of shipping a game that runs equally well in windows and linux?

You would have loved working in the industry 10 years ago.

Reply on news.ycombinator.com