> The problem is that Microsoft's implementations suck. Apple's are thoroughly mediocre and that's ok, people who want more can easily get more, but Microsoft is too afraid of cannibalising Outlook and what not to really commit to it.
I find it shocking how bad Microsoft is at this.
I had my dad, who isn't the most tech literate person, set up on the Windows built-in mail client for a while, which I thought worked pretty okay, a decent default solution.
At some point a banner appeared in the App, saying that it was being deprecated in favor of "The New Outlook".
I thought okay, I am personally using Outlook for work on my Mac because of an IT policy, and I found it to be an alright Email client there, and it's one of Microsofts flagship office programs, surely it's gonna be a good experience on Windows right?
It was a complete nightmare, immediately during setup it turned out that "The New Outlook" doesn't support regular IMAP/SMTP Email setups, only account login via outlook.com or google mail (I assume this changed now), so I had to switch him to whatever the "old" outlook is, an extraordinarily convoluted looking piece of software with comically bad user experience, nothing like the Mac version. I genuinely felt bad putting my Dad through this, and it's wild to me that they manage to deliver a so much worse experience on their own platform than on Mac.
"New Outlook" is an entirely new codebase (yup... targeting Electron).
From my sources within MSFT, the Outlook codebase is amongst the gnarliest of all in the Office org (though probably not as bad as Word's text layout+flow algorithm...), so it's not really that surprising to me that MS wants to rewrite Outlook instead of continuing to try (seemingly in vain) to refactor the codebase.
Part of me also thinks the problem might be inter-generational: a lot of Gen-Z programmers will have started-off with the NodeJS ecosystem and I imagine they also have less overall exposure to C/C++ - and probably even less experience with Win32/COM/COM+/DCOM, which is the foundation of Outlook.
...still, dropping compatibility with VBA, macros, and COM Automation in a top-tier Office product is definitely a shoot-of-your-own-nose-to-spite-your-face movement by MSFT.
> Part of me also thinks the problem might be inter-generational: a lot of Gen-Z programmers will have started-off with the NodeJS ecosystem and I imagine they also have less overall exposure to C/C++ - and probably even less experience with Win32/COM/COM+/DCOM, which is the foundation of Outlook.
My team around 2014 in Microsoft had problems finding people who wanted to learn COM, I think at one point we literally drew straws for who'd have to learn it.
The Office org has plenty of Win32 C++ people, but even there they are outnumbered now days thanks to all the other platforms.
FWIW I spent a year in the Office org, and while the code is impressive in many ways, doing anything in it is very hard. Not necessarily because the code is bad, it is just that it is big, with lots of history and layers, so doing simple things like getting an image passed around through various parts of the code means jumping through lots of hoops.
The other issue is that now days Windows programming skills are basically non-transferable. It used to be everything ran on Windows, so if you spent some time at Microsoft learning the depths of Win32, you were easily employable as a senior/principal engineer at a ton of other companies.
Nowadays the number of C++ Windows development positions is so low that unless a developer wants to spend their entire life at Microsoft, learning native Windows development is basically wasted time on the resume.
> The other issue is that now days Windows programming skills are basically non-transferable. It used to be everything ran on Windows, so if you spent some time at Microsoft learning the depths of Win32, you were easily employable as a senior/principal engineer at a ton of other companies.
>
> Nowadays the number of C++ Windows development positions is so low that unless a developer wants to spend their entire life at Microsoft, learning native Windows development is basically wasted time on the resume.
And it's a negative-cycle too: competent (let alone expert) desktop app developers will become a rare-breed as the capabilities of the web platform (i.e. Chromium) keep on growing, year after year. I figure that eventually even the most web-unfriendly and nativist of native desktop applications (e.g. Photoshop, AutoCAD, et cetera) will end up as WASM blobs rendering to a <canvas> as their UI slowly shifts from whatever in-house Win32 wrappers they have to HTML+CSS. I don't think Tim Berners-Lee could have ever imagined that.
...and this is all because MSFT couldn't put together a consistent and coherent modern desktop development story after VB6 got killed in 2001. If you're some wide-eyed kid in 2012 who wants to make a simple form/window/app that plays fart sounds when you click a button it's 100x easier to do that in HTML+JS than in WinForms/.NET (whereas in VB6 it might even be easier than in HTML+JS, tbh).
The biggest shame here is that as everything moves to the web and off from desktops, we'll lose control over our own data: what incentive would 2033's Adobe have to let you download your own PSD files from the WASM-only Photoshop of the future?
The shitshow that was Win32 -> Windows Forms part 2 (non native "Strip" controls) -> WPF -> WinRT -> UWP -> WinUI 2 -> WinUI 3 pretty much killed any chance at a nice cross platform native-UI library developing. Even Qt tells people not to use the native windows theme anymore since you don't even get a dark mode.
Several years back I needed to prototype a website, so I spent less than a day putting something together in WinForms that had all the functionality I needed. I hadn't used WinForms for several years at that point, but Visual Studio made it really easy to hook up the many, many, data bound fields I had.
Over 2 months later I had a React version of the app working.
Sure the React site was cross platform, and worked on mobile and desktop, but holy cow, 1 day versus 2 months.
WinForms along with Visual Studio, is an amazing combo for productivity.
> "New Outlook" is an entirely new codebase (yup... targeting Electron).
Woah really? Do they actually use regular chrome-based Electron or do they have a version based on Edge or some Edge WebView system? That's pretty surprising to hear.
Microsoft was a relative early adopter of Electron - this isn't anything new: Skype, VS Code, Azure Data Explorer, Azure Storage Explorer, MS Teams, GitHub Desktop, Yammer Desktop - they're all Microsoft products that are now based on Electron.
My understanding was that the only reason those teams opted for Electron was because they intended to target Linux and/or macOS and/or browser-based users, and didn't want to have to maintain different codebases for each platform (of course this means they ended-up with a non-native UI look-and-feel on all platforms now...). But all of those products I mentioned above definitely needed to target Linux and browser-based users, so I can't get too angry about that move.
...but doing the same for Outlook, a long-time anchor-product for enterprises to buy-into Windows and Office, feels off to me. This does not bode well for the Windows platform as-a-whole if Microsoft isn't even targeting it anymore.
WebView2 is basically the modern equivalent of MSHTML.dll (except it runs the Blink/Chromium code out-of-proc), whereas Electron is a more than just a white-label web-browser: it also bundles NodeJS and it provides a runtime environment with its own platform API (and with NodeJS) so that HTML+JS-based applications can have more-or-less do the same things as native code.
It's not Electron, it's using Edge WebView2 which is drastically different from MSHTML.dll in many ways. If you have it installed you can see the msedgewebview2.exe processes in Task Manager.
Agreed that it appears WebView2-based (at least on Windows). I apparently have the new Outlook already on my computer (how? Not sure!) and I see WebView2Loader.dll but not LICENSES.chromium.html.
Huh - okay, I retract my claims about it using Electron.
...which I based entirely off the fact the right-click menu used Chromium's non-native-menu-styling - along with MS' history of using Electron elsewhere.
In hindsight, I think Windows 7's hayday - and Windows 10's - are certainly up-there with Windows XP.
Though remember XP received a lot of (well-deserved, IMO) flack for its Fischer-Price look, but at least it was (somewhat) customizable, before things got increasingly locked-down and restricted since Vista.
I was there and there were 3 apps what I used from WinXP and Win7 (in any meaningful amount, Charmap and the like, used once in a full moon doesn't count):
Notepad,
Calc,
Paint.
Everything else were 3rd party or updates.
In no particular order:
IrfanView, ACDSee
MPC/VLC (and K-Lite ofc)
ImgBurn/Nero/UltraISO
Office
Adobe Reader/Whatever else I forgot
Corel PhotoPaint 3 (lol, yeah, till I moved to 64-bit Vista), Paint.net, PhotoShop, GIMP
I find it shocking how bad Microsoft is at this. I had my dad, who isn't the most tech literate person, set up on the Windows built-in mail client for a while, which I thought worked pretty okay, a decent default solution. At some point a banner appeared in the App, saying that it was being deprecated in favor of "The New Outlook".
I thought okay, I am personally using Outlook for work on my Mac because of an IT policy, and I found it to be an alright Email client there, and it's one of Microsofts flagship office programs, surely it's gonna be a good experience on Windows right?
It was a complete nightmare, immediately during setup it turned out that "The New Outlook" doesn't support regular IMAP/SMTP Email setups, only account login via outlook.com or google mail (I assume this changed now), so I had to switch him to whatever the "old" outlook is, an extraordinarily convoluted looking piece of software with comically bad user experience, nothing like the Mac version. I genuinely felt bad putting my Dad through this, and it's wild to me that they manage to deliver a so much worse experience on their own platform than on Mac.