Microsoft Office rewrite to React.js nears completion | Hacker News Reader

Microsoft Office rewrite to React.js nears completion

react-etc.net

67 pointsvelmu49 comments

I'll reserve judgement on office until I see it running, but this trend towards moving everything to web tech is a little worrying. So many of my "desktop" apps feel slow and bloated now, and I keep seeing instances of decent software being rewritten in JS. :(

I don't want my spreadsheets crapping out on me at a few thousand rows.

Even though I never use outlook/ms stuff.

I like google google docs. The thing is, I rarely have to use them, so and it's been FOREVER since I've anything like libreoffice installed. So, in the case I have to handle a word document or spreadsheet, docs is good. I'd rather deal with a slightly slower web app rarely then having all the office suite stuff installed.

I was a big fan of google docs 10 years ago. But have lost interest as they have stagnated. Sheets is slow for anything over 100 rows compared to Excel and there’s a lot of 20% functionality that’s been missing for years in functions, charts, pivot, etc.

It’s great for lists, but I want an Excel clone on web. Fortunately, MS has been building this.

If MS ever simplified their license, I’ll switch.

What’s the complex part about their licensing? I thought it was a monthly subscription if you want upgrades or a one-time fee if you want the current version only.

They have commercial and non-commercial. Different features are active in different configurations.

The actual license is simple for office. I actually pay $100/year for my family. But almost every few months a new feature is announced only to learn that it’s only available for business. Or it’s not available for personal users. Stuff like that.

Google is dead simple. Everything free for personal use, but more storage space. Or business is $50/user/year/forever.

Google Docs is great until you want to use it in a low-netowork bandwidth or resource-constrained environment. That’s when you see how much of a resource hog it can be. (Offline Google Docs doesn’t really compare.)

> I don't want my spreadsheets crapping out on me at a few thousand rows.

Agreed. Besides the sheer lack of functionality of the web spreadsheets, the clipboard is a continual annoyance for me... 35 years of correctly working clipboard technology, and the more modern web based spreadsheets don't even get that right.

> this trend towards moving everything to web tech ...

Agreed... maybe Web technologies will eventually mature to the point where they're a competitive desktop application platform... but it's been 20 years so I'm not holding my breath.

At first I thought that they might be using Electron for each app which would concern me as well, but they are using React Native for almost every build except for win32 which will get Electron. I'm curious to see how React Native performs, especially on desktop, for such large scale applications like the office 365 suite. I'm cautiously optimistic

Going on this [0] comment, desktop Office is remaining in C & C++, and on this [1] Code is Typescript and has no plans to move from Electron.

So I'm really not sure what to make of this random viral tweet.

[0] https://news.ycombinator.com/item?id=17305332, [1] https://news.ycombinator.com/item?id=17306589

That makes much more sense. Thanks.

Even more details here, apparently (and by the same author as the original tweet):

https://news.ycombinator.com/item?id=17304128

original reddit post:

https://www.reddit.com/r/programming/comments/8qqhlz/office_...

Though it still doesn't make things much clearer to me, unfortunately, other than the general idea of: "Yeah, but no"...

Just read the whole twitter thread. The author of the original tweet makes so many semantic mistakes and ambiguities, it really could mean anything. Also, other Microsoft employees are constantly debunking most of common interpretations. There's little point in making news stories out of it, it's just a low quality gossip initiated by an overly excited employee.

I know I read somewhere he said there is one source code that compiles to all platforms. And that source code is written in JS.

https://mobile.twitter.com/TheLarkInn/status/100676113439583...

Do they mean that just the user interface is being rewritten in React/JavaScript or do they mean the entire application?

It is hard to believe that several million lines of Excel C/C++ code is being rewritten into JavaScript. It must be possible, but the cost and time to rewrite so much heavily optimized code seems prohibitive. And surely will run much slower than the existing Win32 version.

I wouldn't be surprised if the whole thing were to be rewritten in JS/TS because their goal is to give you a full experience that competes with Google Docs by the sound of it. It also appears to me that just like they ditched updating Windows versions they're just going to have 'Office 365' aka it always updates, no more versions (externally).

Their online product is already on par or better than Google Docs, right now.

Only thing I can think is that they are trying to unify the UI code base across devices, and React is seemingly the winner there at this point.

Interesting that they also appear to be ditching the Ribbon for a simpler UI as well: https://www.engadget.com/amp/2018/06/13/microsoft-office-ui-...

only the frontend, there is a post on reddit in which one of the devs specifically said that all the backend is still in c++ and will remain that way

You got it. One of the engineers from the office product group chimed in and said as much. They are using react native for some UI components.

It's only about Office 365, the web application. It's written so in a first sentence of this article.

Already discussed earlier : https://news.ycombinator.com/item?id=17303745

Microsoft has a pretty nice component library as well called Fabric. https://developer.microsoft.com/en-us/fabric

Should probably correct the title to "Office 365 rewrite..."

I've already had two hardcore js nuts come to me separately and exclaim that office is being rewritten in js, and have had to explain that O365s front-end, which is obviously already in some form of js, is being rewritten in React.

Has nothing to do with Office Desktop and the 365s backend services.

>and a version for WIN32 APIs is built using the Electron framework.

Good grief. As if native Office wasn't bloated already.

They're quite good at optimising Electron apps though as demonstrated by Visual Studio Code.

The memory overhead of Visual Studio Code is insane. Don't see how they did a good job optimizing anything there.

It only seems like it because a year ago Atom was so much worse.

Why are you complaining about memory usage? How much RAM do you have? Most developer machines come with at least 8 Gb, and you can easily add in an additional 24 or 56. Something to keep in mind is that unused memory is a waste. Windows actually keeps the most used applications in memory for faster access time. Between the wide availability of RAM and SSDs, complaining about memory usage on a developer machine is a rather archaic mindset.

> Something to keep in mind is that unused memory is a waste

yes, but I'd like to put my own stuff in RAM, not accidental RAM usage due to the technologies being chosen.

> you can easily add in an additional 24 or 56

No, you can't. If you have an MBP, for example, RAM is soldered onto the mother board and cannot be upgraded. If you have a Thinkpad x220 or x230 like a lot of us do, you can only go up to 16GB because the BIOS doesn't support any more.

And regardless of which laptop you use, RAM is expensive in a lot of places. You can't expect everyone to throw hundreds of dollars at RAM just so they can run VS Code. Not to mention the "throw more hardware at it" attitude is the reason why we have bloated inefficient software in the first place.

>you can easily add in an additional 24 or 56

Yeah, for like $700

Yes but this article is not about developers. Not everyone who uses excel can just dump 700 bucks worth of memory into their corporate provided workstation.

Regular users matter too.

The most popular developer machines (MacBook Pro) come with either 8 GB or 16 GB LPDDR3 (not upgreadable).

Intel's Cannon Lake is the only CPU that can use LPDDR4, but they are yet to solve their yield problems.

"unused memory is a waste"

Programs with a bigger working set tend to run slower, because of bottlenecks across the memory hierarchy.

> The most popular developer machines (MacBook Pro)...

That's incorrect. The vast, vast majority of developers around the entire world are running Windows and on a PC, not a Mac.

You are right, Windows is the primary OS developer's use (Stack Overflow Developer Survey 2018: 49.9%) followed by OS X (26.7%).

Since when is Office a developer tool that runs only on dev machines?

Minimising the memory usage doesn't just create wasted 'free memory'. Among other things...

> Windows actually keeps the most used applications in [inactive] memory for faster access time.

When an app uses extra memory, it prevents this from happening. If the extra memory use doesn't help the user, the net effect is a harmed user experience, even if they have enough memory to hold everything the currently running apps want to store.

> optimising Electron apps though as demonstrated by Visual Studio Code.

Go ahead and open 6mb CSV file. Keep me updated :)

Works fine. VSCode also works fine opening 500mb files. Atom still crashes for me tho.

I downloaded a 50 MB CSV file full of russian tweets from NBC [1] in response to your challenge and VSCode opened it nearly instantly (~2 seconds) on my self-built Windows 10 PC with an i5-4690 CPU @ 3.50 GHz with 2 other instances of VSCode already running.

Total memory usage for VSCode processes was 1.5 GB. The other 2 instances of VSCode were debugging a Node.js Express app and editing a rather large React/Redux app.

When VSCode had no other running instances, opening the same file took about .5 seconds longer.

[1] https://www.nbcnews.com/tech/social-media/now-available-more...

Rust support is the only reason why I put up with Visual Studio Code.

I can understand but coming from IntelliJ, vscode feels light and fast :D

IntelliJ with its continuous indexing and lack of compilation on save made me love Eclipse again.

Even so, VSCode with the same amount of plugins and features as IntelliJ would most likely crawl.

I have tried purescript ide, haskell ide, dart ide, reasonml ide and more. It’s yet to disappoint. Although it’s true intelligent features to IntelliJ detail are rare but it’s useless when I can’t type more than one character / 2 seconds.

Counter-point: they're awful at optimizing Electron apps as demonstrated by Microsoft Teams.

React is pretty crazy. It seems like it's taking over in a way Angular and others never did.

Well this shows that even if Facebook ditches React, at least Microsoft will have a heavily vested interest in maintaining React. I wonder if they used ReactXP or not.

Edit:

My only disappointment is no direct mention of Linux. I would be fine with the Linux variant being Electron based, but I need this thing to run on Linux too!

It's still largely C++ based on the backend, I doubt they're going to add an entirely new compile target just to support a tiny minority of Linux desktop users. Especially since it would just be the Electron app anyways, which probably isn't a huge improvement over the web version you can already use on Linux.

I can’t wait for this. A (hopefully) significantly lighter-weight and cross-platform Office installation that supports VBA and shares DNA with its web and mobile offerings?

Sign me up!

Strange, one would think they would move everything to .net core as it would be a perfect fit for it.

Reply on news.ycombinator.com