Hacker News Reader

Comment by DaiPlusPlus | Hacker News Reader

"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.

View on HN

> 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.

Hold on now, WinForms is really nice to use.

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.

UPDATE: HN won't let me edit the above post, but I'm wrong about it using Electron, it's actually WebView2.

It's not Electron, it's using Edge WebView2 - https://developer.microsoft.com/en-us/microsoft-edge/webview...

If you have it installed you can see the msedgewebview2.exe processes in Task Manager.

Electron or WebView2?

Electron.

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.

Thank you for the correction!

Reply on news.ycombinator.com