Hacker News Reader

Comment by morrbo | Hacker News Reader

Why not C#? Seems a bit of a missed opportunity to feed some of the APIs undoubtedly created for this into the new .net core stuff. I guess i'll just keep dreaming of the day when i can reliably convert a docx into a pdf without using office interop.

View on HN

Reading this thread, with all the Javascript talk, makes me feel like I should be scared of continuing to be a C# developer..

I had to like really think 10 times over, to comment or not, being a PHP dev....

Don't think that'll be an issue. Just sad to not see .NET Core finally get a UI layer added on. They're investing in ASP .NET Core its a nice back-end ecosystem.

Office client never used .net or C# to begin with

Actually at one point they went very close to replace VBA with .net. It was called VSTA and meant to be a mini visual studio in office apps. I believe one of the office apps shipped with it in Office 2007, then they killed it.

VSTO, right?

Nope. VSTO actually shipped and is used to create office addins. VSTA was an embedded IDE.

I made this change back in 2011 when the Windows 8 developer preview with WinRT single-handedly annihilated all the WPF & Silverlight consulting work. The writing was on the wall for months, but for me the last straw was the JavaScript WinRT apps.

There is still work for COBOL developers. I don't think C/++/#/etc. work will be going away any time soon.

This is the confusing part for me, yes. Javascript is fine and well, but C# seems the better choice in general here.

What makes it the better choice in this situation? C# can't run in browsers whereas Office 365 can.

Well, blazor exists now, so that's not totally true.

They are actually using Typescript, and this will lead to less friction wrt hiring devs, supporting all those platforms and integrating web components. Still I would have hoped that MS would be a little more forward thinking, and put some of their MSR tech in good use, to encourage the use of better languages. Just like how Facebook is pushing ReasonML.

I think that the C# focus of .NET is a major mistake holding the platform back, especially when we have languages like F#, Scala, Swift, ReasonML and Rust these days.

How do you know they're doing that? Not that it doesn't make total sense to use TypeScript from any angle I can imagine.

> I think that the C# focus of .NET is a major mistake holding the platform back, especially when we have languages like F#, Scala, Swift, ReasonML and Rust these days.

Yeah F# is really nice, but the IDE support is kinda meh. Also .Net expects you to embrace nil at a lot of points which doesn't gel so nice with F#. But Swift has a worse problem with Objective-C-isms but being a first class citizen really helps as they make a lot of API's really better to use with Swift.

You mean JavaScript not Office 365 right? They are working on compiling C# to Web Assembly FYI.

IE11 will never support wasm, so I suspect wasm isn't their first choice eh

This is a good point. MS has agreed to support IE11 until 2025. I'm not sure if that means they have an internal mandate that Office 365 must work with IE11, but I wouldn't be surprised. Those poor poor MS developers.

I wouldn't call them "poor" in this case. WASM is super cool and has a hopeful future, but productionizing wasm apps is currently still quite difficult in practice - it's still missing a lot of relevant tooling (debugging is hard)

I wonder if it has anything to do with their being more JS developers than C# developers. Though, I imagine the average C# developer is a better programmer than the average JS programmer, but since quality is often a function of quantity, maybe there are going the later route. Or maybe it's something entirely different ;-)

> to do with their being more JS developers than C# developers.

My boss told me there was no future banging out C on small embedded processors. 25 years later there is always work because there are so few people who can still do it. When 80% of programmers can't do anything other than JavaScript they'll be more than plenty of work for the other 20%

I'm guessing that in this case they're only talking about the "office software running in the browser" version of Office 365, not the "subscription pricing model for the desktop suite" version.

Except they actually are talking about all the versions, including desktop apps.

Source? Edit: Never mind; the later tweets confirm they are using Electron and React-Native. Madness!

I'm guessing they're just going to ship an Electron app and they won't be different codebases any more.

On Windows 10, they will target WinRT on UWP, with Fluent Design UI. Not Electron.

Wrong https://twitter.com/thelarkinn/status/1006761134395834368?s=...

Not wrong, see the Windows 10 OneNote app for example, which already uses Typescript on WinRT/UWP. An Electron target will only be for legacy platforms, like Windows 7 and 8.

Also see https://www.thurrott.com/cloud/office-365/161295/microsoft-r...

It's interesting they're using Electron for Win7/Win8 when React Native for Windows has a WPF rendered that works nicely on Win7 and 8. Perhaps they just found that maintaining two slightly different RN office apps for Windows wasn't worth the effort given the declining market share of the older Windows versions.

So much for "learn once, write anywhere".

It's funny that the "new, simplified ribbon" in Thurott's screenshot looks a lot like the old interface in Office 2000.

Why at all? I would expect, long term, the ideal solution for a “run in browser” solution would be WebAssembly, possibly with JavaScript glue to the DOM. If so, they probably can keep large paths of their existing code base.

Also, I expect the existing code base isn’t small, so a rewrite won’t be ready soon.

That makes cross-compiling from whatever they have now to WebAssembly or JavaScript seem even better options.

Well TFA is about a big-time rewrite of Office into JavaScript, so at least MS doesn't appear to see any perspective in WASM.

Considering they are uniquely positioned to make it happen given their C# buy-in and probably more than just a bit of existing software to leverage, I'd say this is as strong a signal of non-endorsement as it gets.

I don't think we can read that much into it. The tweet says the project is nearly finished, and this doesn't sound like a small effort — so it would have started either before WASM was really a thing or when WASM was still a very risky bet. I mean, I don't imagine they'll be jumping to WASM, but I don't think we can read it as "they're deliberately not endorsing WASM" so much as "WASM is still quite new."

C# doesn’t easily compile to the web. This is why they are rewriting office 365 in the first place right?

WebAssembly?

DOM access?

They just demoed running a winforms app in the browser using .NET CORE so maybe it would be less work/more successful to explore this path instead of trying to somehow re-implement the oxygen-sucking monster that is Excel using only the "new hotness (tm)".

I bet this is only the new stuff like Delve and the less functional, more social apps/components. I can't imagine how they could pull this off for a full version of Excel or even Word or PP..

They are doing some of those tricks now with the current office 365. I assume they just want to migrate away from those tricks because they have drawbacks.

Besides, office currently isn’t written. In .net, they would be migrating away from C++ code.