Live data from Hacker News

Office 365 is being completely rewritten in JavaScript

twitter.com

161–170 of 459 posts

Re: Office 365 is being completely rewritten in JavaScript

#161

I wonder how much of global warming is caused by inefficient code written in higher level languages requiring more powerful hardware to run. It might be infinitesimal but still non-zero.

"Javascript is literally killing the Earth" might be the most HN comment I've ever read

Re: Office 365 is being completely rewritten in JavaScript

#162
post #98

Ugggh :( I miss my old Outlook 2013. Outlook 2016 is so slow it can’t keep up wirh my typing. I thought it already was javascript. Guess it will be even slower still. Super! (not)

2003 was the sweet spot, I always thought. I still have a usb stick with a portable copy of Word 2003 on it from somewhere, that I pull out when Word 2016 starts crashing and locking up.

Re: Office 365 is being completely rewritten in JavaScript

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

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.

Re: Office 365 is being completely rewritten in JavaScript

#164

As if they didn't learn their lesson with skype for business.

There's a Skype for Business written in JavaScript? I know there is Skype, but it doesn't talk to our Skype for Business (Lync) server.... I have to use Pidgin for that. (Linux)

Definitely not. Unless it's the godawful Mac client that doesn't work for most things, which is possible, since it's using UCWA under the covers.

The Skype for Business Windows client was barely reskinned from the Lync 2013 client. I think they are still only a couple dozen patch revisions apart on the version number.

Re: Office 365 is being completely rewritten in JavaScript

#165

I wonder how much of global warming is caused by inefficient code written in higher level languages requiring more powerful hardware to run. It might be infinitesimal but still non-zero.

Technically JavaScript is only ~7% slower then C++ to execute. But snipe away at that stats with real data.

Technically, maybe. In practice, each language has its culture, its ecosystem. Its set of tools to pick from. Is it reasonable to expect the JavaScript Office will really just bind directly to all the native APIs it was using before, thus incurring only 7% penalty (+/- FFI)? Or is it more likely that it'll have web rendering shoved in everywhere, and then layers upon layers of off-the-shelf JS libraries, thus incuring more like 700% penalty in resource use?

Re: Office 365 is being completely rewritten in JavaScript

#166
post #67

Earlier quoted context omitted.

>it's just not a terribly good or fast one From everything I've seen, its performance sits just below Java (4x slower, perhaps) on some standard algorithms or tasks, and significantly faster than languages like Ruby, Python, etc.. I never see hate for those languages like for JS, so I'll disregard that. >not terribly good This one never has made sense. What is it missing that makes you hate it so? I think it has rath…

> What is it missing that makes you hate it so? 1. Type Safety. TypeScript helps, but until strong typing is mandatory in the language, I can't fathom using JS in any sizable project. This is also true of Python, et al. 2. A sane dependency management framework. Maven solved this problem a decade ago. Gradle is trying to fix Maven's XML mistake. But the fact is, if I need a dependency in Java, I know how to get it. A…

2. After the npmjs.com registry became immutable and npm got lockfiles I feel npm is pretty much there as far as dependency management systems go. I'm not sure if npm shares the cache across projects (like the ~/.m2/repositories folder for maven/gradle/leiningen), but you can get that with the yarn client if saving disk space is important.

Re: Office 365 is being completely rewritten in JavaScript

#167

I for one welcome our new Libre Office overlords.

Does LibreOffice still look like a Windows 3.11 application?

Maybe if you had this theme installed:

https://www.gnome-look.org/p/1079270/

Hey you know, with a different font and a slightly different colour scheme that wouldn't be far off the Metro look.

Re: Office 365 is being completely rewritten in JavaScript

#168
post #40

FWIW, I personally like the direction Microsoft is going in. I look forward to seeing where this transformation leads.

The positive side of breaking compatibility with all legacy technologies (COM, VBA, XLL, etc) that currently force large companies to stick to MS Office is that it has the potential to reintroduce competition in the office-like software space. And in my opinion Office is the main reason why large enterprises stick to Windows. Most internal apps are moving to the web. If office backward compatibility goes away, then i…

Not sure if employees will enjoy the return to the days of time-sharing and remote X-Windows sessions though.

Which is the end result of Webification of our tools.

Re: Office 365 is being completely rewritten in JavaScript

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

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

Re: Office 365 is being completely rewritten in JavaScript

#170

Earlier quoted context omitted.

It's a "real" language, it's just not a terribly good or fast one. It's works decently when its use is limited to what it was made for: manipulating web pages. For anything else, the "designed on the back of a used piece of toilet paper" starts to shine through. And no, a JIT can't save you from this, it can only make things acceptable. That it can create "real world value" is an extremely low bar, which is passed by…

"real world value" is a completely fair metric. You might be able to argue that different languages offer more value than JS, for different use cases. But mocking the idea of "real world value" seems to completely miss the underlying point of app development -- which is to deliver value.

Again, "delivering value" is a ridiculously low bar, when you measure "value delivered" by revenue. We ought to do better than that.

Some extra hoops to jump above "delivering value (measured in revenue)" are:

- Not creating extra problems for yourself down the line (maintenance costs, complexity, technical debt).

- Not creating extra problems for everyone else (promotion of technologies causing problems if adopted).

- Not dumping externalities on other people (inefficient solutions causing worse UX, more frustration and extra electricity usage).

- Delivering actual value, as measured on the user end (whether or not the software makes them more productive), instead of revenue end (i.e. did we manage to trick enough people to pay us?).

Post reply on HN