The myth of the “modern browser” | Hacker News Reader

The myth of the “modern browser”

christianheilmann.com

50 pointsv33ra23 comments

> I think it is time we stopped thinking in browser versions and instead check for availability of features.

Great. How? Detecting features can be really difficult, it's why we need libraries like Modernizr. Some are outright impossible: try detecting touch support. I know you think you can but you can't without UA sniffing.

Even harder, try detecting mouse support.

I don't know what the history is behind document.implementation.hasFeature but I know that it doesn't work for anything but SVG today. Not sure if that's the way to go but we definitely need a better way that the try/catch and complicated loops we currently employ.

I cannot detect mouse support, except on the assumption of no touch support.

But to check for touch support, all you have to do is test for the existence of ontouchstarted on the window object.

> I cannot detect mouse support, except on the assumption of no touch support.

Bad assumption, you can have a desktop with a touch screen monitor, or a tablet with a bluetooth mouse.

> But to check for touch support, all you have to do is test for the existence of ontouchstarted on the window object.

Firefox uses the same codebase for desktop and mobile, so you'll get false positives on laptops and desktops.

It's silly the hoops we jump through to get to 75% certainty on a feature.

End users should always have the newest browser without having to work on it and thus get new features when they are ready and hotfixes and security fixes in the fastest way possible.

People chasing the chimera of the browser as universal app platform have lost the forest for the trees. Do you really expect me to take a dev platform seriously that can't be versioned and is constantly being changed out from underneath users?

I don't envy QA teams working on web apps.

In a word: yes.

Features are being added, but not removed - at least, not unprefixed ones, even if the vendor prefix process seems to be a little broken. If your app breaks, it's probably either your fault for trying to manually detect browsers or use unsupported features, or a bug that can be fixed relatively quickly (and in the meantime, you can always advise switching browsers, as ugly as that is). If it doesn't work because the user's browser is too old, the advice should just be to use a browser that keeps itself up to date.

This seems like a very handwavy dismissal of the difficult problem of backwards compatibility.

It's hardly a secret that building an acceptably performant web app today requires all kinds of browser-specific tweaks and workarounds. Can I really expect that nobody's going to "fix" the code that made them necessary in some future update to browser X?

Yeah, it's a bit handwavey (I'm a little tired)... but your claim that the web platform can't be taken seriously is exaggerated in turn. Unless you're using unstable features (or possibly writing for mobile devices - but that's a separate issue), you really don't need "all kinds of browser-specific tweaks and workarounds". The definition of "unstable features" is a bit nebulous, and it depends on whether you're trying to support all browsers - WebKit is apparently dragging their feet on unprefixing, say, CSS transitions, but Internet Explorer doesn't support them at all - but for most of the relatively old features like that, the spec is settled, so a combination of shims for existing browsers, which libraries can and do provide, and preferred use of the unprefixed feature should pretty much work forever.

It worked well so far with Chrome. You get your development environment refreshed regularly, often gaining in productivity.

However I started to get some more serious bugs popping up recently. Last week was the break-points were not hit anymore(a little nightmare, now solved! But made me go back to Firefox for a week). And this week are visual errors, like trailing borders when mouse overing links, round corners that are cut,...

All in all, I find more positive reasons than negative to live on a moving platform, and knowing that my clients will run the same and last version as I do.

Let's say you're a large business, like a major bank, and you have 15,000 people running Chrome. They all come in at 8:30am one morning, turn on their PCs, and the latest version magically installs itself (let's pretend there's some way that a whole bunch of clerical workers who might have access only to an intranet can do this, and that their bandwidth can support 15,000 simultaneous downloads of Chrome at 8:31am). Now, what happens if the latest version of Chrome happens to have a bug that disables some mission-critical web app that this bank uses?

If you're a hacker, you can use Firefox until Google resolves the bug and pushes a new update. But if you're an end user at a bank, your PC is locked down and you can't install another browser (even if you knew how). That little bug in Chrome 26.0.0.1 that got fixed in Chrome 26.0.0.2 the next day could cost the bank millions of dollars as 15,000 people sit at their desks for a day unable to enter transactions.

Businesses like this have to be able to install browsers using a controlled process in which all their web apps get tested with the new version of the browser. And installing a new browser on 15,000 machines takes a lot of IT man-hours (remember, the users don't know how or aren't allowed to install their own software), so there has to be a pretty good justification to upgrade.

Welcome to the grim realities of corporate computing...

By the way, you don't have to be a large bank for something like this to affect you. You could be some tiny business like a real estate broker that depends on a web app but is not big enough to be able to afford a full-time IT staffer to maintain your software for you. I guess my point is that once you're out of the world of software developers, minor problems with browsers can be very costly and upgrading to a new version constantly can be risky.

Welcome to the grim realities of corporate computing...

Exactly. I have to assume the people that don't get this have never worked in these environments.

Don't businesses use the corporate versions of browsers? EDIT: never mind, it would be useless in this case, Google does not keep the old versions. Crap.

http://www.google.com/intl/en/chrome/business/browser/ http://support.google.com/a/bin/answer.py?hl=en&answer=1...

https://www.mozilla.org/en-US/firefox/organizations/all.html

I, for one, am looking forward to post-modern browsers.

I am thinking the "HTML5" buzzword is misleading: http://yuhongbao.blogspot.com/2012/07/why-html5-buzzword-is-...

IMO "modern browser" isn't too bad if used properly and definitely better than "HTML5".

I agree it's misleading, but some companies have spent a lot of money on the HTML5 brand, so expect to see a lot more of it.

Yea, I know it is not going to disappear overnight. tantek suggested on whatwg IRC to do a CSS-style modularization of HTML, with HTML5 being the CSS 2.1.

Browser versions are more useful to the end-user who need to upgrade their browser to support your application, but I agree in actual code features should be checked.

"The web is full of outdated tutorials and bad advice and the largest part of those happened because a snapshot of browser functionality at that time was considered state of the art and “modern browser” stuff. "

This can happen with anything on the web and the reason why I always pay attention to the date of each article.

Let's suppose that a browser vendor claims that they support a feature, when in fact it's broken (either small but annoying bugs, or "horribly"). Therefore you can't trust a browser's self-reported feature set. So, an obvious solution is to create a similar client-side table of features. Why can't we do that now instead?

> I think it is time we stopped thinking in browser versions and instead check for availability of features.

This is the pythonic way, right? Instead of trying to determine the class taxonomy of the object you have, you query it for the method you want to use. I could be thinking of something else, though...

Yeah, and really it doesn't even look like that. Instead of asking whether the object has the member in question, you just go for it and catch AttributeErrors.

It doesn't matter how you call it but you can't just stop "thinking in browser versions", that's a stupid meta-discussion without much practical impact. It's browser versions the end customer uses, it's browser versions selenium tests run on and it's browser versions that are in every contract for a serious website.

The point is: In the end the customer doesn't care if you call it modern browser or html5 or interwob2.0, it has to work. The basic notion is that the customer uses a browser and not a feature in some standard called HTML5.

I don't think the author says versions are useless.. yes they are handy to indicate, well, what version you use, but from a code point of view he is totally right imo. Look at it like this: there's the choice between a) writing a huge if/then/else for every version you can possibly encounter and b) checkig for features. I'd pick b).

What does it even mean to "have" a feature? Suppose a particular browser implements a feature poorly, or with certain known bugs; you may still need to be able to work around actual behavior.

Welcome to the world of technical writing.

Reply on news.ycombinator.com