23 ms·
The Chrome Distortion: how Chrome negatively alters our expectations
- f_allwein 11y agosays 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.
- FunnyLookinHat 11y agoI 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?
- sydneysider 11y agoI 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)
- masklinn 11y agoextensions 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.
- tajen 11y agoOne 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.
- MBCook 11y agoI had that same problem with Adblock. Much happier now on Safari and uBlock.
- sydneysider 11y agoLink for ublock on safari? I looked but my google-fu is lacking I guess
- MBCook 11y agoIt's not, you're right. I use Ghostery on my Mac and 1Blocker on my iPhone.
- coldtea 11y agoHe specifically talks about MOBILE versions of these.
- deleted 11y ago[deleted]
- bluejekyll 11y agoNo. He mentioned desktop and mobile.
- coldtea 11y agoRead the article more carefully. He mentions the desktop BRIEFLY, but it's not the topic of the article, which is 99% mobile Chrome.
- eridius 11y agoWhich 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.
- matt2000 11y agoDoes 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!
- Klathmon 11y agohttps://arewefastyet.com/#machine=29 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 https://arewefastyet.com/#machine=31
- swampthinker 11y agoWhat's Chrome turbofan?
- Klathmon 11y agoIt'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.
- bluejekyll 11y agoDead it looks like.
- deleted 11y ago[deleted]
- Joeri 11y agoThe 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).
- riprowan 11y agoI'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.
- coldtea 11y ago>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-law-really-is-dead-this-time/ http://arstechnica.com/information-technology/2016/02/moores... https://www.siliconrepublic.com/machines/2016/02/15/moores-law-is-dead https://www.siliconrepublic.com/machines/2016/02/15/moores-l... http://fossbytes.com/intel-moore-law-dead-chip-tick-tock/ http://fossbytes.com/intel-moore-law-dead-chip-tick-tock/
- wpietri 11y agoYeah, 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.
- tachion 11y agoStill? 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?
- coldtea 11y agoNo, 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...
- dave2000 11y agoDon'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.
- 21 11y ago> 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...
- dsugarman 11y agoI 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.
- thenomad 11y agoOddly, 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.
- zdkl 11y agoSame experience. I've switched to Vivaldi, it feels like the Firefox of old. It's chromium under the hood though
- j_koreth 11y agoOpera 12 is the only viable choice
- kwhitefoot 11y agoI 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.
- Al-Khwarizmi 11y agoI 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.
- Pxtl 11y agoI'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.
- coldtea 11y agoSince nobody in the comments seems to have read TFA thoroughly: it's specifically about the mobile Chrome and Safari.
- dsugarman 11y agoIt specifically ranks chrome and chrome mobile seperately (both poorly), then talks about mobile development later in the article.
- coldtea 11y agoWell, were "later" is 80% of the article...
- true_religion 11y agoIncluding comparing mobile Safari to desktop Chrome, so I think its all part of one argument.
- derimagia 11y agoThe 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.
- runspired 11y agoAuthor: 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.
- zaroth 11y agoAmen. 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 :-(
- __Joker 11y agoI 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.
- Zigurd 11y agoThe 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.
- andrewvc 11y agoI 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
- jorgecastillo 11y agoSince everyone is entitled to have an opinion. In my opinion Chrome is the best web browser available today.
- MBCook 11y agoWhy 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.
- deleted 11y ago[deleted]
- abritishguy 11y agoI've always liked this article by one of Stripe's interface designers: https://medium.com/@bdc/chrome-is-the-new-ie-1a21c1efc133#.3uae32q82 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.
- wahsd 11y agoPretty 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.
- techdragon 11y agoI'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.
- LoSboccacc 11y agoWat. 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.
- jacobolus 11y agoSafari 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.
- r1ch 11y agoChrome 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).
- m1sta_ 11y agoI've not had this experience on Win 7 or Win 10. There's also Firefox if you refuse to upgrade or fix your box.
- evook 11y agoJust FYI vivaldi beta 3 is stable enough for personal browsing and works well with µBlock origin (AM) + flash control.
- bobajeff 11y ago>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.
- 21 11y agoTo be fair, many asm.js demos freeze my desktop Firefox for a minute or so until it downloads/compiles everything.
- sweetbabyjesus 11y agoMy Nexus chrome browser is magnitudes faster than a fresh Firefox install. I don't know what this person is talking about.
- therealmarv 11y agoYou need to compare to Safari and iOS devices to see the real difference.
- sweetbabyjesus 11y agoWill do.
- sweetbabyjesus 11y agoYou 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.
- bendbro 11y agoWhile 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-will-always-be-inferior-to-safari-on-iphone-and-ipad/ http://www.howtogeek.com/184283/why-third-party-browsers-wil...
- ec109685 11y agoNot anymore. Chrome switched to the native safari/webview recently, so it is much faster.
- 11y ago
- therealmarv 11y agoMessing 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/ 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.
- takno 11y agoI'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
- therealmarv 11y agoI'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.
- evook 11y agoµblock on android is the number one reason for firefox on android. For me A reason good enough to live with lags and stuttering.
- Macha 11y agoBeen 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.
- x0x0 11y agoweird. I'm running ff + ublock on a 2.5 year old nexus 5 and it works fine.
- bdickason 11y agoI 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
- okket 11y agoSuch 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).
- SomeCallMeTim 11y ago>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.
- anon1385 11y ago>You mean "on iOS", not on mobile devices in general. Also on FirefoxOS and ChromeOS where third party browsers aren't possible at all.
- athenot 11y ago> 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.
- TazeTSchnitzel 11y agoIt'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.
- kbrosnan 11y agoWhen people come across such things please report them to https://webcompat.com/ 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.
- jimmaswell 11y agoThere 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.
- smeehee 11y agoSometimes, 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.
- bzbarsky 11y agoIt'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...
- mwcampbell 11y agoHow 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.
- 21 11y agoIt would be interesting to know how Mobile Firefox compares to Mobile Chrome on Android. Maybe someone here can give us some insight into that.
- ocdtrekkie 11y agoI switched to Firefox on Android for performance reasons a long time ago, but I don't know how well that holds true today.
- dstaley 11y agoI 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.
- r00fus 11y agoDidn'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?
- georgemcbay 11y agoNot 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).
- clumsysmurf 11y ago"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.
- jnem 11y agoI'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.
- TazeTSchnitzel 11y agoSafari is slow to adopt new features, yes, but the features it has work properly and everything runs snappily.
- masklinn 11y ago> 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.
- Macha 11y agoOr 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..
- Chris_Newton 11y agoSafari 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.
- donatj 11y agoI 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.
- evook 11y agofefe[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 https://blog.fefe.de/?ts=a80874c9
- mbrock 11y agoThat'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.
- hrktb 11y agoWould 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.
- Mikeb85 11y agoI'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.
- magicalist 11y agobizarre that a comment asking for actual benchmarks is downvoted in the face of a hundred upvoted handwavey comments about people's current favorite browser.
- Mikeb85 11y agoNot 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.
- rjeli 11y agoMobile 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.
- coverband 11y agoI 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.
- seanwilson 11y agoIs 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.
- eridius 11y agoHow can you abuse that for phishing attacks? The whole reason for it to only show the domain is specifically to avoid common phishing attacks.
- dheera 11y agoMobile 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 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.
- wodenokoto 11y agoIn what case do you need it to be off?
- dheera 11y agoLook 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.
- wodenokoto 11y agoI 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.
- ksec 11y agoAnd yet people here https://twitter.com/nolanlawson/status/709456732381175808 https://twitter.com/nolanlawson/status/709456732381175808 and here https://www.youtube.com/watch?v=HuHCHHuWL1s&feature=youtu.be&list=PL9ioqAuyl6UKZdsQFXJJWrwgZAgeAaFWa&t=2877 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.
- kainolophobia 11y agoI'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)
- BinaryIdiot 11y agoInteresting 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?
- fixermark 11y agoI 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.
- jimmaswell 11y agoCan you link it?
- bzbarsky 11y agoIf 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!
- stevebmark 11y agoIf 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.
- robdodson 11y agoI 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/ http://mathieuancelin.github.io/js-repaint-perfs/ember/ And the performance of other frameworks/libraries: Angular: http://mathieuancelin.github.io/js-repaint-perfs/angular/ http://mathieuancelin.github.io/js-repaint-perfs/angular/ Polymer: http://mathieuancelin.github.io/js-repaint-perfs/polymer/ http://mathieuancelin.github.io/js-repaint-perfs/polymer/ React (optimized impl): http://mathieuancelin.github.io/js-repaint-perfs/react/opt.html 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 :)
- mwcampbell 11y agoYou 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-android-in-2015-is-poor/33889 https://meta.discourse.org/t/the-state-of-javascript-on-andr...
- Uehreka 11y agoI 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).
- emehrkay 11y agoI 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.
- gracenotes 11y agoI have been a little mad at Safari while building a website recently (https://windmill.thefifthmatt.com 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.
- magicalist 11y agoThis 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.
- deleted 11y ago[deleted]
- erikpukinskis 11y agoThe 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.
- carterehsmith 11y ago>> 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 :)
- deleted 11y ago[deleted]
- smeehee 11y agoOops. 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...
- bunkerbewohner 11y agoPerformance 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.
- ctvo 11y agoA 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?
- hollander 11y agoWhere 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.
- hhsnopek 11y agoI'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.
- vladgur 11y agoMy 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 https://news.ycombinator.com/item?id=11366468
- NicoJuicy 11y agoHe 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.... :)
- pier25 11y agoWhat 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.