Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Chrome Distortion: how Chrome negatively alters our expectations

blog.runspired.com

Post reply on HN
Print view View original

171–180 of 230 posts

Re: The Chrome Distortion: how Chrome negatively alters our expectations

#171

Post by Uehreka »

mwcampbell wrote: post #168
robdodson wrote: post #162

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:/…

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).

Re: The Chrome Distortion: how Chrome negatively alters our expectations

#173

Post by ac29 »

sweetbabyjesus wrote: post #134
therealmarv wrote: post #42

Earlier quoted context omitted.

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.

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

Re: The Chrome Distortion: how Chrome negatively alters our expectations

#174

Post by erikpukinskis »

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.

Re: The Chrome Distortion: how Chrome negatively alters our expectations

#175

Post by hrktb »

robdodson wrote: post #162

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:/…

> 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.

Re: The Chrome Distortion: how Chrome negatively alters our expectations

#176

Post by [deleted] »

robdodson wrote: post #162

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:/…

[deleted]

Re: The Chrome Distortion: how Chrome negatively alters our expectations

#177

Post by xenadu02 »

jnem wrote: post #56
clumsysmurf wrote: post #53

"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.

Re: The Chrome Distortion: how Chrome negatively alters our expectations

#179

Post by hrktb »

thenomad wrote: post #14
dsugarman wrote: post #9

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.

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.

Re: The Chrome Distortion: how Chrome negatively alters our expectations

#180

Post by bzbarsky »

athenot wrote: post #50

> 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 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...
Post reply on HN