Hacker News Reader

Comment by DougN7 | Hacker News Reader

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)

View on HN

Really the choice of language is unlikely to be the cause of any slowness you are experiencing in different versions. JS can be faster than a native experience, all depends on program architecture. The main JS engines are blazing fast and a low-latency UI is perfectly possible; sluggishness is not a sacrifice you must accept when coding in nearly any language in 2018. But bad practices in any language can lead to a poor user experience.

Technically true, but in practice, the culture matters. JS ecosystem is what it is - based on past and current experience, you can't expect efficiency coming from there.

Maybe not from the ecosystem at large, but from Microsoft, on something like Outlook, sure you can expect efficiency.

I am not aware of a single piece of software written by Microsoft that I would call efficient, apart from maybe Notepad or MSPaint.

https://en.wikipedia.org/wiki/Sysinternals

Very efficient, though technically MS acquihired Mark Russinovich.

He still works on them even though he's Azure CTO.

Maybe so, but I have never seen a fast Electron app.

VS Code, Discord, Slack, etc., all have awful performance on older hardware where native programs like the full Visual Studio fly.

It's my personal suspicion that people cheerleading JS all are working with fantastic developer hardware, where the performance impact is pretty muted.

Part of that is electron itself - I've heard it carries quite a bit of bloat - and part of that is the DOM. The DOM is very slow because of the guarantees it makes. You can edit any part of the HTML at any time - by hand or by API - and everything will resize and reflow implicitly. That's an incredibly powerful yet heavyweight feature. If they're using React Native, the only non-native thing is the raw JS logic itself, which is far, far less of a bottleneck.

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, including React, goes through that API at the end of the day. This is why React has its own whole virtual DOM: so that it can touch the real one as little as possible.

My full-time job is writing tools in React that often have to handle datasets in the >10k items range.

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.

An Electron app doesn't need to be slow just because it uses the browser DOM, but UI mutations will almost universally be slower than their native counterparts. Now, if the desktop app is poorly written and the Electron app is well-written, then of course the Electron one can be faster, because there can be sources of slowness other than UI mutations.

Let me illustrate the DOM question with an example.

Let's say you've got an "old style" jQuery to-do app. The user types something into the field, and clicks "Add".

- The input field will be cleared

- A new element will be added to the list, containing the string

- The counts for "total items" and "items remaining" will be updated

Now let's say you rewrite this app in React. The user types something into the field, and clicks "Add".

- The input field will be cleared

- A new element will be added to the list, containing the string

- The counts for "total items" and "items remaining" will be updated

Your code that accomplishes this will look completely different - much more readable and less fragile - but the exact same DOM API calls will be made, and it will perform exactly the same.

The "speed" we associate with React is not in comparison to "old school" libraries, but to the naiive way of achieving data-driven syntax. You could just nuke the page entirely and re-render everything from scratch each time your data changes. This would be the easiest way of achieving data-driven syntax, but it would indeed be extremely slow. React gives you (something approaching) the performance of jQuery-style mutation, with the developer experience of reconstructing the DOM from scratch every time data changes.

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.

2007 because of docx support.

If I'm typing a sentence that I am very familiar with, I can get up to 95 WPM and Outlook 2016 has no problems keeping up.

Perhaps it's your computer and not Outlook.

Yes but it's disappointing that it's slower than the 2013 version on the same hardware.

A Commodore 64 can keep up with even the best human typists. How is it even remotely acceptable that any application running on a GHz+ multicore CPU can't?

The issue seems to be down to your network connection. As Outlook is sending or receiving emails and making other service calls you experience a slowdown. Onsite our connection is very slow and everyone experiences this problem. Additional bandwidth was not considered for the O365 and if you monitor your service calls with fiddler for example you'll see constant traffic to the O365 servers.

We're talking about pressing keys on a keyboard and the corresponding letters appearing on the screen, maybe even with spellchecking. This has been computationally achievable for decades. It's not something where you need a state-of-the-art PC in order to be able to experience it.

JavaScript compiled to native code[1] so perhaps not because of that!

[1] https://twitter.com/TheLarkInn/status/1006761134395834368

Reply on news.ycombinator.com