Windows 10 explorer.exe is 100x faster than Windows 11 explorer, it's not even close.
It also signals the death knell for Windows native apps. Microsoft can't make them anymore. It won't be long until even Excel is a Electron sloplication.
I have a hard time believing this. I'm pretty sensitive to performance losses and I haven't noticed any difference between those. It wouldn't make sense either, given they should both host the same shell icon views. Are you sure the difference you're seeing is in explorer.exe? As opposed to something else, like a new shell extension or a new filesystem filter driver on Windows 11?
M$ has now introduced web-latency into the desktop along with their adoption of web-tech into the OS. You gotta get used to staring at that spinning blue circle, counting the many precious moments of your life draining away.
So we're back to the woes of Active Desktop on Windows 98. Everything old is new again.
Ultimately, what difference does it make? The file explorer in Windows 10 is much faster than the one in Windows 11, and it's very noticeable. Turn on the old context menus, and try right clicking a file. Instant in Windows 10, visible delay in Windows 11.
It does offer some new features for businesses. Nothing useful for the consumer, and nothing to justify the massive performance loss
The new calculator even manages to screw up basic input. The old calculator accepted both commas and periods as decimal separator inputs. It just worked no matter what I typed in. The new calculator has some sort of "clever" localization where my inputs change depending on the language of the operating system. My language uses commas so of course it only accepts those. Infuriating. Hope whoever coded this is enjoying their promotion.
browser.urlbar.suggest.calculator = true
I don't know if you need to restore the urlbar first, before that works.It wasn't very sophisticated. But it was fast and it handled commas and periods. It wasn't localized, but it could be.
Sad to think that me having a month of coding experience made a better product than MSFT, yet whoever coded the calculator is probably making ten times what I am right now.
To me it's not sad, it's infuriating. This corporation is worth a trillion dollars. Why can't they do their jobs? I'm sure the old calculator could be maintained and improved without screwing it up beyond belief. Send us some fat stacks and we'll do it.
Reminds me of the shitty gamer laptop manufacturer apps that would take over a minute to display a glorified rectangle on the screen. All this to configure keyboard LEDs. I reverse engineered that garbage and made a Linux version that works instantly, proving their incompetence.
An i9 with 128GB RAM isn’t enough resources to open a menu?
The slowdown appears to be due to XAML Islands, which allow legacy code to use modern MS UI stuff.
https://www.techindeep.com/why-is-windows-explorer-slow-7289...
20231109 https://news.ycombinator.com/item?id=38212453 Windows 11 Update 23H2 is stealing users' IMAP credentials (666 points, 278 comments)
> the new Outlook is a thin wrapper around the cloud version, so the IMAP sync happens in the cloud, not locally
Btw, just before that I found this page regarding Edge, and this is why I paid more attention to these things: https://learn.microsoft.com/en-us/legal/microsoft-edge/priva...
That list is way too long for my taste, and it really indicated me that Windows became completely adversarial.
Literally the best parts of Windows have been the parts they forgot existed for 10+ years and never changed.
Somehow in this timeline AI can only be used to make things worse and sloppier
The inverse has been happening. AI seems to be best at JS and React, so many projects use this just to have the best results. I think this is the whole reason that Claude Code is actually React that's then mapped onto a terminal.
AI code that isn't properly guided and controlled by an engineer is just as sloppy as the human behind it.
AI is an accelerate for programming, but some developers create horrible code before AI, snd AI won't change that. It just lets them do it faster.
That being said, no one ever looked at good code and said "that's AI gold," so opinions may be skewed.
I don't think that was ever not the case. The popular UI toolkits include a WYSIWYG editor where you can pick widgets and just put them where you want them with the mouse. Sure, that might not be what developers like to use, but invoking a widget constructor is not that hard and gets you a lot more functionality out of the box, that you would need to implement in JS.
Cross-platform GUIs is also more of a problem of theory. It used to be a big thing, because the GUIs don't look native to the platform, but that concern has gone out of the window with websites now. Win32 programs run with WINE, which I guess is not desirable for deploying to ordinary users, but I guess the people who write for Win32 generally do not care much about porting their programs outside of MS Windows. GTK+ and Qt both run on MS Windows. TCL/Tk comes built-in with Python and looks native on MS Windows.
Encoding algorithms is not that much different across C-like (Algol-derived) languages. Registering callbacks also looks kind of the same. I guess what makes a real difference is the ubiquity of async in JS, where you would use threads more in native applications.
I think what is an actual difference is the mindset around styling and layout. This is something that you actually need to adapt. CSS is more declarative, much like writing constraints for sizes, because you just write a formula about e.g. size in relation to other sizes. On native toolkits you would need to implement this stuff imperatively, I guess this looks like a real downgrade coming from the web, but it is really just a different mindset. Also when you run on the actual machine you have actual access to the device/viewport characteristics and can adapt based on that, and don't need to write an abstract layout. The other side of the coin is that the default widget packaging mechanism has been grid based while CSS only gained that later.
What I guess is also easier in JS, is just drawing on a canvas. The native UI toolkits want to nudge you into implementing a custom widget which implements all the required functionality of widgets. That results in a way better interface for the user, but when you just want a raster graphic you can click on, it can feel like a huge waste of time.
Since now native toolkits also support CSS, have JS bindings and Webpage targets, a guess the difference blurs.
Think one step ahead. They will want you to pay them for some LLM "agent" to use the GUI instead. It's not important that GUI is human usable anymore, actually the opposite.
They forgot that Enterprises are made out of Users.