4 ms·

It's a tragedy of the commons. It's very rare for one piece of software to be solely responsible for slowness, but each individual piece contributes just ever s

It's a tragedy of the commons. It's very rare for one piece of software to be solely responsible for slowness, but each individual piece contributes just ever so slightly. I happen to know quite a bit about front-end technologies, so I'll speak to those. Bootstrap is around 100 kilobytes. One hundred thousand bytes - after gzip and minification. By itself, is it slow? Not very. Bootstrap fans will point you to endless benchmarks and tests that show its impact on performance. Same with React: one hundred and forty five thousand bytes, after gzip and minification [0]. According to React fans, React is blazing fast! But development happens, so you throw in a few hip libraries and frameworks and suddenly Slack takes one billion bytes of RAM. Whoops. "But it's not React's fault!" Sure it's not. If React is the only bloated thing on your site, it will work great. But chances are that if you've got React, you've also got Bootstrap, and some visualization things, and some code from Stackoverflow that iterates over your DOM in O(n!^n!). And all of that is how things get slow. Now, I might be a bit biased, because I spent years of my life working on a CSS framework 100x smaller than Bootstrap, but I think that if everyone spent time optimizing the size of things to be 100x faster we could get back to snappy UIs. Yes, it would be hard, and yes, it would require compromises, but the result just _feels_ good. There's something about a webpage loading in 250ms, or a button reacting as soon as you tap it, that just feels nice. Maybe it means not using React; maybe it means you don't use as many nice-to-have frameworks, but I think it's an achievable goal. [0] React fans will point out that if you don't need to interact with the DOM, this gets smaller. Yes, this is true, but obviously for most webpages you kind of need DOM interactions.

samstave 9y ago
Sure but tbf, we didn’t even have gpus in 1983, we had text and ascii, and a terminal. And a math coprocessor if you were lucky. And roads, and the aqueduct. And sewers. And a VT100 But other than that, what did IBM ever do for us?
tome 9y ago
> I spent years of my life working on a CSS framework 100x smaller than Bootstrap Interesting! Can you share that?
- owenversteeg 9y ago
  http://mincss.com http://mincss.com (and yeah, homepage needs some work, my friends say it sounds like too much of a corporate product and not a FOSS CSS framework)
  - tome 9y ago
    Thanks! I will investigate it in the future where I would normally have considered Bootstrap.
zinckiwi 9y ago
I've written many sites with React, Bootstrap, and a dozen or three other third party dependencies, but I've never run into a case of a button not responding when clicked or things taking a noticeably long time to load (assuming that the server processing or sheer size of the payload over the network isn't the cause). I think a lot of it boils down to "don't do work you don't have to." But there's nothing about a framework that causes -- or saves you -- from that.
- owenversteeg 9y ago
  Great work on the sites you've made! Unfortunately, most of the time when I see a simple webpage not responding or lagging heavily, it's made with React/Bootstrap. It's particularly tragic when the page is only text and images.
- ams6110 9y ago
  You probably weren't updating 50 different ad networks on every mouse event.
CGamesPlay 9y ago
> some code from Stackoverflow that iterates over your DOM in O(n!^n!) OK, I'm curious. What's a legitimate problem where the most naive solution is O(n!^n!)?
- owenversteeg 9y ago
  That was a joke, honestly I doubt anything would be that slow. There are a few algorithms that are O(n!) though.
- zlynx 9y ago
  There was one I helped suggest fixes for on StackOverflow a while back. The program searched DOM nodes, found its target, split the node, inserted the two new nodes, and continued searching in the new node it had just inserted. The result of this was truly horrific performance. If one node contained thousands of matches, the repeated node removal, copying, inserting, repeat, took more than 30 seconds. 30 seconds on a 4 GHz machine.
s73ver_ 9y ago
"but I think that if everyone spent time optimizing the size of things to be 100x faster we could get back to snappy UIs." Quite possibly. Who's going to pay for it, though? And who's going to make sure the frameworks are still easy to use and not buggy?

samstave 9y ago

Sure but tbf, we didn’t even have gpus in 1983, we had text and ascii, and a terminal. And a math coprocessor if you were lucky. And roads, and the aqueduct. And sewers. And a VT100 But other than that, what did IBM ever do for us?

tome 9y ago

> I spent years of my life working on a CSS framework 100x smaller than Bootstrap Interesting! Can you share that?

owenversteeg 9y ago
http://mincss.com http://mincss.com (and yeah, homepage needs some work, my friends say it sounds like too much of a corporate product and not a FOSS CSS framework)
- tome 9y ago
  Thanks! I will investigate it in the future where I would normally have considered Bootstrap.

zinckiwi 9y ago

I've written many sites with React, Bootstrap, and a dozen or three other third party dependencies, but I've never run into a case of a button not responding when clicked or things taking a noticeably long time to load (assuming that the server processing or sheer size of the payload over the network isn't the cause). I think a lot of it boils down to "don't do work you don't have to." But there's nothing about a framework that causes -- or saves you -- from that.

owenversteeg 9y ago
Great work on the sites you've made! Unfortunately, most of the time when I see a simple webpage not responding or lagging heavily, it's made with React/Bootstrap. It's particularly tragic when the page is only text and images.
ams6110 9y ago
You probably weren't updating 50 different ad networks on every mouse event.

CGamesPlay 9y ago

> some code from Stackoverflow that iterates over your DOM in O(n!^n!) OK, I'm curious. What's a legitimate problem where the most naive solution is O(n!^n!)?

owenversteeg 9y ago
That was a joke, honestly I doubt anything would be that slow. There are a few algorithms that are O(n!) though.
zlynx 9y ago
There was one I helped suggest fixes for on StackOverflow a while back. The program searched DOM nodes, found its target, split the node, inserted the two new nodes, and continued searching in the new node it had just inserted. The result of this was truly horrific performance. If one node contained thousands of matches, the repeated node removal, copying, inserting, repeat, took more than 30 seconds. 30 seconds on a 4 GHz machine.

s73ver_ 9y ago

"but I think that if everyone spent time optimizing the size of things to be 100x faster we could get back to snappy UIs." Quite possibly. Who's going to pay for it, though? And who's going to make sure the frameworks are still easy to use and not buggy?