Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Office 365 is being completely rewritten in JavaScript

twitter.com

Post reply on HN
Print view View original

301–310 of 459 posts

Re: Office 365 is being completely rewritten in JavaScript

#301

Post by cmjqol »

Most of the comments seems to say "it's a bad idea" , keep in mind Microsoft is now using React very intensively for most of their projects as well as angular (VSCode , Windows Server etc... )

Meaning it's not the language the real issue , it's what you do with it.

Also Junior at school are less and less trained with Java and C# but straight up with JS or PHP , so it will be much easier to integrate juniors on this re-written version of office rather the pile of legacy C++ / COM / C# bridges mess they have right now.

Re: Office 365 is being completely rewritten in JavaScript

#302

Post by rpeden »

TensorMetric wrote: post #243
cududa wrote: post #237

Earlier quoted context omitted.

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.

Re: Office 365 is being completely rewritten in JavaScript

#303

Post by awinder »

vesak wrote: post #6
rbinv wrote: post #3

Office for Windows (WIN32) will be an Electron app? I have no words. edit, since there seems to be some confusion: I am explicitly talking about the WIN32 variant, which he confirmed to be based on Electron.

"No they are not electron apps. They are compiled to native code. It's now finally one toolchain(#webpack) It's one codebase and it compiles to: Web Android IOS MacOS UWP WIN32 (only one that uses electron) 7:52 AM · Jun 13, 2018" https://mobile.twitter.com/TheLarkInn/status/100676113439583...

comment seems to be saying -- in modern windows (UWP) it'll be using native code, but microsoft is taking the easy path on win32. i guess some people are surprised that despite years of telling people that win32 is going away microsoft is finally making good. but I am not, I'm more excited than anything at another good sign that Microsoft is finally done with legacy windows.

Re: Office 365 is being completely rewritten in JavaScript

#304

Post by youseecomrade »

chandmk wrote: post #283

As a side note, Microsoft login echo system sucks big time in the context of office. You have no idea which URL to use to login to office 365. Between login/logout/timeout/other office apps/personal accounts/business accounts/forgot password workflows browser redirects to various URLs at least a dozen times. And you keep seeing new URLs I am wondering how less tech savvy people are coping with their authentication wo…

Some login servers that you go through, like Skype's, share the same IP address that many "anti-telemetry tools for Windows (10)" are blocking.

Re: Office 365 is being completely rewritten in JavaScript

#305

Post by hellofunk »

_bxg1 wrote: post #288
hellofunk wrote: post #281

Earlier quoted context omitted.

Updating the DOM in Electron is like updating the DOM on the web -- you can do it fast or you can do it old. Most Electron apps I've worked on or looked at the source are using things like React for the DOM, which is much faster than what you describe. But if an app does it "old school" then it can definitely be very slow.

Not true. The DOM in Electron is precisely the same as the one on the web, yes. But while React is faster than some of the other data-driven frameworks, it is not faster than "old school" DOM manipulation. The advantage of modern frameworks is developer experience, not performance. The DOM API is fundamentally slow because of how much work the browser has to do under the hood to respond to changes. Every framework, i…

My point stands if by “updating DOM” it is meant the developer approach to making DOM changes, which in React go implicitly through a virtual DOM first, yes, which is vastly faster than updating the DOM directly. And an Electron app doesn’t need to be slow just because it uses a browser DOM.

I work on a React project that has a faster UI than its native desktop counterpart.

Re: Office 365 is being completely rewritten in JavaScript

#306

Post by JCSato »

scrollaway wrote: post #285
JCSato wrote: post #277

Earlier quoted context omitted.

I know, right? Friendly, bearded, probably lives on the west coast and uses a Mac. Ugh. Can't wait for new technology to make these pathetic hipster devs hired by Microsoft for their abject lack of competence to go out of work.

Sarcasm or not, how did you and the parent commenter write this and think "Hm, yeah, this is a high quality HN comment that is sure to elevate the discussion"?

Fair

Re: Office 365 is being completely rewritten in JavaScript

#307

Post by rawrmaan »

andrewmcwatters wrote: post #300
crooked-v wrote: post #299

Earlier quoted context omitted.

You may want to actually learn what Typescript is before blithely making such comments.

Yeah, I know what Typescript is. It's another transpiled language. I don't care what the syntax looks like, the point is you've added a secondary level of knowledge required to operate in a codebase written in it, and most don't fluently know the first. Please tell me more about what I don't know.

Well, if you remove your assumptions about how incapable people are, TypeScript is the way to make large JS code bases maintainable. It doesn’t even change any of the JS syntax, it just adds to it. It’s the opposite of CoffeeScript in many ways.

Re: Office 365 is being completely rewritten in JavaScript

#308

Post by walshemj »

cmjqol wrote: post #301

Most of the comments seems to say "it's a bad idea" , keep in mind Microsoft is now using React very intensively for most of their projects as well as angular (VSCode , Windows Server etc... ) Meaning it's not the language the real issue , it's what you do with it. Also Junior at school are less and less trained with Java and C# but straight up with JS or PHP , so it will be much easier to integrate juniors on this r…

Mail is one of the key parts of the internet no offence you don't want someone straight out some boot camp of dubious provenance having any input into what language or the spec of a MUA or MTA.

Any new developers on this need to have experience working with email standards and a good knowledge of C++ / C not some fracking scripting language!

And as some one who used to do international interconnect I think I have some valid input here - this has shades of the amusing project spitfire fiasco in the late 80's.

Re: Office 365 is being completely rewritten in JavaScript

#309

Post by chrisseaton »

cmjqol wrote: post #296
jhall1468 wrote: post #227

Earlier quoted context omitted.

Web Views with native API's. So not truly native compilation.

Has been said many many many times , it's not electron for Windows 10 , it's React Native .NET which bridges the built in Javascript VM with WPF. So it's not a web view for UWP, it's 100% native code.

> it's 100% native code

He's said it's not compiling the JavaScript to native code - it's running it in a normal JavaScript JIT. It's not 100% native code.

Re: Office 365 is being completely rewritten in JavaScript

#310

Post by seanmcdirmid »

morrbo wrote: post #142

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.

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