Hacker News Reader

Comment by paulddraper | Hacker News Reader

A fair reaction.

Also, Teams isn't written in 1999 JavaScript.

> 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

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.

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.

Reply on news.ycombinator.com