4 ms·

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 im

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.
  - mwcampbell 2y ago
    > 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.
    - mike_hearn 2y ago
      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.
      - mwcampbell 2y ago
        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.
      - neonsunset 2y ago
        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).
    - senderista 2y ago

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.
- mwcampbell 2y ago
  > 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.
  - mike_hearn 2y ago
    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.
    - mwcampbell 2y ago
      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.
    - neonsunset 2y ago
      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).
  - senderista 2y ago