The Chrome Distortion: how Chrome negatively alters our expectations
blog.runspired.com
blog.runspired.com
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 :)
[1]: https://meta.discourse.org/t/the-state-of-javascript-on-andr...
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.
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 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.
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.
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....
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
There are probably more efficient workflows, but this one works fairly well for me.
EDIT: uBlock or similar is absolutely must though, unless you browse only slim, "old-school" websites.
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:
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.
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.
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.
Sorry, I have to bite. Why?!?
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.
- 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).
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:
Sharp, pure non-antialiased text. I can read text like that all day without feeling like my eyes are going out of focus.
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.
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
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).
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.
Also on FirefoxOS and ChromeOS where third party browsers aren't possible at all.
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.
> 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?
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.
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.
The differences in non-UI code mostly relates to memory usage optimizations - most of them should be upstreamed by now though.
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.
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.
Then I open it in Chrome and it works. And it's clear which browser the developers tested the site against.
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.
For a view of what's needed in real-world terms for compat with the web nowadays, see https://compat.spec.whatwg.org/
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.
Feels like this would be like going back to the end of IEs reign..
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!"
:)
(That's the case for me with FF at the moment, anyway.)
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.
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.
It becomes a habit to switch between browsers depending on the service.
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.
What I did notice after the last Safari release, was that because it's faster/smaller memory footprint, it also used less battery.
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.
Maintaining an entire modern browser on your own is no joke.
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.
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 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.
Before you give a score to every browser, why don't you back it up with something objective?
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.
Of course, between "should" and the reality, there's room for tolerance.
Much happier now on Safari and uBlock.
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.
Is there a browser for Android based on a recent version of WebKit (not Blink)? If so, that would help answer the question.
Maybe someone here can give us some insight into that.
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).
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.
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.
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.
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.
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.
it's specifically about the mobile Chrome and Safari.
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.
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 :-(
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.
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...
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)
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.
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 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.
In general, in situations like this when there is a public link available, please do file bugs on Firefox!
> 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?
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.
Not gonna work -- just like heavier-than-air flying machines, and horseless carriages, will never work :)
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.
This might explain why many asm.js demos tend to crash Chrome for Android.
Edit: actually this view is probably better for people who don't care about JavaScript engine internals: https://arewefastyet.com/#machine=31
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.
> 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.
> Chrome is the new IE
Browser wars are troll wars by children. That's all. Move along.
Anyway, this is probably good (for users), and definitely better than the pre-Mozilla IE monoculture.
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.
You used to have to use chrome because the other browsers were just too slow and naff but they've all caught up now.
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...
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 thought the point of this was to make phishing less likely by making you focus on the domain name you're on.
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.
Machines will get faster quickly. Providing a strong platform is more important than being the fastest, today.
YMMV.
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...
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...
[0] hence efforts like Servo, to explore architectural rebuilding such that browsers can actually use multithreading and GPGPU support for their normal workload
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.
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.