My web app died from performance bankruptcy
-
TL;DR Chrome team breaks web to make Chrome perform better.
As a user, I certainly do not care about “being part of moving the web forward aggressively”. Why should I? I like my stuff working, not broken. Nobody ever wants it the other way around.
Hah! I like that statement a lot. It really shines a light on how some of us view web development... there's something to be said about backwards compatibility
Filed under: People give me shit for introducing breaking changes in NodeBB, so I'm pointing it out when Chrome does it too!
-
This one simple trick can make you never need glasses again! Eye doctors hate it!
-
@julianlam said in My web app died from performance bankruptcy:
they’re also supposed to rely on
acomplex, brittle and accidental effects to check for it.Also the colors of that blog are extremely harsh on the eyes, as pointed out on reddit (and maybe also by @ben_lubar). My eyes were hurting after I finished reading and now they're tearing up, and I even had blue light reduction enabled.
Anyway, I agree this is a mess and feature detection is a must. We had a similar period in C++ for a while but we've got feature detection now at least.
-
@lb_ said in My web app died from performance bankruptcy:
we've got feature detection now at least.
I do want to point out that while I was reading that article, I was thinking about how Modernizr worked really well a couple years back. I wonder if it's still a good go-to.
It also supports feature detection for passive event listeners.
-
Not too long ago Chrome suddenly broke the FreeNAS interface somehow. I wonder if this is related?
-
@lb_ said in My web app died from performance bankruptcy:
and maybe also by @ben_lubar
Nah, I was just saying that there's always a simple way to solve a problem by creating a worse problem.
-
Ethos of the web has always been "do not, ever, for any reason break old websites". That's why we put up with half the shit javascript has to keep dragging around.
Seems like Chrome is changing that. And these days they have the clout to do so.
-
No mention what his web app does, so hard to judge whether the feature was really needed.
Anyway, no surprise here. Nowadays I am more surprised when a web app is not broken (especially on mobile).
It is a performance vs feature trade-off.
Whether it was worth it, we would need to know how much the performance was increased vs how significant the usages of preventing-scrolling are. Hard to judge either way, as different things are important to different people.To be honest, the announcement about this change discusses some solutions (inelegant, as usual in web tech) to mitigate it:
-
@adynathos said in My web app died from performance bankruptcy:
It is a performance vs feature trade-off.
As a consumer, I'll always pick performance over features.
-
@cartman82 said in My web app died from performance bankruptcy:
Ethos of the web has always been "do not, ever, for any reason break old websites". That's why we put up with half the shit javascript has to keep dragging around.
Right, but is there any reason why websites can't just say "this page uses HTML-2017" and the browser will disable all the old ugly javascript things and enable all the new behaviors? It seems to be the cleanest way to allow breaking changes over time.
Admittedly that won't help if the Chrome team decides to retroactively change the HTML-2010 behavior to "make pages faster at the cost of just a little breakage"...
-
@anonymous234 said in My web app died from performance bankruptcy:
Right, but is there any reason why websites can't just say "this page uses HTML-2017" and the browser will disable all the old ugly javascript things and enable all the new behaviors?
But that’s not The HTML5 Way(tm).
-
@anonymous234 said in My web app died from performance bankruptcy:
Right, but is there any reason why websites can't just say "this page uses HTML-2017" and the browser will disable all the old ugly javascript things and enable all the new behaviors? It seems to be the cleanest way to allow breaking changes over time.
Sounds good to me. Kind of like "use strict;" in javascript.
-
@cartman82 said in My web app died from performance bankruptcy:
Sounds good to me. Kind of like "use strict;" in javascript.
I still laugh at that statement being a part of the language that allows adding objects and arrays. Or is it arrays and objects? Oh who cares, both works, it's just that the result is different.
-
Turned out, Google wasn’t concerned about your websites at all. It was more concerned about its own product performance, Google Chrome Mobile. That’s why on February 1, 2017, they made all top-level event listeners passive by default. They call it “an intervention”.
Nice. I'm going to ignore it. If anything breaks on Chrome mobile, I can now blame on Chrome.
-
If ever a topic belonged in the Side Bar...
-
@onyx yeah, a huge missed opportunity. They didn't even think to set up some versioning scheme.
It's the general story with everythinh ECMA does. Good intentions, half-assed implementation.
-
@cartman82 said in My web app died from performance bankruptcy:
They didn't even think to set up some versioning scheme
use real_strict
-
@anonymous234 said in My web app died from performance bankruptcy:
Right, but is there any reason why websites can't just say "this page uses HTML-2017" and the browser will disable all the old ugly javascript things and enable all the new behaviors? It seems to be the cleanest way to allow breaking changes over time.
Sure...
kind ofexactly like HTML doctypes. That worked out well, didn't itOkay, so let's not trust the web developers, and put the onus on browsers to self-report compatibility... shit
@boomzilla said in My web app died from performance bankruptcy:
If ever a topic belonged in the Side Bar...
... it's my first day?
-
@julianlam said in My web app died from performance bankruptcy:
... it's my first day?
That would explain why you choose Node JS
-
It's shiny and all I had to do was
npm install forum-boilerplate
-
@anonymous234 said in My web app died from performance bankruptcy:
@cartman82 said in My web app died from performance bankruptcy:
Ethos of the web has always been "do not, ever, for any reason break old websites". That's why we put up with half the shit javascript has to keep dragging around.
Right, but is there any reason why websites can't just say "this page uses HTML-2017" and the browser will disable all the old ugly javascript things and enable all the new behaviors? It seems to be the cleanest way to allow breaking changes over time.
Admittedly that won't help if the Chrome team decides to retroactively change the HTML-2010 behavior to "make pages faster at the cost of just a little breakage"...
Are you crazy? That's not the JavaScript way. The JavaScript way is to add shims, polyfills, bells, whistles, and a whole host of cool sounding things to add another layer to JavaScript "compiling".
-
@julianlam said in My web app died from performance bankruptcy:
It's shiny and all I had to do was npm install forum-boilerplate
GIVE AWAY ALL OUR SECRETS, WHY DON'T YOU?
-
@sumireko said in My web app died from performance bankruptcy:
polyfills
That's such a funny word. I always assumed it was some kind of algorithm for painting polygons.
-
Technically, that thing is painting a polygon right now!
-
@anonymous234 said in My web app died from performance bankruptcy:
That's such a funny word. I always assumed it was some kind of algorithm for painting polygons.
Yes, we use it to force rectangles into same positions regardless of browser.
-
@anonymous234 said in My web app died from performance bankruptcy:
@sumireko said in My web app died from performance bankruptcy:
polyfills
That's such a funny word. I always assumed it was some kind of algorithm for painting polygons.
I thought of https://en.wikipedia.org/wiki/Spackling_paste#Polyfilla myself.
-
@julianlam said in My web app died from performance bankruptcy:
TL;DR Chrome team breaks web to make Chrome perform better.
As a user, I certainly do not care about “being part of moving the web forward aggressively”. Why should I? I like my stuff working, not broken. Nobody ever wants it the other way around.
Hah! I like that statement a lot. It really shines a light on how some of us view web development... there's something to be said about backwards compatibility
Filed under: People give me shit for introducing breaking changes in NodeBB, so I'm pointing it out when Chrome does it too!
For the life of me, I don't understand why we have to have so much backwards compatibility and force people to use the latest thing at the same time.
Why can't we sell people on upgrading their code, by introducing new features in a different version of the language?
-
@xaade
Because it's open source, you don't sell anything, data was meant to be FREE!!!!!
-
@izzion said in My web app died from performance bankruptcy:
@xaade
Because it's open source, you don't sell anything, data was meant to be FREE!!!!!sell, as in, convince.
-
@xaade
What you actually meant ic ing
-
@sumireko said in My web app died from performance bankruptcy:
@anonymous234 said in My web app died from performance bankruptcy:
@cartman82 said in My web app died from performance bankruptcy:
Ethos of the web has always been "do not, ever, for any reason break old websites". That's why we put up with half the shit javascript has to keep dragging around.
Right, but is there any reason why websites can't just say "this page uses HTML-2017" and the browser will disable all the old ugly javascript things and enable all the new behaviors? It seems to be the cleanest way to allow breaking changes over time.
Admittedly that won't help if the Chrome team decides to retroactively change the HTML-2010 behavior to "make pages faster at the cost of just a little breakage"...
Are you crazy? That's not the JavaScript way. The JavaScript way is to add shims, polyfills, bells, whistles, and a whole host of cool sounding things to add another layer to JavaScript "compiling".
All of which breaks with the next release of whatever framework the developers are using because the maintainers can't be arsed to update their documentation.
-
@slavdude said in My web app died from performance bankruptcy:
because the maintainers can't be arsed to update their documentation
What documentation ?
-
The one where any deviation from the norm is left as an exercise for the reader.
-
@timebandit You know, the documentation that needs an entire documentation website devoted to decoding.
-
@magus said in My web app died from performance bankruptcy:
@timebandit You know, the documentation that needs an entire documentation website devoted to decoding.
Honestly, most of the time I'd be happy if I could find out what their framework actually does other than "fetching HelloWorld.json from the RESTful Cloud WebHook CDNs!"
-
@cartman82 said in My web app died from performance bankruptcy:
Ethos of the web has always been "do not, ever, for any reason break old websites". That's why we put up with half the shit javascript has to keep dragging around.
Seems like Chrome is changing that. And these days they have the clout to do so.
Tell that to Adobe (and, funnily enough, yet again Google).
-
This is a breaking change, and it'll break every single one of those scroll-hijack pages.
On further thought...... This might be a good thing.
-
@cheong said in My web app died from performance bankruptcy:
Turned out, Google wasn’t concerned about your websites at all. It was more concerned about its own product performance, Google Chrome Mobile. That’s why on February 1, 2017, they made all top-level event listeners passive by default. They call it “an intervention”.
Nice. I'm going to ignore it. If anything breaks on Chrome mobile, I can now blame on Chrome.
So I read relevant bug in bug checker during lunch. Seems only "touch" related event had changed to use passive as default, others like pointer event are not touched.
If that's the case there's no big deal to me, as I'm not using touch event anyway.
-
@zecc said in My web app died from performance bankruptcy:
@adynathos said in My web app died from performance bankruptcy:
It is a performance vs feature trade-off.
As a consumer, I'll always pick performance over features.
What good is performance if the features are broken and don't work properly?
-
@el_heffe said in My web app died from performance bankruptcy:
What good is performance if the features are broken and don't work properly?
It fails faster!
-
@thegoryone said in My web app died from performance bankruptcy:
@sumireko polyfills
Look at me, I'm a JS dev now!
In fact, that's what in my mind first when I heard about "polyfill". :P
-
@thegoryone said in My web app died from performance bankruptcy:
@sumireko polyfills
Look at me, I'm a JS dev now!
That's pretty acurate.
-
@el_heffe said in My web app died from performance bankruptcy:
What good is performance if the features are broken and don't work properly?
features, not features. Note the airquotes.
-
Wait, so let me get this straight.
- You have countless old websites written according to the spec, which work correctly and fast enough.
- Your shitty new websites are too slow because you keep putting in ever more useless libraries, abstractions, and non-features
- You decide to remedy this by unilaterally changing the spec and breaking existing pages, instead of making the change opt-in.
Wow, I thought only Google corporate were assholes, but their engineers are really smart. That's some seriously retarded move there, definitely front page material.
Thank Chuck I don't get anywhere near web development.
-
@topspin said in My web app died from performance bankruptcy:
Wow, I thought only Google corporate were assholes, but their engineers are really smart. That's some seriously retarded move there, definitely front page material.
Thank Chuck I don't get anywhere near web development.
Years ago, most websites were designed so that they rendered properly with Internet Explorer. Microsoft didn't really care about "standards" because they had the browser used by 90% of the world and Fuck You if you don't use IE. Then other browsers came along and everyone, even Microsoft, started following a set of web standards. Sort of. Most of the time.
Apparently, Google has decided to become the new(old) Microsoft.
-
@julianlam Does this have anything to do with mobile scroll broken over pinned threads on my nodeBB forum?
-
@dangeruss You know what, it might actually... but you said upgrading Chrome fixed it, no?
-
@julianlam said in My web app died from performance bankruptcy:
@dangeruss You know what, it might actually... but you said upgrading Chrome fixed it, no?
Well I said it works on a different phone (higher OS version, but same chrome version).
Other people have been able to replicate. So far it's broken on Galaxy S5 and Galaxy Note 3 (both running Lollipop)
-
Kind of related. Gary Bernhardt (from Destroy All Software) had a little twitter arguments with one of the people behind AMP.
Apparently their limited CSS implementation has broken in-page search on iOS safari and they don't intend to fix it on their end.
https://twitter.com/garybernhardt/status/863074378304462848
Sounds like there WAS a change of mind in Google regarding backwards compatibility, and they ARE going to be using their monopoly to push the web "forward" (in the direction they like).
-
It probably saved you more lifetime this month waiting for pages to load than it cost you to write all these tweets.
Wow, they think they need praise for coming up with the idea of "what if websites weren't horribly bloated turds".