Which software exactly is functionally the same yet consumes more resources? Can you give some specific examples? Nah, having lived and written code through the last 20 years, I think this often repeated argument just isn’t true at all. I can see why it’s easy to jump to this conclusion and easy to believe, if you don’t know or don’t pay attention what’s under the covers. It’s easy to forget about all the conveniences you’ve gotten used to along the way. You wouldn’t agree the functionality is the same if you tried using software from 20 years ago.
One easy to overlook difference is displays. It’s easy to forget that 20 years ago we had 800x600 screens, 24 bit color was not ubiquitous, and 60hz monitors were practically non-existent. Today 4K is normal, and combined with refresh rates and colors, we’re pushing upwards of 2 orders of magnitude more data to our screens. We have much better compositing, much better text and graphic rendering, better antialiasing, all around higher quality and faster rendering.
YouTube and Netflix didn’t exist 20 years ago. Browsers were incredibly slow and couldn’t support streaming video or anything but the smallest of applications written in JavaScript. Localization didn’t exist, web analytics wasn’t really a thing, browsers didn’t run background tasks.
> A world where some websites still don’t work properly across web browsers
This specious framing might have you believe that web portability hasn’t improved that much, while in reality the difference in support for web standards has changed dramatically in the last 10 years. Supporting IE6 was a real and widespread problem for businesses compared to the few minor corner cases that are left.
Compare basic document editing in Office 365 with Office 2000 running on Win2k. Sure, 365 has loads of additional functionality, and your data follows you across devices. But the base user experience is largely worse.
> It’s easy to forget that 20 years ago we had 800x600 screens, 24 bit color was not ubiquitous, and 60hz monitors were practically non-existent.
This was maybe the case in the mid-90's. But by the late 90's 1024x768, 85hz, and 24 bit color were standard. 1280x1024 and even 1600x1200 were not uncommon.
Right, so you’re agreeing with me and disagreeing with @miltondts? UX isn’t what we were discussing.
> This was maybe the case in the mid-90’s.
“In the PC world, the IBM PS/2 VGA (multi-color) on-board graphics chips used a non-interlaced (progressive) 640 × 480 × 16 color resolution that was easier to read and thus more useful for office work. It was the standard resolution from 1990 to around 1996. The standard resolution was 800 × 600 until around 2000.”
https://en.wikipedia.org/wiki/Display_resolution#Evolution_o...
Then 1920x1080 didn't seem worth the cost.
Then gaming landscape changed and 60Hz is not a thing anymore, now it has to be 120+.
So have been waiting until 4k 120Hz+ and the money in my pocket meet.
My iiyama VisionMaster was doing 1600x1200 @ 90Hz and running Quake 3 just fine back in 1999/2000.
> better compositing, much better text and graphic rendering, better antialiasing, all around higher quality and faster rendering.
Thank you Nvidia, I guess? They have been carrying the water since the late '90s when everyone else dropped the ball.
But let's get something straight. When we went from CRT to LCD/LED we weren't picking visual fidelity. We, as a consumer base, picked convenience. Thin and light vs. great colors, contrast, viewing angles, refresh rates, etc. My first LCD was in 2004. It was an expensive top of the line brand. I took it home and the ghosting was incredible. Massive input lag. If you were sitting in your chair and just leaned back, all the colors would shift on the display. The viewing angle was nonexistent. I took it back the next day. We are just now getting to the point of matching a CRT from the '90s. And you may have noticed we still don't have OLED on the desktop.
Around that same time we all got stuck with perhaps the worst crime against monitor tech: 16:9 aspect ratios. Not only is that aspect not "cinematic" (theatrical 16:9 does not exist), but we're leaving tons of resolution and screen space on the table. Because your monitor will always have the same footprint due to the width, we could have much better vertical resolution if we stuck with 4:3. Consumer TV fads really hurt the computing industry.
> support for web standards has changed dramatically in the last 10 years.
Yeah well, Webpack, Babel, and numerous polyfills all say otherwise. We're only just now dropping support for IE11 everywhere. Maybe that's the light at the end of the tunnel? But I have my doubts. The incentives are too high for the web to fully standardize. Embrace-and-extend will continue. Developing for the web has never been more complex than it is today.
The other bit of sad news is that the web is no longer open. HTML5 is not an open technology. It requires proprietary DRM which only a few companies allow you to use.
> web analytics wasn’t really a thing
I'm going to shed no tears when Google Analytics finally dies.
I’m confused by this. Film aspect ratios are even higher than 16:9, at 1.85:1 and 2.39:1. I don’t understand why you complained about 16:9 being not cinematic while suggesting 4:3 is better, could you elaborate?
4:3 is better because it fits the application better. What are you doing at your computer? Probably work or browsing the web. If you watch YouTube videos then you have a chicken-and-egg issue... YouTube content is 16:9 because that's what your device is (to see what I mean: look at all the vertical videos today... the content follows the device). YouTube/TikTok creators aren't using aspect ratio in an artistic manner because few of these people are even aware that they could have a say in the matter. Unlike say, Kubrick, who deliberately picks a ratio for each of his films. They are using what the prosumer cameras are designed for, which is all 16:9.
The point is: you're getting black bars if you watch theatrical content whether it's 4:3 or 16:9. The width of your computer monitor is a constant. So we lost vertical screen space for what? Nothing, that's what. Slightly less black bars on the top and bottom when we watch a Marvel movie on our desktop computer or laptop.
> So we lost vertical screen space for what? Nothing, that's what. Slightly less black bars on the top and bottom when we watch a Marvel movie on our desktop computer or laptop.
It's not "nothing" that we lost; on a X" display with Y total pixels, the marvel movie will be larger and higher resolution on a 16:9 than it will be on a 4:3. This is true for any of the post 1960ish popular ratios for films: 15:9, 1.85, and 2.35.
Similarly, 4:3(1.33) content will use more pixels than it would on a 1.85 or 2.35 ratio screen.
Would you be so kind as to clarify on this?
> And you may have noticed we still don't have OLED on the desktop.
I am pondering one the LG CX 48" OLED display but I have no clue what are the pros and cons.
1. if you sit about 1m or more away from the monitor, it might be usable in terms of size
2. it has brightness limiters, so if you have a mostly white screen (say a fullscreen diagramming app with a white canvas) the monitor will dim by about 50% so you will need to keep some empty space around your window of the desktop image visible (unless you are in complete dark mode for the app)
3. its a glossy display, so if you have direct light behind it wont work out well
4. 4k at 48 inches, the pixel density is a bit low, and if you do scaling of the ui its quite nice but then you loose the advantages of a large monitor to have more desktop space
5. darkmode + low light is brilliant
6. oled is beautiful (wish i could get it without the gloss though)
7. you will need a good enough gpu to get 120fps at 4k (laptop + egpu or latest macbook pro might work)
8. you will need a hdmi 2.0 cable to get 120fps at 4k
9. there are only hdmi inputs
10. if you want to prevent the timed autodimming (you cannot disable dimming completely (see 1) you will need to get the factory remote to disable it
11. to prevent damage to the oled, it auto shifts the screen output by about 5 to 10 pixels every few minutes in desktop/game mode (so you might notice the mac menubar is slightly cut off, thats normal)
12. the remote is a but wonky but cool... there are no direct shortcuts to brightness controls unfortunately... ---
it will also take while to get used to it.... it took me about 2 weeks to start liking the size... (i sit about 80cm from the monitor, deep desk)
honestly, if you sit close, say 50cm or less, a 32 inch 4k display will be better (like the lg 32 inch 4k displays)
edit: my dream monitor is 8k oled at about 38 inches (not ultrawide) and not glossy... thats a few years off i guess (and also who knows if they would make that size in non-ultrawide..)
Yeah, I'm never buying a glossy display again though. You helped me make a decision.
From this end user's perspective, Google Chat is functionally no different than ICQ or MSN Messenger were 20 years ago. Notifications show up on my phone screen instead of my windows 95 screen. And now we call them emojis and there are more of them. And Google chat has more lag (~1400ms) when I open a chat window from my contacts list. All while the functionality of getting some text from myself to my friends has stayed identical (actually decreased - I can't use custom fonts/bold/etc on the modern version)
Things got a bit better when I switched off JavaScript. But yeah. The web is basically unusable on older machines. For many use cases all I want is some text, maybe some images, maybe some forms and buttons. How hard can it be to render that?
But realistically Google chat uses more ram than the PC I used MSN messenger on even HAD.
And msn was “hoggish” for the time.
How do you know the RAM usage of gchat? I agree Chrome uses more (and again it’s a completely different ballgame than it used to be) than but where are you getting the chat specific app metrics?
I don't buy that. Because you can attach bots? or make calls, custom emoji? (you can do all of these on MSN) and more (like theme customisations and font changes!)
> How do you know the RAM usage of gchat?
You can see each tab's memory usage with Safari on MacOS as it's tied into the Activity Monitor.
Google Cloud Console uses 989MB for me, for instance.
And to add on to that - these features shouldn't have any noticeable resource consumption of the kind people are complaining about. Bots shouldn't affect performance at all. The ability to make calls should have no performance impact when a call is not being made. People aren't complaining about Slack with a call being slow - they're complaining about Slack taking a long time to start up, and Slack using lots of memory and CPU just sitting there doing nothing.
That's not necessarily a good proxy. Safari, like Chrome and Firefox over-allocate far more than they need speculatively for caching & rendering purposes. There was a whole blog post on HN that completely bungled memory metrics when looking at the integrated Activity Monitor https://news.ycombinator.com/item?id=26179817
Because you can access an indexed repository of every conversation your team has had, organized by grouping, channel, digression, and participants, even if you weren't present, online, or even a member at the time. What's the MSN Messenger approach to this? Everyone join one giant group conversation window and try to keep the conversation straight, everyone send every file to every person each time, everyone keep every file you've been sent, grep through your 5 years of logs to find stuff, and hope you never need to use a different device or lose your connection? Slack provides the ability to reply to specific messages in digressionary threads, which is a key part of keeping busy channels readable in the present, let alone in the future, and the only reason many conversations can span long periods without getting lost in noise. I shudder to imagine my job relying on staying up to date with an MSN Messenger window with 44 participants.
Then there's integration with the bugtracker and support ticketing system, and Keybase, putting live-updating views from spreadsheets and the database directly into chat, drop-in/out call channels (which aren't comparable to MSN/WLM's direct calls), compatibility channels to migrate from IRC and mailing lists without losing anybody... those don't count as extra functionality? There's a reason professional teams use Slack when they never used MSN/WLM.
?? 60Hz progressive scan was fairly standard for SVGA 20 years ago; people looked for 70+Hz displays because they were bothered by the flicker (my college roommate in 2001 ran at 1024x768@75Hz rather than 1280x1024@60).
800x600@60i was the bargain-bin monitor even in the late 90s. By 2001 you could get a used 800x600@60p or 1024x768@60p monitor for nearly free if you lived anywhere that had companies upgrading to higher resolution.
Casey Muratori has been running down the insane failings of terminal emulation lately:
https://twitter.com/cmuratori/status/1405342954194051073 https://twitter.com/cmuratori/status/1405347255511486464
Chaser: https://twitter.com/cmuratori/status/1405356794495442945
This is to say nothing of the fact that VSCode is the most popular editor on the planet and that the very notion of allocating several gigs of ram to embed a web renderer ( one that is constantly having to be patched for the annual round of UAF vulnerabilities ) in order to DRAW TEXT is the very height of inefficient idiocy.
If you just want to draw text, you can simply use Notepad or Notepad++. VSCode has a lot more functionality, though.
> allocating several gigs of ram to embed a web renderer […] is the very height of inefficient idiocy.
No doubt theres bloat around, but I think you don’t understand web browser allocation strategies. Chrome, Firefox, and Safari are allocating enormous chunks of ram for both caching purposes, and rendering efficiency. It’s extremely difficult to know how much memory is really needed for any given app, you cannot make the assumption that the RAM reported for any given app or page has anything to do with how much the page itself asked for.
You also lack justification for calling memory use idiocy if you aren’t running out of memory. As long as there is free memory in the system, it’s fair game, and does not represent inefficiency.
"Going slow* is using resources. Clock cycles are a resource.
> No doubt theres bloat around, but I think you don’t understand web browser allocation strategies.
Using a web rendering engine to render a text editor is still bloated and inefficient. It doesn't matter if web browsers are intrinsically expensive - building a text editor using webtech is the incorrect design decision.
> You also lack justification for calling memory use idiocy if you aren’t running out of memory.
It should be obvious that the people here aren't complaining about applications that take a trivial amount of memory. In 2021, nobody cares about a text editor that consumes 8 MB of memory. People are complaining about applications that do take up a significant amount of memory and cause you to run out.
Mozilla's Firefox hardware report[1] says that just under 25% of Firefox users have only 4 GB of installed RAM. If running on Windows, probably half of that is consumed by the operating system. Suddenly, a 400 MB Electron app is consuming a full fifth of your available memory. That's a real problem, especially for folks that either (1) don't have much money and can't afford a newer machine or (2) want to try to conserve the environment by not spuriously buying new hardware when the old stuff should work.
> As long as there is free memory in the system, it’s fair game, and does not represent inefficiency.
Maybe by your definition of "inefficiency". Most of the people in this thread are (apparently) using it to mean "using significantly more resources to provide functionality than are intrinsically necessary". This is a much more reasonable definition given that you don't actually know how many resources the user has.
This is not true for terminals, nor in general. You can, and terminals do, go slow without consuming more clock cycles. Latency in terminal rendering, not throughput, is the main reason for them feeling slow. In other words, delays in the system are the bottleneck, not compute.
https://danluu.com/term-latency/
> People are complaining about applications that do take up a significant amount of memory and cause you to run out.
People are complaining about memory usage without understanding why it's used or what it's being used for. Nobody yet has complained about running out of memory, I haven't seen any relevant discussion about virtual memory, memory compression, nor about what browsers actually do when they run low on memory. Turns out, surprise!, browsers can fit many more tabs than you think if you had blindly assumed that the amount of memory your process manager reports will scale linearly until you run out... that's not how it works.
The problem is, people don't take responsibility for their work and almost nobody simplifies stuff. Stuff just somehow works but most of it just isn't solid or it isn't compatible or it is extremely (over)complicated. The next guy using it as a dependency has all these problems on top of the problems of his or her own with the problem at hand. This tree is multiple levels deep. Your pyramid is built on stuff that hundreds of smart engineers basically overlooked/ ignored for decades. Meltdown and friends is just one example, there are HW bugs, there are management engines, there is the OS, the libraries, other software/ daemons/ services, bad APIs, old APIs, deprecated APIs, functionality split between old and new API, bug ridden runtime, inconsistent behaviours of a markup language processing and styling implementation etc. pp.
We all need to get our act together and the harsh reality is, most of us just don't know everything and there isn't time to know everything. We need basic stuff to really just work and be as simple as possible given the problem domain, else we will not progress without gigantic investments.
Right as I type this, gnome-terminal has 68MB allocated, of which 57MB is resident. My scrollback buffers are limited to 4096 lines and I have 7 tabs open, four of which are sitting on a bash prompt doing nothing. By ANY measure, this is absolutely insane.
> you don’t understand web browser allocation strategies
You may have missed my point. Rendering TEXT with a library intended to render gmail.com and facebook.com is a ludicrous extravagance.
> As long as there is free memory in the system, it’s fair game
This is my favorite argument. Just buy more ram, bro. CPUs are super smart bro, caches are magical and you'll always get a hit no matter how much you allocate or how fragmented your heap gets. YOLO.
Building software as if DDR4 is just as close to the ALU as L2, that our L2 is fully-associative, that branch prediction and cache hits on vtable dispatch is perfect, then spraying huge numbers of small objects all over the heap, and declaring that all you need to do is buy more RAM, and that halting your application for 6 MMU wait states every dozen cycles is perfectly acceptable.
Yes, waiting 20 billion cycles on an amdahl-adjusted basis to move a scrollbar is definitely the future.
Why? Is it using CPU while doing nothing? Scrollback might need at least 4096 lines * 7 tabs * 80 unicode chars =~ 5MB, conservatively. You have 7 child shell environments, and perhaps 7 large bitmaps cached for fast scrolling (I don't know what gnome-terminal caches for rendering, just guessing about what's possible). Plus the program code, the UI code, the terminal fonts. You haven't really explained why 60MB seems like too much to you, let alone "insane". It seems like you're just not accounting for all the features.
> Rendering TEXT with a library intended to render gmail.com and facebook.com is a ludicrous extravagance.
Why? Isn't it possible if the text rendering library were customized and smaller, that it would then consume more memory because it would be a 2nd library can't be shared with your HTML+CSS renderer, and you need those loaded too anyway?
The whole reason the library is big is because it does a lot of things. What reason is there for small/simple uses to not use a library that's already there?
> Yes, waiting 20 billion cycles on an amdahl-adjusted basis to move a scrollbar is definitely the future.
Your scrollbar takes multiple seconds to respond? Mine doesn't.
Your hyperbole notwithstanding, the reasons that browsers speculatively over-allocate is for caching - it is precisely because it's more efficient and performant that way. I didn't write Chrome, but I don't think what they've done is insane.
Here is one concrete example: visual studio startup and debugging. Source: https://youtu.be/GC-0tCy4P1U
Maybe I could start collecting examples. I never did because it is so obvious. I mean, have you never updated android/iOS/windows on the same hardware?
Regarding the "exactly" part in you sentence. Why would more features equal less performance? The only possible reason I can see this happening, is if you have features that run in parallel. Otherwise it's just another callback/if etc. That is, something to be triggered by the user that should have imperceptible impact (slightly more pressure on the instruction cache) on the performance of other features.
Certainly there are reasons why a feature might slow down a system beyond the branching (for example, if it requires you to load other resources)... but really, the issue is that as pointed out in the youtube video. Software companies very frequently do not care about performance.
"More features" can include things that were not feasible in the '90s. Things that inherently consume more resources.
Icons/images are a simple example.
Of course good software can get plenty done with 16x16 images. Good software may get all that done and more with access to more memory for higher resolution images and more CPU cycles for image manipulation.
Wait, really? Are you serious? Adding features historically is - by far - the single biggest cause of bloat and losing perf on a given fixed hardware configuration. I have no idea why you’re suggesting that unnamed “features” are “just another callback/if”. What features are you talking about, why are you assuming how they’re implemented?
I don’t think Visual Studio is representative of most software, nor a reasonable demonstration of your argument above against clean code practices. That said, I’ve been using Visual Studio for 20 years, and in my experience it’s significantly faster now to start up than it used to be. The functionality has also changed, so it’s not an example of functionality staying the same while resource usage increases.
It should be pretty obvious that many features should have no perceptible performance impact if they're not actively being used.
> Adding features historically is - by far - the single biggest cause of bloat and losing perf on a given fixed hardware configuration.
If by "bloat" you mean binary size - nobody is complaining about that. If by "bloat" you mean idle CPU, UI latency, startup time - that's an engineering failure.
> I have no idea why you’re suggesting that unnamed “features” are “just another callback/if”.
Because that's true. Most features literally have no reason to use CPU if they're not being used. If Spotify adds a new "double-shuffle playlist" option, there is no valid reason that feature should use any CPU except when it's actually being used to shuffle things.
> What features are you talking about,
Most features? Take almost any program, start enumerating the features, and then start partitioning them by what resources they consume while not in use. Let's see, Google Chrome, downloads tracker. Is there a good reason for it to use CPU while you're not clicking a download link? Nope.
> why are you assuming how they’re implemented?
This entire thing is about bad implementations. If a particular implementation of a computationally cheap thing is inefficient, then that's a bad implementation, and it should be rewritten. Nobody is complaining that ML models take a long time to train, or that videos take a lot of CPU to be transcoded, because everyone knows that those things are intrinsically computationally expensive, regardless of how you implement them (although obviously the difference between a good and bad implementation can still shave off massive amounts of time and space).
> It should be pretty obvious that many features should have no perceptible performance impact if they're not actively being used.
That's true, and irrelevant. It's also true that feature bloat is the number one cause of software slowing down. It doesn't have to be all or most features, it's still a fact.
I've lost track of your point. Software is bigger? I agree. Some software is bloated and uses resources it doesn't really need? I agree. You're arguing with everything I say, but don't seem to be trying to have a conversation or to understand or give any benefit of the doubt. Some of the things you're saying are true, I may not be disagreeing with you, a lot of this is just not relevant to either my points or the comments I replied to.
> Google Chrome, downloads tracker. Is there a good reason for it to use CPU while you're not clicking a download link? Nope.
Did you mean to include during downloads to refresh the page, or during scrolling and interaction with the page? I don't understand your example, have you seen the tracker consuming copious CPU? Does this example support your argument about engineering failures somehow? I opened my Chrome task manager just now and my downloads tracker is consuming exactly 0 cycles. Have you seen Spotify shuffle consuming CPU? If not, why did you bring it up?
> Most features literally have no reason to use CPU if they're not being used.
This is completely meaningless, until you name all features and all software, and define what "feature" means in all cases. You have no basis here to make any claims about "most features" of software.
Many features do have reasons to use resources. Caching is a feature that always uses memory when not in use, and caching is absolutely ubiquitous. Rendering is a feature that uses CPU even when the user isn't asking for anything. Speculative downloads, background processes, pre-computation, event driven callbacks, timers... the list of things ("features") your OS and browsers and applications intentionally do when you're not looking is very, very long. Claiming otherwise only demonstrates ignorance of what's under the hood. Naming a couple of cherry-picked features that don't use a lot of resources is not particularly compelling.
I am presuming to speak for nobody except myself, by responding to your arguments.
> The argument at the top of the thread was that good implementations are to blame for perf decay.
I don't see that anywhere in the thread. If, by "good implementations", you mean "scalability, portability and clean code" - then you're wrong, because implementations that are highly inefficient are not "good", regardless if they're any of those other things too.
>> It should be pretty obvious that many features should have no perceptible performance impact if they're not actively being used.
> That's true, and irrelevant.
It's completely relevant, because the topic is "performance", and your argument is that the performance losses are caused by added features.
> It's also true that feature bloat is the number one cause of software slowing down. It doesn't have to be all or most features, it's still a fact.
...a claim which is so vague as to be unprovable, and for which you have provided absolutely no evidence whatsoever - so, no, it's not "still a fact".
Meanwhile, I can make any number of arguments from first principles as to why there's no good engineering reason why many of the added features of modern-day programs should cause the massive increase in used resources over their older equivalents.
I'm willing to bet that you cannot point out more than two or three features in Discord, Spotify, Teams, Atom, Slack, or other similarly bloated applications that actually necessitate their ridiculous resource consumption. As in, O(n) for space and time use. (hint: none of these programs are solving the traveling salesman problem)
> I've lost track of your point. Software is bigger? I agree. Some software is bloated and uses resources it doesn't really need? I agree.
Perhaps I should have stated my point more clearly: the main reason that modern programs are inefficient is because they're implemented with inefficient technologies, most relevantly Electron (and webtech more generally), and not because the added features that they bring are intrinsically computationally expensive.
> You're arguing with everything I say, but don't seem to be trying to have a conversation or to understand or give any benefit of the doubt.
A "debate" is different than a "conversation", and this isn't surprising. I'm not trying to have a conversation, I'm trying to debate points that you're making. Not everything can or should be a "conversation". Moreover, there's no "benefit of the doubt" to give - I'm not assuming that you're being malicious, I'm just asking for actual empirical evidence and/or argument from first principles - neither of which you're giving.
> Does this example support your argument about engineering failures somehow? I opened my Chrome task manager just now and my downloads tracker is consuming exactly 0 cycles. Have you seen Spotify shuffle consuming CPU? If not, why did you bring it up?
It should be pretty obvious that I brought those examples up to illustrate examples of features that should not use resources while not actively being used.
> Many features do have reasons to use resources. Caching is a feature that always uses memory when not in use, and caching is absolutely ubiquitous. Rendering is a feature that uses CPU even when the user isn't asking for anything. Speculative downloads, background processes, pre-computation, event driven callbacks, timers... the list of things ("features") your OS and browsers and applications intentionally do when you're not looking is very, very long.
None of these are "features" - these are all implementation details. A "feature" is the downloads page in Chrome, or the shuffle feature in Spotify.
> Naming a couple of cherry-picked features that don't use a lot of resources is not particularly compelling.
You haven't been able to name a single actual feature that has a technically valid reason to use significant resources simply by being added to a host program, let alone one that's relevant to the highly-inefficient applications that everyone throws around (Discord, Spotify, Teams, Atom, Slack). My features, while individual examples, are miles better than the literal nothing that you have provided.
And, for emphasis: I'm willing to bet that you cannot point out more than two or three features in Discord, Spotify, Teams, Atom, Slack, or other similarly bloated applications that actually necessitate their ridiculous resource consumption. As in, with big-O notation for space and time use. (hint: none of these programs are solving the traveling salesman problem)
I can tell, please consider relaxing a little. I appreciate the time you put into responding to me, but FWIW your extra long reply is almost completely straw man from my point of view, and getting unnecessarily aggressive and hyperbolic now. I don’t need to debate this, because you’re not actually addressing my points, because you haven’t actually understood what I’ve said, because you’re trying so hard to debate. This conversation wouldn’t have gone down like this face to face, and as engineers there’s a pretty good change we’d agree. Good luck, TTFN.
Everything that uses NVIDIA drivers on Linux, e.g. through OpenGL. Just bringing up an empty window takes over a second these days, while it was <200ms just a few years ago, even with spinning metal disks instead of SSDs.
That said, I think in the last very few years it's turned around a bit, mainly due to SSDs. In my experience most times that software is painfully slow (in any era) it's because you have too many things open and you're swapping. And SSDs provide acceptable speed even when swapping.
In other words, I find modern machines to be roughly as slow as ~2005, but only up to the very recent years when SSDs have become the norm. Now I'm starting to finally feel things being faster overall.
But, back then, getting the "desktop context menu" up too approximately no perceivable time, whereas these days I notice time passing. I don't think that is because my reflexes have improved massively in the last 20 years.
Maybe the question to ask is how much of this is to the benefit of the end user versus building ever more sophisticated adtech.
This is irrelevant, as it's extremely difficult to find any two pieces of software that are "functionally the same", regardless of their age of release or performance - and, moreover, because we're programmers, we can make informed estimates about the minimum performance impact of most features without just guessing.
For instance, string localization should have no perceptible performance impact - it's literally just a key-value lookup (O(1) with a hash table). The additional features that Spotify provides over Audacious (a local Linux music player) are either not intrinsically computationally expensive (fetching audio over a network) or are done server-side (playlist recommendation). Discord has no technically valid reason to be taking up 15% of a CPU core while sitting in the background. And so on.
> Today 4K is normal, and combined with refresh rates and colors, we’re pushing upwards of 2 orders of magnitude more data to our screens.
We have GPUs that now do all of our graphics rendering work for us. The features implemented by Spotify, Slack, Discord, and Visual Studio Code do not intrinsically require enough graphical resources that they should stress even an older integrated GPU, let alone take 5 seconds to start up on CPU and RAM that are, similarly, one to two decimal orders of magnitude faster than what we had two decades ago.
> YouTube and Netflix didn’t exist 20 years ago. Browsers were incredibly slow and couldn’t support streaming video or anything but the smallest of applications written in JavaScript. Localization didn’t exist, web analytics wasn’t really a thing, browsers didn’t run background tasks.
None of this is relevant to applications. Browsers were slow back then? Fine. Browsers are faster now? Also fine. That's still irrelevant to the fact that many applications are slower now, on much faster hardware, than they were then.
Yes, indeed. You're illustrating is why the post I replied to is a straw man argument. Most software, as you say, is not functionally the same anymore.
> string localization should have no perceptible performance impact
Yes, my argument was that we got localization without a noticeable perf impact. But it does consume memory, bandwidth and code size, and as you correctly point out, a small amount of compute. I would venture to suggest that rendering Asian fonts is a tad more involved than an O(1) hash table lookup. Localization is just one of hundreds of features we have standard now that we didn't have 20 years ago.
Operating systems, particularly Windows. Given fixed hardware, you cannot expect an operating system to continue working indefinitely.
They all run processes, do they not?
Instant messaging. Even if we ignore applications like the original MSN Messenger, Trillian, etc, the original Skype before Microsoft's acquisition was much faster. Sure, it wasn't as fast as it could be - but still didn't had an entire browser wrapped around it nor needed checks 350MB of RAM and 7 background processes just to display an icon on the tray so i can send text messages and perhaps the occasional video call once every two years.
And to be honest? I do not really find it that weird if a program needed some extra resources to make a video call - which is why LoadLibrary and (especially) FreeLibrary exist. But in practice that is never done or when it is done it is piled on top of an overengineered system to the point where it loses any benefits under the weight of the architecture astromancy.
> if you don’t know or don’t pay attention what’s under the covers.
Or don't care.
Don't forget the don't care part! It is very important because a lot of the bloat is presented as "functionality" (which, assuming most people even care - and that assuming they'd know what they "pay" for it - often doesn't even need to be as heavy and bloated as it is).
> One easy to overlook difference is displays.
Aside from resolution, physical dimensions and thinness, displays are worse nowadays. Compared to CRTs they have bad contrast, often bad colors, increased latency (even the ultra-fast 144Hz+ ones), a fixed resolution with awful results if you try to use anything but the native, etc. Note that i'm writing this from a 165Hz 27" 2560x1440 monitor BTW with a few CRTs next to me connected on older systems. And BTW
> It’s easy to forget that 20 years ago we had 800x600 screens, 24 bit color was not ubiquitous, and 60hz monitors were practically non-existent.
That'd be 30 years ago, not 20. 20 years ago was the year 2001 :-P. While 800x600 was indeed common, it was pretty much as common as 1024x768. And monitors at 60Hz were not common because those would hurt your eyes - even standard VGA released in the 80s runs at 70Hz. But by 2001 pretty much every monitor was able of 85Hz and several went much higher (e.g. 120Hz for mine).
> Today 4K is normal
4K is a tiny minority that is barely a blip in statistics. Here, check this:
https://data.firefox.com/dashboard/hardware
This is Firefox's hardware statistics. The most common resolution, by far, is 1920x1080. The next most common? 1366x768! Both make about 64% of every web capable computer out there! And the resolutions after that are actually lower than 1920x1080 until you reach at around 2% for 2560x1440.
Even among games where 4K has meme status, in Steam Hardware Survey you can see that only around 2.44% have a 4K monitor. There are more than three times more gamers using monitors less than 1080p that aren't 1366x768 or 1360x768!
There will be several years before 4K becomes a normal on the desktop. Right now it makes way more sense to think about something like 1366x768 than 4K.
The situation today is vastly better than in the days of IE6.
> A world where clean code destroys performance
Clean code does not mean code that is not performant.
In my mind, "clean code" is foremost small methods that do one thing, and are well-described. These small methods will often be optimised away, in the unlikely situation where they were the bottleneck in the first place.
In my experience messy code "for performance" reasons was usually code that had claims to being "fast", but was often incorrect and hard to fix.
In Android land for example, there is a popular "clean" 3 layer architecture, where model classes are blindly mapped multiple times (even in cases where this is suboptimal).
I have lost count of people building "clean" inefficient caching mechanism instead of just using an HTTP cache.
Side note:
I believe these things are useful in some situations. Maybe the solution is to have a smart compiler that compiles out these inefficiencies?
Some (most?) apps are just skins around a database. Amazing what Facebook did with Messenger rewrite [0]
Is there an incentive problem? Generally, people get bonuses/accolades for making a slow system fast, not for keeping a system consistently fast. I admit the former is easier to measure.
0 - https://engineering.fb.com/2020/03/02/data-infrastructure/me...
Assuming you are referring to “pure”, in the context of functional programming and isolation of side effects.
Allow me to quote me, to clarify this part, then.
"when [they aren't] a great fit for the host language"
However "clean code" connotes to me the techniques advocated in "Clean Code" by Robert C. Martin, which amongst other things, advocates small descriptive functions.
Compilers are software. A "smarter" compiler is probably going to consume more resources.
I would argue that in most cases the choice is not between fast, optimized and slow, unoptimized software. The choice is between having a functioning program (using a universal, "reasonably" efficient stack) and not having one at all (because the amount of resources it takes to develop a customized, low-level implementation is prohibitively high).
A good example: https://www.youtube.com/watch?v=tInaI3pU19Y A custom 3D engine performs immensely better than a comparable Unity project, but it took the author 3 to 4 times the effort.
I don't see it having anything to do with scalability, portability, or clean code.
It's just cheap and (for the developers) convenient. Developers think that their software is a gift to the world, and simply getting it made (not matter how cheaply and craply and user-hostilely) is a net positive. (I wonder how many people use all these bloated things only because they pretty much have to, due to peer pressure, company requirements, etc.)
It is possible to make software that scales, is clean, portable, and doesn't rely on massive bloat.
Of course a JIT compiler will never be as performant as precompiled binaries, especially when its running in a full featured web browser that is packing functions that the developer neither needs nor is using.
Even GTK is cross platform!
That's the key phrase, and it means easy way for front end web devs, those who have forced the entire toolchain to dance to Javascript's tune because everything would be easier if we had one language to rule them all.
Even Zig has Qt bindings[1] and that's still enough of a hot young thing to regularly reach HN's front page, so it's likely that other popular languages that are older have bindings, no need to devolve to using something JS devs crave. There's wxWidgets[2] or Shoes (I loved using Shoes, thanks _why!) and many more[3].
[1] https://wiki.qt.io/Language_Bindings
[2] https://en.wikipedia.org/wiki/List_of_language_bindings_for_...
People talk about electron being 'the only way to create cross platform apps' and ignore fltk, juce, qt, gtk, wxWidgets, tk and a whole host of other solutions, not to mention making a local webserver, opengl guis etc.
When someone only knows javascript they might want to work with electron, but no one who is going to use that software wishes it was made in electron. That's the bottom line, people don't want it, it is a selfish decision that creates terrible interactivity and grossly bloated software.
Not browsers, not photo editors, not games, not many chat applications. Certainly there must be some big ones that do right?
The dozen cross platform libraries that have been around for multiple decades are all 100 times faster than the electron, that's the point.
Obviously none of them include the Web as a platform (unless you count Java applets, which you shouldn't since they're basically dead, even if they'd seem high-performance and quite nice compared to what we've replaced them with).
If you're defining "cross platform" as, strictly, "the Web", then I'm not really sure what kind of exchange you're trying to have or what you're trying to add, here. Obviously only the web satisfies the criterion of being the web. Which makes me wonder even more why you didn't find that obvious.
"Well, no, we've had that for a long time, especially if you consider the performance compromises of Electron or in-browser 'apps' to exist within the acceptable range. Electron does make mimicking this year's UI trends as easy on the desktop as on the Web, and doing so on every platform at once, and that was hard before."
"Right, but do those earlier solutions support the web as a platform?"
"... huh?"
See why I'm confused about where you're taking this? It's like someone claimed that airplanes were the only way to travel by machine, and I pointed out that, for one thing, trains existed before that, and now you're asking me if trains can fly. No—and, again, obviously so unless we've got some seriously different life experience, here—but that's... a complete non-sequitur to the conversation already in progress.
The first thing is using web technology to build apps that are distributed as native apps on many platforms (which works because there are open source web browser engines that already support most computer platforms). This is what Electron is.
The second thing is for any cross-platform framework to support targeting the web, because the web is itself a very huge platform. This is important, because not all platforms and situations support installing native apps. If you want your cross-platform app to work on web browsers, you need your cross-platform app to support targeting the web. This might be important if you want your app to work in computer labs, for example.
Seems to me the desire for having "web" as a platform isn't so you can also support a browser application. Its so you can make it a web app and call the job done.
Even if not prioritizing cross-platform, Electron has some serious appeal.
What are my alternatives? Qt? Gtk? Native libraries?
I wrote a bunch of GTK desktop apps with Python like 15 years ago and they were snappy and you'd never even know it was Python behind it, but I wouldn't do that now. Too hard to distribute, bindings a bit clunky, lots more cross-platform testing, it's hard to look at the relative levels of effort and not take the faster path.
I put application in parentheses because other paradigms may make sense for high performance rendering pipes like games.
Honestly I don't think HTML5/CSS/JS is that bad as a pure presentation layer. It has warts as they all do, but it can be made to look decent and is fairly productive. The bloat is mostly the fault of Electron specifically. Tauri and Sciter are much leaner, in some cases leaner than Qt depending on the app.
I don't know what the development side is like, but as a user I do find Qt apps to be fairly nice.
I also think Java (Swing) apps are basically fine. Java was "bloated" back in the day, but not relative to what else is in use today.
Qt development can be excellent or nightmarish, sometimes both. I don't know enough to know why the disparity but I've been adjacent to teams that love qt and ones that loathe it. I'm guessing a big aspect is state management; qt predates the reactive revolution, and IIRC is prone (as is any gui) to callback hell.
Yes. You are not a Javascript Programmer, or a Frontend Programmer; Choose the right tool for each job.
I don't think scalability, portability, and clean code are the enemy.
C/C++ are as portable as they ever were, and Java/.NET provide higher-level abstractions that work across both Windows and *nix systems. Even Electron doesn't have to suck, in theory.
The reason performance is bad these days is because developers are just bad. The number of developers doubles every five years. Ergo, half of all developers have less than five years of experience. The vast majority of them don't have a CS, CE, or EE degree. A large number of them went through bootcamps (which are an expensive version of the old "Learn VB in 21 Days!" books.) And they're all writing the Electron apps we love to hate.
That said, I'm in agreement that most devs don't know much at all about performance. Frankly, we're told not to... it's a sad state. Performance is explicitly referred to as a last priority, the "optimization is the root of all evil" quote is completely taken out of context and parroted everywhere (go look up Knuth/Hoare's context if you haven't), etc.
All that is to say, the issue is not specific to education but is an unfortunate part of engineering culture. We, as a large group, explicitly neglect performance and treat it as a dirty word.
IMO we need a sort of performance revolution the way testing got one. I've written lots of software in a 'benchmark driven' way, and the results are extremely fast programs - I've gotten programs down from just under 1ms to a few dozen nanoseconds like that.
All of these three - when interpreted reasonably - coincide and even constitute performance improvements:
* You make less assumptions, including regarding the speed of things, when you make your code portable.
* When your code is clean, it's easier to generalize speed benefits rather than when you need to apply some ugly spaghetti hand-written optimization in 20 places.
* Scalability means scaling up, out but also _down_ from the machine you're currently using. How else would you run your, say, distributed search web app on, say, a cluster of RPi 0's?
... Of course, if your approach to scalability and portability is to stick things in a container or vm, and manage a fleet of those, then yeah, that's kind of a problem.
A world where software can barely fit in a single machine and can only scale up. In many cases, this software doesn't even do anything that is functionally different from 10 or 20 years ago, but it still consumes many more resources.
A world where some websites still don't work properly across web browsers. Electron apps which should enable easier cross platform applications, don't (e.g. Microsoft Teams doesn't have feature or even UI parity in windows and linux).
A world where clean code destroys performance, because the time of developers must be paid for by the company, but the costs of resource wastage are externalized. And there isn't even any evidence that these practices actually help to do what they are supposed to do!