6 ms·

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.

hulitu 2y ago
I'm still worried about the sanity of people writing web apps. /s
paulddraper 2y ago
A fair reaction. Also, Teams isn't written in 1999 JavaScript.
- viraptor 2y ago
  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?
  - paulddraper 2y ago
    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/es5/ https://compat-table.github.io/compat-table/es6/ https://compat-table.github.io/compat-table/es6/ https://compat-table.github.io/compat-table/es2016plus/ https://compat-table.github.io/compat-table/es2016plus/ https://compat-table.github.io/compat-table/esintl/ https://compat-table.github.io/compat-table/esintl/ --- Not to mention that fact that Teams is actually written in TypeScript (tho compiled to JavaScript).
    - viraptor 2y ago
      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.
      - paulddraper 2y ago
        > babel-style compilation "It's not a different language, because you could have another language compile to it."
        viraptor 2y ago
        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.
    - mhio 2y ago
      Also https://node.green/ https://node.green/ which lays out features in one big list
  - mhio 2y ago
    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.
- pjc50 2y ago
  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.
  - brazzy 2y ago
    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.
- lelanthran 2y ago
  > 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.
  - paulddraper 2y ago
    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/ https://benchmarksgame-team.pages.debian.net/
    - deleted 2y ago
      [deleted]
    - lelanthran 2y ago
      > 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)
      - paulddraper 2y ago
        JavaScript (V8) is well over an order of magnitude faster than Python (CPython). https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python3-node.html 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/fastest/java-node.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
flomo 2y ago
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?
loup-vaillant 2y ago
Just because it became reality doesn't make it any less insane, though.
mike_hearn 2y ago
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-the-api-war/ 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.
- pjc50 2y ago
  > 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.
  - mike_hearn 2y ago
    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.
nutrie 2y ago
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.

hulitu 2y ago

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

paulddraper 2y ago

A fair reaction. Also, Teams isn't written in 1999 JavaScript.

viraptor 2y ago
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?
- paulddraper 2y ago
  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/es5/ https://compat-table.github.io/compat-table/es6/ https://compat-table.github.io/compat-table/es6/ https://compat-table.github.io/compat-table/es2016plus/ https://compat-table.github.io/compat-table/es2016plus/ https://compat-table.github.io/compat-table/esintl/ https://compat-table.github.io/compat-table/esintl/ --- Not to mention that fact that Teams is actually written in TypeScript (tho compiled to JavaScript).
  - viraptor 2y ago
    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.
    - paulddraper 2y ago
      > babel-style compilation "It's not a different language, because you could have another language compile to it."
      - viraptor 2y ago
        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.
  - mhio 2y ago
    Also https://node.green/ https://node.green/ which lays out features in one big list
- mhio 2y ago
  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.
pjc50 2y ago
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.
- brazzy 2y ago
  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.
lelanthran 2y ago
> 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.
- paulddraper 2y ago
  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/ https://benchmarksgame-team.pages.debian.net/
  - deleted 2y ago
    [deleted]
  - lelanthran 2y ago
    > 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)
    - paulddraper 2y ago
      JavaScript (V8) is well over an order of magnitude faster than Python (CPython). https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python3-node.html 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/fastest/java-node.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

flomo 2y ago

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?

loup-vaillant 2y ago

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

mike_hearn 2y ago

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-the-api-war/ 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.

pjc50 2y ago
> 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.
- mike_hearn 2y ago
  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.

nutrie 2y ago

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.