61–70 of 349 posts
I wonder how much of this is a result of UI designers deliberately putting tiny delays/animations into their UIs to make them more "usable"? For example, it was a common piece of advice that if clicking a button opens up a dialog box, there should be a brief animation showing the box expanding from the direction of the button, so the user would associate the clicking of the button with the appearance of the box and u…
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.
Was originally a tweet-storm -> https://twitter.com/gravislizard/status/927593460642615296 , if anyone is confused by the stream-of-consciousness style. It is frustrating that I've got a machine on my desk more powerful than supercomputers a generation ago, and it locks up and can't refresh the screen as fast as my relatively slow typing on a regular basis...
(Great read.)
https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and...
We have gigantic, steamrolling, bullet train machines capable of going nearly infinite miles-per-hour. And everyone's "design" solution... is to add their own stops along the way so the train has to come to a complete stop, [un]load some passengers and start chugging along again. And surprise surprise, a gigantic train takes awhile to accelerate back up to speed.
We've built faster and faster trains, but filled them with so many stops along the way that it's sometimes faster to take the bus.
everything seams a bit much. There are so many things you just could not do at all in 1983, like HD videos or 3D engines or even rendering Mandelbrot fractals
Was originally a tweet-storm -> https://twitter.com/gravislizard/status/927593460642615296 , if anyone is confused by the stream-of-consciousness style. It is frustrating that I've got a machine on my desk more powerful than supercomputers a generation ago, and it locks up and can't refresh the screen as fast as my relatively slow typing on a regular basis...
Can anyone eli5 why this is?
I typically have thirty tabs open at any given time.
The core point of the entire thread can be summed up by one of the tweets; "I believe well designed keyboard interfaces and well designed GUI interfaces have exactly the same learning curve." I agree with this. A properly and well designed keyboard interface is faster than any mouse. On the other hand, a properly designed mouse interface can be fast too. Both need to be applied when it makes sense. I can also resonat…
IMO Google Maps became completely awful when they made that new version of it, and they've been doing everything in their power to continue making it worse. Sure the scrolling is a lot smoother, but it's missing just a ton of features that the old version had. Plus the problems mentioned in the tweet storm, everything disappearing as soon as you change one item. PLUS that stupid side-bar that takes up half the screen…
Note that if they clear your pins so you have to re-search for something, that's potentially another CPC payment to them...
You can sign into multiple Gmail accounts? How on earth does that work, does it involve the menacing prospect of "linking" them?
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 endles…
But other than that, what did IBM ever do for us?
This! I once took over programming a point of sale system that our (internal to the company) users were complaining about. Turns out there was no concept of tab sequence, you had to use the mouse for everything. I asked the previous programmer to show me how to use the form he created, and he started typing a phone number using the top row of the keyboard instead of the numpad. But hey, it had lots of javascript!
I don't get your point about typing phone numbers. When I was being taught to touch-type in first and second grade, my teachers told me that I should type on the top row, not the numeric keypad. Not sure why. Maybe because it takes less time to move to the top row and back? Anyway, to me, typing numbers on the top row is not an obvious problem.