X is justifiably slow (2022)
zeux.io
zeux.io
I think just having the intuition of how fast computers can work is what the industry is sorely lacking. I am usually able to achieve very good performance for the stuff that I'm working on, despite the fact that it often requires a stupid amount of computation, just because I know how much a computer can actually do in a given amount of time when it's tuned correctly.
Pressing a key to start a launcher, typing and using enter within a second does not seem to have been possible back then.
Most applications and games launch in single-digit seconds. I don't recall this being the norm in the Windows 95 days either.
With all of that, it does feel wrong to have to wait for apps to load. How much of that is the calling home to validate the app has been signed?
I wish I never developed it. It turned what used to be mild annoyances into questioning my career choices.
And I'm not talking about techies, I'm talking about the man in the street.
Today, all computers, all programs are "fast enough". Most people can't name a benchmark, much less use it for comparison. Computer sales seldom focus on mhz. Your phone is either fast or slow. But actual measures are not what phone users care about.
These days it's all about capability. Most of which is assumed to exist as table stakes, and which didn't even exist in Windows 95 days.
Maybe people under-estimate how fast their PC is, but equally they grossly underestimate how much work it -is- doing.
Some, but not huge, amounts of time are spent on making things "as fast as they can be". Because customers are paying for more capability, not more speed.
That is what people are experiencing - 500ms-3000ms delays for basic UI interactions (or more), frozen UI’s, jerky/laggy autocomplete and UI renders. Like the classic ‘button is a different button by the time you see the old button and click on it’.
On incredibly lightly loaded and overpowered hardware.
Everyone has been focused on some core algorithm, and completely ignoring the user experience. IMO.
Getting under 100ms really shouldn't be hard for most things. At the very least it should be easy to get the ripple (or whatever button animation) to trigger within the first 100ms.
All UI thread frameworks end up doing the UI interactions on a single thread, or everything becomes impossible to manage, and especially if not careful, it’s easy to not properly setup an async callout or the like with the correct callbacks.
It is easy to make a responsive, < 100 ms UI, it’s often harder to keep it that way.
In the former, one can have a complicated and dynamic three-dimensional scene with millions of polygons, gigabytes of textures, sprites, and other assets being rasterised/path-traced, as well as real-time spatial audio to enhance the experience, and on top of that a real-time 2D UI which reflects the state of the aforementioned 3D scene, all composited and presented to the monitor in ~10 ms. And this happens correctly and repeatedly, frame after frame after frame, allowing gamers to play photorealistic games at 4K resolution at hundreds of frames a second.
In the latter, we have 'wew bubble animation and jelly-like scroll, let's make it 300 ms long'. 300 ms is rubbish enough ping to make for miserable experiences in multiplayer games, but somehow this is OK in UIs.
Games need ultra-responsiveness because rendering frames slower is essentially blocking further user interaction, since players are expected to provide a constant stream of interaction. Being 'engaged' is essentially requiring constant feedback loops between input/output.
On the web the task of reading a webpage doesn't require constant engagement like in games. UI (should) behave in more predictable ways where animation is only there to draw association, not provide novel info. Similarly UI animations are typically (or should not be) blocking main thread responsiveness and (should be) interruptible, so even low frame rates are not breaking the experience in the same way.
But still, your point stands, its crazy what we've come to accept.
How can a UI framework be abused so heavily that it’s that frustrating to try to use?
There is absolutely nothing mental about it, and I'm saying this as someone who's worked on a couple of game projects myself.
Somehow people making these comparisons are never willing to put their money where their mouth is and give random web pages the same level and amount of access to system resources as they give to those "photorealistic games at 4K resolution at hundreds of frames a second".
I'm on a 5-year old intel Macbook, and I think in my daily experience, core software (browsers, emacs, keynote, music) are pretty snappy.
I do routinely work with some extremely frustratingly slow software, but it's pretty stark how much its performance stands out as, well... exceptionally bad.
One thing I've noticed lately is mouse lag. Like, say, in Ye Olde Start Menu on Windows: Move the mouse to the Start menu, and press the mouse button down. Nothing happens. Release the button, and then: Something happens.
The menu is triggered on button-up events, not button-down events. This adds a measurable delay to every interaction.
Same with Chrome when clicking on a link: Nothing happens until the button is released. This adds a delay.
I mean: Go ahead and try it right now. I'll wait.
And sure, it might be a small delay: After all, it can't be more than a few milliseconds per click, right[2]? But even though the delay is small, it is something that is immediately obvious when opening the "Applications" menu in XFCE 4, wherein: The menu appears seemingly-instantly when the mouse button is first pushed down.
[1]: It took me more than three tries to pick a streaming device from Plex on my phone yesterday. I'd press the "cast" button, and a dynamic list of candidate devices would show up. I'd try to select the appropriate candidate and before my thumb could move the fraction of an inch to push the button, the list had changed as more candidate devices were discovered -- so the wrong device was selected.
So I then had to dismantle the stream that I'd just started on the wrong device, and try (and fail) again.
[2]: But even small delays add up. Let's say this seemingly-unoptimized mouse operation costs an average of 3ms per click. And that 100 million people experience this delay, 100 times each, per day.
That's nearly an entire year (347 days) of lost human time for the group per day, or 347 years lost per year.
Which is 4.4 human lifetimes, per year that are lost within the group of 100 million, just because we're doing mouse events lazily.
Switching Chrome tabs works on button-down. Activating the three-dot menu in Chrome also works on button-down (which is good) but then it needlessly fades from 0% to 100% opacity (which is a crime against nature).
I didn't even have to go digging in the memory hole to find this. It's right here in front of me.
> Switching Chrome tabs works on button-down.
True; the same in Firefox. That is interesting. Perhaps it’s because simply selecting a tab is considered a safe and reversible operation. I did use the word “decisive” for a reason.
Or at least it did in classic Win32 UI. You can still see this in action if you open, say, Disk Management. But in Win11 Notepad (which is modern XAML), holding mouse down will open the drop-down submenus, but you won't actually be able to activate an item by releasing the mouse button while hovering over it, so it seems that someone partially copied the design without understanding its purpose.
I just tried this on Firefox and can confirm similar behaviour. Some of the things I clicked on appear to have some alternate long-press function despite having a pointer device with multiple interaction modes.
It seems we have condemned our desktops to large latencies on the off-chance someone might try and interact with them using touch.
Mouse interactions have (at least) 5 different events: hover, down, up, click and double click. The interactions you describe all happen “onclick”, which requires a down and up event to happen consecutively.
I get your point, that small delays add up, but mouse events aren’t a great example, IMO. Each of the events have a purpose and you want to make sure that a button is only activated with an onclick, not just an ondown.
> Each of the events have a purpose and you want to make sure that a button is only activated with an onclick, not just an ondown.
That's stated as if it is a rule, but why is that a rule?
And if if is a rule, then why does Chrome -- for example -- handle this inconsistently?
Clicking on a different Chrome tab sure seems to happen with ondown, but clicking on the "reply" button below the text box I'm typing into works with onclick.
X window was the odd one out in the old days that would show a context menu on mouse down. Made it feel a bit unrefined.
Maybe it's so if you're going to start dragging the window/tab you can see what is in it.
The inconsistency is bizarre, since some here say that clicking-and-releasing before a resultant thing is allowed to happen is a hard-and-fast rule of GUI implementation that has been in place for decades, but that just doesn't seem to be the case at all.
Buttons normally only respond to the “on click” event. This lets you move off the button if you change your mind mid-click.
Window focus could be (I haven’t tested) an “on down” event because you might want to see what’s behind it while doing something else before you release the button (like drag it around). But focus used to be “on hover”, where just moving your mouse over a window brought it to the foreground. “On up” wouldn’t make sense because if you wanted to do something like move the window around, you couldn’t as you’ve now released the mouse.
It all depends on what you’re trying to do and the OS. Each OS has a design language that “tries” to bring some consistency to event handling. But ultimately, it’s up to the application to handle many things.
UI buttons have activated on the mouse-up event since forever ago. There's a reason: to give the user the choice of backing out of an action even after the user has pressed the corresponding button. They can just move the pointer off the button, release, and the action will not be committed.
John Carmack made this same point recently. John Carmack is wrong. Maybe the trigger on your gun in Doom needs to respond on mouse down, for the immediacy and realism -- that's how real gun triggers work, no takesie-backsies once it's pulled. But especially for potentially destructive UI actions such as deleting or even saving over a file -- or launching the nuclear missiles -- you want to give the user every opportunity to back out and only commence the action once they've exhausted all those opportunities.
It's been that way since the 1984 Macintosh -- since a time people remember as having much snappier UIs than now.
Besides which, worrying about the few milliseconds lost each time a button waits for the release is pennywise and pound-foolish; there are much larger, more egregious sources of lag (round trips to the server, frickin' Electron, etc.) we should work on first.
Some things do run very quickly, for sure, but so many of the high touch pieces of code out there from big name corps have some of the worst performance. Hundreds of millions of people use Teams, and many of them use it a lot throughout the day. You must just be getting lucky in what apps you use on a regular basis.
And you’re referring to your (and most other people’s) daily experience, which is of a major software firm producing daily used software with a super slow UI on desktop.
With a little cynicism, these two views are quite compatible.
This is somewhat exacerbated by, ironically, UI mostly being async these days. Back then, if app was slow, it would usually block the UI thread outright, so you couldn't click anything until processing was done. But these days UI is usually "responsive" in a sense that you can interact with it, and lag instead manifests by UI getting out of sync with the actual state (and constantly trying to catch up with it, causing the problem you describe).
Like, there are websites that absolutely suck, but that’s mostly due to some idiotic management decision to add 4 different tracking bullshit libraries, and download 6 ads per click. Thinking about the regular software I use.. could it be better? Certainly. But it is very far from unusable.
I have to constantly close my browser on a 12-core Intel Mac MINI just because four open sites get its fan spinning like it's a Hoover Dam turbine.
Plus web and mobile developers have put a ton of work into animations and things like that to make slowness feel natural, which lowers expectations even further. Nobody expects a device to respond quickly. You expect to have to wait a bit for round-trips or animations or both.
I cover this in "Your Database Skills Are Not 'Good to Have'": https://renegadeotter.com/2023/11/12/your-database-skills-ar...
Specifically when I cite THIS: https://designingforperformance.com/performance-is-ux/
possibly it might not be smart enough to reorder an index on (field1, field2), or it had some weird internal constraint on tuple ordering, or it was simply different enough to go down a different query plan sometimes, or maybe there’s something around the actual physical ordering on disk?
but yeah postgres and SQLite are modern marvels that we take for granted… myISAM was not a good time, or at least people tended to violate the correctness/visibility rules it promised (iirc) or something like that. The fact that you can just open up a stable, well-tested sql instance that runs against disk, or drop Postgres into most transactional use-cases, and generally not have to worry about unduly fighting the DB itself, is underappreciated.
This is looking at the problem wrong.
I notice your shittily optimised application not just because it’s slow, but because it’s draining the battery.
This is a problem, and developers need to wake up to it. Crappy performance uses more energy because the machine is doing unnecessary work to an end that could be achieved more efficiently, often much more efficiently.
So, please, invest time in performance.
Burning up a laptop CPU and torching racks of servers and routers in some data center just because the web is full of shitty ui frameworks should be intolerable to consumers and providers. Efficiency really needs to be a goal of all system designers.
Modern uses forced a lot of layers for genericity and security ..
That’s a pretty bad idea in general. Handling priorities properly is absolutely essential for the stability of a system. I’m not familiar with Amiga, but systems weren’t known for their stability back then. Whole OS crashes were much much more common back then.
There's plenty about Amiga that is and/or feels instant. My workhorse is a 14 MHz A1200 and I use it at least once a week, so I get plenty of opportunity to compare. For its intended use cases, most things feel very snappy. Then there are of course areas where it doesn't stand a chance compared to a modern PC, even if the workload is "Amiga sized". Decompression and picture downsampling, for example.
This just isn’t true: optimizing for speed is always a trade-off and, when an application is fast enough, it can be wasteful to focus on speed rather than other factors
I find dismissive statements like this to be extremely useless to the conversation. I agree that a modern operating system could be blazing fast. But if that’s not the case, then there obviously is a reason.
If you know the reason why software in general has gotten slower (compatibility?, bad devs?, more feature?), and already dismissed it as an invalid or insufficient reason, then share what you think that reason is.
If you, like me, don’t know what that reason is, then let’s approach it with a problem-solving attitude and try to find out.
There isn't a singular cause to brainstorm. It's everything in the entire stack optimizing just a bit in other directions that produces the end result of disappointing, sluggish computers despite their actual capabilities. This discussion isn't going to tread any new ground either. All of these things are known because there are people who can't afford modern computing, like the HFT firms that are all on FPGAs now and real-time embedded systems. It's not hard to do, it's just tedious and expensive the way development used to be for everyone.
Most desktop software just doesn't give a shit about performance.
IMO Product Managers should be steering resources based on what end users want rather than what we feel they should want. Now if we could just get more of them to listen to actual users more than marketing people that are more interested in growing their list of feature bullet points than making software that's useful to anybody at all.
What we can increase is parallelism, but most problems simply can’t be parallelized for a good enough percentage of the workload, and Amdahl’s law can’t be circumvented.
Nonetheless, many other things can be scaled, like resolution (like, think how much bigger 4k@120fps vs hd@60fps is), file sizes, etc, so the workload does increase and not everything can cancel out, hence the perceived slow down in certain cases.
For good reason. Clock speed isnt the sole factor in performance. A PowerPC 970 can clock up to 2 GHz, but it only achieves 8 instructions per cycle (on average!) for arithmetic instructions. Modern mobile CPUs clocked at a fraction of 2 GHz achieve much higher throughput for arithmetic. The branch predictor in the PPC chip, while impressive for its time, is simple in comparison to those of modern processors. A CPU without pre-fetching is going to have much worse latency and throughput than any CPU with it. So on, so forth.
Overall, it's naive at best to focus on clock speed for performance. I used to fixate on it when I was a teenager, but not anymore.
Meanwhile I find it very challenging to build performant web apps without digging myself into a framework-shaped hole, even when the app shouldn't be doing anything particularly complicated.
Maybe part of it is a skill issue on my end, but it really feels like a team of smart engineers could help bridge the performance gap between native and web. Or maybe create an island that sits in the middle.
IMO the problem is what JS enables: making lots of very slow Ajax calls for every small interaction. Which works great in development machines but sucks when a real network is involved.
But your point stands, dropping to server-rendered HTML makes it fast again.
I've been using Gleam in Vue[0] for my task app Netful[1] and it surprisingly reduced a lot of the jank, because... it's sync.
Awaits are used very often for things that shouldn't be used for and have compounding overhead.
This so much.
I semi-recently made an Android app with Flutter and a custom storage solution of just simple mmap calls. It cold starts instantly, even after a long time of not being opened.
I then made a web thing, PWA style offline-first. It has a noticeable loading phase when you start it up, even though the entire thing is just static files on disk. Looking at the performance tab in chrome dev tools makes me want to cry. Things take way too long. And don't get me started on Indexeddb. (I realize that profiling incurs overhead, but it's still embarrassing. Indexeddb isn't even instrumented and it takes 20+ms to fetch one record out of an index)
SQLite on frontend was trending for awhile recently. I tried using that to get around terrible Indexeddb, but the startup time was so bad. Several seconds just to initialize the library and read the database file. It's pretty quick to query once running, but a non-starter if you want to show users their data quickly upon starting the app. It seems that even just chugging the wasm takes a significant amount of time...
I can't think of a slower language. Then all your IPC is done through json as if everything was a website hundreds or thousands of miles away instead of something more sensible such as a shared memory.
Won't beat Rust on most benchmarks, of course.
Software engineer time is still often the primary cost metric, but Java didn't ever get actually fast - things like constant pointer chasing and poor cache utilization still hurt it significantly in "regular" code. So, too, does the complete lack of compile time optimizations and limited JIT thoroughness & comprehensiveness.
There's pockets of people doing Java + performance, but they are far & away the exception and they are frustratingly insular about what they do & why they do it. And yeah it tends to often go against every bit of guidance from things like Effective Java & similar.
It still takes many seconds to just start the program
Maybe the JRE is simply a pain to start ?
We pretty much locked in a latency pattern (eg, acceptable upper bound for user path completion speed) such that we’re happy with the speed you can go. Much faster and it feels weird.
We just want to continue to shrink it down.
Anything, from booting the computer to any random application is much faster in my Win 11 than on my old Win 2000 (with good hardware for the time).
I still remember the hourglass on the icon when opening so many applications (let alone together..).
After more than 3 decades of writing software, I can confidently say that computer specifications are a lot like a persons house or flat. The more space you have, the more ways you find to fill that space. And the less space you have, the more ways you find to optimise for that space.
For many people, Win 95 was paired with 486s with 8 MB RAM or early underpowered Pentiums with hardly any more. Opening the start menu would sometimes take seconds, like the computer had to ponder for a while. Applications frequently had to sit in waiting as the spinning rust slowly volunteered some data.
Things are much better now.
Even just loading files off the old spinning disks took ages. Loading screens for a game could take 5-10 minutes.
Even just booting into my Linux box took 3-5 minutes and optimizing the boot time was a whole thing you spent a lot of time on.
I remember the day I received my first SSD and installed it in my computer, it was like Christmas morning. Things are way faster now.
My Macbook goes off when I shut the lid and right back on when I open it up. Try doing that on my early 90's Toshiba Satellite.
We live in a magical world now of high speed, multi-core and NVMe hardware. I have no desire to ever go back.
It's instantaneous compared to the 90s and even the 2000s. It wasn't until 2010-2012 that I remember switching to SSD, which is when I feel the turning point was.
I still have it, and when I put an 32bit version of Debian on it a couple years ago, it was molasses. Somehow I used it for years with no complaints.
Even the first Mac Portable[1] had fast sleep/wake. As did the Radio Shack Model 100[2] from the early 1980s. Early Apple laptops could spin down the hard drive (vs. modern Macs where you can't easily shut off I/O-intensive background daemons like mdworker, syspolicyd, photoanalysisd, etc.; fortunately SSDs mitigate the issue somewhat.)
---
And significantly less reliable.
Remember how common crashes were? (Including BSoD!)
Like, you can solve 90% of memory crashes by using a memory managed language but that is course has costs.
I see references that mention that installing fonts can significantly impact boot time. Maybe the installed software and devices had a significant impact.
The fact of the matter is the hardware has gotten faster and the software has gotten slower, cancelling each other out at best and slowing down at worst.
It still does take several seconds to open start menu, same for calculator. Explorer takes sometimes a minute so I have a different file manager open constantly.
The trick is to combine windows with any type of DLP enterprise software. It consistently delivers this horrible experience.
But aside from poor enterprise setups, try opening win11 start menu on a computer that has internet, just veeery slow. Suddenly you will miss those times of win95 loading start menu icons one by one, with a soundtrack of scrubbing HDD.
I don't miss those times purely because of huge stability differences. 20 years ago or so, systems crashed all the time and filesystems had to be repaired constantly. I even clearly recall how often was a kernel panic on random Linux distro, when you tried early docker.
It's frankly ridiculous how everything "kinda seems to work" but not really
>yet computers don't feel much faster
it depends on the computer rather. The slowest I've experienced was a cheap laptop with Windows Vista where just right clicking on an icon to see the menu could take like 30 seconds. I'm now on an M1 macbook air where everything is pretty much instant. That said the other instant computer I had was a Psion 3 which came out 33 years ago so it's down to the individual design I guess. Windows has always been kind of bad to varying degrees.
I can still run a Debian 12 with KDE on a standard SSD way faster than a Win 11 installation on a NVMe, and that installation is 8 years old, and runs tons of applications at any given time.
Also hardware input lag definitely isnt better, and many times worse than in past: https://danluu.com/input-lag
Like literally, I have a Pentium MMX 200 Mhz (64 MB RAM, 8 GB CF Card) machine right next to my Surface Pro 9 (i5 1235U, 16GB RAM, 2 TB SSD). The Pentium (running Windows 98 SE) demolishes my Surface Pro 9 (running Windows 11) in opening applications, and UI latency. I can literally open about 30 copies of Windows Explorer before Windows 11 opens a single one. Honestly the only thing that's really slower is booting since it takes forever in the BIOS stage.
Modern software is just slow. We've given up all of the advantages of our orders of magnitude faster I/O.
When Windows 95 was introduced it took so long to boot that it wasn't even worth it for me. I remember that a popular magazine did an aprils fools joke that the new Intel CPU was so fast it could boot Windows within few seconds.
Hard disagree: all applications back then needed splash screens to reassure the user something was happening while the application was loading components on into RAM. Today, most applications load within seconds.
I booted an old computer from 2009 just the other day, and everything felt sluggish from boot to launching applications.
It starts with choosing the right algorithms, using an index instead of doing a linear search, minimizing network traffic, ... but sometimes there are just unneccessary sources of slowness.
I was tinkering with a react-native app the other day which shows a map and lets the user click on a building, and then highlights the building and shows some information. There was a noticable delay after clicking which made it not much fun to use. So I spent a couple evenings (hobby time, not company time) to integrate a proper spatial database with a fast spatial index, precache a lot of data, so I didn't have to hit the network. It got snappier, I could query a lot of geometry much faster, but it still felt slow. Then I looked into the source of the libraries, and in some react-native glue code I found that the event handler was waiting after the first tap for a double-tap, and thus would only register the tap after a couple hundred ms. One tiny change and it became blazing fast.
I believe most apps could do most things instantaneously. Google can find any document on the net in a few ms, after all. But of course not everybody has the time and money (or even skills) to polish their apps that much. If the customer will buy your app when it is good enough then why should you put in more work (besides from a personal sense of craftsmanship)?
No one cares anymore. I don't get it.
So part of the reason may be that developers tend to have access to hardware which isn't representative of a typical user. I probably could've written a more clever algorithm at the time, but why bother for a one-off?
Most of web programs are slow because of ad business.
You need to be evaluated. Are you a robot? Which cohort you fit into? Which ads should it fed you?
They capture every bit of information about you, so you could be tracked more, or to sell your data.
Then they display what you want to see.
Corporations focus not on providing info you would like to see. Therefore X/meta/youtube will not have a good subscription UI / behavior.
The corporations focus on suggestion algorithms so they can spoon feed you with data they want to monetize for advertisers.
2)
Big corporate projects are built by thousands projects, and thousands abstractions tied together by a duct tape. Layers upon layers, built by engineers not happy with outcome, but engineers that met deadline.
But these are the messy human + economic reasons why things are actually slow.
I'd add some nuance to (2), that even small corporate projects are often built by companies that are explicitly incentivized to build as quickly as possible, any other barometer of success goes out the window.
If you use software developed by companies or projects that are outside (1) and (2), you'll find it is actually pretty fast, subjectively.
As opposed to this, whenever I don't feel like bothering with this and just type in 'Read %THING% online free', the resulting sites tend to be just html pages where the pages are linked in as images and the whole things is blazing fast, and I can scroll without bother.
I'm quite the former sites re built by a small army of engineers and it's some kind of orchestrated microservice thing running region-replicated on some cloud provider-hosted kubernetes cluster, and is loaded to the brim with DRM authorization.
While the latter sites are probably running on some kid's old surplus gaming PC tucked into the corner of their bedrooms, on some PHP site thrown together over the weekend.
Yet the latter is infinitely more usable.
My first program ran on a 2MHz CPU with 64KB RAM and (floppy) disk access time measured in seconds. I think something of the art and science has been lost when even a wonderful “toy” computer runs at 2.4GHz.
Often when I ask “what is the system really doing when X is slow?” people (including developers who built it) have little idea.
E: this article is deeply confusing and I should probably bill the owner for my time
I assume he’s using X as a generic placeholder instead of formerly-known-as-Twitter, but the argument applies in either case.
In my experience this is never the case. There’s always ridiculously low hanging fruit. On the ground and rotting, in fact.
I’ll use Jira as an example. Their online version takes a solid minute to open an empty form. A minute! Do you have any idea how much computing power this represents!? I can install Windows Server 2022 into a virtual machine in less time than this! I can read 42GB of data from disk, or download a DVD from the Internet.
Someone working for Atlassian was here making excuses: customers implement many complex customisations, they have security rules, etc, etc…
“The system is doing a lot of hard work” is what he was trying to say.
I tried a new, empty tenant. No data, no customisation of any kind.
Took nearly a minute to show an empty form. That’s not “hard work”, that’s the baseline. It can only get worse from there!
This is the literal opposite of what the author is saying though? The article even closes with him expressing annoyance because people who claim that X is justifiably slow have almost certainly not done enough analysis to say so.
If you fail at making it clear what the topic of your writing is, then you failed as writer. I shouldn’t have to guess what the subject under discussion is.
Now assuming he is taking in general, the whole article is just content free, because the writer is reduced to literally just brainstorming anything and everything, and saying, “See? There’s lots of reasons for something to be slow!” Well, fuck dude, I think we all know that.
What new features does windows 11 have compared to win XP? Now compare the requirements needed to even start the OS.
Web is even worse... 2kB of usable information means tens of megabytes of downloaded crap, and that's even before the ads. Why does a simple site with a sidebar need megabytes of javascript?!
The problem usually is: really poor code that is blocking, triggers a million rerenders for every interaction, insane bloat, or just the absolute massive amount of abstractions through packages. Plus HTML + CSS is really slow.
thanks Elon
> As should be obvious from the framing, X here is a variable, not a web site formerly known as Twitter.
Usually, I will call people however they preferred to be called, even when it seems silly.
But renaming Twitter to "X" crosses the line of confusing. I'm not sure it should've been allowed.
> As should be obvious from the framing, X here is a variable, not a web site formerly known as Twitter.
Not only did I misunderstand the article, the author tops it off by calling me a dummy at the end..
Xtreme iAir Pro+ | AI for My BlockchainThis could be one of the needlessly confusing articles I've seen yet.
I think X on its own should never be Twitter, it should always be referred to as x.com to eliminate any ambiguity.
I vote on "the website previously known as Twitter".