You can not really turn telemetry off, maybe your apps just keep working against you, collecting the info to send after the next system update which use to enable all "disabled" telemetry features.
If anything, doesn't this demonstrate that Windows lacks a sufficient amount of telemetry? If it was sending home stats about how long it takes to draw these windows, and profiles of what the program was doing, then they could target those and make it faster.
I see you're operating under the assumption that the purpose of telemetry is to improve the user experience. I'm not sure that is even a business goal inside Microsoft.
I think due to perverse incentives it causes the exact opposite to happen. Why did the Windows calculator need to be remade with a much slower and less responsive version? Telemetry probably showed the calculator was frequently used, so a Project Manager targeted it for "improvement" and it was then ruined.
I don't know since I never use the Windows Calculator but it seems probable to me that the newer version has improvements that you don't need and therefore do not perceive. Perhaps it is more accessible to the blind, or the support for Urdu numerals is new. A lot of the reasons why old versions of Windows ran apps instantly is that they excluded the entire non-European world and did not even attempt to deal with complex languages.
>A lot of the reasons why old versions of Windows ran apps instantly is that they excluded the entire non-European world and did not even attempt to deal with complex languages.
Yes the western versions of Windows at the time didn't include support for Chinese (etc.) language. But there is really no reason why they should - if the user's language can be represented in an 8 bit codepage, why should they have to pay any price in performance for something they will never use?
Conversely, would a Chinese-speaking user prefer an operating system designed to support all the other languages that exist, with an implementation that is likely not as specifically tailored to their requirements?
Every developer for the past two decades has been banking on Moore to save them from the consequences of poorly written code and importing a boatload of 3rd party dependencies but Moore is running out of funds and the bill is coming due.
I think you can add a couple of decades to that statement. People were already complaining about poor C code, when you could write "proper" performant code in assembler...
I think a lot of that could be brought back to something closer to resembling immediacy if you go and take the time to remove all the stuff they introduced along with vista (The fadein/fadeout animations especially)
no, no, and no. Lets see if we can petition Microsoft to add them, and then we'll see if Win2000 still runs decently fast on a P4 with 4gb of ram.
My guess is: yes, it will.
Somehow, in the past 15 years, "progress" seems to include "software keeps getting noticeably worse, but anyone pointing this out has to be shot down because progress."
Ah, there's another question, I'm running 32GB of RAM currently on this machine and 64GB at home. How well does Windows 2000 support >4GB RAM or SMP? Does it come with a good hypervisor? I do like running a lot of VMs in Hyper-V as well.
Sure sounds like there's a ton of gaps in things I really want out of my operating system on Windows 2000...
Does the switch to 64 bit slow things down enough to explain what happened between Windows 2000 and XP?
Does the operating system have to support virtual machines? Seems easy enough to install vmware then run operating systems inside it for most use cases.
I mean, you can keep 'what if'ing me here, but, is it really worth having all the features that you, clearly as a power user or professional, use installed on every computer everywhere? No. No it really doesn't. It's bloat.
> Seems easy enough to install vmware then run operating systems inside it for most use cases.
That's a way different experience than running Hyper-V.
> is it really worth having all the features that you, clearly as a power user or professional, use installed on every computer everywhere? No. No it really doesn't. It's bloat.
I also didn't realize that managing WiFi networks or using display scaling are things only power users and professionals would want on their machines. I guess supporting Bluetooth natively in the OS and a modern sound stack is just bloat for most people.
so, I can't reply to your latest message because it's too far down but...
Let me just hop on my wifi and browse the web. Lets do it on a computer from 1999. 2000. 2001. 2002. 2003. 2004. 2005. 2006. 2007. 2008... etc, etc.
Why is it that every couple years from 2012 onwards, doing the same thing keeps taking longer, even with new hardware, without the same revolutions in quality and experience that came with that new software previously?
...
you completely missed the relevant part with the "1999" part. The relevant part is the "2012" part.
Things used to get better, do more, and faster.
The last 15 years, the "do more" part has been less and less useful, and the "faster" part has turned into "slower" in a number of ways.
Software engineers are relying on an increase in hardware performance to pick up their slack, and that line is running out quickly, and there will be many years ahead where we're cleaning up over a decade of laziness.
I bought a newer PC because my older one from 2012 legit wasn't fast enough for what I wanted to do. It couldn't handle the VR applications I wanted to run, as its PCIe and RAM performance just wouldn't be up to the task to run the resolutions, texture qualities, and latencies I wanted. The newer one is miles ahead of the older hardware, and the applications I use are significantly better because of it.
But even then, from the other perspective of continuing to run similar-ish workloads using newer software, a lot of the other things continue to run the same experience-wise with slightly better features than when the software was new. When I first built that 2012 machine I installed the then brand-new Windows 8 on it. These days its running Windows 10. From a UX perspective it definitely feels faster than the OS it shipped with. Things like the new Terminal app are way better functionally than the old cmd.exe that used to be on it. I do demand more still from using VSCode with more plugins and what not than before while previously I used things like PyCharm more. I videochat, watch more streaming content on it than when I first had it, and it consumes far more animated GIFs and what not than it used to.
But in the end even with software supposedly getting more bloated and what not, its at least as snappy if not more than it was when it was brand new in 2012, other than the fact there's a whole new class of application I demand from my hardware.
So yeah, even today things are still getting better, doing more, and getting faster. Its not the extreme doubling or quadrupling of stuff like the 80s and 90s where things literally went from only text interfaces to GUIs to 3D apps, but there's still bleeding edge stuff that legit just takes more oomph than a box from 2012.
There's been a problem of lateral rather than forward progress in nearly all industries since the early 2000s. Lateral progress being a different way to do the same exact thing (a doorknob versus a lever latch for example), and forward progress being a new way to do a similar thing but in a much more efficient and modular way.
It's been bothering me for some time ever since I noticed it with the advent of IoT "smart" devices that have the same features as traditional appliances for twice the cost and technical debt. My washing machine still washes clothes and turns itself off, but now I need to set the wash type using my phone because lateral progress dictates a physical interface on the device itself is obsolete.
It blows my mind how unresponsive modern tech is, and it frustrates me constantly. What makes it even worse is how unpredictable the lags are so you can't even train yourself around it.
I was watching Halt and Catch Fire and in the first season the engineering team makes a great effort to meet something called the "Doherty Threshold" to keep the responsiveness of the machine so the user doesn't get frustrated and lose interest. I guess that is lost to time!
Even worse is the new trend of web pages optimizing for page load time. You wind up with a page that loads "instantly" but has almost none of the data you need displayed. Instead there are 2 or 3 AJAX requests to load the data & populate the DOM. Each one results in a repaint, wasting CPU and causing the page content to move around.
There was a small accordion in some Google search results that opened around ~1 second after the results page was loaded and I think it was the most infuriating thing ever. And we are talking about Google here.
Worse, sometimes the people who do it are completely unaware they are making a dark pattern, because they see the result of A/B test and convince themselves it's superior to what they think.
The ultimate version of this was done by Optimizely some years ago, where - let's assume here unintentional - bad UI design encouraged people to terminate their A/B tests early when the metrics favored the new version, leading to people without good understanding of statistics implementing dark patterns (or just stupid patterns), blissfully unaware that they've biased their own A/B tests so strongly that they could just as well be replaced by a piece of paper with words "NEW THING WORKS BETTER" written on it.
A/B testing is so gross. In other domains human experimentation of any kind, no matter how low risk, involves getting fully informed consent and ethics board approval before going ahead.
Experimental behavior manipulation, without even telling the subject they are part of a manipulation experiment? You would be chased out of the room and your reputation destroyed! Utterly unacceptable. But in webdev universe this is somehow seen as a totally normal practice.
This is exactly how users felt when Reddit ran A/B testing on their "feature" that forcibly signed out people on mobile browsers and said they needed to use the Reddit app to sign back in. I saw a crazy long thread of straight backlash about how messed up it was and how they aren't cattle to experiment on and how they didn't consent to that (which they prolly did in the T&C but no one reads that and actually understands what they're agreeing to).
Seeing as they were posting the backlash on Reddit, I'm guessing a lot of people downloaded the app to log in and Reddit said "Big Success!" when they checked the stats.
> which they prolly did in the T&C but no one reads that and actually understands what they're agreeing to
The GDPR's notion of informed consent really needs to be applied pervasively to all kinds of consumer contracts. If it's hidden in walls of text that the average user doesn't read it shouldn't count as consent.
I really could see Apple adopting an approach from FPS games, where the phone applies a click to what was under your finger 1/4 second-ish instead of what's there when the click is recognized. Time-travel clicking.
My guess for this is that the average user doesn't parse text on pages as fast as more tech-savvy users. That delay is perfectly timed for the average user to grab their attention.
For me, I use google so often that I can rapidly parse information without really needing to read much of the text, the link just sort of 'looks' right. I've observed my wife reading google results and she is much slower and more methodical, probably because she doesn't google things 20+ times a day every day like I do.
That's how I end up misclicking, because i'm not working at the speed of a normal googler.
It is really annoying though, there are some css tweaks you can make using browser extensions to make that disappear if you're so inclined.
Their new AI shit on the top of the sesrch results does this. It's slow AF and I'll sometimes have scrolled partway down the page before it farts a huge blob of text up top and pushes stuff I've already scrolled past back down past my finger.
This drives me crazy, especially because it breaks finding within a page. Eg. if you order food and you already know what you want.
Old days: Cmd + f, type what you want.
New days: first scroll to the end of the page so that all the contents are actually loaded. Cmd + f, type what you want.
Is just a list of dishes, some with small thumbnails, some without any images at all. If you can't load a page with 30 dishes fast enough, you have a serious problem (you could always lazily load the thumbnails if you want to cheat).
Firefox allows you to use / to start a conventional search.
As a bonus, in Firefox if you hit the ' key (apostrophe) you get a search that looks only within hyperlinks and ignores all the un-clickable plain text. Give it a try, sometimes it can be very useful
> New days: first scroll to the end of the page so that all the contents are actually loaded. Cmd + f, type what you want.
Only to discover that 2/3 of the matches are invisible text that's put there for $deity knows what reason, and the rest only gives you the subset of what you want, as the UI truncates the list of ingredients/toppings and you need to click or hover over it to see it in full.
Nothing to do with React, it's a common optimization to improve performance with long lists. You only render the dom elements in the viewport, with some buffer. A common technique to achieve that is called "virtualization" or "windowing".
It's common enough that there were a couple browser proposals to deal with this and would address the Ctrl+F issue. I believe this has been merged into the CSS Containment spec, but at the moment it doesn't make windowing obsolete in every situation.
It's not even a technique limited to browsers. When I did Android development years ago it was a technique used in native list controls to reduce the overhead of them. Though in that case, there's no search based on what's been rendered like a web browser has. And of course if you did implement search, you could have that look at the underlying data, so it doesn't matter if it's been rendered.
But Web browsers already don't render off screen content right? I'm pretty sure I remember opening hundreds of megs of data in Firefox at one point without an issue. Or old reddit with RES has infinite scroll and you can go dozens of pages deep without a hitch. All while not lazily rendering the other pages.
Someone should invent a way for a web server to return a representation of the text, complete with styling and formatting that the browser can use to render it.
Well, the tech stack is insane: Some virtual machine running a web browser process running a virtual machine for a html renderer which consumes a document declaration language incorporating a scripting language to overcome the document limitations trying to build interactive programs.
Actually much worse as Microsoft once did with their COM model, ActiveX based on MFC foundation classes with C++ templates, etc.
And to build those interactive programs somebody is trained to use React, Vue, etc. using their own eco systems of tools. This is operated by a stack of build tools, a stack of distribution tools, kubernetes for hosting and AWS for managing that whole damn thing.
Oh - and do not talk even about Dependency Management, Monitoring, Microservices, Authorization and so on...
But I really wonder - what would be more complex?
Building interactive programs based on HTML or Logo (if anybody does remember)?
And don't forget the UX designers armed with their figmas and alikes. The tech-stack is only one among a number of organizational and cultural issues crippling the field.
Notice that in this sub-topic we're talking more generally about causes for low-quality software -- laggy UIs being only one of the symptoms.
Figma contributes by enabling UI designers to easily author interfaces which look allegedly beautiful but are complex to build, test and maintain.
And the resources burned on building such esthetically pleasant piles of barely usable software could find better use on making it simpler, faster and more focused on user actual functional and non-functional requirements (much of them taking place on the server-side) instead of sugaring their eyes by throwing tons of code on their clients
On one project, I actually shifted quite recently from working on old-school, pre-Windows XP, DCOM-based protocols, to interfacing with REST APIs. Let me tell you this: compared to OpenAPI tooling, DCOM is a paradise.
I have no first clue how anyone does anything with OpenAPI. Just about every tool I tried to turn OpenAPI specs into C or C++ code, or documentation, is horribly broken. And this isn't me "holding it wrong" - in each case, I found GitHub issues about those same failures, submitted months or years ago, and still open, on supposedly widely-used and actively maintained projects...
I too was once very excited that OpenAPI specs I had access to would save me untold hours in implementing an API for a service since I could pass them through a generator, only to find once I tried everything seemed somewhat broken or the important time saving bits just weren't quite ready yet.
In some ways COM is pretty optimized. An intra-thread COM call is just a virtual function call - no extra overhead. Otherwise it's a virtual function call to a proxy function that knows exactly how to serialize the parameters for IPC.
>An intra-thread COM call is just a virtual function call - no extra overhead.
There was a time when a virtual function call was a lot of overhead
Even having a VMT is overhead.
Sometimes the COM interface is implemented as actual interface, where the implementing class is derived from another class and the interface. (in C++ the interface is just another class with multiple inheritance, but other languages have designed interfaces). Then the class even needs to have two VMTs.
Multiple VMTs have even more overhead. And with multiple VMTs, it is not just a method call. In the functions, this always points to the first VMT. But when a function from the VMT is called, the pointer points to that VMT. So the compiler creates a wrapper function, that adjusts this and calls the actual function.
when methods from the later VMTs are called , this points (non-virtual thunk)
That may be so, although a VM on AWS is measurably slower than the same program running on my Xeon from 2013 or so.
But, more generally, the problem is that tech stacks are an awful amalgamation of uncountable pieces which, taken by themselves, "don't add much overhead". But when you add them all together, you end up with a terribly laggy affair; see the other commenter's description of a web page with 30 dishes taking forever to load.
My experience has been that HTML and making changes to HTML has huge amounts of overhead all by itself.
I don't dispute that very bad javascript can cause problems, but I don't think it's the virtualization layers or the specific language that are responsible for more than a sliver of that in the vast majority of use cases.
And the pile of build and distribution tools shouldn't hurt the user at all.
When half the layers add up to 10% of the problem, and the other half of the layers add up to 90% of the problem, I don't blame layers in general. If you remove the parts that legitimately are just bad by themselves, you solve most of the problems.
If you have a dozen layers and they each add 5% slowdown, okay that makes a CPU half as fast. That amount of slowdown is nothing for UI responsiveness. A modern core clocked at 300MHz would blow the pants off the 600MHz core that's responding instantly in the video, and then it would clock 10x higher when you turn off the artificial limiter. Those slight slowdowns of layered abstractions are not the real problem.
(Edit: And note that's not for a dozen layers total but for a dozen additional layers on top of what the NT code had.)
Unfortunately, at this point some of the slow layers are in hardware, or immediately adjacent to it. For example, AFAIR[0], the time between your keyboard registering a press, and the corresponding event reaching the application, is already counted in milliseconds and can become perceptible. Even assuming the app processes it instantly, that's just half of the I/O loop. The other half, that is changing something on display, involves digging through GUI abstraction layers, compositor, possibly waiting on GPU a bit, and then... these days, displays themselves tend to introduce single-digit millisecond lags due to the time it takes to flip a pixel, and buffering added to mask it.
These are things we're unlikely to get back (and by themselves already make typical PC stacks unable to deliver smooth hand-writing experience - Microsoft Research had a good demo some time ago, showing that you need to get to single-digit milliseconds on the round-trip between touch event and display update, for it to feel like manipulating a physical thing vs. having it attached to your finger on a rubber band). Win2K on a hardware from that era is going to remain snappier than modern computers for that reason alone. But that only underscores the need to make the userspace software part leaner.
--
[0] - Source: I'll need to find that blog that's regularly on HN, whose author did measurements on this.
At this point there are so many layers that it would be hard to figure out the common problems without doing some serious work profiling a whole bunch of applications
"But when you add them all together, you end up with a terribly laggy affair"
I think this is the key.
People fall in love with simple systems which solves a problem. Being totally in honey moon they want to use those systems for additional use cases. So they build stuff around it, atop of it, abstract the original system to allow growth for more complexity.
Then the system becomes too complex, so people might come up with a new idea. So they create a new simple system just to fix a part of the whole stack and allow migration from the old one. The party starts all over again.
But it's like hard drive fragmentation - at some point there are so many layers that it's basically impossible to recombine layers again. Everybody fears complexity already built.
WASM is designed to cut through all the bullshit and leave only a minimal amount of bullshit, even though it turns out there's still a lot of bullshit in the other parts of the system that WASM doesn't address.
I like websockets for the same reason. Each message has a two byte overhead compared to TCP. Two bytes. Unfortunately messages sent by the client have a whopping four additional bytes to help protect buggy middleboxes.
Well, the way in which we got there is in adding more features to the "obvious" answer: all any given site necessarily has to do, to have the same presentation as today, is place pixels on the screen, change the pixels when the user clicks or types things, and persist data somewhere as the user does things.
Except...there's no model of precisely how text is handled or how to re-encode it for e.g. screen reading...the development model lacks the abstraction to do layout...and so on. So we added a longer pipeline with more things to configure, over and over.
But - the computing environment is also different now. We can say, "aha, but OCR exists, GPT exists" and pursue a completely different way of presenting many of those features, where you leverage a higher grade of computing power to make the architectural line between the presentation layer and the database extremely short and weighted towards "user in control of their data and presentation". That still takes engineering and design, but the order of magnitude goes down, allowing complexity to bottleneck elsewhere.
That's the kind of conceptual leap computing has made a few times over history - at first the idea of having the computer itself compile your program from a textual form to machine instructions ("auto-coding") was novel and complex. Nowadays we expect our compilers to make coffee for us.
Here's a fun fact, most fonts have a font program written in a font specific instruction set that requires a virtual machine to run. There is no escaping the VMs!
A VM is not a VM. Just because a program’s semantics are defined in-terms of “a” virtual-machine (Java, .NET, etc) - it’s otherwise entirely unrelated to virtualisation.
It always kind of cracks me up when I hear someone having to explain the difference between between these 2 breeds of VM.
At one point back in school a friend said to me "hey, I can't figure out how to install and boot JVM on Virtual Box. I need to use it for homework in another class. Help me?"
I wish I had been able to explain it as succinctly as you. Instead I sat there laughing in the guy's face for a good minute, eventually realizing from his expression that he was being serious, which only made me laugh even harder.
> But I really wonder - what would be more complex?
> Building interactive programs based on HTML or Logo (if anybody does remember)?
Hold my beer: my Github Actions CI scripts use Logo to generate the bash build scripts as images that are then OCRed and executed by a special terminal that exploits the Turing complete nature of Typescript's type system.
>If you can't load a page with 30 dishes fast enough, you have a serious problem
That depends on your scale. If your product is "large enough" it is relatively easy to get into the range of several seconds of response time.
Here are some of the steps you may want to execute before responding a resquest to your user:
- Get all the dishes that have the filters the user selected
- Remove all dishes from restaurants that doen't delivery in the user location
- Remove all dishes from restaurants that aren't open right now
- Get all discount campaigns for the user and apply its effects for every dish
- Reorder the dish list based on the history of the user interactions
Now imagine that for every step in this list you have, at least, a single team of developers. Add some legacy requirements and a little bit of tech debt... That's it, now you have the perfect stage for a request that takes 5-10 seconds.
Dafuq kind of scale could even a service for lots of restaurants have, that that wouldn't be a single query taking milliseconds to execute? I'd maybe split the last bit (user history re-ordering) into another operation, but the rest, nah, not seeing it, one quick query, probably behind a view.
I mean maybe your DB is a single node running on a potato and your load's very high but you're also somehow never hitting cache, but otherwise... no, there's no good reason for that to be slow.
[EDIT] Your last paragraph is the reason, though: it's made extremely poorly. That'll do it.
Recently I stumbled across the online catalog for Segor Electronics (segor.de I think? Google it. Only in German. They're not paying me to post this)
It's extremely fast. Super duper fast. And a quick look at the network debugging tab shows why: it loads the shop's entire catalog data (about 3 megs) upfront, and the entire application runs locally with not a single request until you buy something. Now that's efficiency.
Really. Go to their website, clock on KATALOG and click some random buttons, pick a product at random, add it to your cart, remove it from your cart.
The product images are the only things that aren't pre-loaded.
None of the things you said mentioned should be hard. We did complicated things like that and more in the 1990s.
But it was different...
Yeah. It was. That's exactly my point.
A major problem is the number of places in our code stacks where developers think it's perfectly normal for things to take 50ms or 500ms that aren't. I am not a performance maniac but I'm always keeping a mental budget in my head for how long things should take, and if something that should be 50us takes 50ms I generally at some point dig in and figure out why. If you don't even realize that something should be snappy you'll never dig into why your accidentally quadratic code is as slow as it is.
Another one I think is ever-increasingly to blame is the much celebrated PHP-esque "fully isolated page", where a given request is generated and then everything is thrown away. It was always a performance disaster, but when you go from 1 request to dozens for the simplest page render it becomes extra catastrophic. A lot of my web sites are a lot faster than my fellow developers expect simply because I reject that as a model for page generation. Things are a lot faster if you're only serving what was actually requested and not starting everything up from scratch.
Relatedly, developers really underestimate precomputation, which is very relevant to your point. Your hypothetical page layout is slow because you waited until the user actually clicked "menu" to start generating all that. Why did you do that? You should have computed that all at login time and have it stored right at your fingertips, because it is a reasonable assumption given the sort of page you're talking about that if the user logged in, they are there to make an order, not to look at their credit card settings. Even if it expensive for reasons out of your control (location API, for instance) if you already did the work you can serve the user instantly.
Having precomputed all this data, you might as well shove it all down to the client and let them manipulate it there with zero further network requests. A menu is a trivial amount of information.
It isn't even like precomputation is hard. It's the same code, just running at a different time.
"But what about when that doesn't work?" Well, you do something else. You've got a huge list of options. I haven't even scratched the surface. This isn't a treatise on how to speed up every conceivable website, this is a cri de coeur to stop making excuses for not even trying, and just try a little.
And it is SO MUCH FUN. Those of you who don't try you have no idea what you are missing out on. It is completely normal on a code base no one has ever profiled before to find a 50ms process and improve it to 50us with just a handful of lines tweaked. It is completely normal to examine a DB query taking 3 seconds and find that with a single ALTER TABLE ADD INDEX cut that down to 2us. This is the most fun I have at work. Give it a try. It's addictive!
Yeah, your last point is totally spot on, it is so gratifying to make something feel obviously much faster, in a way that few other things in programming are, and there's usually a lot of low hanging fruit.
Also, if you work on a website, the Google crawler seems to allocate a certain amount of wall time (not just CPU time) to crawling your page. If you can get your pages to respond extremely quickly, more of your pages will be indexed, and you're going to match for more keywords. So if for some reason people aren't convinced that speed is an important feature for users wanting to use your site, maybe SEO benefits will help make the case.
ALTER TABLE ADD INDEX, in some cases, can create speed increases in multiple orders of magnitude.
I was using a SAST program that used MS SQL Server and was generating reports, and often finding the reports took HOURS to generate, even when the report was only ~50 pages. A report on one specific project took over a DAY to generate a report. I thought it was ludicrous, so I logged onto the SQL server to investigate and found that one query was taking 99% of the time. This query was searching through a table with tens of millions of rows, but not indexed on the specific rows it was checking against, and many variations of the query were being used to generate the report. I added the index (Only took about an hour, IIRC), and what took hours now took a couple minutes.
I was always surprised the software didn't create that index to begin with.
In my use case, impact on inserts was not noticed. I did notice higher disk space usage, but it absolutely was worth it. Spending $200 on a larger disk was absolutely worth saving literally days on report generation.
If you think that’s enraging just wait until you get a page that unloads the previous content as you scroll. You can only search the text that’s visible. Maddening.
And when you're about to click on something, something new loads and everything jumps unpredictably and you end up accidentally clicking on the wrong thing lol
Yes, in Windows 50% of my day is fighting with something obscuring my view or taking focus. Something pops up just as I was clicking or pressing Enter. I have to sign into multiple systems in the morning and sometimes it takes four attempts to enter creds for one login because I keep getting interrupted. It's infuriating.
you would think they could figured out that programs not directly opened by the user shouldn't be able to steal focus from the program the user is currently interacting with. seems like basic UX/UI failure
You're talking about people who haven't figured out you should be able to edit the options on the right click menu from a single settings menu and that the task bar should expand and contract dynamically with the number of open windows. Microsoft stopped improving the Windows UI around 2006.
This is actually pretty hard to get right. Just yesterday I was confused why opening my text editor under KDE didn't pop up a window. Turns out some update to KDE's focus stealing prevention (or some other involved component) changed things so the new text editor window got pushed behind existing windows.
Even more annoying is when ads pop in a second or so later under the cursor position just before you click, taking you to the ad not what you wanted to click.
I could kind of understand things moving around back in the 2000s when we were all getting used to AJAX but all these years later can we (at least) have the main navigation links stay still?
This is so frustrating. Though I recently come across a rare bread, that I thought stood out on load speed. The BBC of all places.
While following the sub disaster I was pleasantly surprised at how quick it always loaded. Nearly always it would load near instant after clicking my bookmark.
(Definitely not something that is that common when you live in NZ)
Not at all what I expected from a news site. They're usually full of crap and dog slow.
Adjacent but similar, I am so over all of the animations and corporate bullshit on pages. I run a business making decent and super optimized web pages and people love them. They’re the only website in their town and field that doesn’t take 10 seconds to load and render.
Unfortunately I don’t have a website for myself and I don’t feel comfortable sharing my client’s websites. I operate purely through word of mouth in my local town, and I don’t have any aspirations to “go big”
I realize I didn't formulate my comment well -- the XYZ problem happened.
I am interested in your fast loading techniques in general. I also am considering making a bunch of personal / pro websites where I'll use a static generator. Just looking for some inspiration and ideas to steal I suppose.
Since it's kinda fresh pursuit for me, I am still looking to gather some links and do proper research. I wasn't looking to deanonymize you, my apologies.
As far as my inspiration, I use Craigslist and google as my inspiration. I try to get a sleek and simple look like google pages, but maintain the “old school” functionality and layout ideas of Craigslist .
As far as actual development is concerned, I use oracle ARM servers that are grossly overpowered for a webhost, cloudflare nameservers OR CDN, and I keep as much of the development as possible server side with as little JavaScript as I can. An example was a simple blogging system I made. The entire system is set up with a MariaDB table that has “title, date, image url, and content” as the data bits for it, and then each function works on one of two pages: a backend using php session that has all of the functions with get request, and a front end that has all of its content on a page with post requests. There is no JavaScript involved on either page, which means the stuff transmitted over the internet is lesser, the stuff done on the client computer is lesser, and the number of outside calls is lesser. This does make it “less responsive”, but does the blog really need image zoom in on hover and shit like that?
I have found the best way to develop for speed and simplicity is to curb the enthusiasm of the client from “looks as good as possible” to “simple, cheap, fast, and robust, while still looking better than average”
The final suggestion I have is to develop with security AND accessibility in mind first. If you want to put aria links of all of your stuff, it is much harder to go back later and 1) determine what the link does, and 2) write an aria for it than it is to just include it in the first place. Always follow proper form for mitigating risks like SQL injection and XSS, and do as much as possible on the server before you resort to JS.
If you are looking for a couple of sites that I didn’t build, but get the point of what I am trying to do across, check out
Smashingmagazine.com
Hacker news doesn’t look the best, but it follows the logic set forth,
Openai.com (this one surprised me because if you remove a lot of the slightly more interactive elements it is fast as hell)
If you have any specific questions, ask away and I’ll do my best
Google specifically reengineered YT last year to do exactly that! From loading ready to display html with subsequent clicks ajaxing more html to loading 1MB .js library and 400KB of json on first load with every subsequent click requesting anotehr ~400KB of json to be interpreted.
This is called cumulative layout shift (CLS for short) and there’s a push in web dev to work against and around this - it’s recently become part of the performance measurement of googles lighthouse scoring and server side rendering and static site generation metaframeworks like nextjs and Astro allow you to send out the entire static page HTML without having to lazy load any new data.
We also have tech companies that claims sub 300ms request response time is good enough. I wish people look at StackOverflow and understand how they do everything at under 20ms.
I get your point, but "losing interest" can also mean losing flow, because the user got interrupted for five seconds instead of instantly taking the next action in their mental plan.
When apps have these kinds of interruptions all over the place, that's even worse than just having them at startup.
I was just reading this week about someone trying to get their UHK keyboard to launch an application on Windows by producing a sequence of keys starting with the Windows key. They needed to put in a delay to get this to work, and it reminded me of my frustrations launching programs in Windows as the start menu takes its sweet and variable time. Not least because I know the technology has been focused on getting adverts into the start menu.
There is, but even that's not perfect. I have this stupid habit where I bring up the NVDA screen reader when I want it by typing Windows+R, typing "nvda", and pressing Enter. (I have low vision, and I use a screen reader sometimes, but not all the time.) I know, I really should use a desktop keyboard shortcut instead. Anyway, it's muscle memory, and I do it automatically, without watching for the Run dialog to appear. Only sometimes, the Run dialog doesn't appear fast enough, and maybe the "n" doesn't make it into that dialog's edit box. Or, on one or two embarrasing occasions, the Run dialog didn't grab focus at all, or at least not until way too late, and a message that just said "nvda" made it into a chat window.
MacOS manages to provide an advanced search launcher experience as fast or faster than the run dialog that requires the perfect exe name.
What’s Microsoft’s excuse? Tired of their incompetence being handwaved and a several decades old jank non-solution being held up as acceptable. MS needs more accountability in their teams.
Or this new version will just break... I had some nice weeks when the search just didn't work at all... While I was too lazy to restart the computer to fix it...
Then again, I guess any other OS might break in same way. Like my Debian VM just kinda stops responding to part of the screen sometimes if programs are maximised...
This is partly an OS design issue. There's no deep reason the OS should ever throw away keypresses, but contemporary GUIs have a very weak and flaky notion of focus. Contrast this with mainframe apps where users could learn to go incredibly fast, because keystrokes were buffered per connection and the mainframe would process them serially, so even if you typed faster than the machine could process them it wouldn't matter, no keys were lost.
It's not necessarily Windows throwing away keypress events but the order of events system wide not necessarily staying in the expected order or the target for an event not being active at the right time.
If you activate the start menu with a keypress it's going to grab focus. Before it grabs focus the previous window in focus will get events. The same applies with panels (drawers? I forget Windows' name for them) in the Start Menu. There's a non-zero time between activation and grabbing focus to receive keypress events.
Everything from animation delays to stupid enumeration bugs can affect a windows not grabbing focus to receive keypress events. Scripting a UI always has challenges with timing like this.
A mainframe terminal has a single input context. You can fire off a bunch of events quickly because there's no real opportunity for another process (on that terminal) to grab focus and receive those events.
Note the above doesn't absolve Windows of any stupid performance/UX problems with bad animation timings and general shittiness. Microsoft has been focusing on delivering ads and returning telemetry with Windows instead of fixing UX and performance issues.
Yes, my point is that an alternative OS design could serialize keystrokes such that a keypress has to be handled (including focus changes) before the next keys are delivered, allowing you to type ahead without keypresses going to the wrong place or depending on the vagaries of timing. It might require a different approach to UI API and design, though.
That's not really practical with a preemptive multitasking OS. There's no guarantee (without real-time scheduling) any process will have uninterrupted time on the CPU(s).
According to an external wall clock the keypress events happen at seconds 1, 2, and 3. The first press triggers a window to appear (menu panels are a type of window). It takes 0.5s to instantiate and register to receive keypress events from the shell. Wall clock time is 1.5s. Nice.
The second window (menu panel) receives a keypress event at wall clock 2s which opens a third panel. That panel because it has more complicated drawing and page faulted so had to fetch a page from disk swap unfortunately took 1.2s to register for focus. A keypress triggered at wall clock time of 3s. Our third panel though didn't register focus until wall clock 3.2s. That keypress went to panel 2 because that had focus when the keypress event triggered. All times greatly exaggerated.
The shell needs to add events to processes' event queues but it can't just arbitrarily add them to every process. It also can't know any individual window wants events until the process tells it so. Unlike mouse events a keypress event doesn't have coordinates so a process can't really figure out the intended target of an event.
A model that prevents preemption means your back to the Win16 cooperative multitasking. A process can't be interrupted until it gives up the CPU willingly. That however means background processes can't do work while a foreground process holds the CPU. If you make just your shell and GUI apps cooperative the responsiveness of the system will end up awful.
That's the issue you'd face with today's operating systems and UI designs, yes, but I'm talking about a hypothetical new OS design.
In such an OS the APIs would allow you to atomically transfer focus as part of other operations, for example, starting a new program or opening a new window could simply transfer focus atomically to the pending new program/window such that the OS buffers keystrokes until the recipient is ready to receive them. Also, taking focus would require you to advertise what keys you're willing to receive, allowing a focus cascade such that there's never any situation in which keystrokes get delivered to a UI that isn't able to do anything with them. At the top level of the shell there'd be a kind of global command line or palette that is the default receiver of all other unhandled keystrokes. Because focus transfer is always deterministic under this scheme, people can learn where keystrokes will go without timing playing a part.
Mainframes don't buffer keystrokes at all: rather, they send a screen to the terminal with marked "fields", and then the terminal handles all keystrokes until you press return or one of the attention keys to submit the changes back to the mainframe. Thus, even on a heavily loaded system, typing is instant because the main CPU doesn't get involved at all
Right, but what I mean is, if you press some keys to move from one screen to another, you can start typing before the navigation is complete and those keystrokes will be buffered by the terminal. They won't just be discarded, meaning you can learn to type ahead of where the server is up to.
That sounds terrible. Why interact with the start menu at all if you can just start the application itself through the path? That's the kind of abuse that delays things in the first place.
OTOH I recall alt-tabbing full screen games (Warcraft 3 on a single core machine is a specific memory) and then sitting back for a while…
Office suites have never been good, but office suites in like 2005 seemed to stretch systems to the breaking point.
Lots of consumer software has always sucked out of the box, I guess if you are here you were possibly a technically savvy kid at some point, is it possible that you were just more selective about the types of programs you ran when you were using the computer for fun?
Old text word processors on my 286/386 back in the late 80s / early 90s, ran just fine. Instant everything. Only thing that was truly slow was the scanner.
I have fond memories of that, but basically the editor was a UI into a linked list with a blue screen. So not comparable to what people are being asked to do with Word and 365 today.
My personal beef with Word is that it struggles so much with long documents. Trying to read, say, a 300 page spec from 3GPP is miserable.
Most games don't need to change screen resolutions anymore which is the expensive bit since not only do you have to wait for the hardware to settle, you have to throw out basically everything in GPU memory and reset it all
Also, having to throw out basically everything in GPU memory is largely a thing of the past in the first place.
I still have this instinctual reluctance to change screen resolution in a game's setting screen, even though 99% of the time it's an instantaneous thing these days.
Modern games typically don't change the screen resolution at all. If there is a resolution setting then it usually is just for the internal render resolution and the final pass will scale that up to the native resolution of the display. Changing the screen resolution only made sense with CRTs where the display is actually capable of different resolutions unlike LCD displays where there is only one native resolution and non-native resolution needs to be resampled (either by the display, the GPU or the game).
> you have to throw out basically everything in GPU memory and reset it all
This is not an inherent limitation of CPUs but a part of Windows' exclusive fullscreen concept. Just another thing that was simply accepted as the way things are instead of being improved (until exclusive fullscreen went out of style).
Full-screen games were a specific issue because they would have full control of the graphics card (GPU multitasking hadn't been invented yet or something). When the game gets focus it has to set up the GPU from scratch.
This is what happens when you have a leaning tower of abstractions, with each layer being developed with a philosophy of, "it's good enough". Some performance loss is unavoidable when you're adding layers, but that aforementioned attitude of indifference has a multiplicative effect which dramatically increases losses. By the time you get to the endpoint, the losses snowball into something rather ridiculous.
Along those lines, I have numerous clients who just want plain Ruby on Rails -- no react front end. They are all business to business, or at least professional users on the end. They just want their data loaded and to work with it.
Ruby on Rails may not be the poster child for speediness as things get big or complex, but if you aren't fighting the ORM, it's consistently quick from click to data.
Which is not a RoR issue. You get those accidentally if you write plain SQL as well. (Actually passing the AR query fragments makes the n+1 easier to avoid in complex situations)
Each level of abstraction has its own caching and buffering routines because the underlying layers are slow, and without the ability to make them better, you can only put your own cache on top of it. This helps initially, but in the end, the time goes wasted managing all those caches and buffers at every given layer.
Recently I re-discovered my old collection of mp3s. I copied them to my laptop and started listening (using VLC). It blew me away how pleasant the experience was, particularly the overall responsiveness, navigating from track-to-track, skipping around in a track, stuff like that. I never really noticed the delays from streaming services until they were gone.
Spotify’s trick when it first launched is that search and playback was so fast it almost felt like you had all the music in the world on your hard drive.
Unfortunately I cannot think of a single thing that has gotten better about Spotify since I started using it, and a lot which has gotten worse.
Depending on when you started using Spotify, accessibility might have gotten infinitely better. The original Windows app, with its custom GUI toolkit, was completely inaccessible with a screen reader. Then they re-did the UI using Chromium Embedded Framework.
Some file selection dialog (and explorer) issues come down to the anti-virus. I've had folders on an SSD that took a minute (60 seconds!) to load. After I added it to an exclusion list in Defender it loaded in a second.
Another one that can be slow with file dialogs is that sometimes (maybe it has been fixed now) it will try to query whether a networked drive is around on another computer. If it isn't then the call to it can be blocking your file UI.
A third problem I've noticed with file selection dialogs and explorer is that the My Computer 'folder' that contains your disks takes a long time to load. Much longer than any sub-folders on any of the drives.
I think the problem is largely with explorer.exe. If I browse those folders in a web browser the experience is snappy.
Trying to meet a specific threshold is part of the problem. The better the development hardware, the earlier that threshold is met in testing, which tends to mean optimization effort falls off a cliff.
Also that threshold is an entire 400ms. We should expect significantly better than that these days.
About 20 years ago I was evaluating solutions for reporting to see if we could save money switching from Crystal Reports. One reason we stayed with Crystal was they did something they other report engines did not; they made available for display every page as it was rendered. So for a 400 page report, you could start working with it immediately. It took each engine (with a couple exceptions) about the same time to generate the entire report, but for the other engines, you had to wait until they were done.
There is speed, then there is the perception of speed. Crystal got this right.
Note that modern versions of MS Paint (with few improvements over the original) takes seconds to load on a quad core 3+ghz machine, loaded from an SSD.
I would not say that the C# runtime is slow, but it is a JIT compiler that is not optimizing for start-up (as far as I know), and it is "doing a lot of work" at runtime to achieve the eventual performance it is capable of.
Start-up time is not the most important property for a lot of services, but for user applications it's pretty high up there, so if the underlying runtime is not optimizing for that this shows a disconnect in the choice of technology stack.
I'm quite impressed of both .NET and OpenJDK in some metrics, but it is often not resource efficient, which is something I do value.
One example of an application that works as I would expect others to do is MuPDF, Being able to open 20MB+ PDFs in 1/10 seconds on a 10 years+ old laptop.
By the way, does anyone know why Debian launches LibreOffice so much quicker than Ubuntu, Fedora or Archlinux (or any other distro I've tested with)? In Debian its 1-2 seconds, and the others 5-10 seconds. I mean it could be included extensions or how they are configured, but I'm honestly interested.
Did not assume. Asked, maybe the other distros are old versions. Not sure why else there would be a huge difference... maybe flatpack/snap dependencies not in fs page cache.
Ok, sorry for assuming your intent. No, its nothing like that. They are all the distro provided stable versions installed as "regular" applications.
And it seem to be the start up process that differs, as putting them all in a ram-disk does not alleviate the issue, and restarting the app cuts the time in ~1/2 but equally for each distro.
My guess, as I said first is what default libraries as loaded, and possibly how they are configured. I do however find it strange that this has not been mentioned elsewhere as I've been struck bu this difference for years, when I happen to load a pure Debian install (not what I usually use).
I keep harping on Visual Studio, but I learned programming with Borland Turbo Pascal (and later Turbo C/C++) on a 4.77MHz machine with 512k memory.
It was orders of magnitude more responsive than VS on my current 16 core 3.5GHz 128GB machine.
The only exceptions are: 1) the actual build, which is faster on the modern machine, but only for a large number of source files and 2) reading and writing files - a floppy disk cannot beat an nvme drive of course.
Reminds me of my hp48 calc, which original system was often .. sluggish, but with enough input buffer and predictability (stack + RPL) meant that it was actually beneficial since it forced you to learn things by heart and anticipate more, and the pauses would serve as thinking time for your brain. A rare kind of slow and laggy turning out to be fun.
Also impressive how our brain is sensitive to all of this.. no matter how impressive a current OS / web browser / jitted js is.. I dearly miss the past eras "behavior".
We're so glued to our screens now that our threshold for losing interest is far higher. We'll check our phone while waiting for a desktop app to open rather than walking away and finding another activity.
I’ve been sharing videos like this for a month or two
I have a 2015 MacBook Air I abandoned recently for being so painfully slow to use that I had almost not touched it for months. I have an iPad Air 2 that is basically unusable at this point. Both are 2-3 orders of magnitudes faster than those old computers that work instantly.
But windows and web apps are super slow now too
Think of all the landfills and wasted work hours earning the money needed to fill those landfills. The heavy and rare metals
This is proof that if computers were 10x faster, they would run slower than ours today, because in the past we’ve seen that be true over and over. The software companies will just make heavier and heavier programs and operating systems until we have gained nothing but a significant amount of co2 emissions
Aren't those devices also running non-contemporary OSs? I wonder if installing the factory OS would make them seem fast again, albeit at the cost of 8 years of software updates.
This is only true as the software industry keeps piling abstractions on top of abstractions, as Moore’s law allows it. But we’re reaching the end of the Moore and already feeling the effects of it, for example Javascript frameworks priding themselves on performance instead of features.
Give it some time for the industry to finally mature.
> What makes it even worse is how unpredictable the lags are so you can't even train yourself around it.
What is worse than that: not being able to predict if inputs will be buffered or dropped during unresponsiveness. I kind of look like an idiot when I keep clicking/typing away on someone else’s computer while things are frozen, thinking “oh, it’ll catch up in a bit”, and then 5 seconds later I have to work harder to fix the chaos: some keystrokes at the beginning made it through, then only every other one, then the next couple hundred got dropped, but the next 100 came through fine, and interspersed everywhere there are bizarre runs of duplicated keys, as if I had held the letter aaaaaaaaaaaaaa down continuously.
Everyone’s mix of hardware, OS, text editor, text editor plugins, etc makes this behavior highly variable, and hard to guess if it makes sense to keep typing or just wait out the frequent 1-5 second lockups.
Android is almost as responsive as things like that. Linux is good, sometimes, windows seems better.
1GB programs are rarely instant but that's usually just the price for very complex functionality if it's too interconnected to load parts of it on demand.
As cynical as this comment may be, there may be an element of truth to it. If it is time consuming to add a bunch of visual effects and transitions, you aren't likely to spend time doing that if you could instead be adding useful features.
Most software is not developed by a single person and adding animations have very little overlap with most functionality, so it is almost completely parallelizable.
I know you probably meant it in jest but as someone who wrote a bunch of desktop apps at one time, it was actually easier to develop desktop apps in tools like Delphi in the 1990s than it is to develop apps now.
It was/is a huge step backwards in terms of DX, but an infinite step forward for distribution. Distribution is the ONLY problem, which is why the shift happened.
I am using xfce with a minimal set of services and all the system apps and most others open instantly. Alt+tab is also always instant. It is an MS, Apple, Gnome/KDE problem, not modern computers one.
Absolutely, after using xfce for years I find windows very frustrating to use, to the point I can see my colleagues using it and I can see the lag they just think is normal.
Imagine if you work on computers for hours everyday what the cumulative impact is
A lot of people are bringing up Wirth's law or other things, but I want to get more specific.
Has anyone else noticed how bad sign-on redirect flows have gotten in the past ~5 years?
It used to be you clicked sign in, and then you were redirected to a login page. Now I typically see my browser go through 4+ redirects, stuck at a white screen for 10-60 seconds.
I'm a systems C++ developer and I know nothing about webdev. Can someone _please_ fill me in on what's going on here and how every single website has this new slowness?
OMG Yes. At my megacorp I work at they have this internal HR/401k site thing. I think it goes through 30+ redirects to get anywhere. It's INSANE. We have something called "Pitstop" and clicking on the list of tickets takes 30s+ to load.
My record is Jira successfully loading a page in around 8 minutes. It seriously sat on a white screen for 8 minutes, then boom there's the page - no interaction or F5. What on earth could it have been doing for that long??
- the database and/or the Tomcat server have way too low RAM and start swapping like no end
- way too many people had admin access in Jira and installed a metric shit ton of plugins
- the AD configuration is messed up and instead of only user accounts it loads (and verifies) tens of thousands of user and machine accounts at each login
Given that people absolutely love to upload multi-GB files to Jira (and will nag the admins to disable timeouts and size limit), many admins have long since relented...
After all, why pay for an expensive DMS when you have Jira?
Jira is a horrible app though. I don't understand why it's so popular.
Worse thing is the only reason we have to use it is to log our hours. Because the CIO wanted us to be "agile". Apparently logging ones hours in Jira makes us "agile". Yeah I don't know how either. Someone ticked a nice box there for themself. Now we're just creating a useless swamp of data that has no meaning because there are no guidelines on how to log everything. Normally when you implement the full process that stuff is straightforward because you have things in other places in Jira to link to. Not in this case. The only thing we have achieved is making Atlassian a bit richer.
The same with "cloud". We had to be "on cloud". So what do they do? Migrate every physical server. Every time we need a new "server", we still have to fill in the same 18-page excel sheet. Only the tab with the physical rack location has been replaced with one with AWS locations. We still have the delay of several weeks of approvals and everything runs 24/7, nothing scales automatically or is auto provisioned. This is not "cloud". This is fooling oneself. And paying too much. We're technically in the cloud but we don't take advantage of anything it's actually good at. Paying only for resources we actually use? Nope. Auto scaling demand? Nope. Quick provisioning? Lol you wish. And we can't because the infrastructure architect team has locked everything down so nothing can be automated. They only trust themselves to that as they are the high priests.
It's really time for megacorps to stop trying to be like a startup. It doesn't work, unless you basically rebuild the entire org from the ground up. Which will never happen because it will disrupt too much. Too much legacy, too many strings attached to "the business". Too many processes that will never be changed because it means the entire org would have to change.
Just work with what you have and improve that instead of trying to pretend you're something else.
Jira redefines how slow and clunky a piece of software can be. It reliably takes 15 seconds to update an issue. Even when doing a mass update, 15 seconds per issue, the whole way.
That's not really an excuse - you really only need 3 page loads:
* initial page provided by the service you're logging into - this gets your email address so it can lookup your account and determine which SSO provider to redirect to
* actual login page served by your SSO provider - here you authenticate to the SSO provider. It can occasionally cause another page load to get your 2FA code if configured, or go through further identity checks
* final "page" that consumes the query parameters sent back by the SSO provider - this is often just a 302 redirect to the home page but sets a session cookie.
The main problem is that all these pages are super bloated, with tons of unnecessary JS and BS. All the code for login page that takes a username and password should be able to fit entirely on an A4 sheet of paper - it's literally just an HTML form and a few lines of CSS.
Furthermore, even beyond inter-company SSO, there are shitty companies out there which use such flows internally even though everything is part of the same security domain, hosted on the same infrastructure and thus can be hosted on the same top-level domain and use a single session cookie. Microsoft is a pretty bad one - Teams for example will use a redirect to some other Microsoft-owned domain to get your (already existing) Office 365 session; this is completely unnecessary, they can host all those things on the same top-level domain and reuse a single session cookie seamlessly.
Because we never decommissioned the old auth server fully and we have to serve some of the page on a separate domain. Oh and the landing page URI has changed. Also we need to send you to a certain locale. And on and on..
A lot of sites now don't even a "sign in" now. You only have a large "sign up" button, which you have to click, and then in very small text at the bottom of the sign up screen find the link for "already have an account?"
Don't you see? All that matters is those tasty conversions. They want your email. They want your conversion. What's that? You've converted already and want to login? Sorry, we've got more conversions to drive, can't be bothered.
I worked with a designer that actually told me this un-sarcastically. "My KPI is signups, not logins. Bury the login link. Existing users don't move the metric."
Metrics-based and KPI-based software development has ruined quality for decades.
Reminds me of those explorers who paid the natives for every dinosaur bone they turned in, only to be horrified when they realized the natives were breaking the bones into as many pieces as possible to collect as much currency as possible.
This is what happens when you strongly tie promotions to metrics. Make sure you have the right ones, or don't do it. Left to his own devices, the designer would probably have done the right thing. It takes a bad incentive to make someone do something like this.
Web UX designers need to find some alternative button label that users understand means both “Sign up” and “Sign in”. The site will know if your email address has an account and should then be asked does a password. Though users will still complain that the login process requires two steps: entering a username and then the backend determining whether to next serve a password or registration form.
Needing a bunch of JavaScript to make it work, which will get bungled by the devs and break it for people using password managers, making the thing even worse. Login is such a common pattern that it should be just handled by the browser.
Good point. It's unfortunate that HTTP Auth never become popular. I don't know if that was because the browser support or UX was bad or if web developers wanted more control over their sites' login flow or user information required.
1. send in plain text with http basic auth. Over https this isn't a problem, but https was expensive). This is sent on every request.
2. Use digest. This is also sent on every request, and also requires actual processing, at which point you might as well go for 4 so it looks nice.
3. Use certificates. Nobody does this on the pubic web. The only website I've ever used certificates was whatever certificate site predated let's encrypt, can't remember the name at the moment, and as someone who doesn't use client certificates it was a huge pain (blame that on the browsers though)
4. Use a form on the website with a session token, and you get control over the UI including error messages and styling. Much more user-friendly. You can trivially prevent the user from (easily) sending requests with pain text passwords by only showing sensitive pages like login over https. The user can't bookmark or share a URL with a password embedded in it. You can request more information than just username and password (Bank: do you want to see your checking account or savings account? Forum: go back to previous page or to homepage? SSO-ish (DayForce): what's the name of the org you're signing into?)
My mother signs out of her email every time she closes it, and does the same for other websites as well. She's the only one who uses her computer, and it has a password on it (mostly because Windows won't do file sharing without one). She still refuses to stay signed in.
Not everyone wants to stay logged in, and not everyone uses a single browser; I occasionally use the wrong browser profile for something because I cbf loading up the correct one; in these cases I usually load the website in a private browsing tab to avoid container/addon settings interfering. When I can't log in easily, I get quite annoyed.
The sad part is that we have an OS-managed standard for SSO called Kerberos, successfully used as part of Microsoft Active Directory, and for which most mainstream OSes still include support. This allows any application on your machine to inherit that auth without ever seeing a single login screen.
While it can't easily be used cross-companies (and thus why SAML/OIDC exists), it's perfect for internal company infrastructure, and SAML/OIDC can still be handled somewhat seamlessly by having a minimal service that verifies your Kerberos identity and immediately dispatches you back to whatever third-party service you wanted to authenticate to, with no intermediate login pages or even any kind of UI (this service doesn't need UI because your authentication is managed via Kerberos for which your OS provides the UI).
The problem is that you can't make money (nor "growth & engagement") off stable, battle-tested stuff that already exists and happily works in the background, so Okta/etc shareholders need to peddle worse solutions that waste everyone's time and processing power.
Kerberos relies on line of sight to the TGS. In the '90s and '00s, this was common place. As of COVID, less so.
Kerberos is also difficult to administer and secure (Golden Ticket?). Kerberos also requires the target service be a member of the Kerberos Realm (or otherwise trusted) which again means line of sight between the service and TGS or Realm to Realm.
And then we get into the whole ticket size issue.
Kerberos is not a good candidate for web-based AuthN.
Isn't this the same with any SSO provider? The SSO provider must be reachable by the end-user's browser during any authentication operation.
(in case of KB it must be reachable by the target services too, but in a server-to-server environment it's less of an issue)
> Golden Ticket
Isn't this exactly the same to let's say a session cookie of a web-based IdP?
The IdP could apply policies on its backend that bind the cookie to a given IP address, user-agent or other indicators, but can't this also be done for Kerberos tickets using a server-side middleware on every service you wish to access (since KB is internal-only, it shouldn't be that big of a deal)?
Isn't Kerberos explicitly designed to run over untrusted networks and not require any additional transport encryption?
You could argue that the common implementations are large piles of legacy C with questionable memory safety that could open them to exploitation by malicious actors, but that's an implementation detail rather than the protocol itself - and I believe there's at least one (mostly?) memory-safe implementation in Java called Apache Kerby.
SSO can seem intimidating to someone new to authentication implementations. I think this is in part because it is a bit complicated but also because it is an inherently invisible technology which we dont need think about as users. Sign in with fb/google on the other hand is something we all see in our day to day business and have at least some kind of mental picture of how it works. We've also seen it used as authentication for otherwise poorly implemented services so we might think that "since they managed to use it, how hard can it be?". Hence, a lot of developers and product owners choose those instead of SSO.
Google and Microsoft are the worst for this. When you sign on you can see it flashing through several of their products, signing you on in each, before finally redirecting you to wherever you intended to go.
It might be done for user retention reasons with the idea that people are more likely to use sites they're already signed into, but I really don't need to be signed into YouTube when I sign into my Google work account. Please just skip that and sign in a few seconds quicker.
I'm pretty sure Google does it to set all the appropriate cookies on the right domains. Microsoft probably has similar redirect flows.
You can either do the redirects all at once on login or do them once you use the service first. Since login is already a time-consuming process (username, next, password, next, 2FA, next) I think you may as well take a second to add the redirects and be done with it.
It doesn't make much sense for Google work accounts but it makes sense if those are a minority on the platform. They could definitely patch this out, but then again the login process is something that takes a second extra every month or so, so who really cares.
What does bother me is how every service wants you to enter your username and password separately now. Autofill gets confused and sometimes even stops working because the stupid hidden input fields for the password don't get shown until you click the magical "next" button, just in case you need a special third party auth service.
Either decide that work accounts are important and take out the extra YouTube redirect, or decide they aren't important and let me fill in my username and password on a single form. Both make complete sense individually but combined they're just a massive waste of time.
When I've done login screens, I usually also include a hidden password field so that the password manager can autofill... this way, it's already filled when the password field is visible after clicking "next". It's at least an improvement to the workflow for those of us using a password manager.
Explaining it to the SecOps person, that was painful though.
It's because Microsoft and Google are the two largest identity providers around. Microsoft has M365 logins that can be configured with about 12 different authentication systems, as well as the various services like outlook.com, Hotmail etc. It has to check the login against those systems and then redirect you to that system.
Modern browsers heavily restrict cookies. The redirect chain right after login, that takes you through all subdomains, is a way to evade cookie restrictions if your sites use different domains.
Ten years ago I worked at a very large cloud company and I spent a lot of time wrestling with the various login flows. I remember seeing a flowchart that documented over 100 service calls that happen in the course of the 4 redirects that took place during a login.
This is the worst. You can't even click an internal site link anymore without being redirected through several scummy third-party domains, so that some knucklehead product manager can claim that they are tracking "engagement" and show off "metrics" to their upper managers.
I use Firefox containers with Temporary Containers (https://addons.mozilla.org/en-US/firefox/addon/temporary-con...) so oh boy do I deal with this a lot. With some hacking I can stop the page at the right time to make it 'always open in X container' - there doesn't seem to be an obvious way to glob for different subdomains.
Some of it has to do with changes to browsers’ acceptance of cookies. If you need to set cookies on multiple domains you control (common for SSO), you used to be able to do it by loading a pixel image or tiny script from each domain. Now, however, that’s considered a third-party cookie, and rejected by many browsers. The only reliable way now is to redirect the whole page, and then redirect back.
My university portal login flow (Microsoft login via university SSO), frequently has me log in with password+2fa+nag screen to use microsoft authenticator, just to then randomly fail and have me do the entire thing again. It is infuriating, especially since any login cookies appear to only be valid for 1-2 days per device.
I suspect that the amount of time I spend on just logging in to websites each day is upwards of 5 minutes, and I doubt it will decrease over the coming decades. Such a waste.
First issue is likely solvable by your IT department by looking through the AAD sign-in logs for your activity.
The second is because authentication is per-device (and depending on the scenario, per-app). The token lifetime is configured by your IT department. Microsoft's default is 365 days, if I recall.
It's a standard meant for system A to authenticate a user with system B. Ever logged in to a website with your Google account, or seen those permission screens asking you if you want to allow a third party website to access your Google account? That's OAuth.
Now, as to why many websites do this even when you login with credentials for that system (and not third party auth) - my guess is the system has separate teams for each subsystem, each hosted on different subdomains. In order to transfer auth state from one subdomain to another, you need something like OAuth since cross-domain cookies are forbidden by the browsers.
Your browser gets bounced between different sites that don't have the full picture because the process is optimized for the explainability of each part of the system instead of the performance of the whole system. It's something like: the website says "go to Microsoft to get signed in" and then microsoft.com says "actually Microsoft logins are now Live logins so go to login.live.com" and then that says "oh hey, you are already authorized, let me return this result back to Microsoft.com" which then says "oh hey, here's your result, pass it to yourwebsite.com". Something like that. Not exactly that. The point is: nobody has responsibility for the system. People only have responsibility for parts and Conway's Law applies.
Only Windows has this issue. There's nothing about my Mac or my Chromebook that is anything less than immediate. You can quibble about whether the compositor introducing an extra frame of latency was worth the tradeoff, but that is on the margins.
The Mac is no better, in my experience. I just timed how long it takes to open the Calculator app – the simplest app I could think of – on my 2019 MacBook Pro, and the window appears 600ms after clicking on the dock icon. I would not call that immediate, and it only gets worse when you try more complex applications, especially those written in Electron.
All my subjective experience, but it's basically instant in experience. I think it also helps that it doesn't show fade in/out animations, which LOOK sluggish to me.
Code comes from the same shop that writes Windows. However, I would compare that with older software of similar purpose and capability. How long does it take to launch Visual Studio '97? According to some youtube screen recordings, VS '97 needs over a minute to draw a window even with a hot file cache, which is consistent with my memory.
On my M1 MBA, I just tried measuring opening Calculator using QuickTime screen recording, and then the "trim" function to determine 10 ms precision. It takes 260 ms. Definitely fast enough for me.
Electron feels snappy on modern machines as well. If only it took a bit less RAM than it currently takes to run an app.
I read somewhere that Webkit and specifically Chrome are optimized towards more efficient CPU usage in the expense of a larger RAM use. Probably makes sense in terms of energy consumption but you need more RAM.
Opening a command prompt or mspaint is not exactly demanding and opens instantly on modern computers too when all desktop compositing animations are turned off.
Instantly? Are we watching the same video? Have you not used any version of Windows past 2000? It took well over a second for explorer to open (and even longer to load) on the modern laptop; It even took over a second for the terminal to load. Having native programs open in under a frame on modern hardware would be trivial just ask the kernel team to write the application software.
We just rely on layers and layers of cruft. We then demand improvements when things get too bad, but we're only operating on the very top layer where even dramatic improvements and magic are irrelevant.
Windows is especially bad at this due to so much legacy reliance, which is also kind of why people still bother with Windows. Not to claim that Linux or MacOS don't have similar problems (ahem, Catalyst) but it's not as overt.
A lot of the blame gets placed on easy to see things like an Electron app, but really the problem is so substantial that even native apps perform slower, use more resources, and aren't doing a whole lot more than they used to. Windows Terminal is a great example of this.
Combine this with the fact that most teams aren't given the space to actually maintain (because maintaining doesn't result in direct profits), and you've got a winning combination!
It's the fact that manpower can't keep up with the exploding amount of complexity and use cases that happened to computing in the last decades.
We went from CLI commands and a few graphical tools for the few that actually wanted to engage with computers, to an entire ecosystem of entertainment where everyone in the world wants 'puters to predict what could they want to see or buy next.
To maintain the same efficiency in code we had in the 90-2000s, we would need to instantly jump the seniority of every developer in the world, right from Junior to Senior+. Yes, you can recruit and train developers, but how many Tanenbaums and Torvalds can you train per year?
The biggest amount of cruft not only went to dark patterns and features in programs like animations and rendering that some people regard it as "useless" (which is debatable at minimum). But the layers went also to improve "developer experience".
And I'm not talking about NodeJS only. I'm talking about languages like Python, Lua, or even the JVM.
There's a whole universe of hoops and loops and safeguards made so that the not-so-genius developer doesn't shoot themselves in the foot so easily.
I'm sure that you can delete all of that, only leave languages like Rust, C and C++ and get a 100x jump in performance. But you'd also be annihilating 90% of the software development workforce. Good luck trying to watch a movie in Netflix or counting calories on a smartwatch.
I'm afraid you're putting too much weight on language. Windows is largely built on C++, no? The impact of adding features, multiple layers of architecture, maintained by many people over a long time is worse. Don't underestimate the capacity of creating slow software in ANY language. Software architecture and project management are unsolved problems in the industry.
Windows is a behemoth of legacy protocols, abandoned projects, and software support that ranges from bleeding edge gaming hardware to obscure ancient machines required by long term support partners and investors.
Devs at MS have to make everything right in an universe where everything else is dead or crap. And the fact that Windows 11 can even run without crashing daily is an engineering marvel.
PD: Not to defend MS, but I'm sure their current devs are very capable and doing their best.
Microsoft has been trying to migrate Windows development to a managed language for over 20 years; their first attempt at this was a complete disaster and NT 6.0 (Vista) would ultimately be developed the old way.
It's only really been in the last 5-7 years, with Windows 10 and 11, that MS has managed to get their wish as far as UI elements go, which is why the taskbar doesn't react immediately when you click on it any more and has weird bugs that it didn't have before.
Oh please, get over yourself. How many of those oh so smart 90s devs used those elite skills to write code littered with exploit vectors? Or full of bugs? Or, hell, even really performant?
You are looking back with rose tinted glasses if you think all software was blazing fast back then. There was a reason putting your cursor on a progress bar to track whether it was moving was a thing.
> There was a reason putting your cursor on a progress bar to track whether it was moving was a thing.
The reason it's not a thing today is because those progress bars got replaced by spinners and "infinite progress bars". At least back then you had a chance to learn or guess how long slow operations would take. These days, users are considered too dumb to be exposed to such "details".
The real reason people moved to the infinite ones is that the determinate progress bar is almost never accurate or representative, hence useless.
Like beyond truly "dumb" tasks like downloading a file it's basically a guessing game how long it will take anyway, right? Say you split the whole loading bar into percentages based on the number of subtasks, suddenly you end up with a progress bar stuck on 89% for 90% of the total loading time.
Obviously you could post-hoc measure things and adjust it so each task was roughly "worth" as much as the time it took, but people rarely did that back in the day and my boss would get mad at me for wasting time with it today. Hence, spinners.
> Say you split the whole loading bar into percentages based on the number of subtasks, suddenly you end up with a progress bar stuck on 89% for 90% of the total loading time.
Sure. But now as a user, I get to see the glimpse of what's going out under the hood. Combined with other information, such as a log of installation steps (if you provide it), or the sounds made by the spinning rust drive, those old-school determinate progress bars were "leaking" huge amount of information, giving users both greater confidence and ability to solve their own problems. In many cases, you could guess the reason why that scrollbar is stuck on 89% indefinitely, just by ear, and then fix it.
Conversely, spinners and indeterminate progress bars deny users agency, and disenfranchise them. And it's just one case of many, which adds up to the sad irony of UI/UX field - it works hard to dumb down or hide everything about how computers work, and justifies it by claiming it's too difficult for people to understand. But how can they understand, how can they build a good mental model of computing, when the software does its best to hide or scramble anything that would reveal how the machine works?
> everyone in the world wants 'puters to predict what could they want to see or buy next.
This doesn't strike me like something "everyone in the world wants", but rather something a small group of leaches is pushing on the rest of the population, to enrich themselves at the expense of everyone else. I'm yet to meet a person that would tell me they actually want computers to tell them what to see or buy. And if I met such person, I bet they'd backtrack if they learned how those systems work.
Exercise for the reader: name one recommendation system that doesn't suck. They all do, and it's not because recommendations are hard. Rather, it's because those systems aren't tuned to recommend what the users would like - they're optimized to recommend what maximizes vendor's revenue. This leads to well-known absurdities like Netflix recommendations being effectively random, and the whole UX being optimized to mask how small their catalogue is; or Spotify recommendations pushing podcasts whether you want them or not; or how you buy a thing and then get spammed for weeks by ads for the same thing, because as stupid as it is, it seems to maximize effectiveness at scale. Etc.
> I'm sure that you can delete all of that, only leave languages like Rust, C and C++ and get a 100x jump in performance. But you'd also be annihilating 90% of the software development workforce. Good luck trying to watch a movie in Netflix or counting calories on a smartwatch.
I'll say the same thing I say to people when they claim banning ads would annihilate 90% of the content on the Internet: good. riddance.
Netflix would still be there. So would smartwatches and calorie counting apps. We're now drowning in deluge of shitty software, a lot of which is actually malware in disguise; "annihilating 90% of the software development workforce" would vastly improve SNR.
For the most part, that 90% of the development workforce is not working on solving a new and unique use case, but rather solving an already solved use case but for yet another walled garden (think Disney+, Amazon Prime Video, HBO Max, etc. or the analogous diaspora of fitness tracking apps).
The early 00’s “open standard” of web forum + eMule + VLC would still be light years ahead of Netflix&co. if it weren’t for how hard it’s been gutted by governments, copyright lobbies, ISPs and device/platform vendors through the years. Heck, the modern equivalent often still is (despite all the extra hoops), unless you are trying to watch the latest popular show in English.
They might be referencing the “controversy” around it, where a prominent developer claimed and later proved that the terminal’s render speed is simply orders of magnitude slower than it could be.
It later turned out to be due to some Unicode handling in-built into a windows api they were using, while the developer’s version also not completely feature-complete. But both sides were sort of right.
> Windows is especially bad at this due to so much legacy reliance
Part of the "problem" with Windows is also lack of legacy reliance. As in: MacOS and Linux are at heart Unix systems, with a kernel architecture meant for 1970s hardware. The Windows NT kernel family is a clean-sheet design from the 1990s, a time where compute resources were much more plentiful.
For example, on Linux file system access has (by default) very basic permissions, and uses a closely coupled file system driver and memory system in the kernel. On Windows there is a very rich permission system, and ever request goes through a whole stack of Filesystem Filter Drivers and other indirections that can log, verify or change them. This is great from a functionality standpoint: virus scanners get a chance to scan files as you open them and deny you access if they find something, logging or transparent encryption is trivial to implement, tools like DropBox have an easy time downloading a file as you access it without dealing with implementing a whole file system, the complex permission system suits enterprise needs, etc. But on the other hand all these steps make the system a lot slower than the lean Linux implementation. And similar resource-intensive things are happening all over the kernel-API in Windows, simply because those APIs were conceived at a time when these tradeoffs had become acceptable.
> On Windows there is a very rich permission system, and ever request goes through a whole stack of Filesystem Filter Drivers and other indirections that can log, verify or change them. This is great from a functionality standpoint: virus scanners get a chance to scan files as you open them and deny you access if they find something,
Yes, but still it seems to be useless to implementers, because practically every virus scanner implements braindead stuff like DLL injection for on-access-scanning.
> The Windowsw NT kernel family is a clean-sheet design from the 1990s
I thought that the NT Kernel was heavily based on VMS.
When Dave Cutler, their chief OS architect/guru left for Microsoft and took a bunch of engineers with him. FTA:
"Why the Fastest Chip Didn't Win" (Business Week, April 28, 1997) states that when Digital engineers noticed the similarities between VMS and NT, they brought their observations to senior management. Rather than suing, Digital cut a deal with Microsoft. In the summer of 1995, Digital announced Affinity for OpenVMS, a program that required Microsoft to help train Digital NT technicians, help promote NT and Open-VMS as two pieces of a three-tiered client/server networking solution, and promise to maintain NT support for the Alpha processor. Microsoft also paid Digital between 65 million and 100 million dollars."
I have mixed feelings about Catalyst, but at least it moves in lockstep with iOS advancements/deprecations and isn't holding macOS development back for the sake of backwards compatibility with some obscure thing from 20+ years ago.
> A lot of the blame gets placed on easy to see things like an Electron app
I think this blame is fair. Electron is the most obvious example, but in general desktop software that essentially embeds a full browser instance because it makes development slightly easier is the culprit in almost every case I've experienced.
I use a Windows 10 laptop for work.[1] The app that has the most lag and worst performance impact for as long as I've used the laptop is Microsoft Teams. Historically, chat/conferencing apps would be pretty lightweight, but Teams is an Electron app, so it spawns eight processes, over 200 threads, and consumes about 1GB of memory while idle.
Slack is a similar situation. Six processes, over 100 threads, ~750MB RAM while idle. For a chat app!
Microsoft recently added embedded Edge browser controls into the entire Office 365 suite (basically embraced-and-extended Electron), and sure enough, Office is now super laggy too. For example, accepting changes in a Word doc with change tracking enabled now takes anywhere from 5-20 seconds per change, where it was almost instantaneous before. Eight msedgewebview2.exe processes, ~150 threads, but at least it's only consuming about 250MB of RAM.
Meanwhile, I can run native code, .NET, Java, etc. with reasonable performance as long as the Electron apps aren't also running. I can run multiple Linux VMs simultaneously on this laptop with good response times, or I can run 1-2 Electron apps. It's pretty silly.
[1] Core i5, 16GB RAM, SSD storage. Not top of the line, but typical issue for a business environment.
Don't blame Electron for Teams. It certainly doesn't help, but there's plenty of Electron apps that are perfectly functional and fairly snappy. Just compare it with VS Code. Same company, both Electron apps. The difference is astonishing.
Create a cross-platform UI toolkit that is easy to use, has all the accessibility features of the browser built in, and has a UI control toolkit as rich as say mui.com ... Support SVG as well as stylized layout similar to html+css.
It's not an easy task, and it's not something that anyone has really done. There are plenty of single platform examples, and Flutter is about as close as you can get in terms of cross platform.
There are also alternatives that can use the engine of an installed OS browser. Tauri is a decent example for Rust. Also, Electron isn't to blame for the issues with Teams. VS Code pretty much proves you can create a relatively responsive application in a browser interface.
Not only that, if you want to use a web page for a GUI, then do it by making a local web server back end and just use the web browser.
This idea that electron is somehow the only way to get cross platform GUIs is some sort of bizarre twilight zone where a bunch of people who only know javascript ignore that last three decades of software.
Okay, care to name some of these many cross-platform, easy to use UI toolkits that include the accessibility that the browser has?
Also, I never said Electron was the only way... I specifically mentioned Tauri in my comment as an example of a browser renderer. And it doesn't need to use a local web server either.
And it doesn't need to use a local web server either.
Shipping an entire browser so someone can pop up a single window is not a positive. Again, if you want html as your interface, use html and let people use their own browser so that the entire program is 400KB instead of 400 MB
Qt, open-source only or expensive licensing. C++ only bindings... wouldn't call it "easy to use"
FLTK, no accessibility features
WxWidgets, really limited theming, not even close to html+css. Cross platform compatibility is hit and miss, usually requiring a lot of one-off platform corrections.
Also, as I said, you don't need to ship the entire browser... not once, but twice... try reading slower.
It's LGPL, lots of programs use it like qTorrent, VLC and much more. You can make up criticisms but it has been a backbone of GUIs for decades.
FLTK, no accessibility features
What exactly do you need and do you need it for every GUI you make? If you want a web page, use a web page.
WxWidgets, really limited theming,
Suddenly theming is your deal breaker.
not even close to html+css
Thankfully, because that is often not a good way to make a GUI.
as I said, you don't need to ship the entire browser...
No, you said "it doesn't need to use a local web server either." Also 'entire web browser or not' electron programs end up being hundreds of megabytes for a simple window use hundreds of megabytes of RAM.
The bottom line here is not that electron is necessary. It is that you want to use javascript even though your users will hate it.
> What exactly do you need and do you need it for every GUI you make?
A GUI toolkit that has no support for screen readers, or other assistive technologies that require accessibility APIs, should be a non-starter for most applications IMO. We need more options that meet that criterion without going all the way to a web page.
Well, I've specifically stated more than once, you don't need to use Electron specifically. The advantage Electron does provide is relative isolation from your installed browser (which are generally well sandboxed anyhow). The only other significant advantage is they are easier to jail/isolate for use with the likes of appImage, Snap and Flatpak/Flathub. So you can target multiple Linux platforms with a single build process, without dependency hell or getting stuck on older repository releases. Electron also offers a consistent option for your application's packaging and updates along with a consistent browser surface, where a separately packaged application that uses the system's browser will be indeterminant in terms of potential render issues and bugs.
Again, not that I'm advocating for Electron specifically, and haven't been. I've specifically mentioned Tauri and others as alternatives that use the system's browser engine, which you have repeatedly ignored.
From my original comment, "cross-platform UI toolkit that is easy to use, has all the accessibility features of the browser built in, and has a UI control toolkit as rich as say mui.com ... Support SVG as well as stylized layout similar to html+css"
So, you've failed to meet the requirements from the start.
I've also said, many times now, that you can use browser tech without an entire browser and the answer doesn't need to be electron.
It's been done many times. HTML/DOM is a very primitive UI toolkit by any measure, even with extensions like mui.com beating it is not all that difficult. Are a few open source hackers going to manage - no. Can other companies manage it, yes. Especially accessibility really isn't as hard as people sometimes make out on this forum, and HTML isn't that good at it (because it lacks a lot of semantic information by default).
Consider the feature set of JavaFX when used in combination with the AtlantaFX theme/widget pack. It isn't well known, but is maintained and has an active open source community today.
- All the same controls as mui.com shows and more advanced ones too, like a rich text editor, a way more advanced table view, tree views, table tree views, etc.
- Media and video support.
- 3D scene graph support. HTML doesn't have this! If you want to toss some 3D meshes into your UI you have to dive into OpenGL programming.
- When using FXML, semantic markup (<TabView> etc)
- Straightforward layout management.
- A dialect of CSS2.something for styling, a TextFlow widget for styling and flowing rich text.
- Fully reactive properties and collections, Svelte style (or moreso).
- Icon fonts and SVG works.
- Sophisticated animations and timelines API.
And so on. It's also cross platform on desktop and mobile, and can run in a web browser (see https://jpro.one where the entire website is a javafx app), and can be accessed from many different languages.
Flutter is actually not quite as featureful in comparison, for example there's no WebView control or multi-window support on desktop, though Flutter has other advantages like the hot reload feature, better supported mobile story. The community is lovely too.
Then you have AppKit, which is also very feature rich.
So it's definitely a task that people have done. Many of these toolkits have features HTML doesn't even try to have. The main thing they lack is that, well, they aren't the web. People often find out about apps using hypertext and being able to have a single space for documents and apps is convenient. When you're not heavily reliant on low friction discovery though, or have alternatives like the app stores, then web-beating UI toolkits aren't that big of a lift in comparison.
> Electron isn't to blame for the issues with Teams. VS Code pretty much proves you can create a relatively responsive application in a browser interface
Electron is great, but most apps aren't VS Code. On my 2019 Intel MacBook Terminal.app starts in <1 second and WhatsApp starts in about 7 seconds. Electron is Chrome and Chrome's architecture is very specifically designed for being a web browser. The multi-process aspect of Chrome is for example not a huge help for Electron where the whole app is trusted anyway, though because HTML is so easy to write insecurely, sandboxing that part of it can still be helpful even with apps that don't display untrusted data. That yields a lot of overhead especially on Windows where processes are expensive.
The jpro.one website looks like it's rendering in the browser to me, are you sure the "standalone" and "cross-platform" options aren't also using a browser render surface?
I also said, "Flutter is about as close as you can get" regarding coming close to what I was referring to.
AppKit is NOT cross-platform. Beyond this, you have other means of embedding a browser-ui application without all of chrome included, see Tauri as one example.
JPro runs the app server side, but the UI is rendered to a stream of commands that are then interpreted by the client in the browser to draw using divs, SVG and browser text. The result is that scrolling, text rendering, fills etc are done by the browser but all the actual app logic is server side. However event handling is all server side. If you run the same app on the desktop then it uses its own rendering stack.
> Especially accessibility really isn't as hard as people sometimes make out on this forum
Just to make sure I'm not being one of those people: What AccessKit [1] has now, across Windows, macOS, and Linux, took roughly six person-months of work. We still need to support more widget types, especially list views, tables (closely related), and tree views, but we do already have text editing covered on Windows and macOS. Perhaps it helps that I'm an accessibility expert, especially on Windows. Anecdotally, it seems that implementing UIA from scratch is daunting for non-experts. But I guess in the big picture it's really not that hard.
We need linux to add electron or an equivalent directly to the OS. Cut out the browser and the bullshit. Allow meme developers to write in meme languages but still get good performance.
>We need linux to add electron or an equivalent directly to the OS.
Almost like some kind of... web OS?
To think we almost had it, but Palm made some bad decisions back in 2009 and the dream of app-as-browser + Node.JS + consistent application styling and syscalls through a provided JS framework (Enyo) is, sadly, probably dead forever.
Tauri, Photino, DeskGap and others have this.. it's not as consistent, and does vary by development language and platform. It has been relatively approachable however. Electron is of course a bit more popular and does bring a bit more to the mix.
That "slightly" is doing a massive amount of heavy lifting in that sentence.
I run a company on the side that produces software for events which require a website and mobile apps for iOS (iPhone and iPad)/Android. I cannot imagine being able to do this all on my own without being able to share a codebase (mobile apps built via Capacitor) across all of them. Would native apps be faster? Almost certainly but I'm not going to learn Kotlin and Swift and triple the number of codebases I have to work it. It's completely infeasible for me, maybe some of you are able to do that but I'm not, there aren't enough hours in the day.
I fully understand the cruft/baggage that methods like this bring but I also see first-hand what they allow a single developer to build on their own. I'll take that trade. I'm a little less forgiving of large companies but Discord and Slack (and other Electron apps) work fine for me, I don't see the issues people complain about.
While you are definitely right to a degree, let’s also not forget that depending on how far we go back, everything was English, ascii-only with no accessibility and security.
By requiring more than that, we had to increase the essential complexity. I believe this tradeoff in itself is well worth it (and hopefully we can all agree on that going back to us-ascii-only locale is not a forward direction).
The problem I see is that the layers you also mention, each expose leaky abstractions (note that abstractions are not the problem, no person on Earth could implement anything remotely useful without abstractions — that’s our only tool to fight against complexity, of which a significant amount is essential, that is not reducible). Let’s also add a “definition” I read in a HN comment on what constitutes an ‘expert’: “knowing at least 2 layers beneath the one one is working with” (not sure if it was 1 or 2).
Given that not many people are experts and a tendency of cheaping out on devs, people indeed are only scratching that top layer (often not even understanding that single one!), but the problem might also be in how we organize these layers? When an abstraction works well it can really be a breeze and a huge (or only significant, see Brooks) productivity boost to just add a library and be done with it — so maybe the primitives we use for these layers are inadequate?
>We just rely on layers and layers of cruft. We then demand improvements when things get too bad, but we're only operating on the very top layer where even dramatic improvements and magic are irrelevant.
It's cheaper to beef up the hardware than to fine-tune the software. Fine-tuning may be excruciating because it hinders all other activities related to the software development.
They're loading the toy applications that came with Windows 3.51 an operating system developed when 486's were common and first generation Pentiums were the bleeding edge, so around 100 MHz. (Also, using clock speed alone discounts any generational bumps in efficiency.) Of course it will be fast.
Please don't take my excuses the wrong way, since I wish the performance in software reflected the increased performance of hardware, but we are comparing the performance of an operating system released five years prior to the CPU it is being run on to the performance of an operating system contemporary to the CPU. A couple of other things to note: the comparison uses a bleeding edge Intel processor for Windows NT and, to try to be polite about it, a processor optimized for energy efficiency for Windows 11. (If the tests depended upon CPU performance alone, the benchmarks for processor in the Surface Go 2 are comparable to my 11 year old i5 3330. That i5 wasn't even a high end processor at the time.) The second thing to consider is that performance gains were much more dramatic back then, so even if we could test Windows 11 on a 2026 processor, I wouldn't expect such dramatic results.
Windows 95 running on a 133mhz computer would open Excel (I believe from Office 98) essentially instantly once the machine was up and running. Which unless you had AV running took under a minute.
I checked if I do have Calculator on my Debian and I found it. It opened instantly. However that was an issue for Ubuntu and was fixed in 20.04, three years ago.
By the way, I do my math with bc -l from the command line.
I use WinMerge[1] a lot, and it's always impressed me how it immediately opens to a useable state. So it's absolutely still possible to write Windows software that can open instantly. I think the biggest issue, which multiple other comments have identified, is that people just don't care. Apps open fast enough these days, and no one is pushing back on developers to improve their app's startup performance.
Windows NT 3.51 minimum hardware requirements were a i386 or i486 processor at 25MHz or better and 12MB of RAM for the workstation version. So the 600MHz machine with 128MB RAM is exceeding the minimum requirement by (conservatively) 24x in CPU speed and 10x in RAM, along with all the architectural improvements from going from the i386 to what's presumably a Pentium III-class machine.
If that's actually a Surface Go 2 running Windows 11 - well, it doesn't have a quad-core i5 as the tweet claims - the Surface Go 2 came with a Pentium Gold or a Core m3; both with only two cores and of those is an ultra-low power variant.
As such, that exactly meets the minimum CPU specification for Windows 11 and only doubles the minimum 4GB RAM requirement.
I'm not trying to apologize for the difference here, but it's not an entirely like-for-like comparison.
If you ran Windows NT on the bare minimum it was not as slow (barring hitting swap) as Windows 11 on the bare minimum hardware. Not even close. Windows NT on the minimum hardware wasn't a joy exactly but it was certainly workable. If you run Win11 on the bare minimum you'll very quickly learn to hate everything.
The min specs would be the same, laptop or desktop. A laptop with those kind of specs back then probably just had terrible battery life and was really big & heavy, didn't throttle down or anything. Not like today when you'd expect the "same part" or "same clock speed" to not really be the same, between a mobile and desktop chip.
In 1998, I exclusively used NT 4 on a Dell Latitude to do software development for a month while working overseas. It wasn’t super fast but it was comparable to a non-workstation desktop - in both cases you could not skimp on RAM but otherwise it was fine. The biggest gripe I had was the Synaptics touchpad, which is evergreen.
They do have a better example with Windows 2000 on the Pentium 3 which is very era appropriate.
I see similar sluggishness opening command prompt on my Ryzen 3700X with 64GB RAM on Windows 11 22H2 with an NVME SSD. First it draws the outline of the window then fills it in with content. And that's repeatable!
I feel like the intent was to say notepad from 20 years ago and notepad from today has (approx) the same functionality whereas the processors are x4 times faster, it should be at least as fast as it was before, shouldn't it? In my mind, regardless of the OS requirements, a processor x4 more powerful shouldn't need double the time to launch the same program unless you've added x4+ features.
I can start notepad on my relatively slow Win10 VM with spinning disks in RAID and it starts with similar speeds - starting it on my physical windows machine with a SSD, it launches at exactly the same speed.
Another very similar example to this is the adding text feature in MS Paint. I noticed that somehow on the Windows 11 version, it takes many seconds after clicking the "add text" button to be able to actually start typing. Previously, it was instantaneous.
I think the stock Notepad in Windows 10 is perfectly fine and speedy at least, I've never considered it too slow unless I open a huge file with word wrapping on.
Notepad2 is my all-time favorite though. It supports key features like line numbers and directionless search, but is much closer to stock than Notepad++. [0]
I imagine they're also not using vintage hard drives. Its pretty common in the retro computer world to use things like CF and SD cards for storage emulation. Even a basic CF card is miles faster than a 1990's HDD. Put in a period-accurate storage device and see how bog slow it gets.
The text content of the tweets seem pretty unreliable as this states its a Surface Go 2 with a Quad Core i5, despite the fact the Surface Go 2 never shipped with anything quad core and definitely not an i5.
Maybe it is a spinning rust disk. Even then there's a world of difference between a period accurate drive and a late model IDE drive. The last IDE drives had more drive cache than most desktops had RAM when NT was new.
"Bloat" includes the addition of intentional, but frivolous, features. An application can be well-optimized but still slow simply because it's doing too much.
But I think the reason that most modern software performs badly is because of optimization: we're optimizing to reduce production costs over increasing performance.
It's economic in nature. We minimize production costs by using frameworks and other labor-saving tools. The code produced using these tools tends to be poor, but hardware is cheap enough to make up for poorly performing software.
Some of that bloat is useful. Windows indexes files in the background, which would choke a single-core machine with HDD for sure. Thanks to that I can quickly access my files... well, so long as Windows is able to find the correct thing...
Well, all of that type of bloat is presumably useful to someone or it wouldn't have been written. That doesn't change the fact that there's a cost for including it.
> Windows indexes files in the background
But here's an example of the tradeoffs. I hate this behavior. It incurs an overhead that provides no benefit that matters to me. So, your useful feature is my useless bloat.
> But here's an example of the tradeoffs. I hate this behavior. It incurs an overhead that provides no benefit that matters to me. So, your useful feature is my useless bloat.
Even when you turn the search indexer off, the indexer background service still seems to be doing ... stuff.
I have a Windows 10 VM I use for some testing and such, and all these background things keep using up huge mount of resources, no matter what knobs I turn and regedit levers I pull I just can't get it to stop.
For comparison, I also have a macOS VM which certainly isn't fast, but nothing like the Windows one. And the BSD and illumos VMs work basically fine (although in fairness they also don't start X11; but I do just ssh in to all of these machines and never use the GUI for anything).
But if you turn it off, you don't get the start menu indexed anymore. I don't need my files indexed, I just want my start menu shortcuts indexed. There's a few other small things that no longer work without indexing, though I forget what they are now. Everything is great, but there's actually other services that depend on search being enabled, as it tells you when you try to stop the service that is shutting down dependent service first.
Expect that the search totally sucks. Have you tried Voidtools Everything? It finds files instantly, even on filesystems with millions of files. Yes, instantly, you type a word and it's just there, no matter SSD or HDD. Windows' built in search is a complete waste of time.
And yet when I want to search in the files in a folder searching with windows search won't turn up anything, so I have to switch to the WSL and grep...
Windows has been indexing files for over 20 years.
Back then I would turn it off as I didn't find the search function that usable, and more than once I've had a "clean and build" process fail because some file was open and being indexed, and since Windows locks files on read, the build could not delete the file and just aborted. So, I turned it off.
I feel like this is something where determinism would be a win. Maybe have indexing, but pre-prioritize certain common searches.
I notice that I get completely different results on my home and work machines doing the "start button, type" search. for "Downloads", expecting C:\Users\Username\Downloads, the home machine figures it out after three characters. The work machine seems to have decided that I clearly want "File Explorer, not any particular directory" and "Change how I download updates in spite of it being a corporate-managed box where I probably can't push that button without asking IT to remote in and do so" are what I want, even when I spot it the whole directory name.
On Linux machine I can access and find my files fast. And without any indexing running on the background.
Shit... even I could run the OS from a rust HDD and be usable without pain. Windows10/11 without an SSD it's painful slow.
The term bloat (as it applies to software) is rooted in gamer-think that has no basis in reality and sends a strong signal of lack of understanding. It's reminiscent of the days of 'BlackViper' and disabling Windows Services -- again, another gamer lack of knowledge issue.
Empty notepad, just started.
82,416K working set in main memory.
25.7MB in dedicated GPU memory.
59 threads.
2 billion cycles spent since launch.
Two threads in !OpenAdatper12 spending ~1.5M cycles per second.
Two threads in !recalloc spending ~256K cycles per second.
As shipped, this is no longer a single executable, it is a collection of 230 files, totaling 10.5MB, about half of which are bytewise duplicates, and another significant chunk have overlapping responsibilities, between the icon fonts and png icons.
"Software bloat is a process whereby successive versions of a computer program become perceptibly slower, use more memory, disk space or processing power, or have higher hardware requirements than the previous version, while making only dubious user-perceptible improvements or suffering from feature creep." -- https://en.wikipedia.org/wiki/Software_bloat
I'm not aware of any substantial new features. It uses a new renderer, but this does not produce a significant observable difference from the previous one beyond using more memory.
It supports dark mode.
I'm no gamer, and "bloat" has been a term used in the industry from well before "gamers" (in the sense used today) existed. It's been a term of art for over 30 years.
It also describes a very real thing.
While there are a lot of things that everyone would agree counts as "bloat", there are also areas of disagreement in the form of "one person's bloat is another's essential feature".
Add onto that the fact the 8th and 10th gen Intel low power mobile parts are, well, kinda garbage (low perf/watt, very little boost time, low core count) and were quickly obsoleted.
I'm not sure why Msft put that CPU and RAM combo in their own device when it's just barely past the minimum specs for Windows 10 let alone 11.
I think the bloating hardware requirements are his point. What precisely have they gotten us? Mind you, this is not the same as "what have we gotten in the time that they've bloated"!
I'm in university and each exam I have to install windows 10 to run Safe Exam Browser (same hardware), in between I use Linux as my daily driver. The perceived difference in responsiveness is always frustrating, though I find that a lot of it probably is just due to user hostile design. No OS that constantly nags about tracking me, showing me ads, and so on will feel snappy. I'm sure there is some real lag as well though.
Microsoft has essentially turned the OS into one of those websites which show ads, news letter dialogs, cookie notices, location permission requests, notification requests and so on constantly.
I'm not sure why Windows minimum hardware requirements are relevant at all. If they were, they could get massive performance improvements by raising the hardware requirements. "Sure it's slow, but it's running on literally 1% of minimum recommended RAM!"
They were very relevant back in the '90s. So relevant, it's why Windows 9x existed. The Windows NT 4 minimum system requirements around RAM were too high, thus deemed too expensive for consumers.
Granted, a Surface Go 2 won't win any perf competition, but even with infinite budget you still couldn't buy a desktop today that has the response times of that NT box.
I ran NT 3.51 on a PS/2 486-66 with either 40MB (maybe 48MB) RAM and a scsi disk. It was nice compiling VC++ programs on it.
I now use a Surface Go3 i3 with 8GB. It's enough for just about everything I need. Web browser, running script language web apps, Java IDE, StarCraft 2. Disabling a bunch of stuff on Win11 makes a big difference. Whenever it felt slow I looked at Task Manager CPU and googled the process name, tried disabling it and only re-enable if necessary. Oh I also have a Peltier cooler+fan that cools the back of the unit when gaming to prevent throttling.
The PS/2 NT machine was top spec at the time. The Go3 is utilitarian now though should be like a supercomputer.
WinNT 3.51 was released in 1995 - the fastest PC in 1995 was either a Pentium or Pentium Pro at ~100 MHz - in 2000 a 600 MHz machine is likely a Coppermine PIII.
A fairly common amount of RAM in 1995 to Run WinNT would have been around 32 megs of ram, 64 megs would be especially generous. 128 megs is a high end workstation amount of memory.
The ATA interface also doubled in performance between 1995 and 2000.
There were significant security and stability improvements between NT 3.51 and Windows 2000 - particularly with changes to the driver model that increased stability. (even more so between 2000 and Windows 10/11)
That's right, Windows 95 on a 600 MHz machine would be even snappier. However, later down the thread the author demonstrates Windows 2000:
>For those thinking that the comparison was unfair, here is Windows 2000 on the same 600MHz machine. Both are from the same year, 1999. Note how the immediacy is still exactly the same and hadn’t been ruined yet.
As someone who was hardcore into Windows around that time, all my memory has is waiting desperately for windows to open & apps to load. I remember watching the left-side of explorer paint before the icons came in, and how the icons would paint in order; some days you’d see black squares paint, then the icon. This was running on some dual-socket, 192mb, 7200rpm spinning disk - it wasn’t a slouch.
I also struggle with the comparison between high-end hardware of yesteryear, and low end hardware of today and comparing.
Try running win2k in 16mb, 300mhz P2, and a 4800rpm drive.
The only times I remember experiencing things this fast in my computing career were (a) with a fair wind, and a fully warmed cache that didn’t hit the disk & was a trivial app (b) the first time I used my Apple M1 Max MBP.
Then don’t dodge the question and tell me the specs of the high-end computer that makes modern Windows that snappy. Because I have a fairly ridiculous machine as my main workstation, and I still wait way longer for stuff to load than I used to.
> WinNT 3.51 was released in 1995 - the fastest PC in 1995 was either a Pentium or Pentium Pro at ~100 MHz - in 2000 a 600 MHz machine is likely a Coppermine PIII.
This is addressed in the linked thread.
>For those thinking that the comparison was unfair, here is Windows 2000 on the same 600MHz machine. Both are from the same year, 1999. Note how the immediacy is still exactly the same and hadn’t been ruined yet.
In 1995 getting 128MB of RAM would have been quite expensive. In 1999 not so much. One of the easy things to do with NT or 98 in the 98-2000 era was to put 128MB of ram in when it suddenly became very affordable. It was a night and day experience. I had one game that ran absolutely rubbish in 1995 when I bought it. Years later I came across a few memory sticks and popped them in and gave the thing 16MB of ram from 8. The game started nearly instantly and ran very nicely (usually took 3-5 mins to start). With 8 it was choppy city and slow. Exact same computer only diff was the memory.
If memory serves me they did not really change much in NT from 4.0 to 2k. Other than add in more services and make it more win98 like. So it is maybe not an 'unfair' comparison. But win 3.51 came out getting that sort of computer just would not be in the cards for most people.
Windows went sideways at vista. The 'start the computer up' out of the box would use 2-3gig of ram. Up from 100-200MB from the XP era. Toss in some corp bloatware items. One place I saw it was 10gig just to open the desktop no productivity software even started yet. Then add in the zillions of indirect layers we have added to make programming easier and we are now with applications that seem to start at about the same rate as 25 years ago.
All of those old API's are still there. No one really uses them much anymore. We use the latest cool frameworks. That use the previous cool framework that eventually uses the old APIs :)
Why does it follow that software designed for modern hardware, running on modern hardware, should be slower than software designed for older hardware running on slightly newer hardware?
The only significant difference in priorities as regards speed would be the modern prioritization of "developer time", ads, and telemetry.
I can run Windows 95 applications at better than era-appropriate speed, in an x86 emulator written in javascript running on a web browser. That's at least 3 layers of virtual machine abstraction and the applications are still faster.
So if you're saying "the comparison isn't fair because modern software is too shit to hold up", then I agree, but if you're trying to tell me there is something else inherent to modern computing that makes software so many orders of magnitude slower, than I request that you show data to support that claim.
Back in the day I had a Windows NT 3.51 machine sitting on my desk, right next to a HP 9000 workstation (PA-RISC) running HP-UX; I do not remember the NT machine being this responsive. It wasn't terrible but I did most of my work on the 9000 because it felt faster than the NT machine.
I wonder if the 600MHz machine in this video is fitted with an SSD of some sort, this would load applications far faster than the average hard drive from 1998.
You might be onto something. As P3 class hardware started to age, IDE to CompactFlash adapters came on the market as an option to replace aging mechanical hard drives.
Wait’ll you hear about changing TV channels in 1985.
Turning on a TV in 1975: wait 60 seconds for the tube to warm up.
Turning on a TV in 1985: wait 10 seconds for the tube to warm up.
Turning on a TV in 1995: wait 2 seconds for the tube to warm up.
Turning on a TV in 2023: stare at the LG logo for 20 seconds, then wait another 30 seconds "for Smart Services to become available" in order to change the channel.
Or for my nearly brand new Samsung smart TV - starts up in about 5 seconds, then you can happily watch TV and I did for a few months until it forced an update, which slowed things down.
Now things still work, but the TV needs a restart about once a week if I use the built in apps like YouTube or Netflix.
Finally bought an Apple TV 4K and it "boots" directly into it. Such a relief! (Well, except for that bizarre touch remote that came with the Apple TV, but that's a small price to pay!)
It's asinine how slow service provider's boxes work nowadays. Our Xfinity cable box has a .5-1.0 input lag, (more like 2secs for ff/rw/play) and it's the same even after customer service replaced it with another unit. What a waste of resources...
Command prompt (now Terminal)? Yes, tons. A massive amount of new features really.
Notepad? Kind of. Newer UI library so it handles display scaling a lot better. Handles different line endings and encodings much better now. Handles the system UI dark mode. The interface supports tabs.
>Command prompt (now Terminal)? Yes, tons. A massive amount of new features really.
Can you name a few that could explain the 1,000x performance cost?
Also, have you heard the story about the guy who told MS that their terminal was shit and could be fixed, only to be ridiculed by a fleet of "super elite 500k/year engineers" that in the end turned out to be ... wrong?
Unfortunately, none of these are responsible for the startup delay. Since version 1.18 effectively ~90% of the startup duration is spent starting up WinUI and having it draw the tab bar and window frame. It still needs a second to start. If it still used GDI like Windows NT did, it would start in well under 100ms even on an extremely old CPU.
Fixing this situation is essentially impossible because it requires rewriting almost everything that modern Windows is built on. Someone else in this thread said you couldn't sell 4 quarters worth of work to fix this, but the reality is that it requires infinite quarters, because it requires throwing away the last 10 years of Windows shell and UI work and that will never happen. You could paper over it by applying performance spotfixes here and there, but it'll never go back to how it could be that way. At a minimum, you'd essentially have to throw away WinRT which has an almost viral negative impact on performance. Never before have high latency, but still synchronous cross process RPCs been that prevalent and everything's a heap allocated object, even if it's within the same binary. It's JuniorFootgunRT.
Yeah, you're right, they're related to WinUI. But what I meant is that such features aren't inherently expensive, they're just made expensive due to the choice of UI framework.
Display scaling is very fast in GDI apps and has no impact on launch time, a tab bar is essentially just an array of buttons (minimal impact on launch time?) and transparency is a virtually cost-free feature coming from DWM. I wrote a WinUI lookalike using its underlying technology (Direct2D and DirectComposition) directly one time and that results in an application that starts up within ~10ms of CPU time on my laptop, quite unlike the 450ms I'm seeing for WinUI. That is including UIA, localization and auto-layout support.
I do keep my config backed up and synced between my computers. It doesn't change that much but it's nice having it easily synced across my many machines when I do make a change.
And no, copying text hasn't been Ctrl+c. That sequence sends a sigint to the process, not a copy request. To copy text by default cmd made you enter a mark mode which then had you essentially draw a rectangle and it would then copy as newline characters even when it should have just continued the line. The old copying process of cmd is terrible.
683 comments
[ 5.7 ms ] story [ 346 ms ] threadI think due to perverse incentives it causes the exact opposite to happen. Why did the Windows calculator need to be remade with a much slower and less responsive version? Telemetry probably showed the calculator was frequently used, so a Project Manager targeted it for "improvement" and it was then ruined.
There was Windows 3.2 in 1994 (not to be confused with "Win32", despite the name of the HTML file): http://toastytech.com/guis/win32.html
Yes the western versions of Windows at the time didn't include support for Chinese (etc.) language. But there is really no reason why they should - if the user's language can be represented in an 8 bit codepage, why should they have to pay any price in performance for something they will never use?
Conversely, would a Chinese-speaking user prefer an operating system designed to support all the other languages that exist, with an implementation that is likely not as specifically tailored to their requirements?
That's what happened.
Nothing will change my mind about this, ever. It's been downhill since then.
My guess is: yes, it will.
Somehow, in the past 15 years, "progress" seems to include "software keeps getting noticeably worse, but anyone pointing this out has to be shot down because progress."
Sure sounds like there's a ton of gaps in things I really want out of my operating system on Windows 2000...
Does the switch to 64 bit slow things down enough to explain what happened between Windows 2000 and XP?
Does the operating system have to support virtual machines? Seems easy enough to install vmware then run operating systems inside it for most use cases.
I mean, you can keep 'what if'ing me here, but, is it really worth having all the features that you, clearly as a power user or professional, use installed on every computer everywhere? No. No it really doesn't. It's bloat.
That's a way different experience than running Hyper-V.
> is it really worth having all the features that you, clearly as a power user or professional, use installed on every computer everywhere? No. No it really doesn't. It's bloat.
I also didn't realize that managing WiFi networks or using display scaling are things only power users and professionals would want on their machines. I guess supporting Bluetooth natively in the OS and a modern sound stack is just bloat for most people.
Let me just hop on my wifi and browse the web. Lets do it on a computer from 1999. 2000. 2001. 2002. 2003. 2004. 2005. 2006. 2007. 2008... etc, etc.
Why is it that every couple years from 2012 onwards, doing the same thing keeps taking longer, even with new hardware, without the same revolutions in quality and experience that came with that new software previously?
> doing the same thing keeps taking longer
But I'm not doing the same things anymore. I'm doing a lot more. Things that aren't supported in that 1999 OS at all.
I bought a newer PC because my older one from 2012 legit wasn't fast enough for what I wanted to do. It couldn't handle the VR applications I wanted to run, as its PCIe and RAM performance just wouldn't be up to the task to run the resolutions, texture qualities, and latencies I wanted. The newer one is miles ahead of the older hardware, and the applications I use are significantly better because of it.
But even then, from the other perspective of continuing to run similar-ish workloads using newer software, a lot of the other things continue to run the same experience-wise with slightly better features than when the software was new. When I first built that 2012 machine I installed the then brand-new Windows 8 on it. These days its running Windows 10. From a UX perspective it definitely feels faster than the OS it shipped with. Things like the new Terminal app are way better functionally than the old cmd.exe that used to be on it. I do demand more still from using VSCode with more plugins and what not than before while previously I used things like PyCharm more. I videochat, watch more streaming content on it than when I first had it, and it consumes far more animated GIFs and what not than it used to.
But in the end even with software supposedly getting more bloated and what not, its at least as snappy if not more than it was when it was brand new in 2012, other than the fact there's a whole new class of application I demand from my hardware.
So yeah, even today things are still getting better, doing more, and getting faster. Its not the extreme doubling or quadrupling of stuff like the 80s and 90s where things literally went from only text interfaces to GUIs to 3D apps, but there's still bleeding edge stuff that legit just takes more oomph than a box from 2012.
It's been bothering me for some time ever since I noticed it with the advent of IoT "smart" devices that have the same features as traditional appliances for twice the cost and technical debt. My washing machine still washes clothes and turns itself off, but now I need to set the wash type using my phone because lateral progress dictates a physical interface on the device itself is obsolete.
I was watching Halt and Catch Fire and in the first season the engineering team makes a great effort to meet something called the "Doherty Threshold" to keep the responsiveness of the machine so the user doesn't get frustrated and lose interest. I guess that is lost to time!
Experimental behavior manipulation, without even telling the subject they are part of a manipulation experiment? You would be chased out of the room and your reputation destroyed! Utterly unacceptable. But in webdev universe this is somehow seen as a totally normal practice.
Seeing as they were posting the backlash on Reddit, I'm guessing a lot of people downloaded the app to log in and Reddit said "Big Success!" when they checked the stats.
The GDPR's notion of informed consent really needs to be applied pervasively to all kinds of consumer contracts. If it's hidden in walls of text that the average user doesn't read it shouldn't count as consent.
But the real solution is better web page design.
For me, I use google so often that I can rapidly parse information without really needing to read much of the text, the link just sort of 'looks' right. I've observed my wife reading google results and she is much slower and more methodical, probably because she doesn't google things 20+ times a day every day like I do.
That's how I end up misclicking, because i'm not working at the speed of a normal googler.
It is really annoying though, there are some css tweaks you can make using browser extensions to make that disappear if you're so inclined.
A horrific piece of UI/UX/engineering/whatever.
Which, in my mind, means it didn't load instantly. The page isn't loaded until all of the data is displayed.
I don't disagree with your example, but optimising for page load time is as old as the graphical Web.
Old days: Cmd + f, type what you want.
New days: first scroll to the end of the page so that all the contents are actually loaded. Cmd + f, type what you want.
Is just a list of dishes, some with small thumbnails, some without any images at all. If you can't load a page with 30 dishes fast enough, you have a serious problem (you could always lazily load the thumbnails if you want to cheat).
As a bonus, in Firefox if you hit the ' key (apostrophe) you get a search that looks only within hyperlinks and ignores all the un-clickable plain text. Give it a try, sometimes it can be very useful
Only to discover that 2/3 of the matches are invisible text that's put there for $deity knows what reason, and the rest only gives you the subset of what you want, as the UI truncates the list of ingredients/toppings and you need to click or hover over it to see it in full.
Having Ctrl-F not work correctly is maddening and I hate it.
It's common enough that there were a couple browser proposals to deal with this and would address the Ctrl+F issue. I believe this has been merged into the CSS Containment spec, but at the moment it doesn't make windowing obsolete in every situation.
Actually much worse as Microsoft once did with their COM model, ActiveX based on MFC foundation classes with C++ templates, etc.
And to build those interactive programs somebody is trained to use React, Vue, etc. using their own eco systems of tools. This is operated by a stack of build tools, a stack of distribution tools, kubernetes for hosting and AWS for managing that whole damn thing.
Oh - and do not talk even about Dependency Management, Monitoring, Microservices, Authorization and so on...
But I really wonder - what would be more complex?
Building interactive programs based on HTML or Logo (if anybody does remember)?
Figma contributes by enabling UI designers to easily author interfaces which look allegedly beautiful but are complex to build, test and maintain.
And the resources burned on building such esthetically pleasant piles of barely usable software could find better use on making it simpler, faster and more focused on user actual functional and non-functional requirements (much of them taking place on the server-side) instead of sugaring their eyes by throwing tons of code on their clients
As much as I hated developing with COM, the application interoperability and OLE automation is a form 90s tech utopianism that I miss.
On one project, I actually shifted quite recently from working on old-school, pre-Windows XP, DCOM-based protocols, to interfacing with REST APIs. Let me tell you this: compared to OpenAPI tooling, DCOM is a paradise.
I have no first clue how anyone does anything with OpenAPI. Just about every tool I tried to turn OpenAPI specs into C or C++ code, or documentation, is horribly broken. And this isn't me "holding it wrong" - in each case, I found GitHub issues about those same failures, submitted months or years ago, and still open, on supposedly widely-used and actively maintained projects...
That was about five years ago. :/
There was a time when a virtual function call was a lot of overhead
Even having a VMT is overhead.
Sometimes the COM interface is implemented as actual interface, where the implementing class is derived from another class and the interface. (in C++ the interface is just another class with multiple inheritance, but other languages have designed interfaces). Then the class even needs to have two VMTs.
Multiple VMTs have even more overhead. And with multiple VMTs, it is not just a method call. In the functions, this always points to the first VMT. But when a function from the VMT is called, the pointer points to that VMT. So the compiler creates a wrapper function, that adjusts this and calls the actual function.
when methods from the later VMTs are called , this points (non-virtual thunk)
But, more generally, the problem is that tech stacks are an awful amalgamation of uncountable pieces which, taken by themselves, "don't add much overhead". But when you add them all together, you end up with a terribly laggy affair; see the other commenter's description of a web page with 30 dishes taking forever to load.
I don't dispute that very bad javascript can cause problems, but I don't think it's the virtualization layers or the specific language that are responsible for more than a sliver of that in the vast majority of use cases.
And the pile of build and distribution tools shouldn't hurt the user at all.
If you have a dozen layers and they each add 5% slowdown, okay that makes a CPU half as fast. That amount of slowdown is nothing for UI responsiveness. A modern core clocked at 300MHz would blow the pants off the 600MHz core that's responding instantly in the video, and then it would clock 10x higher when you turn off the artificial limiter. Those slight slowdowns of layered abstractions are not the real problem.
(Edit: And note that's not for a dozen layers total but for a dozen additional layers on top of what the NT code had.)
These are things we're unlikely to get back (and by themselves already make typical PC stacks unable to deliver smooth hand-writing experience - Microsoft Research had a good demo some time ago, showing that you need to get to single-digit milliseconds on the round-trip between touch event and display update, for it to feel like manipulating a physical thing vs. having it attached to your finger on a rubber band). Win2K on a hardware from that era is going to remain snappier than modern computers for that reason alone. But that only underscores the need to make the userspace software part leaner.
--
[0] - Source: I'll need to find that blog that's regularly on HN, whose author did measurements on this.
http://danluu.com/input-lag/
I think this is the key.
People fall in love with simple systems which solves a problem. Being totally in honey moon they want to use those systems for additional use cases. So they build stuff around it, atop of it, abstract the original system to allow growth for more complexity.
Then the system becomes too complex, so people might come up with a new idea. So they create a new simple system just to fix a part of the whole stack and allow migration from the old one. The party starts all over again.
But it's like hard drive fragmentation - at some point there are so many layers that it's basically impossible to recombine layers again. Everybody fears complexity already built.
I like websockets for the same reason. Each message has a two byte overhead compared to TCP. Two bytes. Unfortunately messages sent by the client have a whopping four additional bytes to help protect buggy middleboxes.
Except...there's no model of precisely how text is handled or how to re-encode it for e.g. screen reading...the development model lacks the abstraction to do layout...and so on. So we added a longer pipeline with more things to configure, over and over.
But - the computing environment is also different now. We can say, "aha, but OCR exists, GPT exists" and pursue a completely different way of presenting many of those features, where you leverage a higher grade of computing power to make the architectural line between the presentation layer and the database extremely short and weighted towards "user in control of their data and presentation". That still takes engineering and design, but the order of magnitude goes down, allowing complexity to bottleneck elsewhere.
That's the kind of conceptual leap computing has made a few times over history - at first the idea of having the computer itself compile your program from a textual form to machine instructions ("auto-coding") was novel and complex. Nowadays we expect our compilers to make coffee for us.
At one point back in school a friend said to me "hey, I can't figure out how to install and boot JVM on Virtual Box. I need to use it for homework in another class. Help me?"
I wish I had been able to explain it as succinctly as you. Instead I sat there laughing in the guy's face for a good minute, eventually realizing from his expression that he was being serious, which only made me laugh even harder.
> Building interactive programs based on HTML or Logo (if anybody does remember)?
Hold my beer: my Github Actions CI scripts use Logo to generate the bash build scripts as images that are then OCRed and executed by a special terminal that exploits the Turing complete nature of Typescript's type system.
Turtles all the way down!
That depends on your scale. If your product is "large enough" it is relatively easy to get into the range of several seconds of response time.
Here are some of the steps you may want to execute before responding a resquest to your user:
- Get all the dishes that have the filters the user selected
- Remove all dishes from restaurants that doen't delivery in the user location
- Remove all dishes from restaurants that aren't open right now
- Get all discount campaigns for the user and apply its effects for every dish
- Reorder the dish list based on the history of the user interactions
Now imagine that for every step in this list you have, at least, a single team of developers. Add some legacy requirements and a little bit of tech debt... That's it, now you have the perfect stage for a request that takes 5-10 seconds.
I mean maybe your DB is a single node running on a potato and your load's very high but you're also somehow never hitting cache, but otherwise... no, there's no good reason for that to be slow.
[EDIT] Your last paragraph is the reason, though: it's made extremely poorly. That'll do it.
It's extremely fast. Super duper fast. And a quick look at the network debugging tab shows why: it loads the shop's entire catalog data (about 3 megs) upfront, and the entire application runs locally with not a single request until you buy something. Now that's efficiency.
Really. Go to their website, clock on KATALOG and click some random buttons, pick a product at random, add it to your cart, remove it from your cart.
The product images are the only things that aren't pre-loaded.
But it was different...
Yeah. It was. That's exactly my point.
A major problem is the number of places in our code stacks where developers think it's perfectly normal for things to take 50ms or 500ms that aren't. I am not a performance maniac but I'm always keeping a mental budget in my head for how long things should take, and if something that should be 50us takes 50ms I generally at some point dig in and figure out why. If you don't even realize that something should be snappy you'll never dig into why your accidentally quadratic code is as slow as it is.
Another one I think is ever-increasingly to blame is the much celebrated PHP-esque "fully isolated page", where a given request is generated and then everything is thrown away. It was always a performance disaster, but when you go from 1 request to dozens for the simplest page render it becomes extra catastrophic. A lot of my web sites are a lot faster than my fellow developers expect simply because I reject that as a model for page generation. Things are a lot faster if you're only serving what was actually requested and not starting everything up from scratch.
Relatedly, developers really underestimate precomputation, which is very relevant to your point. Your hypothetical page layout is slow because you waited until the user actually clicked "menu" to start generating all that. Why did you do that? You should have computed that all at login time and have it stored right at your fingertips, because it is a reasonable assumption given the sort of page you're talking about that if the user logged in, they are there to make an order, not to look at their credit card settings. Even if it expensive for reasons out of your control (location API, for instance) if you already did the work you can serve the user instantly.
Having precomputed all this data, you might as well shove it all down to the client and let them manipulate it there with zero further network requests. A menu is a trivial amount of information.
It isn't even like precomputation is hard. It's the same code, just running at a different time.
"But what about when that doesn't work?" Well, you do something else. You've got a huge list of options. I haven't even scratched the surface. This isn't a treatise on how to speed up every conceivable website, this is a cri de coeur to stop making excuses for not even trying, and just try a little.
And it is SO MUCH FUN. Those of you who don't try you have no idea what you are missing out on. It is completely normal on a code base no one has ever profiled before to find a 50ms process and improve it to 50us with just a handful of lines tweaked. It is completely normal to examine a DB query taking 3 seconds and find that with a single ALTER TABLE ADD INDEX cut that down to 2us. This is the most fun I have at work. Give it a try. It's addictive!
Also, if you work on a website, the Google crawler seems to allocate a certain amount of wall time (not just CPU time) to crawling your page. If you can get your pages to respond extremely quickly, more of your pages will be indexed, and you're going to match for more keywords. So if for some reason people aren't convinced that speed is an important feature for users wanting to use your site, maybe SEO benefits will help make the case.
I was using a SAST program that used MS SQL Server and was generating reports, and often finding the reports took HOURS to generate, even when the report was only ~50 pages. A report on one specific project took over a DAY to generate a report. I thought it was ludicrous, so I logged onto the SQL server to investigate and found that one query was taking 99% of the time. This query was searching through a table with tens of millions of rows, but not indexed on the specific rows it was checking against, and many variations of the query were being used to generate the report. I added the index (Only took about an hour, IIRC), and what took hours now took a couple minutes.
I was always surprised the software didn't create that index to begin with.
In my use case, impact on inserts was not noticed. I did notice higher disk space usage, but it absolutely was worth it. Spending $200 on a larger disk was absolutely worth saving literally days on report generation.
This isn't an argument for not trying though.
That's not always an option for a given work environment, however.
Not at all what I expected from a news site. They're usually full of crap and dog slow.
This is the specific URL I experienced this with. Though the whole site seems mostly very quick. https://www.bbc.com/news/live/world-us-canada-65967464
And this is on a 2017 MBP, which some sites are really slow. Nothing crazy like the new silicon CPUs here either.
Then head to the Newswaffle link and input https://bbc.com or just scroll down the page to head to the converted site.
https://gmi.skyjake.fi/lagrange/
I am interested in your fast loading techniques in general. I also am considering making a bunch of personal / pro websites where I'll use a static generator. Just looking for some inspiration and ideas to steal I suppose.
Since it's kinda fresh pursuit for me, I am still looking to gather some links and do proper research. I wasn't looking to deanonymize you, my apologies.
As far as my inspiration, I use Craigslist and google as my inspiration. I try to get a sleek and simple look like google pages, but maintain the “old school” functionality and layout ideas of Craigslist .
As far as actual development is concerned, I use oracle ARM servers that are grossly overpowered for a webhost, cloudflare nameservers OR CDN, and I keep as much of the development as possible server side with as little JavaScript as I can. An example was a simple blogging system I made. The entire system is set up with a MariaDB table that has “title, date, image url, and content” as the data bits for it, and then each function works on one of two pages: a backend using php session that has all of the functions with get request, and a front end that has all of its content on a page with post requests. There is no JavaScript involved on either page, which means the stuff transmitted over the internet is lesser, the stuff done on the client computer is lesser, and the number of outside calls is lesser. This does make it “less responsive”, but does the blog really need image zoom in on hover and shit like that?
I have found the best way to develop for speed and simplicity is to curb the enthusiasm of the client from “looks as good as possible” to “simple, cheap, fast, and robust, while still looking better than average”
The final suggestion I have is to develop with security AND accessibility in mind first. If you want to put aria links of all of your stuff, it is much harder to go back later and 1) determine what the link does, and 2) write an aria for it than it is to just include it in the first place. Always follow proper form for mitigating risks like SQL injection and XSS, and do as much as possible on the server before you resort to JS.
If you are looking for a couple of sites that I didn’t build, but get the point of what I am trying to do across, check out
Smashingmagazine.com Hacker news doesn’t look the best, but it follows the logic set forth, Openai.com (this one surprised me because if you remove a lot of the slightly more interactive elements it is fast as hell)
If you have any specific questions, ask away and I’ll do my best
When apps have these kinds of interruptions all over the place, that's even worse than just having them at startup.
but putting delay between events (not keystrokes) is nevertheless a good practice
What’s Microsoft’s excuse? Tired of their incompetence being handwaved and a several decades old jank non-solution being held up as acceptable. MS needs more accountability in their teams.
Then again, I guess any other OS might break in same way. Like my Debian VM just kinda stops responding to part of the screen sometimes if programs are maximised...
If you activate the start menu with a keypress it's going to grab focus. Before it grabs focus the previous window in focus will get events. The same applies with panels (drawers? I forget Windows' name for them) in the Start Menu. There's a non-zero time between activation and grabbing focus to receive keypress events.
Everything from animation delays to stupid enumeration bugs can affect a windows not grabbing focus to receive keypress events. Scripting a UI always has challenges with timing like this.
A mainframe terminal has a single input context. You can fire off a bunch of events quickly because there's no real opportunity for another process (on that terminal) to grab focus and receive those events.
Note the above doesn't absolve Windows of any stupid performance/UX problems with bad animation timings and general shittiness. Microsoft has been focusing on delivering ads and returning telemetry with Windows instead of fixing UX and performance issues.
According to an external wall clock the keypress events happen at seconds 1, 2, and 3. The first press triggers a window to appear (menu panels are a type of window). It takes 0.5s to instantiate and register to receive keypress events from the shell. Wall clock time is 1.5s. Nice.
The second window (menu panel) receives a keypress event at wall clock 2s which opens a third panel. That panel because it has more complicated drawing and page faulted so had to fetch a page from disk swap unfortunately took 1.2s to register for focus. A keypress triggered at wall clock time of 3s. Our third panel though didn't register focus until wall clock 3.2s. That keypress went to panel 2 because that had focus when the keypress event triggered. All times greatly exaggerated.
The shell needs to add events to processes' event queues but it can't just arbitrarily add them to every process. It also can't know any individual window wants events until the process tells it so. Unlike mouse events a keypress event doesn't have coordinates so a process can't really figure out the intended target of an event.
A model that prevents preemption means your back to the Win16 cooperative multitasking. A process can't be interrupted until it gives up the CPU willingly. That however means background processes can't do work while a foreground process holds the CPU. If you make just your shell and GUI apps cooperative the responsiveness of the system will end up awful.
In such an OS the APIs would allow you to atomically transfer focus as part of other operations, for example, starting a new program or opening a new window could simply transfer focus atomically to the pending new program/window such that the OS buffers keystrokes until the recipient is ready to receive them. Also, taking focus would require you to advertise what keys you're willing to receive, allowing a focus cascade such that there's never any situation in which keystrokes get delivered to a UI that isn't able to do anything with them. At the top level of the shell there'd be a kind of global command line or palette that is the default receiver of all other unhandled keystrokes. Because focus transfer is always deterministic under this scheme, people can learn where keystrokes will go without timing playing a part.
Office suites have never been good, but office suites in like 2005 seemed to stretch systems to the breaking point.
Lots of consumer software has always sucked out of the box, I guess if you are here you were possibly a technically savvy kid at some point, is it possible that you were just more selective about the types of programs you ran when you were using the computer for fun?
I have fond memories of that, but basically the editor was a UI into a linked list with a blue screen. So not comparable to what people are being asked to do with Word and 365 today.
My personal beef with Word is that it struggles so much with long documents. Trying to read, say, a 300 page spec from 3GPP is miserable.
I still have this instinctual reluctance to change screen resolution in a game's setting screen, even though 99% of the time it's an instantaneous thing these days.
This is not an inherent limitation of CPUs but a part of Windows' exclusive fullscreen concept. Just another thing that was simply accepted as the way things are instead of being improved (until exclusive fullscreen went out of style).
If you get bad performance in a game nowadays it's a good idea to try proper fullscreen. Alt tabbing might be slow, but the game will run better.
Ruby on Rails may not be the poster child for speediness as things get big or complex, but if you aren't fighting the ORM, it's consistently quick from click to data.
Also, RoR is definitely not dead.
Unfortunately I cannot think of a single thing that has gotten better about Spotify since I started using it, and a lot which has gotten worse.
What really drives me mad is the latency of some file selection dialogs for example which can take like 10 seconds.
That's why the obfuscated it and now it takes 30 seconds. (Win 10). Unless you want to save on OneDrive.
There's also Dtrace https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
Another one that can be slow with file dialogs is that sometimes (maybe it has been fixed now) it will try to query whether a networked drive is around on another computer. If it isn't then the call to it can be blocking your file UI.
A third problem I've noticed with file selection dialogs and explorer is that the My Computer 'folder' that contains your disks takes a long time to load. Much longer than any sub-folders on any of the drives.
I think the problem is largely with explorer.exe. If I browse those folders in a web browser the experience is snappy.
Also that threshold is an entire 400ms. We should expect significantly better than that these days.
There is speed, then there is the perception of speed. Crystal got this right.
I'm quite impressed of both .NET and OpenJDK in some metrics, but it is often not resource efficient, which is something I do value.
One example of an application that works as I would expect others to do is MuPDF, Being able to open 20MB+ PDFs in 1/10 seconds on a 10 years+ old laptop.
By the way, does anyone know why Debian launches LibreOffice so much quicker than Ubuntu, Fedora or Archlinux (or any other distro I've tested with)? In Debian its 1-2 seconds, and the others 5-10 seconds. I mean it could be included extensions or how they are configured, but I'm honestly interested.
And it seem to be the start up process that differs, as putting them all in a ram-disk does not alleviate the issue, and restarting the app cuts the time in ~1/2 but equally for each distro.
My guess, as I said first is what default libraries as loaded, and possibly how they are configured. I do however find it strange that this has not been mentioned elsewhere as I've been struck bu this difference for years, when I happen to load a pure Debian install (not what I usually use).
The only exceptions are: 1) the actual build, which is faster on the modern machine, but only for a large number of source files and 2) reading and writing files - a floppy disk cannot beat an nvme drive of course.
Also impressive how our brain is sensitive to all of this.. no matter how impressive a current OS / web browser / jitted js is.. I dearly miss the past eras "behavior".
I have a 2015 MacBook Air I abandoned recently for being so painfully slow to use that I had almost not touched it for months. I have an iPad Air 2 that is basically unusable at this point. Both are 2-3 orders of magnitudes faster than those old computers that work instantly.
But windows and web apps are super slow now too
Think of all the landfills and wasted work hours earning the money needed to fill those landfills. The heavy and rare metals
This is proof that if computers were 10x faster, they would run slower than ours today, because in the past we’ve seen that be true over and over. The software companies will just make heavier and heavier programs and operating systems until we have gained nothing but a significant amount of co2 emissions
Give it some time for the industry to finally mature.
What is worse than that: not being able to predict if inputs will be buffered or dropped during unresponsiveness. I kind of look like an idiot when I keep clicking/typing away on someone else’s computer while things are frozen, thinking “oh, it’ll catch up in a bit”, and then 5 seconds later I have to work harder to fix the chaos: some keystrokes at the beginning made it through, then only every other one, then the next couple hundred got dropped, but the next 100 came through fine, and interspersed everywhere there are bizarre runs of duplicated keys, as if I had held the letter aaaaaaaaaaaaaa down continuously.
Everyone’s mix of hardware, OS, text editor, text editor plugins, etc makes this behavior highly variable, and hard to guess if it makes sense to keep typing or just wait out the frequent 1-5 second lockups.
1GB programs are rarely instant but that's usually just the price for very complex functionality if it's too interconnected to load parts of it on demand.
Imagine if you work on computers for hours everyday what the cumulative impact is
Has anyone else noticed how bad sign-on redirect flows have gotten in the past ~5 years?
It used to be you clicked sign in, and then you were redirected to a login page. Now I typically see my browser go through 4+ redirects, stuck at a white screen for 10-60 seconds.
I'm a systems C++ developer and I know nothing about webdev. Can someone _please_ fill me in on what's going on here and how every single website has this new slowness?
- the database and/or the Tomcat server have way too low RAM and start swapping like no end
- way too many people had admin access in Jira and installed a metric shit ton of plugins
- the AD configuration is messed up and instead of only user accounts it loads (and verifies) tens of thousands of user and machine accounts at each login
After all, why pay for an expensive DMS when you have Jira?
Worse thing is the only reason we have to use it is to log our hours. Because the CIO wanted us to be "agile". Apparently logging ones hours in Jira makes us "agile". Yeah I don't know how either. Someone ticked a nice box there for themself. Now we're just creating a useless swamp of data that has no meaning because there are no guidelines on how to log everything. Normally when you implement the full process that stuff is straightforward because you have things in other places in Jira to link to. Not in this case. The only thing we have achieved is making Atlassian a bit richer.
The same with "cloud". We had to be "on cloud". So what do they do? Migrate every physical server. Every time we need a new "server", we still have to fill in the same 18-page excel sheet. Only the tab with the physical rack location has been replaced with one with AWS locations. We still have the delay of several weeks of approvals and everything runs 24/7, nothing scales automatically or is auto provisioned. This is not "cloud". This is fooling oneself. And paying too much. We're technically in the cloud but we don't take advantage of anything it's actually good at. Paying only for resources we actually use? Nope. Auto scaling demand? Nope. Quick provisioning? Lol you wish. And we can't because the infrastructure architect team has locked everything down so nothing can be automated. They only trust themselves to that as they are the high priests.
It's really time for megacorps to stop trying to be like a startup. It doesn't work, unless you basically rebuild the entire org from the ground up. Which will never happen because it will disrupt too much. Too much legacy, too many strings attached to "the business". Too many processes that will never be changed because it means the entire org would have to change.
Just work with what you have and improve that instead of trying to pretend you're something else.
So while all the redirects are annoying, they are probably better than all the hand rolled auth that failed in various ways.
Not always. AT&T goes through about 25 redirects to sign in. No SSO involved.
* initial page provided by the service you're logging into - this gets your email address so it can lookup your account and determine which SSO provider to redirect to
* actual login page served by your SSO provider - here you authenticate to the SSO provider. It can occasionally cause another page load to get your 2FA code if configured, or go through further identity checks
* final "page" that consumes the query parameters sent back by the SSO provider - this is often just a 302 redirect to the home page but sets a session cookie.
The main problem is that all these pages are super bloated, with tons of unnecessary JS and BS. All the code for login page that takes a username and password should be able to fit entirely on an A4 sheet of paper - it's literally just an HTML form and a few lines of CSS.
Furthermore, even beyond inter-company SSO, there are shitty companies out there which use such flows internally even though everything is part of the same security domain, hosted on the same infrastructure and thus can be hosted on the same top-level domain and use a single session cookie. Microsoft is a pretty bad one - Teams for example will use a redirect to some other Microsoft-owned domain to get your (already existing) Office 365 session; this is completely unnecessary, they can host all those things on the same top-level domain and reuse a single session cookie seamlessly.
If anyone thinks you need more redirects than this, I'd really like to know what more you think is necessary.
Metrics-based and KPI-based software development has ruined quality for decades.
It's dumb and current me would just say that out loud and not participate in this circus.
Bad UX though.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentica...
1. send in plain text with http basic auth. Over https this isn't a problem, but https was expensive). This is sent on every request. 2. Use digest. This is also sent on every request, and also requires actual processing, at which point you might as well go for 4 so it looks nice. 3. Use certificates. Nobody does this on the pubic web. The only website I've ever used certificates was whatever certificate site predated let's encrypt, can't remember the name at the moment, and as someone who doesn't use client certificates it was a huge pain (blame that on the browsers though) 4. Use a form on the website with a session token, and you get control over the UI including error messages and styling. Much more user-friendly. You can trivially prevent the user from (easily) sending requests with pain text passwords by only showing sensitive pages like login over https. The user can't bookmark or share a URL with a password embedded in it. You can request more information than just username and password (Bank: do you want to see your checking account or savings account? Forum: go back to previous page or to homepage? SSO-ish (DayForce): what's the name of the org you're signing into?)
"We" just assume that anyone who has already signed up will always be signed in.
Not everyone wants to stay logged in, and not everyone uses a single browser; I occasionally use the wrong browser profile for something because I cbf loading up the correct one; in these cases I usually load the website in a private browsing tab to avoid container/addon settings interfering. When I can't log in easily, I get quite annoyed.
While it can't easily be used cross-companies (and thus why SAML/OIDC exists), it's perfect for internal company infrastructure, and SAML/OIDC can still be handled somewhat seamlessly by having a minimal service that verifies your Kerberos identity and immediately dispatches you back to whatever third-party service you wanted to authenticate to, with no intermediate login pages or even any kind of UI (this service doesn't need UI because your authentication is managed via Kerberos for which your OS provides the UI).
The problem is that you can't make money (nor "growth & engagement") off stable, battle-tested stuff that already exists and happily works in the background, so Okta/etc shareholders need to peddle worse solutions that waste everyone's time and processing power.
Kerberos is also difficult to administer and secure (Golden Ticket?). Kerberos also requires the target service be a member of the Kerberos Realm (or otherwise trusted) which again means line of sight between the service and TGS or Realm to Realm.
And then we get into the whole ticket size issue.
Kerberos is not a good candidate for web-based AuthN.
Isn't this the same with any SSO provider? The SSO provider must be reachable by the end-user's browser during any authentication operation.
(in case of KB it must be reachable by the target services too, but in a server-to-server environment it's less of an issue)
> Golden Ticket
Isn't this exactly the same to let's say a session cookie of a web-based IdP?
The IdP could apply policies on its backend that bind the cookie to a given IP address, user-agent or other indicators, but can't this also be done for Kerberos tickets using a server-side middleware on every service you wish to access (since KB is internal-only, it shouldn't be that big of a deal)?
Yes, but OAuth has one major upside: HTTPS only.
No one wants to create site-to-site VPN networks to flow Kerberos.
You could argue that the common implementations are large piles of legacy C with questionable memory safety that could open them to exploitation by malicious actors, but that's an implementation detail rather than the protocol itself - and I believe there's at least one (mostly?) memory-safe implementation in Java called Apache Kerby.
It might be done for user retention reasons with the idea that people are more likely to use sites they're already signed into, but I really don't need to be signed into YouTube when I sign into my Google work account. Please just skip that and sign in a few seconds quicker.
You can either do the redirects all at once on login or do them once you use the service first. Since login is already a time-consuming process (username, next, password, next, 2FA, next) I think you may as well take a second to add the redirects and be done with it.
It doesn't make much sense for Google work accounts but it makes sense if those are a minority on the platform. They could definitely patch this out, but then again the login process is something that takes a second extra every month or so, so who really cares.
What does bother me is how every service wants you to enter your username and password separately now. Autofill gets confused and sometimes even stops working because the stupid hidden input fields for the password don't get shown until you click the magical "next" button, just in case you need a special third party auth service.
Either decide that work accounts are important and take out the extra YouTube redirect, or decide they aren't important and let me fill in my username and password on a single form. Both make complete sense individually but combined they're just a massive waste of time.
Explaining it to the SecOps person, that was painful though.
I suspect that the amount of time I spend on just logging in to websites each day is upwards of 5 minutes, and I doubt it will decrease over the coming decades. Such a waste.
The second is because authentication is per-device (and depending on the scenario, per-app). The token lifetime is configured by your IT department. Microsoft's default is 365 days, if I recall.
Go to login page
Solve capcha to get to login prompt
Enter user name, get sent to next page
Enter password
Enter MFA code
Failed, try resynching MFA token
Repeat login process
Failed, try rescynching MFA token again
Failed, repeat login process and then go to troubleshoot MFA link on mfa page
Enter password again
Go to altternative factors link
Click link to send verification email
Didn't get email, click link again
Click link in verification email
Click link on login page to get a phone call with a code
Get a call but it doesn't give me a code, try again
Still no code, try again
Get a code this time from the call but the code fails verification, try again
Get a code and it gets verified, sends me to a login page
Solve a capcha
Enter username and password, get logged in
Fortunately, I have found a solution to ensure this series of issues does not reoccur.
And I suppose the margin is too narrow to contain it?
(Care to share?)
It's a standard meant for system A to authenticate a user with system B. Ever logged in to a website with your Google account, or seen those permission screens asking you if you want to allow a third party website to access your Google account? That's OAuth.
Now, as to why many websites do this even when you login with credentials for that system (and not third party auth) - my guess is the system has separate teams for each subsystem, each hosted on different subdomains. In order to transfer auth state from one subdomain to another, you need something like OAuth since cross-domain cookies are forbidden by the browsers.
Everyone and everything uses OAuth/OIDC.
Terminal ~300ms.
iTerm ~400ms.
Calculator ~300ms.
Firefox ~1s.
Textedit ~200ms.
Slack ~1s to appear, ~5s to load.
Sequel Ace ~800ms.
Fork ~500ms.
All my subjective experience, but it's basically instant in experience. I think it also helps that it doesn't show fade in/out animations, which LOOK sluggish to me.
M1 MacBook Pro from 2020...
I read somewhere that Webkit and specifically Chrome are optimized towards more efficient CPU usage in the expense of a larger RAM use. Probably makes sense in terms of energy consumption but you need more RAM.
Also they added desktop compositing animations.
Opening a command prompt or mspaint is not exactly demanding and opens instantly on modern computers too when all desktop compositing animations are turned off.
This guy is also comparing old HDD to SSD, RAM speed is also magnitudes faster
Windows is especially bad at this due to so much legacy reliance, which is also kind of why people still bother with Windows. Not to claim that Linux or MacOS don't have similar problems (ahem, Catalyst) but it's not as overt.
A lot of the blame gets placed on easy to see things like an Electron app, but really the problem is so substantial that even native apps perform slower, use more resources, and aren't doing a whole lot more than they used to. Windows Terminal is a great example of this.
Combine this with the fact that most teams aren't given the space to actually maintain (because maintaining doesn't result in direct profits), and you've got a winning combination!
It's the fact that manpower can't keep up with the exploding amount of complexity and use cases that happened to computing in the last decades.
We went from CLI commands and a few graphical tools for the few that actually wanted to engage with computers, to an entire ecosystem of entertainment where everyone in the world wants 'puters to predict what could they want to see or buy next.
To maintain the same efficiency in code we had in the 90-2000s, we would need to instantly jump the seniority of every developer in the world, right from Junior to Senior+. Yes, you can recruit and train developers, but how many Tanenbaums and Torvalds can you train per year?
The biggest amount of cruft not only went to dark patterns and features in programs like animations and rendering that some people regard it as "useless" (which is debatable at minimum). But the layers went also to improve "developer experience".
And I'm not talking about NodeJS only. I'm talking about languages like Python, Lua, or even the JVM.
There's a whole universe of hoops and loops and safeguards made so that the not-so-genius developer doesn't shoot themselves in the foot so easily.
I'm sure that you can delete all of that, only leave languages like Rust, C and C++ and get a 100x jump in performance. But you'd also be annihilating 90% of the software development workforce. Good luck trying to watch a movie in Netflix or counting calories on a smartwatch.
Devs at MS have to make everything right in an universe where everything else is dead or crap. And the fact that Windows 11 can even run without crashing daily is an engineering marvel.
PD: Not to defend MS, but I'm sure their current devs are very capable and doing their best.
Microsoft has been trying to migrate Windows development to a managed language for over 20 years; their first attempt at this was a complete disaster and NT 6.0 (Vista) would ultimately be developed the old way.
It's only really been in the last 5-7 years, with Windows 10 and 11, that MS has managed to get their wish as far as UI elements go, which is why the taskbar doesn't react immediately when you click on it any more and has weird bugs that it didn't have before.
You are looking back with rose tinted glasses if you think all software was blazing fast back then. There was a reason putting your cursor on a progress bar to track whether it was moving was a thing.
The reason it's not a thing today is because those progress bars got replaced by spinners and "infinite progress bars". At least back then you had a chance to learn or guess how long slow operations would take. These days, users are considered too dumb to be exposed to such "details".
Like beyond truly "dumb" tasks like downloading a file it's basically a guessing game how long it will take anyway, right? Say you split the whole loading bar into percentages based on the number of subtasks, suddenly you end up with a progress bar stuck on 89% for 90% of the total loading time.
Obviously you could post-hoc measure things and adjust it so each task was roughly "worth" as much as the time it took, but people rarely did that back in the day and my boss would get mad at me for wasting time with it today. Hence, spinners.
Sure. But now as a user, I get to see the glimpse of what's going out under the hood. Combined with other information, such as a log of installation steps (if you provide it), or the sounds made by the spinning rust drive, those old-school determinate progress bars were "leaking" huge amount of information, giving users both greater confidence and ability to solve their own problems. In many cases, you could guess the reason why that scrollbar is stuck on 89% indefinitely, just by ear, and then fix it.
Conversely, spinners and indeterminate progress bars deny users agency, and disenfranchise them. And it's just one case of many, which adds up to the sad irony of UI/UX field - it works hard to dumb down or hide everything about how computers work, and justifies it by claiming it's too difficult for people to understand. But how can they understand, how can they build a good mental model of computing, when the software does its best to hide or scramble anything that would reveal how the machine works?
This doesn't strike me like something "everyone in the world wants", but rather something a small group of leaches is pushing on the rest of the population, to enrich themselves at the expense of everyone else. I'm yet to meet a person that would tell me they actually want computers to tell them what to see or buy. And if I met such person, I bet they'd backtrack if they learned how those systems work.
Exercise for the reader: name one recommendation system that doesn't suck. They all do, and it's not because recommendations are hard. Rather, it's because those systems aren't tuned to recommend what the users would like - they're optimized to recommend what maximizes vendor's revenue. This leads to well-known absurdities like Netflix recommendations being effectively random, and the whole UX being optimized to mask how small their catalogue is; or Spotify recommendations pushing podcasts whether you want them or not; or how you buy a thing and then get spammed for weeks by ads for the same thing, because as stupid as it is, it seems to maximize effectiveness at scale. Etc.
> I'm sure that you can delete all of that, only leave languages like Rust, C and C++ and get a 100x jump in performance. But you'd also be annihilating 90% of the software development workforce. Good luck trying to watch a movie in Netflix or counting calories on a smartwatch.
I'll say the same thing I say to people when they claim banning ads would annihilate 90% of the content on the Internet: good. riddance.
Netflix would still be there. So would smartwatches and calorie counting apps. We're now drowning in deluge of shitty software, a lot of which is actually malware in disguise; "annihilating 90% of the software development workforce" would vastly improve SNR.
The early 00’s “open standard” of web forum + eMule + VLC would still be light years ahead of Netflix&co. if it weren’t for how hard it’s been gutted by governments, copyright lobbies, ISPs and device/platform vendors through the years. Heck, the modern equivalent often still is (despite all the extra hoops), unless you are trying to watch the latest popular show in English.
It later turned out to be due to some Unicode handling in-built into a windows api they were using, while the developer’s version also not completely feature-complete. But both sides were sort of right.
Part of the "problem" with Windows is also lack of legacy reliance. As in: MacOS and Linux are at heart Unix systems, with a kernel architecture meant for 1970s hardware. The Windows NT kernel family is a clean-sheet design from the 1990s, a time where compute resources were much more plentiful.
For example, on Linux file system access has (by default) very basic permissions, and uses a closely coupled file system driver and memory system in the kernel. On Windows there is a very rich permission system, and ever request goes through a whole stack of Filesystem Filter Drivers and other indirections that can log, verify or change them. This is great from a functionality standpoint: virus scanners get a chance to scan files as you open them and deny you access if they find something, logging or transparent encryption is trivial to implement, tools like DropBox have an easy time downloading a file as you access it without dealing with implementing a whole file system, the complex permission system suits enterprise needs, etc. But on the other hand all these steps make the system a lot slower than the lean Linux implementation. And similar resource-intensive things are happening all over the kernel-API in Windows, simply because those APIs were conceived at a time when these tradeoffs had become acceptable.
Yes, but still it seems to be useless to implementers, because practically every virus scanner implements braindead stuff like DLL injection for on-access-scanning.
I thought that the NT Kernel was heavily based on VMS. When Dave Cutler, their chief OS architect/guru left for Microsoft and took a bunch of engineers with him. FTA:
"Why the Fastest Chip Didn't Win" (Business Week, April 28, 1997) states that when Digital engineers noticed the similarities between VMS and NT, they brought their observations to senior management. Rather than suing, Digital cut a deal with Microsoft. In the summer of 1995, Digital announced Affinity for OpenVMS, a program that required Microsoft to help train Digital NT technicians, help promote NT and Open-VMS as two pieces of a three-tiered client/server networking solution, and promise to maintain NT support for the Alpha processor. Microsoft also paid Digital between 65 million and 100 million dollars."
[0] https://www.itprotoday.com/windows-client/windows-nt-and-vms...
I think this blame is fair. Electron is the most obvious example, but in general desktop software that essentially embeds a full browser instance because it makes development slightly easier is the culprit in almost every case I've experienced.
I use a Windows 10 laptop for work.[1] The app that has the most lag and worst performance impact for as long as I've used the laptop is Microsoft Teams. Historically, chat/conferencing apps would be pretty lightweight, but Teams is an Electron app, so it spawns eight processes, over 200 threads, and consumes about 1GB of memory while idle.
Slack is a similar situation. Six processes, over 100 threads, ~750MB RAM while idle. For a chat app!
Microsoft recently added embedded Edge browser controls into the entire Office 365 suite (basically embraced-and-extended Electron), and sure enough, Office is now super laggy too. For example, accepting changes in a Word doc with change tracking enabled now takes anywhere from 5-20 seconds per change, where it was almost instantaneous before. Eight msedgewebview2.exe processes, ~150 threads, but at least it's only consuming about 250MB of RAM.
Meanwhile, I can run native code, .NET, Java, etc. with reasonable performance as long as the Electron apps aren't also running. I can run multiple Linux VMs simultaneously on this laptop with good response times, or I can run 1-2 Electron apps. It's pretty silly.
[1] Core i5, 16GB RAM, SSD storage. Not top of the line, but typical issue for a business environment.
It's not an easy task, and it's not something that anyone has really done. There are plenty of single platform examples, and Flutter is about as close as you can get in terms of cross platform.
There are also alternatives that can use the engine of an installed OS browser. Tauri is a decent example for Rust. Also, Electron isn't to blame for the issues with Teams. VS Code pretty much proves you can create a relatively responsive application in a browser interface.
It has been done many times.
Not only that, if you want to use a web page for a GUI, then do it by making a local web server back end and just use the web browser.
This idea that electron is somehow the only way to get cross platform GUIs is some sort of bizarre twilight zone where a bunch of people who only know javascript ignore that last three decades of software.
Also, I never said Electron was the only way... I specifically mentioned Tauri in my comment as an example of a browser renderer. And it doesn't need to use a local web server either.
And it doesn't need to use a local web server either.
Shipping an entire browser so someone can pop up a single window is not a positive. Again, if you want html as your interface, use html and let people use their own browser so that the entire program is 400KB instead of 400 MB
FLTK, no accessibility features
WxWidgets, really limited theming, not even close to html+css. Cross platform compatibility is hit and miss, usually requiring a lot of one-off platform corrections.
Also, as I said, you don't need to ship the entire browser... not once, but twice... try reading slower.
It's LGPL, lots of programs use it like qTorrent, VLC and much more. You can make up criticisms but it has been a backbone of GUIs for decades.
FLTK, no accessibility features
What exactly do you need and do you need it for every GUI you make? If you want a web page, use a web page.
WxWidgets, really limited theming,
Suddenly theming is your deal breaker.
not even close to html+css
Thankfully, because that is often not a good way to make a GUI.
as I said, you don't need to ship the entire browser...
No, you said "it doesn't need to use a local web server either." Also 'entire web browser or not' electron programs end up being hundreds of megabytes for a simple window use hundreds of megabytes of RAM.
The bottom line here is not that electron is necessary. It is that you want to use javascript even though your users will hate it.
A GUI toolkit that has no support for screen readers, or other assistive technologies that require accessibility APIs, should be a non-starter for most applications IMO. We need more options that meet that criterion without going all the way to a web page.
Again, not that I'm advocating for Electron specifically, and haven't been. I've specifically mentioned Tauri and others as alternatives that use the system's browser engine, which you have repeatedly ignored.
What does this mean? What specifically do you think is being prevented?
The only other significant advantage is they are easier to jail/isolate for use with the likes of appImage, Snap and Flatpak/Flathub.
How is a program with hundreds of megabytes of dependencies easier than a single small statically compiled binary?
Again, not that I'm advocating for Electron specifically,
This thread was about people using electron even though users hate it.
So, you've failed to meet the requirements from the start.
I've also said, many times now, that you can use browser tech without an entire browser and the answer doesn't need to be electron.
Consider the feature set of JavaFX when used in combination with the AtlantaFX theme/widget pack. It isn't well known, but is maintained and has an active open source community today.
- All the same controls as mui.com shows and more advanced ones too, like a rich text editor, a way more advanced table view, tree views, table tree views, etc.
- Media and video support.
- 3D scene graph support. HTML doesn't have this! If you want to toss some 3D meshes into your UI you have to dive into OpenGL programming.
- When using FXML, semantic markup (<TabView> etc)
- Straightforward layout management.
- A dialect of CSS2.something for styling, a TextFlow widget for styling and flowing rich text.
- Fully reactive properties and collections, Svelte style (or moreso).
- Icon fonts and SVG works.
- Sophisticated animations and timelines API.
And so on. It's also cross platform on desktop and mobile, and can run in a web browser (see https://jpro.one where the entire website is a javafx app), and can be accessed from many different languages.
Flutter is actually not quite as featureful in comparison, for example there's no WebView control or multi-window support on desktop, though Flutter has other advantages like the hot reload feature, better supported mobile story. The community is lovely too.
Then you have AppKit, which is also very feature rich.
So it's definitely a task that people have done. Many of these toolkits have features HTML doesn't even try to have. The main thing they lack is that, well, they aren't the web. People often find out about apps using hypertext and being able to have a single space for documents and apps is convenient. When you're not heavily reliant on low friction discovery though, or have alternatives like the app stores, then web-beating UI toolkits aren't that big of a lift in comparison.
> Electron isn't to blame for the issues with Teams. VS Code pretty much proves you can create a relatively responsive application in a browser interface
Electron is great, but most apps aren't VS Code. On my 2019 Intel MacBook Terminal.app starts in <1 second and WhatsApp starts in about 7 seconds. Electron is Chrome and Chrome's architecture is very specifically designed for being a web browser. The multi-process aspect of Chrome is for example not a huge help for Electron where the whole app is trusted anyway, though because HTML is so easy to write insecurely, sandboxing that part of it can still be helpful even with apps that don't display untrusted data. That yields a lot of overhead especially on Windows where processes are expensive.
I also said, "Flutter is about as close as you can get" regarding coming close to what I was referring to.
AppKit is NOT cross-platform. Beyond this, you have other means of embedding a browser-ui application without all of chrome included, see Tauri as one example.
Just to make sure I'm not being one of those people: What AccessKit [1] has now, across Windows, macOS, and Linux, took roughly six person-months of work. We still need to support more widget types, especially list views, tables (closely related), and tree views, but we do already have text editing covered on Windows and macOS. Perhaps it helps that I'm an accessibility expert, especially on Windows. Anecdotally, it seems that implementing UIA from scratch is daunting for non-experts. But I guess in the big picture it's really not that hard.
[1]: https://github.com/AccessKit/accesskit
Almost like some kind of... web OS?
To think we almost had it, but Palm made some bad decisions back in 2009 and the dream of app-as-browser + Node.JS + consistent application styling and syscalls through a provided JS framework (Enyo) is, sadly, probably dead forever.
That "slightly" is doing a massive amount of heavy lifting in that sentence.
I run a company on the side that produces software for events which require a website and mobile apps for iOS (iPhone and iPad)/Android. I cannot imagine being able to do this all on my own without being able to share a codebase (mobile apps built via Capacitor) across all of them. Would native apps be faster? Almost certainly but I'm not going to learn Kotlin and Swift and triple the number of codebases I have to work it. It's completely infeasible for me, maybe some of you are able to do that but I'm not, there aren't enough hours in the day.
I fully understand the cruft/baggage that methods like this bring but I also see first-hand what they allow a single developer to build on their own. I'll take that trade. I'm a little less forgiving of large companies but Discord and Slack (and other Electron apps) work fine for me, I don't see the issues people complain about.
What are the specs on the machine you're using?
By requiring more than that, we had to increase the essential complexity. I believe this tradeoff in itself is well worth it (and hopefully we can all agree on that going back to us-ascii-only locale is not a forward direction).
The problem I see is that the layers you also mention, each expose leaky abstractions (note that abstractions are not the problem, no person on Earth could implement anything remotely useful without abstractions — that’s our only tool to fight against complexity, of which a significant amount is essential, that is not reducible). Let’s also add a “definition” I read in a HN comment on what constitutes an ‘expert’: “knowing at least 2 layers beneath the one one is working with” (not sure if it was 1 or 2).
Given that not many people are experts and a tendency of cheaping out on devs, people indeed are only scratching that top layer (often not even understanding that single one!), but the problem might also be in how we organize these layers? When an abstraction works well it can really be a breeze and a huge (or only significant, see Brooks) productivity boost to just add a library and be done with it — so maybe the primitives we use for these layers are inadequate?
Not my area but AFAIK modern (electron based) desktop apps are less accessible then classic win32 apps from win2k - win7.
You just describe modern Web Development.
Yes.
By the way, I do my math with bc -l from the command line.
It is not the main thing going on in this twitter post, but it does show a way modern computers feel slower than older machines.
[1]: https://winmerge.org
Windows NT 3.51 minimum hardware requirements were a i386 or i486 processor at 25MHz or better and 12MB of RAM for the workstation version. So the 600MHz machine with 128MB RAM is exceeding the minimum requirement by (conservatively) 24x in CPU speed and 10x in RAM, along with all the architectural improvements from going from the i386 to what's presumably a Pentium III-class machine.
If that's actually a Surface Go 2 running Windows 11 - well, it doesn't have a quad-core i5 as the tweet claims - the Surface Go 2 came with a Pentium Gold or a Core m3; both with only two cores and of those is an ultra-low power variant.
As such, that exactly meets the minimum CPU specification for Windows 11 and only doubles the minimum 4GB RAM requirement.
I'm not trying to apologize for the difference here, but it's not an entirely like-for-like comparison.
(Also there was a period when a lot of laptops used non-Intel x86 implementations, which typically weren't very good. Cyrix, Via et al.)
I see similar sluggishness opening command prompt on my Ryzen 3700X with 64GB RAM on Windows 11 22H2 with an NVME SSD. First it draws the outline of the window then fills it in with content. And that's repeatable!
So no, it's not really fair to compare a 'simple' text editor.
If you edit the same 1KB file on each computer side by side the 30 year old computer will be more responsive than the modern one.
That's what people are taking issue with.
A huge number of security related things are going on.
Also windows logs a ton of telemetry these days.
Notepad2 is my all-time favorite though. It supports key features like line numbers and directionless search, but is much closer to stock than Notepad++. [0]
[0] https://www.flos-freeware.ch/notepad2.html
Maybe it is a spinning rust disk. Even then there's a world of difference between a period accurate drive and a late model IDE drive. The last IDE drives had more drive cache than most desktops had RAM when NT was new.
Bloat is intentional and fills Microsoft’s wallet.
Optimization drains Microsoft’s wallet.
But I think the reason that most modern software performs badly is because of optimization: we're optimizing to reduce production costs over increasing performance.
It's economic in nature. We minimize production costs by using frameworks and other labor-saving tools. The code produced using these tools tends to be poor, but hardware is cheap enough to make up for poorly performing software.
It's an intentional decision.
Well, all of that type of bloat is presumably useful to someone or it wouldn't have been written. That doesn't change the fact that there's a cost for including it.
> Windows indexes files in the background
But here's an example of the tradeoffs. I hate this behavior. It incurs an overhead that provides no benefit that matters to me. So, your useful feature is my useless bloat.
Everything's a tradeoff.
Turn it off then?
I have a Windows 10 VM I use for some testing and such, and all these background things keep using up huge mount of resources, no matter what knobs I turn and regedit levers I pull I just can't get it to stop.
For comparison, I also have a macOS VM which certainly isn't fast, but nothing like the Windows one. And the BSD and illumos VMs work basically fine (although in fairness they also don't start X11; but I do just ssh in to all of these machines and never use the GUI for anything).
If bloat is useful, notepad in any form on any version of Windows is bloat by definition.
You've got CLI editors that are smaller.
Ships with a TCP/IP stack by default? Just bloat.
Mouse support out of the box? Who would want that?
For some reason even in fairly constrained subtrees it takes forever to find file names.
This was done also in Win 7. It didn't have such a performance hit, but it was the first thing to be disabled after installing windows.
Back then I would turn it off as I didn't find the search function that usable, and more than once I've had a "clean and build" process fail because some file was open and being indexed, and since Windows locks files on read, the build could not delete the file and just aborted. So, I turned it off.
I notice that I get completely different results on my home and work machines doing the "start button, type" search. for "Downloads", expecting C:\Users\Username\Downloads, the home machine figures it out after three characters. The work machine seems to have decided that I clearly want "File Explorer, not any particular directory" and "Change how I download updates in spite of it being a corporate-managed box where I probably can't push that button without asking IT to remote in and do so" are what I want, even when I spot it the whole directory name.
Two threads in !OpenAdatper12 spending ~1.5M cycles per second. Two threads in !recalloc spending ~256K cycles per second.
As shipped, this is no longer a single executable, it is a collection of 230 files, totaling 10.5MB, about half of which are bytewise duplicates, and another significant chunk have overlapping responsibilities, between the icon fonts and png icons.
"Software bloat is a process whereby successive versions of a computer program become perceptibly slower, use more memory, disk space or processing power, or have higher hardware requirements than the previous version, while making only dubious user-perceptible improvements or suffering from feature creep." -- https://en.wikipedia.org/wiki/Software_bloat
I'm not aware of any substantial new features. It uses a new renderer, but this does not produce a significant observable difference from the previous one beyond using more memory. It supports dark mode.
Don't forget what Notepad.exe truly is -- a testbed for new technologies. It's not "just a text editor" to Microsoft.
It also describes a very real thing.
While there are a lot of things that everyone would agree counts as "bloat", there are also areas of disagreement in the form of "one person's bloat is another's essential feature".
I'm not sure why Msft put that CPU and RAM combo in their own device when it's just barely past the minimum specs for Windows 10 let alone 11.
Microsoft has essentially turned the OS into one of those websites which show ads, news letter dialogs, cookie notices, location permission requests, notification requests and so on constantly.
I'm not sure why Windows minimum hardware requirements are relevant at all. If they were, they could get massive performance improvements by raising the hardware requirements. "Sure it's slow, but it's running on literally 1% of minimum recommended RAM!"
I now use a Surface Go3 i3 with 8GB. It's enough for just about everything I need. Web browser, running script language web apps, Java IDE, StarCraft 2. Disabling a bunch of stuff on Win11 makes a big difference. Whenever it felt slow I looked at Task Manager CPU and googled the process name, tried disabling it and only re-enable if necessary. Oh I also have a Peltier cooler+fan that cools the back of the unit when gaming to prevent throttling.
The PS/2 NT machine was top spec at the time. The Go3 is utilitarian now though should be like a supercomputer.
[0] https://news.ycombinator.com/item?id=36503983
Since the aggregate GHz and RAM on offer is more than 25x the minimum spec for windows 10.
Win10 min spec is 1GHz w/ 2GB of RAM - my machine is more than one hundred times faster, yet, everything TFA says is true.
WinNT 3.51 was released in 1995 - the fastest PC in 1995 was either a Pentium or Pentium Pro at ~100 MHz - in 2000 a 600 MHz machine is likely a Coppermine PIII.
A fairly common amount of RAM in 1995 to Run WinNT would have been around 32 megs of ram, 64 megs would be especially generous. 128 megs is a high end workstation amount of memory.
The ATA interface also doubled in performance between 1995 and 2000.
There were significant security and stability improvements between NT 3.51 and Windows 2000 - particularly with changes to the driver model that increased stability. (even more so between 2000 and Windows 10/11)
>For those thinking that the comparison was unfair, here is Windows 2000 on the same 600MHz machine. Both are from the same year, 1999. Note how the immediacy is still exactly the same and hadn’t been ruined yet.
https://twitter.com/jmmv/status/1672073678102872065
cmd, control panel, and most of the things in admin tools launch virtually instantly.
This is for a machine that is running on relatively slow spinning disks too.
I also struggle with the comparison between high-end hardware of yesteryear, and low end hardware of today and comparing.
Try running win2k in 16mb, 300mhz P2, and a 4800rpm drive.
The only times I remember experiencing things this fast in my computing career were (a) with a fair wind, and a fully warmed cache that didn’t hit the disk & was a trivial app (b) the first time I used my Apple M1 Max MBP.
This is addressed in the linked thread.
>For those thinking that the comparison was unfair, here is Windows 2000 on the same 600MHz machine. Both are from the same year, 1999. Note how the immediacy is still exactly the same and hadn’t been ruined yet.
If memory serves me they did not really change much in NT from 4.0 to 2k. Other than add in more services and make it more win98 like. So it is maybe not an 'unfair' comparison. But win 3.51 came out getting that sort of computer just would not be in the cards for most people.
Windows went sideways at vista. The 'start the computer up' out of the box would use 2-3gig of ram. Up from 100-200MB from the XP era. Toss in some corp bloatware items. One place I saw it was 10gig just to open the desktop no productivity software even started yet. Then add in the zillions of indirect layers we have added to make programming easier and we are now with applications that seem to start at about the same rate as 25 years ago.
All of those old API's are still there. No one really uses them much anymore. We use the latest cool frameworks. That use the previous cool framework that eventually uses the old APIs :)
Spoiler: it was still just as fast.
Why does it follow that software designed for modern hardware, running on modern hardware, should be slower than software designed for older hardware running on slightly newer hardware?
I can run Windows 95 applications at better than era-appropriate speed, in an x86 emulator written in javascript running on a web browser. That's at least 3 layers of virtual machine abstraction and the applications are still faster.
So if you're saying "the comparison isn't fair because modern software is too shit to hold up", then I agree, but if you're trying to tell me there is something else inherent to modern computing that makes software so many orders of magnitude slower, than I request that you show data to support that claim.
I wonder if the 600MHz machine in this video is fitted with an SSD of some sort, this would load applications far faster than the average hard drive from 1998.
Turning on a TV in 1975: wait 60 seconds for the tube to warm up.
Turning on a TV in 1985: wait 10 seconds for the tube to warm up.
Turning on a TV in 1995: wait 2 seconds for the tube to warm up.
Turning on a TV in 2023: stare at the LG logo for 20 seconds, then wait another 30 seconds "for Smart Services to become available" in order to change the channel.
Now things still work, but the TV needs a restart about once a week if I use the built in apps like YouTube or Netflix.
Finally bought an Apple TV 4K and it "boots" directly into it. Such a relief! (Well, except for that bizarre touch remote that came with the Apple TV, but that's a small price to pay!)
Notepad? Kind of. Newer UI library so it handles display scaling a lot better. Handles different line endings and encodings much better now. Handles the system UI dark mode. The interface supports tabs.
Can you name a few that could explain the 1,000x performance cost?
Also, have you heard the story about the guy who told MS that their terminal was shit and could be fixed, only to be ridiculed by a fleet of "super elite 500k/year engineers" that in the end turned out to be ... wrong?
Tabbed interface
Support for command interpreters other than just CMD
Multiple profiles for different interpreters and settings
Support for a much wider range of console control characters and terminal emulations (ssh'ing into linux boxes works really well)
Way better resizing support
Clickable URL detection
More (and customizable) keyboard shortcuts
Support for background images
Support for transparency
Configurations as easy to transfer JSON files
Copying text is a way better experience
Just a few of the features that I use all the time. I can't stand using cmd.exe anymore, its an absolutely miserable experience in comparison.
Fixing this situation is essentially impossible because it requires rewriting almost everything that modern Windows is built on. Someone else in this thread said you couldn't sell 4 quarters worth of work to fix this, but the reality is that it requires infinite quarters, because it requires throwing away the last 10 years of Windows shell and UI work and that will never happen. You could paper over it by applying performance spotfixes here and there, but it'll never go back to how it could be that way. At a minimum, you'd essentially have to throw away WinRT which has an almost viral negative impact on performance. Never before have high latency, but still synchronous cross process RPCs been that prevalent and everything's a heap allocated object, even if it's within the same binary. It's JuniorFootgunRT.
> effectively ~90% of the startup duration is spent starting up WinUI and having it draw the tab bar and window frame
I listed "Display scaling support", "Tabbed interface", and "transparency". Is none of that related to WinUI and drawing the tab bar?
Display scaling is very fast in GDI apps and has no impact on launch time, a tab bar is essentially just an array of buttons (minimal impact on launch time?) and transparency is a virtually cost-free feature coming from DWM. I wrote a WinUI lookalike using its underlying technology (Direct2D and DirectComposition) directly one time and that results in an application that starts up within ~10ms of CPU time on my laptop, quite unlike the 450ms I'm seeing for WinUI. That is including UIA, localization and auto-layout support.
O RLY?
Do you have a transparent terminal with a background image? (If so, well ... to each its own :^))
Do you transfer your JSON config files "all the time"?
>Copying text is a way better experience
It literally is Ctrl-C and it's been like that for ages. When did it become a "way better experience"? I missed that.
Modern UX is absolute trash performance-wise. And you're falling into the same pit as the geniuses of the story I mentioned before.
And no, copying text hasn't been Ctrl+c. That sequence sends a sigint to the process, not a copy request. To copy text by default cmd made you enter a mark mode which then had you essentially draw a rectangle and it would then copy as newline characters even when it should have just continued the line. The old copying process of cmd is terrible.