Hacker News new | past | comments | ask | show | jobs | submit login
The Chrome Distortion: how Chrome negatively alters our expectations (runspired.com)
306 points by twapi on March 26, 2016 | hide | past | favorite | 220 comments



I didn't see the author at any point question the performance of their JS framework. More specifically, it seems like the author is using Ember for their apps. My (very rough) understanding is that Ember tends to have a lot of issues running on V8. Due to the way Ember is written, V8 tends to have a hard time optimizing for it.

Looking at the dbmon benchmarks there's a big difference between Ember performance: http://mathieuancelin.github.io/js-repaint-perfs/ember/

And the performance of other frameworks/libraries:

Angular: http://mathieuancelin.github.io/js-repaint-perfs/angular/

Polymer: http://mathieuancelin.github.io/js-repaint-perfs/polymer/

React (optimized impl): http://mathieuancelin.github.io/js-repaint-perfs/react/opt.h...

Where the other libraries all cluster around the same framerate, Ember is running in the single frames. I know that benchmarks can be written in a way to make one library look pathological so this is just one data point, but I wanted to throw it out there. I agree that it would be great if V8 and Ember played better together :)


You might be onto something here. Jeff Atwood posted several months ago about Android's suboptimal JavaScript performance in the context of Discourse [1], and that also uses Ember. I wonder what characteristics of Ember might make it suboptimal under V8.

[1]: https://meta.discourse.org/t/the-state-of-javascript-on-andr...


I was actually spelunking through the Angular source the other day, when I came across a comment noting that Angular avoids using closures for information hiding, due to their poor performance characteristics. Instead, they prefix private variables with a $$ prefix and leave them exposed to developers. Perhaps the Ember team made a different decision in this regard (NB: I don't mean to suggest that this is the sole reason for the difference in performance, just that these might be the kinds of decisions that matter).


> My (very rough) understanding is that Ember tends to have a lot of issues running on V8

From an outsider's perspective, it would be fair to question if the problem is on Ember's side or V8's side.

Look around the web, From the reports Ember is performing well enough on Safari and firefox, so puting the blame on V8 seems sensitive to me.


You have a good point. Ember triggers a weakness in V8's optimizations causing repeated optimizing and de-optimizing of core Ember functions, which takes time and generates lots of garbage, and V8 should fix that.

My understanding is the V8 team _is_ attempting to fix Ember (and Ember-style code) performance on multiple fronts, things like adding an interpreter, tuning how opt and de-opt are triggered, maybe adding dev tools that make it clear when script is spending time de-opting. Probably the most important thing would be to get more realistic workloads into benchmarks.

Ember does appear to be a pathological case though. Every other framework of similar size has managed to attain decent performance on Chrome.

One take-away here is that JS developers should not assume that all code is fast in all VMs. Optimizations are often (very educated) guesswork, and developed and tested against some corpus of benchmarks. If you use a pattern that isn't common in the benchmarks, you might trigger an unexpected problem. Framework developers should measure performance across browsers early, before baking in any hard to change design decisions.


I've worked on a fairly complex web app with advanced graphic effects. It used Angular, and I can confirm anything this article says, and more. For instance, it's extremely complex to get a CSS animation perform reasonably well on Android, compared to old iPhones.

I don't think V8 is a problem per se, it's the whole browser that underperforms on mobile. The only positive point is that at least it updates quickly. Sometimes minor versions of iOS introduces bugs that you don't ever know when they will be fixed.


Author:

Re Questioning Ember: I've questioned it many times (and vocally, but within the community itself where I'm an active member). This article is about something much bigger than my framework of choice.

On the comparison above: I've called this one out before, it's a very poorly built Ember app that's also running a version from nearly 2.5 years ago, before Ember invested a ton of time in building a very fast rendering engine, there's no end of dbMon demos showing Ember at or above the speed of the other major frameworks, and we'll be seeing a new one soon with Glimmer2 landing.

On Ember: Ember does take an initial performance hit, but unlike other frameworks it tends to give you fairly constant time performance as your apps and features grow. This initial hit is something Ember is working furiously to fix (and I might add a lot of that is directly due to Mobile Chrome performance). Glimmer2 (the brunt of the v8 focus), app shell architecture, code splitting, and tree shaking are all concepts that will be built into every Ember app within a few months.

On a more "app specific" note, I've been working on making occlusion, recycling, and parallelism simple and easy to work with at the framework level in Ember apps, much of which enabled entirely because of Ember's conventions and approach. Generally speaking, I've been able to build mobile and hybrid apps in Ember that are more performant than anything I've seen so far via other mobile and hybrid approaches... except for Android.

On The Article: I didn't talk about Ember much because my experience with this goes far beyond Ember (or Angular, the other framework that hits these problems more often). The point is that for anything other than simple JS applications, building a great app for Mobile Chrome is extremely difficult to pull off, and it becomes a large cost for app developers and has led to the rise of huge investments in OS solutions just for dealing with it alone.

A point that I didn't talk about much, but which is something you see more in SPAs and hybrid (ala Ember/Angular) is that honestly, 1MB and even 2MB JS apps shouldn't scare us the way they do right now.

Yes, I do agree that it's a lot of JS to ship to a browser, and tree shaking, code splitting, and app-shell will help us deal with that. Yes, I also agree that we shouldn't be asking our users to download 2mb of Javascript to see one page.

But the bet on this architecture goes beyond one page, the moment you hit page 2, every page hit is a performance win over the last. And with ServiceWorkers, this story will only get better. While progressive enhancement is awesome, and will always have a place, full blown apps delivered by the web do too, and full blown apps are very rarely 250kb of Javascript.

What was the last native app you downloaded that was 250kb? And (just name names), when was the last time you looked at how big Facebook's native app is? When it comes to JS apps, we're competing with native, it's naive to think we'll be keeping our JS to such a tiny payload for all time.


Thanks for the follow up. A lot of good info in there.

Btw, I just saw this article from the Discourse team on this same topic and was wondering what your thoughts are https://eviltrout.com/2016/02/25/fixing-android-performance....


I don't know which version of Ember the author is using, but note that last year Ember introduced a new rendering engine called glimmer which performs much better on the same benchmark:

https://www.isemberfastyet.com/

https://dbmonster.firebaseapp.com/


I've always liked this article by one of Stripe's interface designers:

https://medium.com/@bdc/chrome-is-the-new-ie-1a21c1efc133#.3...

>Chrome is unfortunately contributing to the web’s bad reputation by caring more about developers than end-users. Mobile Safari can easily handle, say, a Photos.app-like interface with a translucent navigation bar, native-like swipe gestures and smooth animations. Chrome handles none of this. No position:sticky, no backdrop-filter, no scroll-snap-type (heck, even IE supports it). It’s concerning that Apple is doing better on a phone than Google is on the most powerful desktop.


I'm a Windows user, and one thing I dislike about Chrome on Windows is the text rendering.

Here is a screenshot of some text from the Google Play store rendered in IE, Firefox and Chrome. Click the image to see it in its full size:

http://imgur.com/yYKSNBB

Firefox looks the best to me; Chrome the worst. IE is not great either, but it is better at larger font sizes than Chrome (IMO).

You might argue that the difference in each browser is not great, but it is a noticeable difference.

I would have thought that text rendering would be top priority from a UX perspective given that reading text constitutes such a major part of browsing the web.


Windows has had a weird font rendering subsystem transition since OpenType and some of the subpixel antialiasing and other stuff. You can flip a flag on the latest builds to try the Direct Type engine, and it looks a lot better.


I have a CRT monitor, and Windows 8 font rendering is overall TERRIBLE on it, as in, heavily aliased AND full of colour fringes.

So I installed MacType, only to find that Chrome has two ways to render fonts, and both are extremely wonky, I spent like 30 minutes tweaking MacType to my tastes, and then 3 hours re-tweaking it to make Chrome behave properly, it was a serious pain.


You can probably go through the cleartype calibration wizard to improve the font rendering, I'm basing that on the assumption that the out of the box settings are probably tuned to look good on generic lcd screens


I did, many, MANY times, also tried disabling it, and doing other things.

there are two issues: 1) Windows 8 assumes CRTs won't ever be used with it, and takes the liberty to do some LCD specific graphics stuff, that doesn't even work in LCDs that are organized differently (example: if the panel is "sideways" somehow).

2) the default system font of Windows 8 onwards is "Segoe", that renders poorly in CRTs, and even worse if you disable anti-aliasing of any kind.


> I have a CRT monitor

Sorry, I have to bite. Why?!?


Because it is better... it is just big.

CRT advantages over the LCDs I have here:

1) Greatly better contrast, in fact it is what made me switch back to CRT (all my LCDs have extremely poor contrast, in some of them is impossible to watch "Game of Thrones" for example because in dark scenes you see just everything gray, except for the teeth of the actors).

2) Greatly better colours (LCD not only has colour shifting as you move around, it has less colours overall too).

3) Greatly faster response time. (even to do normal stuff, like using normal programs, with LCDs I misclick a lot).

4) I can use whatever resolution I want... I can play old games in low resolution can play new games in high resolution, can play widescreen games letterboxed or stretched, can play GPU-intensive games in low resolution to make them faster without losing quality due to upscaling, etc...

5) It feels much easier on my eyes for some reason, I am not sure what.


I worked with a CRT monitor for a while (design job at a non-profit; I had 2 CRTs and a several year old Mac Pro—it held up very well though) and it was actually quite nice.

- Non-16:9 aspect ratio. Photoshop is much nicer on 1600x1200 (relatively common CRT resolution) than on 1920x1080. CRTs are frequently 16:10 or even 4:3, so if I had a particularly nice one I'd be hesitant to replace it (4:3 LCD or LED are really hard to find).

- Higher refresh rate. 60Hz is nice enough, but 96Hz or higher is very pleasant. CRTs have a higher refresh rate than LCDs due to how they work (and if they didn't, you'd get quite a headache because there's no backlight).

High-end LCD screens have more or less caught up by now, but it took them a long time and they're still expensive (granted, high-end CRTs are at least as expensive now, but if you've had one for a while there's no real rush to replace it).


In my case I got it for free when someone was throwing it out, it looks good, it's big enough and 1600x1200, has the expected very low response time, and it's not really that heavy, so I really have no incentive to pay to replace it. In addition I like the anachronistic aesthetic and degaussing is nice.


Is it a Sony GDM-FW900 ?


I'm pretty sure this is because Chrome uses Skia (Android's vector graphics system) instead of the native DirectWrite like Firefox and IE do.


On OS X, too, Safari's text is way stronger and more beautiful than Chrome's.


I would have thought that text rendering would be top priority from a UX perspective given that reading text constitutes such a major part of browsing the web.

The problem, as demonstrated by your example and the replies it's generated, is that people have different preferences on text rendering.

Of your 3 samples I think IE is the best and Chrome's is the worst, with FF inbetween. More precisely, I'd be OK with reading text rendered the first way indefinitely (although I'd want to change it), the second one I could probably stand for a few minutes, and the last one I'd want to stop looking at as quickly as possible, because of how blurry it looks.

This is what I normally use:

http://imgur.com/T3ihEqw

Sharp, pure non-antialiased text. I can read text like that all day without feeling like my eyes are going out of focus.


I think that the IE11 one, of those, is best. I would have said that Firefox's rendering matched it but it's doing that broken kind of anti-aliasing which adds colour fringing.


Pretty much describes the archetypal difference between Apple and Google, end-user experience vs engineers developing for engineers ... and those pesky end-users if we must.


Wat. Safari ios is the most obtuse browser regarding to standards, makes devs life miserable in every conceivable way, breaks every standard web interaction since 199x (like a top fixed navbar), has it's own opinion on transform origin, handles differently than every other pseudo elements positioning parent and to top it all when it crashes because it gobs more memory than the os can handle spits a message vague enough that it's the website owner that gets the blame for its faults.


Safari is also the only desktop browser that can handle my "power user" web browsing style. Chrome completely falls over after a few dozen tabs are opened. Firefox holds up better, but still starts starts stuttering when it gets to 80–100 tabs. Safari keeps going fine with several hundred tabs.

Edit: For the folks who are apparently offended by my browser use, I’ll elaborate:

Why would anyone want a large number of tabs, you ask? Well, when researching a topic, it’s often useful to open in tabs, breadth-first style, every potentially relevant link in a network of {academic papers, historical web pages, wikipedia articles, ..}.

For me, it’s much more efficient to partition my browsing tasks into {open a bunch of tabs without looking closely at the content | go through the list of tabs in order, lightly skimming the content and closing any that aren’t relevant | dive deep into each relevant tab, reading carefully, taking notes, etc.}. I find that, as alternative strategies, both (a) trying to entirely finish with one tab before opening another, storing its hyperlinks in a text file for later examination, or (b) only opening links in the same tab, using the browser history as a linear linked list of my current place in the browsing tree, are much less effective.

Theoretically, my strategy could be done with a set of bookmarks, a list of links in a text file somewhere, one of those "read later" apps, etc. In practice, I find that it works better for me to just keep the tabs open in my browser. YMMV.

Anyway, now imagine you have 4–5 different long-term ongoing research interests/projects (possibly related). Sometimes, when diving into one topic, you end up stumbling across a useful tangent into one of the other topics you care about. Occasionally, the thing you stumble on is important enough to temporarily set aside the first topic (tabling the in-progress search by leaving all of the, say, 50 currently open tabs in their own window) and open up a new window to dive in on the second topic. Alternately, imagine you receive an important email, and need to suspend the entire research session for later. Again, it’s easier to just keep the window open with all the tabs in it, rather than closing everything and reconstructing it later.

This might not be the browsing style for everyone. But it works for me, and Safari is the only browser I’ve tried which holds up.


I can't imagine opening 10 tabs, let alone hundreds of tabs without tree-style-tabs.

And only firefox has the infastructure to support such changes to its UI.

I would say that the only broweser that supports your use case is firefox, not safari.


Check out Tab Outliner[1] for Chrome. Its integration into the Chrome UI is not as good as Tree Style Tab's in Firefox but is has better keyboard shortcuts, rearranging tabs with Drag and Drop is more intuitive and its built in session manager allows you to unload entrie trees from RAM without losing the tab hierarchy.

This enables a workflow with several hundreds of tabs without the drawback of the additional RAM and CPU usage. Previously I shared the impression that Tree Style Tab for Firefox has ruined all other browsers for me and I could never switch away from Firefox but Tab Outliner showed me that I was wrong.

[1]http://tabsoutliner.com/


When he says research, he means porn. 100 tabs of porn.


I see this critique now and then, and it always makes me wonder what is wrong with your Chrome installation.

I typically have somewhere between 200 and 400 tabs open, and I work on a wimpy little 11" MacBook Air. The vast majority of those tabs are heavy things like Google Docs. Chrome seems to barely notice.


Just curious to know why you, or anyone else, need 100+ tabs open. Especially when you say you can have up to 400. Can you remember what's in each? I'm not judging, just trying to understand because it's so different from how I use browsers. When my tabs start to become so small that I can no longer see the titles on them I start to clean up by either bookmarking them or close them. I rarely need to bookmark so I don't have a million bookmarks.


I'm a sysadmin and need to troubleshoot a lot of different services. I use firefox with tab groups (the best thing since browser-sliced bread). I will have one group open for my AWS pages, for example, which will have separate tabs for ec2 instances (and maybe) ec2 volumes, ec2 snapshots, memcache, database 1, database 2, instances in another region, pricing page, monitoring, access management, so on and so forth. All separate tabs, because it takes 5-10s to load a new page in the AWS console, and then you also need to subnavigate that page. Troubleshooting will open up new tabs in-between those tabs. Throw those all in one group. Then, when I need to "do AWS", I switch to that group.

So why bother closing a tab when I can just switch out of the group when I'm doing something else? Another group does mail and google docs, another group does 'Atlassian stuff' (ticketing + wiki), another does build and CI, so on and so forth.

The only problem with this approach is memory consumption, because the modern web developer includes approximately 3/5ths of the entire internet on every page, and I 'only' have 8GB on my machine (non-expandable). Performance is fine for a while, but eventually (a couple of weeks) it starts to grind. Restarting FF at this point doesn't autoload the tabs, so it gives you a fresh slate, effectively.

https://addons.mozilla.org/en-US/firefox/addon/tab-groups-pa...


I don't have 400, but I do have 200+, spread across three windows.

I use Chrome's profile feature, to have separate Google accounts signed in.

And my tabs tend to be in "clusters". E.g. I'll have one cluster (5-10 tabs) where I'm doing research on IPv6, another where I'll have a cluster on some JS, another on say, Python list performance etc.

I remember where each cluster is, and even some of the tabs within each cluster - so I just page quickly to that cluster if I know I need to retrieve that info.

Also, I tend to not be that disciplined when bookmarking or filing stuff - so there's that as well.

I'm still yet to find a good lightweight note-taking system - Confluence as a wiki isn't bad, but is still quite heavyweight.


It's actually because I'm so terrible at remembering certain types of things that I keep so many tabs. They are essentially an accumulation of "what I need to work on" for the next few days or weeks, along with the supporting research work I've done to accomplish those things so far. By grouping them in separate windows per task I'm basically keeping all of that context. I could also do the same with bookmark sets, but I've found when I do that I tend to forget about the task itself entirely.

There are probably more efficient workflows, but this one works fairly well for me.


Extensions can impact performance dramatically.


How do you manage hundreds of tabs in Chrome? I used to use hundreds of tabs in firefox, but firefox had an effective tree-style tabs extension...


I tend to partition them into windows once the favicons go away. Otherwise mostly based on the ordering (which I adjust regularly).

Much of the time they are effectively a queue of things to review/skim/familiarize myself with while I'm authoring some code or a design doc. The ones with different favicons tend to be things like bugs where I owe an update, so I scan through them regularly (I'm extremely forgetful when it comes to lists of things to do).

Honestly I know how tree-style management would go for me: I'd group a bunch of things together in a tree and forget about them, largely defeating the purpose of having kept the tab open for me.


For me it is multiple windows, you can shift-select multiple tabs for easier sorting. As in, if the tab bar starts to get illegible I shift-click a sub-topic or other logical range and pop it in a new window.


My firefox is doing fine with several hundred tabs (on Windows though).


Not on OSX, but both Firefox and Chrome do large tab counts for me. Firefox gets a bit wonky around 250, chrome/chromium never gave me trouble (used up to 380 or so). Eat quite a bit of memory in the process though, but that's probably to be expected.

EDIT: uBlock or similar is absolutely must though, unless you browse only slim, "old-school" websites.


Several hundred tabs? Dear god


Aka The User is Wrong


AKA the software was not written with that use case in mind.

Just because the way he/she uses software doesn't work well with chrome doesn't make chrome bad software, and it doesn't mean the user is wrong. It just means that it's not a good fit for that person.


I definitely am not claiming that Chrome is “bad software”. All I said was that it can’t handle my browsing style, while Safari can.


And I didn't mean to imply that you did, just that the person I replied to did.

Your explanation there is a great example of what I personally want to see more of. A clear concise reason why you prefer one browser to another.

So often its just "X is faster" or "Y uses less memory" without any other details. And those kinds of complaints help nobody.


Honestly I was just shocked someone actually uses hundreds of tabs, I struggle to understand why but I guess that's just me. Downvotes ahoy


I'm honestly not sure which label applies to which here. Since I find both Safari and Chrome have various feature sets where they are swapping developer vs end user focus.


Ugh. Candy. Who cares. People are dying in this world and you judge a platform by candy.


And yet people here https://twitter.com/nolanlawson/status/709456732381175808 and here https://www.youtube.com/watch?v=HuHCHHuWL1s&feature=youtu.be...

Complain, or hate Safari, as if it were the IE 6.

I dont do web development much any more. I did in the era of IE6, so someone please enlightened me. In the IE6 era, even the simplest, basic function and table layout ( Tables :O ) wouldn't look the same in Netscape, Opera or IE. DHTML requires different script for different browsers.

Today we have likely 10x+ amount of standard features working across all browsers.

And we continue to introduce new features, many of them either dead in the water or got replaced by better alternatives.

To me, echoing Stripe Medium post, Chrome tends to introduce the features and left it as is. Developers get new toys to play around with it. And try to implement as much as possible. On the other hand Safari is slow to adopt, carefully picking what work best, refine it before it is landed. And Apple's focus for Safari is Web "Pages", or make it as beautiful as PDFs, while Chrome want the Web to be "Apps". These two different focus has often lead to a very different selection of features.

Personally, I like the way Safari works much better. Putting in a features is easy, taking one out is hard.


I think this article is missing the idea of the browser hype cycle (Every 4-5 years):

1. A cool new browser comes along promising a minimal featureset with a focus on speed.

2. Early adopters make the move and start asking for a few features they liked on their old browser (extensions, some customization, etc).

3. The new browser is excited by the growth opportunity and invests in said features.

4. Eventually, the new browser is now so bloated that users start complaining about it being slow and look for alternatives.

5. See #1


Such a "hype cycle" can only exist where the OS supports integration of 3rd party browsers (desktop only).

On mobile devices you can rarely switch browsers without losing access to major parts of the OS (read: 3rd party browsers can render/view web pages, but forget about integration).


>On mobile devices you can rarely switch browsers without losing access to major parts of the OS

You mean "on iOS", not on mobile devices in general. On Android at least all such integration is done with Intents, a broadcast message from the OS or one app to another, and those Intents can be remapped to target whatever app a user wants, meaning a third-party browser can be as integrated into the OS as Chrome. You can even replace the launcher (the home screen) by having your app accept the "Home" Intent.

Whether a particular browser respects the Intent linkage correctly is another story. But it's absolutely possible. Chrome is doing nothing secret and magic on Android.

The exception is WebViews embedded in apps, which are rendered using the Chrome engine (on recent Android versions). But as an app developer, let me tell you that having random third-parties replace the WebView in my app is a profoundly bad idea. It's hard enough to target all the Android versions without having to also target every random browser rendering engine.


> Chrome is doing nothing secret and magic on Android.

> having random third-parties replace the WebView in my app is a profoundly bad idea

You haven’t heard of Chrome Custom Tabs, have you?


No, actually. Thanks for letting me know about that.

Regardless, my point stands: If I'm writing an app and I use a WebView or a Chrome Custom Tab, I'm going to want to know, for certain, that someone isn't switching out the underlying rendering engine.


Well, but that’s the entire point of Chrome Custom Tabs. There are even Presto and Gecko based implementations of it.


The "point" of Chrome Custom Tabs seems to be performance and better integration with the system browser.

I see that it's done via Intent, so it could potentially be swapped out, so you're right.

So then WebView is more of what I'm talking about, for when you want tight integration, or creating something like a Cordova app (though you can bundle a Cordova app with Crosswalk to sidestep WebView differences entirely); looks like Chrome Custom Tabs is more for when you want a good web experience, not a good embedded app experience.


>You mean "on iOS", not on mobile devices in general.

Also on FirefoxOS and ChromeOS where third party browsers aren't possible at all.


The first of which is discontinued and the second not an OS for mobile devices (phone/tablet)


FirefoxOS still exists.

Anyway if we are criticising organisations for creating platforms that prevents switching browsers then I don't think FirefoxOS's failure to achieve any kind of market penetration should exonerate Mozilla. FirefoxOS is/was objectively worse than what iOS does in that regard.


I'm not sure what OS you're referring to here. I mostly have experience with Android, and know that my browser experience is nothing like what you described. Is it really that bad on other OSes?


Why would I ever want my browser to have access to anything outside its running context? In what universe is this a good idea?!

I don't even want it to have access to the clipboard until I affirmatively paste contents!

The browser is a window into an unsafe world of shit you don't trust or control (also known as THE WORLD.) It's SUPPOSED to be at a remove from your local resources. Lack of integration is a FEATURE.

Creating browsers (and add-ons) without this design tenet from the outset is how you end up with MSIE and Flash.


Opera works great on android (although I guess it's still largely WebKit based)


Opera on Android is 99.9% Chrome, with a different UI (which I designed together with a colleague when I worked there).

The differences in non-UI code mostly relates to memory usage optimizations - most of them should be upstreamed by now though.


That hype cycle seems to affect most things. Ubuntu originally appeared on my radar as a stripped down fast version of Debain with a focus on UI. Now its probably the most bloated Linux desktop I have tried.


> I've learned the hard way that Chrome is the new IE.

I started having similar thoughts when seeing sites that require Chrome because they use some (admittedly awesome) new browser feature that's not yet standard. It's given me flashbacks to the days where people used ActiveX for some accessory feature out of "coolness" when they could have had a slightly less fancy site but which would work across browsers.


It's not unusual to visit a site (often something neglected but really important, like a support website), and find it simply doesn't load in Firefox.

Then I open it in Chrome and it works. And it's clear which browser the developers tested the site against.


When people come across such things please report them to https://webcompat.com/ There are some Firefox, IE and webdevs that work on understanding what is broken and trying to get sites to work cross browser.


Sometimes, it's clear what minimum window size they've assumed. I know of one (bank login) which doesn't work well on a netbook due to this.

I tried to report the problem via the site feedback link which they helpfully provide in most of their page footers. It fails in Firefox but works fine in Chromium; I ended up reporting two problems reported instead of one.


There have been extensions for Firefox that opened tabs in IE compatibility mode, which were needed occasionally in the past. I wonder if such a thing for chrome compatibility will end up having to be made. Hopefully not.


It's even more common for sites to require Chrome because they use a prefixed version of something that _is_ a standard, but they just can't be bothered to use the standard version...


Chrome doesn't use vendor prefixes for new features: http://www.chromium.org/blink#vendor-prefixes


Yes, I know. But they have plenty of old features that they support prefixed versions of, and people often enough use those without the corresponding standard syntax. This means, of course, that Chrome can't drop their prefixed versions without breaking websites. As a result, Edge and Firefox are now implementing a bunch of prefixed stuff simply to be web compatible.

For a view of what's needed in real-world terms for compat with the web nowadays, see https://compat.spec.whatwg.org/


I was waiting for someone to come out and say it. 6 months ago, I couldn't imagine using another browser regularly but chrome has become so slow for me, I can't stand it. I switched to Firefox.


Oddly, I have recently found Firefox so slow - particularly on YouTube where for some reason it's unusable - that I'm considering a full-fledged switch to Chrome.


I swear this conversation is as old as time --- or at least Firefox & Chrome.

person 1: "Firefox is slow now i'm moving back to Chrome"

person 2: "interesting! I find the complete opposite and am moving back to Firefox!"

:)


It often seems like this is because <current browser> has dozens of old, forgotten extensions running in the background. They suck up memory and generally slow things down. Switching to <new browser> erases this problem! For a few years, anyway... And then the cycle repeats.


I just did a clean install of OS X El Capitan and within an hour it was obvious that Chrome was better at managing memory. [extensions: UBlock Origin, Ghostery]

Personally, I think the browsers actually do beat each other in performance every couple of months. i.e. Chrome Version 49.0.2623.87 (64-bit) is better than (current firefox version) but next month it'll be the reverse.


And seemingly few people trying to diagnose why. Particularly when it's specific behaviour / sites that are slow.


You're making some assumptions there. It may also be that they have tried to diagnose why, haven't managed to find anything in an hour or so, and feel that their time could probably be more productively used, post browser switch, elsewhere.

(That's the case for me with FF at the moment, anyway.)


I'm switching to Netscape.


Those people should throw away and recreate their profile, including the server-side backup, which is exactly what switching browsers does.


I've actually started switching browsers by website. General browsing? Firefox. Google Maps or YouTube? Chrome.

Dont get me started on how painful mobile chrome is. The most hilariously bad are ironically mobile "responsive" websites that just make it crawl and the scroll position skips around during long loads so tapping a link is Russian roulette - the link can move after the touch and you get whatever moved into its place.

And just writing this post I got that great "cursor skips around randomly and doubles words when undoing a mistaken autocorrect".

Yeah, I like Google software, but quality isn't really their thing.


I do the same. I was finding Chrome slow and bloated for general use so I switched back to Firefox but I still use Chrome for some Google sites.


I do the same, except I use Vivaldi for Google sites ;-)


I have managed to avoid it.

Feels like this would be like going back to the end of IEs reign..


Most Google properties work way better under chrome. Google docs is incredibly slower under Safari, and some docs will be exponetially worse in Sheets. Youtube is decent in Safari but getting worse in Firefox. Hangout is buggy under Firefox, Keep is way too slow for what it does in both.

It becomes a habit to switch between browsers depending on the service.


Youtube is slow and unstable on Firefox on non-high-end computers. I seriously wonder if Google does it on purpose, making the site work best on Chrome with enough plausible deniability for it to not be obvious. Other video sites (both flash and html5 video) work perfectly fine with no lag or jitter on Firefox on low end computers for me where Youtube is unusable.


It's not necessarily on purpose, but as far as I can tell they develop for Chrome first and then make it work in other browsers as needed. The result is that they do end up depending on various Chrome quirks, including both bugs and things it supports that other browsers don't yet, and the dependencies may or may not be found during testing (which is also Chrome-biased as far as I can tell; I can assure you they test more in Chrome on Android than in Firefox on Android!).


Seeing as most of Chrome is open-source and on Github, that's probably a little far-fetched....

https://github.com/chromium/chromium

It's more likely that most people within Google use Chrome (can confirm), and that if you notice your webapp is performing slowly, you could conceivably go over and speak to the Chrome developers to get them to look into it if it's a performance bug and fix it.


I meant the YouTube devs sabotaging it for Firefox, not the Chromium/Chrome devs doing something.


It's not great on high-end computers either. The PC I'm usually browsing from is high enough spec to meet Oculus VR's recommended spec for VR experiences (just about). But YouTube on FF is still pretty unusable.


YouTube's been fine in Firefox on my i5 6600 / r9 380, maybe you just need to start a new profile without old settings / extensions


Check if sending the Chrome user agent string from Firefox makes it any faster or usable. This has been an issue in the past.


Same experience. I've switched to Vivaldi, it feels like the Firefox of old. It's chromium under the hood though


Opera 12 is the only viable choice


I almost agree but sadly Opera 12 is now so far behind that there are websites that don't work properly with it. Especially if involves video.


I still have it installed. Otter is a good modern alternative for those of us who love Opera 12. It's still missing features but it's getting there, and it's blazing fast.


Chrome was (probably still is) the only usable browser left on Windows, but I never used it or had to use it ever since I switched to Macs a few years ago.

Aside from the plugins ecosystem (which I don't need) Safari works infinitely better (loads faster, uses less resources, even with 100s of tabs, and has nice little features like the Reading List, Reading Mode, Force-Touch Peek and so on) and fits into the OS X look-and-feel more naturally than Chrome does.


I use Firefox on all my platforms (Linux, Windows, OSX, Android). It's fine.


Firefox has been a memory hog for the last few years. Enough that I switched to Chrome, only to find it was just as bad.


So just did a quick check, opened the same setup I had currently in Firefox in Chrome (30 tabs across 3 windows). 670mb in FF, 340mb on Chrome. Firefox has YouTube Center, Ublock Origin + Ghostery, Chrome just has YouTube Center.

I guess for my use case, I just don't care about that much memory usage. Firefox has definitely improved over 3-4 years ago, where it would have been 2GB for the same level of usage.


I switched to Chrome a few years back b/c it was the only browser that gave me a good experience across platforms (Linux, Mac, Windows). At the time I liked it better than Firefox for that, but Servo looks like it could bring me back. Safari was never an option on Linux.

What I did notice after the last Safari release, was that because it's faster/smaller memory footprint, it also used less battery.


I have yet to come across a modern web browser on Windows that's unusable - although I've "replaced" Edge for IE11 for several customers because of missing features. I suppose that would count as unusable, but in those cases it's been for specific reasons.


The PaleMoon fork of Firefox is still quite useable.


Absolutely not, it has really fallen behind on features and the devs aren't competent nor numerous enough to keep the pace. They may get back on track with the new fork they're planning, but I'm betting they're going to fall behind again after that.

Maintaining an entire modern browser on your own is no joke.


Mobile Safari doesn't go anywhere near the top of my rankings until they can make it simple to disable the silly rubber-band scrolling for mobile apps. Every CSS solution I've tried only works 95% of the time, never 100%.

https://www.youtube.com/watch?v=xkwZbi3AslY

The rubber band stuff is downright annoying, but what's shocking is 0:14 where AFTER the top part of the app got rubber-banded once, the bottom part of the page would refuse to scroll further down for another several seconds until 0:19 where it resumes scrolling further down. Then after proper scrolling of the bottom part resumes, the navigation bar just disappears into nowhere (!?).

This is why HTML5 just isn't there yet. Mobile Chrome on the other hand renders this page perfectly, 100% of the time, without any CSS hacks.


I thought the video was of removing rubber failing.

I would hate your Web app if you removed rubber. I don't mind at all if your top bar follows the rubber, which happens on plenty of websites.


I would hope that a web app is compared to a mobile native app experience, not a website... native app top bars never have the rubber effect. It's the stuff in the bottom that should have the rubber effect, but not buggy as in 0:14 - 0:18.


In what case do you need it to be off?


Look closely at 0:14 - 0:18 where there are a couple of major UI hiccups in the midst of the rubber band scrolling, especially 0:16 - 0:17 where it refuses to scroll beyond a certain part of the page despite there being content further down. This resolves itself automatically at 0:19 but then the navigation bar disappears.

Also, from a UI design standpoint, to maintain consistency with everything else in the ecosystem, the navigation bar (i.e. the "entire page") should NEVER scroll or have rubber-band effects for a web app. Only scrollable divs should scroll. Yes, you can disable this in Safari with CSS, but it will still hiccup ~5% of the time.

HTML5 is supposed to be a convenient way to develop Android/iOS in one go. But it's these things that make people say "to hell with it, let's just write native iOS/Android versions" because the native UI widgets don't have these hiccups.


I don't know about that Safari ranking. I get a super-fun rainbow wheel at least 2 or 3 times a day on Safari with only 3 or 4 tabs, and I rarely get that through chrome with upwards of 30.

Before you give a score to every browser, why don't you back it up with something objective?


I noticed the adblock extension on safari makes it freeze up for a second when I open a new tab. apart from that, soooooo much snappier than chrome. (desktop, not mobile ofc)


extensions in general are a huge issue for all browsers, it's easy to install a bunch of them and not notice your performances going down until a few months later, at which point you blame the browser (even for developers, evaluating the performance impact of extensions can be difficult).

That's especially true for content-alteration extensions like ad-blockers as it's very easy to implement them in ways which work well enough with few rules but degrade superlinearly at scale. That's a big part of the issues Firefox has/had (not to mention the "depth" available to XUL extensions), but it's not like other browsers are immune.


One shouldn't let an extension with access to all the pages run continuously. I wait for the day a famous extension like Awesome Screenshot will be pirated and publish everyone's bank account credentials...

Of course, between "should" and the reality, there's room for tolerance.


I had that same problem with Adblock.

Much happier now on Safari and uBlock.


Link for ublock on safari? I looked but my google-fu is lacking I guess


It's not, you're right. I use Ghostery on my Mac and 1Blocker on my iPhone.


Which sites are you loading in the tabs?

These days Safari actually shows that rainbow spinner when the background process that runs the tab is hanging, even though Safari.app itself is perfectly responsive. This usually is indicative of a problem with a site loaded in one of the tabs in the window (I believe Safari does process separation per-window), as opposed to a problem with Safari or WebKit itself.


He specifically talks about MOBILE versions of these.


No. He mentioned desktop and mobile.


Read the article more carefully. He mentions the desktop BRIEFLY, but it's not the topic of the article, which is 99% mobile Chrome.


Messing for the last several months also with mobile browsers on my Android devices. Especially because mobile scare-/malware was bothering me too much in recent times ( harmless example you could open on Android: https://shkspr.mobi/vibratescam/ ). Compared them all (Chrome, Chrome beta, Firefox, Firefox beta, Opera, Brave) and realized that Firefox+uBlock, especially since Firefox 45, is reasonable fast and good to use as daily driver on Android. It blocks all the malware and web videos work even better in Firefox than in mobile Chrome.


I'd love to know what I'm doing wrong. FF45 on a fast Android phone for me is almost unbearably laggy both on loading and scrolling pages. I mean to the point where I can't really understand how anybody is using it. I've tried this with and without a couple of ad blockers and ghostery


µblock on android is the number one reason for firefox on android. For me A reason good enough to live with lags and stuttering.


I'm running Firefox beta (now 46) mostly... they are constantly improving it and it's more bleeding edge but still stable enough, maybe give it a try.


Been using Firefox on Android since they switched over from their initial UI to the natively built one. Used it on a HTC Desire HD, One M7, Nexus 7 and Nexus 5X. Only site I really have issues on are the Wikia family of sites. Just checked, they're better but still not a pleasant experience on Chrome either.


I've got a wimpy first gen moto g and don't have any issues with firefox


weird. I'm running ff + ublock on a 2.5 year old nexus 5 and it works fine.


How much of the poor performance discussed in this article is due to Chrome itself, and how much is due to the fact that Android devices tend to have worse single-core performance than iOS devices?

Is there a browser for Android based on a recent version of WebKit (not Blink)? If so, that would help answer the question.


Didn't the author address this by talking about testing on both burner and top-line android models vs getting the web app working decently on an iPhone 4S?


Not really. Top of the line Android phones can actually be worse for this problem than cheaper ("burner") ones.

Top-of-the-line Android phones tend to follow the pattern of having a CPU with many cores each of which is slower than the CPU would be if they used a single core solution. This is excellent for native apps that properly use multithreading, but dreadful for web apps since JavaScript as it is commonly written (ignoring the various *Worker extensions to the language attempted over the years) is essentially single-threaded, so the majority of the app code is running on one slow core while the rest sit idle (or run background services that have nothing to do with the foreground app).


It would be interesting to know how Mobile Firefox compares to Mobile Chrome on Android.

Maybe someone here can give us some insight into that.


I ran the Ember Complex List test on Chrome and Firefox on my Nexus 6P. Chrome averaged 240ms while Firefox scored 260ms. Both of these results are slower than the iPhone 5S score of 175ms.


I switched to Firefox on Android for performance reasons a long time ago, but I don't know how well that holds true today.


The single-core performance of the most common Android SoCs are from 50-70% the single-core performance of the iPhone 6s. They're going to be slower, but for most web loads that should be "imperceptibly slower" because it might be 3ms instead of 2ms.

Chrome on Android absolutely seems to be a bit like Superman -- it is strong and mighty much of the time, but when it faces certain otherwise benign kryptonite scenarios, performances fall through the floor, to the point of comedy.


"Chrome is 3x to 300x slower than Safari."

This would not surprise me.

I have a 2009 MBP with 4G RAM. Performance issues become very obvious with low spec hardware. Safari is incredibly snappy, complex pages like amazon.com scroll smoothly with no effort. This old machine actually feels new in that scenario.

The only concern I have about Safari is that Apple's security patches seem to come at a slow pace.


I'm suprised by all this safari love in 2016. Working in front end web development, Safari has become the IE of today. Compatability and support for otherwise common web technologies is just plain broken.


If by "common web technologies" you mean mostly non-standard or experimental technologies then yes.

Lets not forget that it was Google that forked WebKit resulting in duplicated effort to implement various features. Google also loves to ship stuff that isn't actually standardized yet (which is fine) but today's web developers go whine about Safari not supporting it yet. No shit Sherlock, it's your own myopic view.

Only testing in Chrome is as bad as only testing in IE 6 in 2006.


Most of the "experimental" features we whine about are supported by all vendors, save for Apple (Firefox, Chrome, Opera and freaking IE). It's a definite pattern: Safari is last to implement features, if at all.


Safari is slow to adopt new features, yes, but the features it has work properly and everything runs snappily.


> the features it has work properly

You may want to avoid that blanket statements around developers who've worked with indexeddb, safari's implementation is famously awful, so much so that caniuse makes special note of it.


Or even I have a CSS issue to look into in Safari soon where a combination of tables, max-width, width and overflow properties is behaving oddly on Safari only (even IE gets it right). This is CSS2 stuff..


Safari is slow to adopt new features, yes, but the features it has work properly and everything runs snappily.

Assuming we’re still talking about mobile Safari on iOS here, unfortunately that isn’t true in all areas. For example, the way iOS Safari handles HTML5 media elements is essentially to play them through a plug-in. We had to implement a whole new authentication mechanism for a site I work on that serves video content to logged in users, because it wasn’t actually Safari requesting the video resource so we weren’t seeing the user’s ID cookie. There are numerous other problems with how iOS Safari handles video content that make it difficult or impossible to implement other functionality or UI behaviour that would make our site better for our users.


Since nobody in the comments seems to have read TFA thoroughly:

it's specifically about the mobile Chrome and Safari.


It specifically ranks chrome and chrome mobile seperately (both poorly), then talks about mobile development later in the article.


Well, were "later" is 80% of the article...


Including comparing mobile Safari to desktop Chrome, so I think its all part of one argument.


Amen. Probably just spending too much time on HN lately but I'm getting increasingly frustrated at the number of comments which are orthogonal or oblivious to the OP.

Yesterday's worst offender I think was PriceZombie where fully half the commenters didn't realize it was the Affiliate program not the Pricing API they got kicked off and so many "they could just scrape the data", "but no what about CFAA" back and forth.... And you read it and just shake your head :-(


The main issue is that it shouldn't have ranked the desktop platforms. It sounds like those are more for him, because the rankings were confusing to me.


Author:

In some ways, yes. But the ranking is really where I slide various browsers in terms of ease of getting an app working well, and I think it's important to note that I generally find desktop Chrome more troublesome than Mobile Safari.

The article is primarily about mobile Chrome vs mobile Safari, but the issue is only partially Android's fault. Chrome performs just as bad in JS and render benchmarks on desktop as it does on mobile, and it's memory leaks are present in both; but this matters less on desktop because powerful machines mask this for us.


My Nexus chrome browser is magnitudes faster than a fresh Firefox install. I don't know what this person is talking about.


You need to compare to Safari and iOS devices to see the real difference.


You are right. I ran a futuremark test on chrome, ff and safari (iphone 6) and chrome was the slowest BUT in terms of actual website loading, chrome was faster than FF. Although safari beat them all significantly!

Future mark scores: Chrome:618 FF: 728 Safari: 2348

Actual website loading speeds were near instant on safari, followed by laggy chrome and incredibly slow FF.


While your test is exactly what is expected from iPhones, it says nothing about their performance on other devices.

Chrome and Firefox on the iPhone are not the same Chrome and Firefox found on desktop and android devices. Apple restricts apps that provide web browsing to use old and outdated versions of the native IOS rendering engine and JavaScript engine.

http://www.howtogeek.com/184283/why-third-party-browsers-wil...


Not anymore. Chrome switched to the native safari/webview recently, so it is much faster.


What exact futuremark test where you running? The only one I found was peacekeeper which is "no longer supported".


Will do.


I read all these instructions he gives on making an "efficient" app and just wonder if everyone wouldn't be better off with less JavaScript. I have never used a JavaScript app I would call "better" than a static site. 2-4mb of Js? You've gotta be kidding me. There's no any that's a better experience than 10-20 50kb HTML requests for anyone. You're just working way to hard. Very very few apps benefit from that kind of interactivity. The form driven majority certainly do not.


fefe[0] commented on his rant very precise "Folks, if you continue to let your pile of shit grow, then you may not point your fingers at google if the shit hits the fan. It's your pile of shit, not chromes"[analogous translation]

[0]https://blog.fefe.de/?ts=a80874c9


Would you see Discuss or Gmail or google docs implemented as a static site ? As I understand it, we are talking about sites that behave more like an actual application, and not a wikipedia like "let's read one page after the other" type of experience.


That's a surprising comment to read as someone's who's immersed in making web apps in JavaScript that work great offline and synchronize data when possible. For me, sites that require network roundtrips for every state change are often near unusable. Instead, with JavaScript and AppCache/ServiceWorker, I can make web-delivered programs with instant response times, intelligent auto-updating, and so on. 2 MB of application code isn't too bad when you can download it once on WiFi and then never need to touch the network again.


I've shipped a Cordova app for iOS that utilized heavy touch interaction. We found that GPU-rendered elements were best kept at the top of the DOM and had to do some serious restructuring of the app to get everything to perform "well enough" on the iPhone 4.

Weird thing is, when we went native, the users didn't seem to care too much. Comparison tests repeatedly left us with users that didn't notice/care about a lagging touch interaction or a screen that took too long to load. This was the case for both in-house tests and overall app usage metrics.

In our case (dating app), I think we noticed something akin to the weather app phenomenon: if an app tells you it's going to rain, and it doesn't, you feel lucky. If the app tells you it's not going to rain, and it does, you blame the app.

Most people either don't notice, assume they need to upgrade their device, or believe there's some technical problem that's out of their control (which it is) and that their experience only depends on what the app does, not how fast it does it. If the app does what it says it will do, albeit slowly, they'll still use it. This isn't to say that buggy apps won't lose users, but rather, slow apps aren't as bad as we might think.

(Note: on the flip side, I've made performance improvements on large scale consumer web sites that saw noticeable increases in user activity/revenue)


Interesting though it doesn't preclude it from being a UX issue. For instancing asking people who are already active users rarely matters (unless the app is just that bad). Typically making a change like that you measure the retention rate of new users and if it went up or down. How was the retention rate of new users after the change?


I'm curious to see some actual benchmarks... In my experience, Chrome still has the fastest JavaScript. It still renders WebGL pages the best (although Emscripten allows Firefox some impressive feats).

Does Safari have some special extensions for the shitty 'native look' apps I encounter at Apple.com? Did their JavaScript engine become 100x faster in the year or so since I've used it? Is the author comparing an iPhone 6S plus to a Galaxy S3?

This article basically raises more questions than answers since there's literally no objective analysis of any sort...

There's not even an example of a page that runs on mobile Safari well but bad on Chrome, to allow me to see for myself. Just lots of handwaving.

Edit - No responses?

Anyhow, I eventually figured I'd try hammerjs' examples, since that's one of OP's projects. On a Galaxy Note 3, Chrome is pretty shit, Firefox works well. On an iPhone 5S, Safari is shit.


bizarre that a comment asking for actual benchmarks is downvoted in the face of a hundred upvoted handwavey comments about people's current favorite browser.


Not that bizarre, lots of threads about the superiority of Apple technology wind up like this.

I just found it odd and infuriating that the blog post said Safari is 3-300 times faster, but then literally offered no justification whatsoever. Also didn't even show a link to anything that can be tested, literally nothing objective.


I remember saying in 2008/2009 that IE and Opera (because it used the same or similar JS engine) had some of the best reasons for failing with regard to badly coded JavaScript. I would always just open up IE to check to see if my code was "valid" even when I wasn't targeting IE specifically. Just swallowing errors is not good practice, but I can't say that I noticed this in Chrome, tbh. I can say that Chrome's dev console is better than Safari's/Webkit's. Chrome isn't my default browser, I really only open it for flash content and to debug a site's JS when Safari isn't giving me the info that I need. I agree with the overall tone of the article -- (mobile) Safari is a decent browser, and in a lot of ways, a better experience for both the user and developer than Chrome. In some ways it isn't.


Chrome has become awfully slow in the last year for me, culminating in the last few updates where the entire UI will randomly freeze for seconds at a time and bring up the "not responding" dialog on Windows. Sadly the alternatives aren't really any better (no Edge on Win 7).


I've not had this experience on Win 7 or Win 10. There's also Firefox if you refuse to upgrade or fix your box.


I think the biggest issue is the high variance in performance between browsers overall, coupled with the declarative nature of UI rendering using the DOM.

I have a UI that runs very smoothly in Chrome and Safari (desktop, not mobile). As of Firefox 44, it's unrunnable in Firefox. Why? Don't know. Profiling says we're losing a bunch of time in "layout" but why we're losing a bunch of time in layout, I can't tell. Chrome and Safari just... Don't. And there's so much decoupling between the rendering agents on all three browsers and the language we're using to declare what should be rendered that my best tool after profiling is guess-and-check.


If you have a public URL to the page involved, I'd be happy to take a look and see if I can figure out what's going on there.

In general, in situations like this when there is a public link available, please do file bugs on Firefox!


Can you link it?


A fun read, but there's a lot of claims and opinions without additional information or citation. Off the bat there's an arbitrary grades list. Why is Opera a B and desktop Chrome a B-? Author claims mobile Chrome required a bunch of optimizations. I believe him, but would love to read more on what type of work had to be done.

> The end result of this is that we've been brainwashed into believing Chrome is the best browser, when the reality is that across all metrics, Chrome is 3x to 300x slower than Safari.

In what way? The Javascript engine? Repainting?


The problem is the basic assumption that there should be a "framework" and your app is "on" it. I respect the shit out of Tom Dale, but the "megabytes aren't that big in 2016" attitude isn't going to cut it in the long term.

Loading a web page needs to happen in a few milliseconds. Accepting anything less than that is just Stockholm Syndrome. Downloading a bunch of code that might run is antithetical to loading a web page in a few milliseconds. The path forward is treating the browser like hardware and actually only sending the hardware calls that are strictly necessary to flip the pixels you need to flip, and only fill the registers that are necessary to flip those pixels.

People like Jonathan Blow have written the web off completely because they've gotten the idea that browser makes that impossible. But it's not the browser that makes it so hard to write performant web experiences, it's the frameworks.

I'm not saying we don't need abstractions, and I'm not saying abstractions can't introduce waste. I'm saying web programmers are treating web pages like application bundles and that's not gonna work. Because there's network calls everywhere and anywhere and because the target hardware (the browser) is only fast at a somewhat quirky set of things. Lead designers and lead software architects need to get way more zen with the reality of that.


>> I'm saying web programmers are treating web pages like application bundles and that's not gonna work.

Not gonna work -- just like heavier-than-air flying machines, and horseless carriages, will never work :)


I have been a little mad at Safari while building a website recently (https://windmill.thefifthmatt.com), and the issues I ran into seemed like Safari's "fault"—it does not implement several web features such as requestPointerLock which Chrome and Firefox implement, so I had to jerry-rig worse experiences for Safari users. I had to neuter a Content-Security-Policy header because Safari refused to render a font no matter what font-src was... still have not figured that one out. Mobile browsers are similar here, although I have not tried out Safari remote debugging (only Chrome remote debugging).

Obviously both browsers are developed by highly talented software engineers (disclaimer: biased Google employee here, not in Chrome, speaking for self). But I think type of website and upfront ecosystem investment have some effect on where the most development pain comes from. My naive guess is that rich content consumption sites are easier to do in Safari, more app-like long-tail-of-features stuff easier in Chrome. If this is true, why? My guess is that Apple has its own idea of which general-purpose platform it'd prefer to most invest in.


>Keeping the JS payload below 750kb seems to be the key point for Android, but keeping below 500kb is more ideal.

This might explain why many asm.js demos tend to crash Chrome for Android.


To be fair, many asm.js demos freeze my desktop Firefox for a minute or so until it downloads/compiles everything.


Where does Firefox Mobile (Android) stand? I use that as my default browser on Android, and it works for me. I haven't used Chrome since long, especially because of privacy issues, so I can't compare them.


Does anyone have a reliable place for browser javascript benchmarks? Some searching only brought up a range of promotional type stuff from browser makers and old articles. Thanks!


https://arewefastyet.com/#machine=29 has most popular benchmarks across most JavaScript eninges on multiple platforms

Edit: actually this view is probably better for people who don't care about JavaScript engine internals: https://arewefastyet.com/#machine=31


The focus on JS benchmarks is becoming ludicrous. By far the biggest performance issue is DOM/CSS layout. JS is so fast on all browsers that the performance differences don't matter at all anymore, except for initial load (and if you're loading that much code on initial page load, you should re-evaluate your architecture).


I agree 100%, but they were asking for a place with JavaScript benchmarks, so I gave my favorite.


Modern frameworks have worked hard to mitigate DOM bottlenecks, thus pure JS bottlenecks are now a thing. Especially data-rich applications. Reflow and paint performance is still an issue but the focus on JS is worthwhile.


Have you measured this? Do you actually build or use specific apps where the dominant factor is JS execution time and not layout or network time?


Yes. String-processing tweets (linkify and emoji-insert) and crunching numbers for time series line charts were two areas where we saw some lag. It was React so these bottlenecks were happening during virtual DOM rendering.

And realizing GP was talking about client-side, but also don't forget server-side, where DOM doesn't exist and the hyper-focus on pure-JS perf is much appreciated.


What's Chrome turbofan?


It's Chrome's (or more accurately v8's) new-ish optimizing compiler. For some of the tests they like to disable the non-optimizing compiler to see how just the optimizing one runs alone with no fallback.


Dead it looks like.


I have no idea what this guy is on about. Chrome is lightning fast for me. Firefox is really fast..... With one tab. With any serious usage ff gets chunky


What is this group the author mentions?

> Chrome has had such a problem with performance they formed a special group just to work the problem, but in nearly two years time that group has yet to produce anything tangible.


My experience with every new release of safari on IOS would break something that worked before. Last one screwed with SVG sprites This one already had issues https://news.ycombinator.com/item?id=11366468


Just FYI vivaldi beta 3 is stable enough for personal browsing and works well with µBlock origin (AM) + flash control.


From personal experience, Vivaldi is a lot more bug-ridden than other common browsers. It's rather new so it's understandable, but I don't really see the place to recommend it currently, especially in a discussion like this.


Tried out Beta 3?


If you're having trouble figuring out the point of this article it's because it's just trolling. This guy ran into a few problems specific to mobile Chrome, and got so angry he wrote this unedited sting piece.

> Chrome is the new IE

Browser wars are troll wars by children. That's all. Move along.


Performance surely depends on the application. In my personal experience, a rather complex JS application I'm working on consistently (tested on Windows, Linux and Android) runs significantly smoother and faster in Chrome than in Firefox, and somewhat better than in Safari.


Mobile Chrome performs much better than mobile Safari on my iPhone 5s. I'm not sure why, because as far as I know, they use the same rendering engine. But, for the javascript on some sites, Safari will hit a brick wall and Chrome will keep sailing smoothly.


says that "Chrome is the new IE" as you have to build your apps specifically to run well on it, and that different browsers have different strengths.

Anyway, this is probably good (for users), and definitely better than the pre-Mozilla IE monoculture.


The author says he agrees with "The web is the only truly open platform we’ve got. It’s the closest thing we have to a level playing field."

While there are places like e-commerce catalogs where "hybrid" apps, which is to say "apps where WebView is important," are the best implementation choice, it's not everyplace. If you treat the browser as a means for app portability, maybe you ought to look at Xamarin instead, or as an addition to your toolkit if a portable code-base is required for many of your apps.

It isn't Google's job to make your cross-platform implementation strategy easy. Platforms have unique capabilities and when you put cross-platform implementation too high in your priorities you'll miss having the best possible app on each platform. In some cases that doesn't matter, but when it does, change your implementation approach and make native apps.


I'm hope he understands that mobile chrome on iOS is completely different than Chrome for Android. In fact I'm curious to why he doesn't rate Mobile Firefox for iOS.


Oops. Somebody forgot to set the background colour on that page. As I've changed the default to light grey (white's too bright), that makes it rather less readable...


He hope the op knows that mobile Chrome on iPhone is not "chrome" at all. It's a layer on top of the outdated webview of iPhone.... :)


Don't know about this features thing. I use Firefox everywhere because it lets me use plugins on android. How does anyone surf without plugins? How are you blocking ads, whitelisting sites for JavaScript, blocking trackers etc? Bizarrely this basic stuff still isn't built into the browser (anyone know why?) and using chrome just compounds the problem.

You used to have to use chrome because the other browsers were just too slow and naff but they've all caught up now.


> How are you blocking ads, whitelisting sites for JavaScript, blocking trackers etc? Bizarrely this basic stuff still isn't built into the browser (anyone know why?)

Try enabling DoNotTrack in Chrome. It will give you a long and confusing warning, that will just scare a non-technical user into thinking that it's a bad idea to enable.

I think the conflict of interest is powerful here...


I am trapped in extension jail with chrome.

Past some months, the problems I faced with chrome(or extensions I use) made me look at alternates. I went to both Edge and safari, both(without extension) look better than Chrome. At this moment I can't say whats the problem.

I still work with chrome with almost all the extensions disabled and enabling them as per need.


I refuse to use Safari on iOS until they stop hiding the full URL on every web site. Shouldn't take too long, someone will soon figure out how to abuse it for successful phishing attacks.


Is there an example of such an attack?

I thought the point of this was to make phishing less likely by making you focus on the domain name you're on.


How can you abuse that for phishing attacks? The whole reason for it to only show the domain is specifically to avoid common phishing attacks.


This article appears to be about the speed of ember in Chrome, which is a real complaint, but everything else is just a sideshow.

Adding new features while being slow on others does not make a browser "the new IE". In general, "new IE" arguments are easy to throw out but don't bring much insight, but this instance completely misses the mark in understanding both what was bad about IE around 2000 and what was bad about IE in the decade that followed.

> And herein is the problem; Google implements features that (usually) work at a high pace, but they very rarely make them work efficiently...they introduced us to shiny few features like CSS will-change, requestIdleCallback, and a fairly solid implementation of ServiceWorker in the hope that new tools would magically make their performance gap go away. It doesn't matter to them that even these shiny new tools are 3x+ slower than their peer's counterparts

While new features are apparently rarely made to work efficiently, of the three actual examples mentioned, one is "fairly solid", one (requestIdleCallback) isn't in any other browser, and the last (will-change) is just a modifier of other properties so web developers don't all have to use hacks (translateZ) forced on them years ago by WebKit to get decent GPU support. And only with one of them (the "fairly solid" ServiceWorker) would it make sense to call slower or faster compared to other implementations...but of course there is no ServiceWorker in Safari yet to compare to. I haven't heard (nor can I find) any complaints about ServiceWorker performance in Chrome vs Firefox, but maybe they're out there and really mad about that 3x+ slower implementation in Chrome, for some vague definition of slower.

I do love:

> There's a lot of these errors that Chrome silently ignores or just "deals with", and it leads to code debt that we "think" is due to other browsers being shitty, but honestly it's just what I've come to call "Scumbag Chrome".

and then proceeding to offhandedly mentioning having to work around old Safari flexbox issues, old Safari WebSQL issues...

But those aren't a big deal to the author, because he knows how to quickly work around them. And that's what most of this article is talking about: bugs the author is familiar with are easy to work around, bugs he isn't familiar with aren't. Honestly 90% of this just sounds like he's used to his iphone and Safari devtools and is upset he has to build for other browsers on other machines.

If you think that sounds exactly like someone with a site that only works in Chrome because they're used to the Chrome devtools and they didn't check it in another browser until right before launch, you'd be right.


I've always held that power (features) trumps speed unless we're talking about OLTP.

Machines will get faster quickly. Providing a strong platform is more important than being the fastest, today.

YMMV.


>Machines will get faster quickly.

Perhaps you missed the memo about Moore's Law officially dying, and the fact that speed (as opposed to transistor) wise, we haven't seen any real increase in the past 5+ years and we are not expecting anything much either...

http://arstechnica.com/information-technology/2016/02/moores...

https://www.siliconrepublic.com/machines/2016/02/15/moores-l...

http://fossbytes.com/intel-moore-law-dead-chip-tick-tock/


Yeah, as an industry I think we're in denial about this. Since the dawn of time, we could keep doing whatever we were doing and things would just magically get faster. That era is over. But we're still mostly using languages and techniques that aren't well suited for where the future's going.


Still? I'd thought we've already used the languages (and thus tools and techniques) designed to squeeze all the available performance from the hardware - it's called assembler ;) My grandfather, who was a programmer and to his last days used to write in asm was mocking me every time when I tried to convince him to anything higher level than asm, be it Python or C. Perhaps he was right and we'll be going back to such tools?


No, it's a totally different landscape.

First, CPUs are much more complex, with branch prediction, parallel execution, etc, so manually rolling assembler is not really feasible.

Second, programs are much larger and demanding nowadays (e.g. neither graphics, nor sound, nor networking and numerous other modern day services were as advanced, prevalent, or even existing, in the good times of assembler coded apps).

Third, today it's all about multicore performance. Not much use to squeeze everything from a single core, when you have other 3 or 7 or 15 sitting idle...


In the past 5 or so years, "full" computers (desktops and laptops) haven't gotten any faster in ways current browsers can make use of. Mobile devices have, but much of the "faster" is gated behind power issues, and having a web application killing your battery life to a few hours doesn't a great experience make.

[0] hence efforts like Servo, to explore architectural rebuilding such that browsers can actually use multithreading and GPGPU support for their normal workload


I've been waiting 30+ years for computers to get subjectively faster. They don't. Ever.

Every new machine or processor is dragged down by the increased bloat and inefficient coding of the new OS to go with it. It'll be quicker starting up, only until you've installed a few basics, then it'll take as long as it always did.

They feel too slow always. Always have. Movies show things happening instantly - I now believe that will never happen. The Matrix should have included 1m "Loading" dialogues. :)

I get annoyed waiting for websites to load on multi Mbps broadband just like I did in the 90s with a dialup connection.

Sure things are doing more, but I'd like the cycle to include making that "instant" future please.


Since everyone is entitled to have an opinion. In my opinion Chrome is the best web browser available today.


Why is that? The author explained his metrics.

I've barely used Chrome myself, I've been using Safari since before Chrome was released (IIRC). Ignoring style issues (I'm just used to Safari) it always amazes me just how much CPU Chrome seems to burn doing nothing. It's a HUGE drain on laptop battery life.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: