Hacker News Reader

Comment by DeathArrow | Hacker News Reader

If someone told me 25 years ago that we will write complex desktop applications like Teams using Javascript I would have been worried about his sanity.

View on HN

25 years ago was 1999. The pioneer of writing desktop-like apps in JavaScript was the Microsoft Outlook team who created the XMLHTTPRequest API so they could implement a fast version of the web version of Outlook. That was in 2000. The real pioneer of this approach though was Oddpost, which created the first truly desktop-like webmail app using XMLHTTPRequest in 2002. It only ran in IE5.

Two years after that Joel Spolsky - former PM on the Excel team - wrote his famous essay "How Microsoft Lost The API War" which predicted everything would eventually be rewritten as web apps. Gmail had launched two months earlier.

https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...

So, even back then the trend was clear. The Windows team systematically dropped the ball / refused to believe the ball existed, and was outcompeted by much smaller teams writing browsers.

> The Windows team systematically dropped the ball / refused to believe the ball existed

Oh, they had a very good go at killing the web or trying to tie it to their existing APIs: the IE6/ActiveX era.

I'm not really sure what they could have done, though. Other than modernize away from WinForms properly; they have repeatedly dropped the ball on UI frameworks and failed to modernize all their own stuff.

Conversely, Apple appear to have "won" despite (because?) completely ditching all backwards compatibility for their APIs on multiple occasions.

Well hindsight is 20:20 so I won't be too harsh on them, but a clairvoyant Windows team could have done some serious competitive analysis to try and discern why developers were wanting to build web apps despite the clear lead the MS ecosystem had in GUI toolkit quality, developer tools, languages and even (at that time) job market for devs.

I think if they'd done that they'd have concluded:

• Devs pick the web because it means deployment+start can be one click on a hyperlink, the browser will also update your software without any prompting of the user.

• Sandboxing really matters because it's what enables the former.

• Guaranteed and easy server connectivity really matters.

• High level scripting really matters.

So, they could have e.g. tried to make a sandboxed version of Visual Basic in which the P-code you downloaded was used just for UI, with all other serious logic on the server. Maybe even using a properly client/server variant of DCOM to provide client<->server calls. Basically a kind of web browser like thing but on top of the MS stack instead of HTML. Devs would probably have found that pretty compelling.

ActiveX was the closest attempt but it didn't fit the bill. It wasn't sandboxed in any way, and ActiveX controls took forever to download because they were all native code. They definitely weren't high level and you didn't get any kind of convenient server connectivity out of the box either. Then BillG decided to do .NET and I guess code sandboxing got sucked up into that project, the Windows guys were somehow allowed to reject the whole .NET concept, and deployment wasn't sorted out for many years. Kernel level native code sandboxing wasn't possible on the Win 9x codebase and is still pretty ropey even in Win 11, so that was also out.

Apple didn't really win against the web, and their API is largely backwards compatible to the start of OS X. Also, the initial versions of OS X did contain support for both running old MacOS Classic apps in emulation, and also porting them to the new APIs whilst minimizing the size of rewrite required (Carbon). So their backwards compatibility isn't too bad.

> the Windows guys were somehow allowed to reject the whole .NET concept

What I heard was that the higher-ups pushed .NET as a core part of the OS pretty hard during Longhorn, and it failed, leading to the Longhorn development reset around 2004 or 2005.

Disclosure: I was on the Windows team at Microsoft, but long after all of this happened (2017-2020), and I never learned about Longhorn history from the inside. I don't remember sources for what I said above, though I think Herb Sutter has talked about it.

Yeah I've always assumed there must have been some really traumatic experiences in the past for Windows/.NET to become so completely divorced. I mean it'd have made sense to port or rewrite a pile of all the little utilities and subsystems that aren't performance sensitive at least. But I guess the backwards compatibility story w.r.t. .NET generics killed off their interest in allowing .NET to become a part of the Windows API.

One of the few Windows utilities that was allowed to be based on .NET, in Vista and Windows 7, was Narrator, the screen reader shipped with the OS. But Narrator was rewritten in C++ for Windows 8. That was still before I got there, but of course I asked about the history, since I was on the Narrator team. I think the deciding factor for doing the rewrite was the sluggish startup of the .NET version. I guess the need to run on Windows Phone 8.1 and Windows 10 Mobile was likely another factor, though now I don't recall if my teammates specifically said that it was.

Back then performance profile of .NET (Framework) was just not where it is today sadly (even with C++/CLI there were warts, but I only know what is publicly available unlike the sibling comment).

That is basically correct. All the Longhorn .NET code I'd written in the past 2 years was junked. Never understood why the concerns that led to .NET being dropped for OS development weren't addressed before development started.

25 years ago, Microsoft was already writing complex desktop apps using Javascript. That was a major feature of Windows 98, you could have a "HTML UI". (ofc they made it easy to call into COM for the busy stuff.) I've never used Teams, but maybe it just sucks for reasons having nothing do with UI programming?

Just because it became reality doesn't make it any less insane, though.

And you would've been right. I'm still worried about their sanity to this day. Btw it's not just devs, most regular users I deal with on daily basis hate it (be it Teams or whatever), they just don't know why it's such a crap. And they don't have to.

A fair reaction.

Also, Teams isn't written in 1999 JavaScript.

It's not far off. We got some syntax niceties and 5 slightly different and conflicting ways to concatenate .js files from different directories a.k.a packages.

Apart from standardizing some things (doesn't hugely matter for electron since it's the only target) and getting async - what has really changed?

Modules, iterators, async/await, localization, proxies, regex features, Promises, date functions, generators, classes, destructuring, WeakMap, strict mode, private members, BigInt, and a hundred other things.

Check out:

https://compat-table.github.io/compat-table/es5/

https://compat-table.github.io/compat-table/es6/

https://compat-table.github.io/compat-table/es2016plus/

https://compat-table.github.io/compat-table/esintl/

---

Not to mention that fact that Teams is actually written in TypeScript (tho compiled to JavaScript).

I see really only: strict mode, weakmap, bind, typed arrays, maybe spread. (+ async mentioned earlier) The rest as far as I can see can be either written as your own function or babel-style compilation. Sure, today's code would be nicer/shorter, but... the language itself really didn't change that much, just how we use it / what we expect from it.

> babel-style compilation

"It's not a different language, because you could have another language compile to it."

This has been the situation for years though. Only recently did we get reasonable native support for most new standards by default. Babel compilation down to IE level was really common just few years ago.

Most of the "modern JS" stuff was based on that idea. Teams was released before even the modules existed in the browsers.

Also https://node.green/ which lays out features in one big list

You could maybe use that argument in 2014 but writing js now is a fundamentally different experience to what it was 10 years ago, let alone 25.

To me, the problem isn't the language, but the use of the web layout renderer. Because it's the one everyone's familiar with, but also the most expensive computationally, and very vulnerable to having to re-layout all sorts of things.

It's also the most powerful and flexible one, increasing the chance that whatever crazy UI ideas your designers come up with can be implemented relatively easily.

> Also, Teams isn't written in 1999 JavaScript.

I dunno how relevant that is: 1999 JS performance is closer to 2024 JS performance than 2024 JS performance is to 1999 C++.

IOW, just because 2024 JS might be faster by a factor of 2, doesn't mean it's faster at all[1] than the equivalent program written in native code.

[1] Maybe it is - I haven't checked benchmarks because programming language benchmarks have almost no correlation to reality when you use the language in a program, because the program is not doing 25k calls to the same function in a while loop.

JS aside, there's virtually a 0% chance Teams would be in C++.

It'd be in a non-native language, like C#.

JavaScript is faster than you think. Miles ahead of Python, Ruby, Perl, PHP. Not too different than C#/Java (especially if you consider 2x to be effectively the same) [1].

[1] https://benchmarksgame-team.pages.debian.net/

> It'd be in a non-native language, like C#.

True; C# is the most obvious choice for Teams.

> JavaScript is faster than you think.

I'd be very surprised.

> Miles ahead of Python, Ruby, Perl, PHP.

Depends on "miles" - I think it is within the same order of magnitude as all of those. If it's far off from being in the same order of magnitude of those, I'd be very surprised.

> Not too different than C#/Java

I don't think so, not for idiomatic usages anyway. Java and C# are pretty damn fast! ISTR that Java/C#/Go are in a different order of magnitude from JS, Python, PHP, etc.

(The link doesn't work, btw)

JavaScript (V8) is well over an order of magnitude faster than Python (CPython).

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

And Java/C# is nowhere even close to an order of magnitude faster than JS.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

There is no direct comparison vs JS but C# is much[0] more capable than Java at number crunching tasks because of its low-level features.

The better showcase would be complex application code where JS cannot keep up with .NET or JVM no matter how much you optimize V8 due to dynamic typing and even simplest operations like property access needing inline caching and guards.

[0]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

déjà vu all over again

(Or would C# aot and GraalVM be more to the point?)

The other links do work.

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

404

I'm still worried about the sanity of people writing web apps. /s

Reply on news.ycombinator.com