chandmk 10 days ago

As a side note, Microsoft login echo system sucks big time in the context of office. You have no idea which URL to use to login to office 365. Between login/logout/timeout/other office apps/personal accounts/business accounts/forgot password workflows browser redirects to various URLs at least a dozen times. And you keep seeing new URLs I am wondering how less tech savvy people are coping with their authentication workflow.

Depending on how you are authenticating you will see URLs with various words in them.

loginlive office.com outlook.office.com office365 outlook.com account.live products.office.com login.microsoftonline.com

and this list goes on and on... I am wondering if they made an announcement that they are fixing their messy authentication workflow instead spending resources in rewriting office in JavaScript, that would have gotten this much attention on hacker news.

  • privacypoller 10 days ago

    When you have multiple accounts it's even worse - especially if you've got a work account with domain authentication, a private one with 2-factor, a sub-account email under another...

    I'm usually pretty savvy about typing information into a rando web form, but with windows logins it's a major chore to figure out what exactly I'm looking at.

    I hope they staff up to meet the 18-month rewrite cycle for modern JS apps. I'll stick with my 2003 version on the desktop for now.

    • amorphid 9 days ago

      This reality bit me when my Skype account was rolled into Microsoft's Live/Outlook/something system. Both accounts had the same email address, and suddenly my Skype account was no longer accessible. I finally figured out how to delete the non-Skype account, but it was a major pain and I had to wait 60 days for it to finally go away.

  • mnm1 10 days ago

    I often go to outlook 365 to view mail and it logs me out. No reason. I didn't go to the logout url. Just logs me out. Happens almost every day now. Sometimes I get a content corrupted error. I have no idea what that even means and I've been doing web development for over a decade. There are at least two ways to reset your password and they each have different, incompatible password requirements with each other. And finally, I'm asked to change my password constantly and to follow stupid password rules as if my random 32 character string needs rotating. If this is the new Microsoft, it's just like the old Microsoft: absolute fucking shit. Garbage that now spies on us. We switched to MS email from zoho, a system that looks like it was last updated in the 90's and it's an absolute total disaster in comparison. I guess they're too busy rewriting everything badly in Javascript to care about actual, real user and UI issues, however. That's another stupid idea in of itself, but since I'm using a version of Office that no longer even gets security updates, it's irrelevant as I will likely never upgrade. If this is the changed Microsoft, I prefer 90's Microsoft. At least they didn't pretend they were something they were not, nor pretend like they actually care about users or developers, something they clearly don't.

  • tqkxzugoaupvwqr 10 days ago

    All public facing URLs should go through Marketing. On macOS, when an Apple app contacts an Apple service and my firewall shows me the domain/host, it almost always looks very thoughtful and pretty. Compare that to MS Office on macOS. So many different requested domains with no thought and coherence behind them.

    • Nullabillity 9 days ago

      Have you ever looked at a WebObjects/iTunes URL?

  • 013a 10 days ago

    My favorite thing I noticed recently; if you buy a book on the Microsoft Store and open it in a web browser, the url is hosted on zune.net. What year is this?!

    • 0xADD1E 10 days ago

      Oh it gets better. If you look at the appx package names for "Groove music" and a couple others they're still Microsoft.Zune prefixed

      • eysquared 10 days ago

        Thats because the team that wrote Groove Music (and Movies & TV) originated from the Zune desktop player and Windows Media Center. In fact it still used a lot of core code from the Zune days for things like library management and DRM.

        Source: former dev on the team.

        • joenathanone 9 days ago

          The Zune desktop app has to be the best music player I've ever used, it was awesome. I continued to use it long after I moved on from my Zune HD. Sad to see something so awesome abandoned.

          • harrygeez 7 days ago

            The UWP music player is slowly but surely shaping up into something just as good, if it weren't for the comical UI density.

      • dpark 10 days ago

        Appx package names seem almost entirely uninteresting and most consumers will never look at them. Why would anyone bother changing them?

        Disclosure: Microsoft employee, but not on Groove (or anything related to appx packages for that matter)

        • vitorgrs 9 days ago

          The thing is, they created the name when Zune was already dead lol

          • dpark 9 days ago

            Doubt it. Even if the app wasn’t published previously, it likely descended from existing code that already carried the name.

            I work on a codebase that still carries product names that stopped being meaningful almost a decade ago. No value in renaming across the codebase and it’d be expensive because of how much code has to be touched.

  • dmitriid 10 days ago

    It's a huge problem for MS login flows and Google's login flows. As they absorbed various disparate products with various logins and tried to force a unified login flow on all of them they end up with a mess.

    For Google, see the very many failings here: https://grumpy.website/post/0PU1U2r3v. Someone (me?) should do the same for MS.

  • olyjohn 10 days ago

    Everybody I support at my office gets super confused about this. Add on top of that local vs web versions of every app, plus UWP vs standard desktop applications (OneNote, OneDrive). Plus naming conventions that change, and applications that have 70% overlap. Just use the classic portal for this, and the new portal for that...

  • emodendroket 10 days ago

    Heaven help you if you have multiple accounts. Logging in and out remains dicey after all these years.

  • qntty 9 days ago

    Recently got caught in a loop of trying to create an Office 365 account and being told that my email is already in use, then trying to say that I forgot my password and was told that my email is not associated with an account.

  • zdragnar 10 days ago

    I wonder at what point the number of domains and subdomains that you can log into becomes its own phishing vector. At least with most services, you can look in the URL and pretty quickly know whether or not you're in the right place!

  • youseecomrade 10 days ago

    Some login servers that you go through, like Skype's, share the same IP address that many "anti-telemetry tools for Windows (10)" are blocking.

    • Tsiklon 9 days ago

      That has to be a deliberate choice on the part of Microsoft.

  • zip1234 10 days ago

    They recently improved this to make it easier. I think they realize that it can get pretty complicated.

    • irrational 10 days ago

      When will that be rolling out? Hopefully soon since as of this morning it is still a nightmare.

thelarkinn 10 days ago

Hi there, original tweeter here. Just to clarify: no one said when this work would land, simply that we are working on it! Sorry to disappoint XD, but I guess blame the OP.

  • dentemple 10 days ago

    Does this mean that VBA will finally die?

    Please tell me that VBA will finally die.

    • leeter 10 days ago

      As much as I can imagine MS would love to kill VBA it would be a major loss of business if they did. Oil and Gas lives in the stuff and would probably even sue MS if VBA died. That said could it be getting a much needed fixup... probably. I suspect the same is true of COM plugins.

      • LarryDarrell 10 days ago

        I rewrote a 3000 line VBA function into C# earlier this year for a Oil/Gas company. It was surprisingly easy. Sometimes tedious, but easy. It runs faster, it's easier to maintain and now they can slap whatever front-end they want on it.

        Is it money, fear or gatekeeping that keeps these VBA programs untouchable?

        • HeyLaughingBoy 10 days ago

          Probably all three.

          I used to be in the Medical Devices field. A couple years ago, I was told to add a feature to a massive VBA app hosted in Excel that we (S/W development) inherited from another department. It was hands down the worst code I have ever seen. Everything was a global variable. I flat out told my boss that it barely worked, didn't come close to meeting the weakest of our development standards, and since it was used to disposition product (determine whether or not it was acceptable to be used on Patients) it was an FDA audit nightmare waiting to happen. I added the features, but made some pretty unpleasant commit comments since I didn't want to have my fingerprints all over it.

          In all fairness, it was originally developed by a scientist with no SW dev training (I knew him well) for his own use, and just grew over the years as he was told to add more features to it. I have no idea how a company with that level of process strictness ever allowed this fiasco to happen.

          [rant over]

          I estimated the rewrite at 6-12 months. It was really not a very complex program and since we already had the Validation tests written and documented, we at least knew what tests its replacement would need to pass. The problem was all the stuff that we knew it was doing that wasn't in any of the tests. That would have been the majority of time spent to replace it.

          Since I left, I heard ownership of it was transferred to Corporate IT and they were making it into a web app to run on their intranet. Heaven help those guys.

          • antpls 9 days ago

            > Since I left, I heard ownership of it was transferred to Corporate IT and they were making it into a web app to run on their intranet. Heaven help those guys.

            At my last job, I developed automated processes. Some software companies sell tools to automate clicks and keypresses. The idea is then to reuse that Excel macro no one understands inside a VM on a server, and adding a friendly webservice on top of it. Users of the web services don't know an actual screen is running and and an Excel file is being clicked for them.

        • Maybestring 10 days ago

          It's simply that the people doing the development only get to use VBA. Not that having a chemical engineer teach themself C# over their lunch break is going to turn out great software...

          Having worked at a big company as a mechanical engineer and produced a few crappy VBA apps, I did it because it would take significantly more time and effort to get approval for an IT project, than to learn VBA and do it myself.

        • ender341341 10 days ago

          Most of them aren't maintained by technical people. Someone wrote some excel file years ago and every month it's copy pasted and the new data put in place of the old and it usually works until it doesn't.

        • rdiddly 9 days ago

          For me it's time, but I guess that's just money...

        • throwaway_12l4 6 days ago

          > Is it money, fear or gatekeeping that keeps these VBA programs untouchable?

          I was involved in work with a regional financial institution. They had a suite of line-of-business apps written in Access and VBA.[0] This was in a pure support and maintenance mode. This series of apps was written over the course of a decade by one developer nee business user. It represented a literal Great Wall of Chesterton.[1] There was so much process and institutional knowledge tied into this suite and the original developer left after being absorbed into the IT organization.

          Some fun observations from work that was done on this suite of applications:

          - "We can tell where the original developer learned various programming techniques and when something was written based on that."

          - There was a source control and deployment app written entirely in Access DBs and VBA

          - There were two scheduling applications, one designed to replace the other, but the first never fully retired. These launched jobs based on dependencies and timings.

          - The applications ran in Access 2010. No upgrade was possible due to observed breakages when attempting to change.

          - A Windows security update caused an outage for a day.

          - Some data was centralized into a SQL Server instance and Access was a thin app layer on these tables. Others held data in the Access database.

          - Different apps could reach into and run arbitrary queries on data of other apps. This was sort of RPC. Huge spooky action at a distance.

          - There is a ticking time bomb based on Access database size limits. They run compaction jobs on a regular basis, with increasing frequency. One of the core apps will simply stop working one day in the not so distant future when its database cannot be compacted to be smaller than the Jet engine limit of 2GB.

          I mentioned that this thing was in perennial support and maintenance mode. There were several assessments over the years for a migration to .Net. All were eventually scuttled due to cost and fear of functionality shifts. No one knew if what was there was correct, and some of the bugs we fixed demonstrated that there was plenty that was incorrect, though scope and impact were difficult to measure. No one wanted to own a migration due to the likely fallout. Different would be wrong, even in the face of huge evidence to the contrary. A C-suite executive was ousted largely over this suite of applications. The Access lives on.

          Eventually a migration, in part or whole, will be necessary. It will be expensive. It will be painful. Each day increases the expense and pain. But every day, it is cheaper and easier to run and maintain.

          [0] This thing hit commercial and customer facing processes, internal things like HR, letter generation, asset management, and basic reporting, among other things.

          [1] See: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

          Note: Throwaway because of the level of detail

      • nwsm 10 days ago

        I'm in Oil and Gas app dev, we are .net with no VBA. I guess I'm lucky.

        • privacypoller 10 days ago

          Don't count yourself so sure - A lot of shadow IT gets done by that excel expert in finance or the engineer who took a programming elective. If anyone ever gave them a database login password, odds are they're pulling into excel or access and writing VBA!

        • leeter 10 days ago

          I dealt with it peripherally in my last job. Apparently the only reason Office has a 64bit version at all is Oil and Gas was causing Excel to run out of ram and demanded it. We were developing a COM addin, and we had clients complain that we broke some of their VBA they were using (turned out it was another VBA addin they were using that wasn't doing proper error handling). But it was definitely common for us to see clients that were deep into VBA.

        • sten 10 days ago

          Dev in finance here, VBA gets used more than I care to think about.

          • artmageddon 10 days ago

            My last job in finance(still am in finance fwiw) used much more VBA to price out billion-dollar swaps and swaptions than I was comfortable admitting to...

      • agumonkey 10 days ago

        Killing VBA would be a business error, deprecating it with proper transition (language analysis, translation) would be a business hygiene.

    • lmkg 10 days ago

      There are COBOL programs still running. I wouldn't get your hopes up.

    • emodendroket 10 days ago

      VBA is really useful and it's not like there is something to replace it, so I hope it does not die.

      • kchr 9 days ago

        Lua, Python, Ruby, ...?

        • emodendroket 9 days ago

          Can you embed any of those in Office documents? No.

          • dentemple 7 days ago

            If it has a library that provides interop with the Common Language Runtime, then it's the next best thing.

            And by the next "best" thing, I actually mean the next worst thing, because I've written apps that interop with VBA macros and no man or woman should ever suffer such an experience.

            • emodendroket 7 days ago

              Writing apps to interop with VBA may be terrible, but embedding VBA in documents is a really useful feature that doesn't require your users to have a bunch of runtimes installed.

  • wiz21c 10 days ago

    when you say rewritten in JavaScript, you mean acutally rewritten or just cross compiled to Javascript ? Or a bit of both ?

  • mhoad 10 days ago

    Happy to take the blame :) It was too interesting a tidbit not to share though.

    • petee 10 days ago

      not your blame to take, perhaps its the guy who is vaguely tweeting without official capacity to do so...

  • golergka 10 days ago

    Why not Typescript, btw?

    • nameiscubanpete 10 days ago

      I'd almost guarantee that it's Typescript. But being a superset of Javascript, it's still correct to call it Javascript.

      • jorams 10 days ago

        It's really not. YAML is a superset of JSON, but you wouldn't call a YAML document a JSON document. The set of all colors is a superset of the set containing only orange, but calling every color orange makes no sense.

        • pnloyd 9 days ago

          I don't think it's exactly right to call it a superset either..

          It adds types and constraints that have no effect on the resulting transpiled code besides an insurance that said type constraints are being met.

          To better illustrate what I mean, in the start of a Unix script you sometimes have them augmented with #!interpreter. But this extra contextual information is not a superset of the scripting language itself. Likewise Typescript is also an augmentation that lives within the code that provides contextual information to the Typescript transpiler itself, but does not necessarily effect the actuall produced JavaScript.

          • nameiscubanpete 8 days ago

            I see your point and not necessarily disagreeing, but noting the creators of typescript refer to it as a superset.

        • kumarharsh 9 days ago

          All colours don't boil down to "orange" in Human eyes, so calling all colours orange really would be pointless. Typescript does compile down to JS, without which it can't even run. So yeah, when you're talking about the runtime or performance, Typescript === Javascript.

          • golergka 9 days ago

            > Typescript does compile down to JS, without which it can't even run. So yeah, when you're talking about the runtime or performance, Typescript === Javascript.

            By this kind of logic, C++ === machine code. It compiles down to it, right?

        • nameiscubanpete 9 days ago

          It's really kinda both, but context sensitive.

      • golergka 9 days ago

        It's the other way around - if A is a superset of B, it's correct to call B as A, but not to call A as B.

  • polskibus 10 days ago

    Does that mean full, desktop version of Office 365 or only the web browser versions of Excel, etc?

  • combatentropy 10 days ago

    > blame the OP

    What did he write that you did not?

chengmau 10 days ago

I know the architecture too good, more than I need as I was leaving MS recently. This tweet is not likely to happen. Talking about desktop apps, this doesn't make any sense. Office apps have millions of lines in code and many years of lost knowledge between the classes. Just too many screens, checkboxes and features. A complete bloatware. Buy MS doesn't take any feature off the app- if you have 1B users, most likely that any minor feature cut will hurt some of them, hundred of thousand of them, and they are probably paying, not free riders. Any new office version only hides features, letting this small users group to get them back, never deleting lines of code. MS doesn't want to get billions fined as happend when they moved to docx/pptx/xlsx and didn't support backwards.

Talking about the online versions of office, it is a mess. For Word and PPT they tried to replicate the desktop to the web, rewriting the code, so their current online versions are already using (mostly) new code dedicated for the web. Saying that, they also have a huge number of legacy components and features that they need to support for backward compatibility.So for word and ppt this is a mix in code, not a total re-write. They also have a substantial subset of the features that appear only in their older desktop brothers. Even the PMs don't dare to dream on features parity between the versions.

Excel is a different world and a big-big elephant that won't likely be rewritten any years soon. Think of a code that is maintained over 30 years. Literally, developers are still maintaining code written in the 90s. Trying to bring Excel to the online world made MS create an architecture of html frontend which communicates with a dll session behind the scenes. As weird as it sounds, this dll lives as long as the browser has the spreadsheet opened. Think of it as MS raising VM for every excel file that is opened over the internet. While this is not very cost effective (saying the least) and not very performance friendly (hey ma! I made an understatement) this allowed them to move forward with Excel online very quickly by having a UI communicating with the bloatware dll that runs on the background in Azure. Summarizing Excel, it probably won't also be rewritten in js.

So this PM might be talking about the new apps - Teams or flow or something similar. Not the office cash cows. Personally I really hope he is talking about Skype which became a total garbage in the past versions.

Anyone from Google here? I'm looking for a job :-) ping me (chengmau) in the blind app

  • AnIdiotOnTheNet 10 days ago

    The way I see it, even saying that this is the goal is bad news. It's basically an official admission that Microsoft intends to abandon the Desktop OS entirely. Windows 10's bullshit isn't just some bump in the road that would eventually be recognized as the bad idea that it is, it's a deliberate move to push people off of Windows Desktop and on to Windows tablets, smartphones, and a desktop web kiosk. Windows as a personal computing Desktop OS would be completely dead, and given the state of the alternatives that means that personal computing desktops are also dead. Everything will be a web kiosk or a console.

    It's pretty much exactly the scenario of my nightmares.

    • wtetzner 10 days ago

      > Windows as a personal computing Desktop OS would be completely dead, and given the state of the alternatives that means that personal computing desktops are also dead.

      Maybe, or maybe it would open up an opportunity for more competition. Who knows? Maybe the year of the Linux desktop is still coming :)

      • AnIdiotOnTheNet 10 days ago

        Sure, if a comet takes out pretty much the entirety of the current Linux Desktop community at OverengineeringCon 2020 or something and some reasonable people take it over.

    • crooked-v 9 days ago

      Microsoft already has one extremely successful JS/Electron-based desktop app in VS Code.

  • jzl 10 days ago

    Is it possible there will simply be "Office 365" standalone apps that are basically just baked-down versions of the web apps (like typical Electron style apps), but distinct from the official desktop apps? I could see there being some utility to this such as speed vs running in the browser, large-scale enterprise deployment, convenience reasons (why I always run the standalone Slack app myself), etc..

  • exikyut 9 days ago

    I've always been curious... are the Word and Excel layout engines more complex than HTML+CSS+SVG?

    Not in terms of code bloat/complexity (these exist in both, as you've just described), but in terms of engine size, drive-ability, edge-case handling, etc.

    It's probably a hard question to answer; it's (for some reason) hard for me to articulate exactly what I mean too.

    And regarding Excel-literally-in-the-cloud... is that why Microsoft needed to make Azure? :P

  • chengmau 10 days ago

    holy cow, I created an email for that - chengmauchengmau@gmail.com

morrbo 10 days ago

Why not C#? Seems a bit of a missed opportunity to feed some of the APIs undoubtedly created for this into the new .net core stuff. I guess i'll just keep dreaming of the day when i can reliably convert a docx into a pdf without using office interop.

  • artmageddon 10 days ago

    Reading this thread, with all the Javascript talk, makes me feel like I should be scared of continuing to be a C# developer..

    • iKSv2 10 days ago

      I had to like really think 10 times over, to comment or not, being a PHP dev....

    • giancarlostoro 10 days ago

      Don't think that'll be an issue. Just sad to not see .NET Core finally get a UI layer added on. They're investing in ASP .NET Core its a nice back-end ecosystem.

    • dragonshed 10 days ago

      I made this change back in 2011 when the Windows 8 developer preview with WinRT single-handedly annihilated all the WPF & Silverlight consulting work. The writing was on the wall for months, but for me the last straw was the JavaScript WinRT apps.

    • irrational 10 days ago

      There is still work for COBOL developers. I don't think C/++/#/etc. work will be going away any time soon.

    • contextfree 10 days ago

      Office client never used .net or C# to begin with

      • cm2187 10 days ago

        Actually at one point they went very close to replace VBA with .net. It was called VSTA and meant to be a mini visual studio in office apps. I believe one of the office apps shipped with it in Office 2007, then they killed it.

        • jkaptur 10 days ago

          VSTO, right?

          • cm2187 10 days ago

            Nope. VSTO actually shipped and is used to create office addins. VSTA was an embedded IDE.

  • JCSato 10 days ago

    This is the confusing part for me, yes. Javascript is fine and well, but C# seems the better choice in general here.

    • shawnz 10 days ago

      What makes it the better choice in this situation? C# can't run in browsers whereas Office 365 can.

      • zip1234 10 days ago

        You mean JavaScript not Office 365 right? They are working on compiling C# to Web Assembly FYI.

        • bpicolo 10 days ago

          IE11 will never support wasm, so I suspect wasm isn't their first choice eh

          • irrational 10 days ago

            This is a good point. MS has agreed to support IE11 until 2025. I'm not sure if that means they have an internal mandate that Office 365 must work with IE11, but I wouldn't be surprised. Those poor poor MS developers.

            • bpicolo 5 days ago

              I wouldn't call them "poor" in this case. WASM is super cool and has a hopeful future, but productionizing wasm apps is currently still quite difficult in practice - it's still missing a lot of relevant tooling (debugging is hard)

      • recursive 10 days ago

        Well, blazor exists now, so that's not totally true.

        • TensorMetric 10 days ago

          They are actually using Typescript, and this will lead to less friction wrt hiring devs, supporting all those platforms and integrating web components. Still I would have hoped that MS would be a little more forward thinking, and put some of their MSR tech in good use, to encourage the use of better languages. Just like how Facebook is pushing ReasonML.

          I think that the C# focus of .NET is a major mistake holding the platform back, especially when we have languages like F#, Scala, Swift, ReasonML and Rust these days.

          • dep_b 10 days ago

            How do you know they're doing that? Not that it doesn't make total sense to use TypeScript from any angle I can imagine.

            > I think that the C# focus of .NET is a major mistake holding the platform back, especially when we have languages like F#, Scala, Swift, ReasonML and Rust these days.

            Yeah F# is really nice, but the IDE support is kinda meh. Also .Net expects you to embrace nil at a lot of points which doesn't gel so nice with F#. But Swift has a worse problem with Objective-C-isms but being a first class citizen really helps as they make a lot of API's really better to use with Swift.

    • irrational 10 days ago

      I wonder if it has anything to do with their being more JS developers than C# developers. Though, I imagine the average C# developer is a better programmer than the average JS programmer, but since quality is often a function of quantity, maybe there are going the later route. Or maybe it's something entirely different ;-)

      • Gibbon1 10 days ago

        > to do with their being more JS developers than C# developers.

        My boss told me there was no future banging out C on small embedded processors. 25 years later there is always work because there are so few people who can still do it. When 80% of programmers can't do anything other than JavaScript they'll be more than plenty of work for the other 20%

  • bunderbunder 10 days ago

    I'm guessing that in this case they're only talking about the "office software running in the browser" version of Office 365, not the "subscription pricing model for the desktop suite" version.

    • rbinv 10 days ago

      Except they actually are talking about all the versions, including desktop apps.

      • IshKebab 10 days ago

        Source? Edit: Never mind; the later tweets confirm they are using Electron and React-Native. Madness!

    • mcintyre1994 10 days ago

      I'm guessing they're just going to ship an Electron app and they won't be different codebases any more.

      • TensorMetric 10 days ago

        On Windows 10, they will target WinRT on UWP, with Fluent Design UI. Not Electron.

        • cududa 10 days ago
          • TensorMetric 10 days ago

            Not wrong, see the Windows 10 OneNote app for example, which already uses Typescript on WinRT/UWP. An Electron target will only be for legacy platforms, like Windows 7 and 8.

            Also see https://www.thurrott.com/cloud/office-365/161295/microsoft-r...

            • cvwright 10 days ago

              It's funny that the "new, simplified ribbon" in Thurott's screenshot looks a lot like the old interface in Office 2000.

            • rpeden 10 days ago

              It's interesting they're using Electron for Win7/Win8 when React Native for Windows has a WPF rendered that works nicely on Win7 and 8. Perhaps they just found that maintaining two slightly different RN office apps for Windows wasn't worth the effort given the declining market share of the older Windows versions.

              • roryisok 10 days ago

                So much for "learn once, write anywhere".

  • Someone 10 days ago

    Why at all? I would expect, long term, the ideal solution for a “run in browser” solution would be WebAssembly, possibly with JavaScript glue to the DOM. If so, they probably can keep large paths of their existing code base.

    Also, I expect the existing code base isn’t small, so a rewrite won’t be ready soon.

    That makes cross-compiling from whatever they have now to WebAssembly or JavaScript seem even better options.

    • tannhaeuser 10 days ago

      Well TFA is about a big-time rewrite of Office into JavaScript, so at least MS doesn't appear to see any perspective in WASM.

      Considering they are uniquely positioned to make it happen given their C# buy-in and probably more than just a bit of existing software to leverage, I'd say this is as strong a signal of non-endorsement as it gets.

      • chc 10 days ago

        I don't think we can read that much into it. The tweet says the project is nearly finished, and this doesn't sound like a small effort — so it would have started either before WASM was really a thing or when WASM was still a very risky bet. I mean, I don't imagine they'll be jumping to WASM, but I don't think we can read it as "they're deliberately not endorsing WASM" so much as "WASM is still quite new."

  • seanmcdirmid 10 days ago

    C# doesn’t easily compile to the web. This is why they are rewriting office 365 in the first place right?

    • privacypoller 10 days ago

      They just demoed running a winforms app in the browser using .NET CORE so maybe it would be less work/more successful to explore this path instead of trying to somehow re-implement the oxygen-sucking monster that is Excel using only the "new hotness (tm)".

      I bet this is only the new stuff like Delve and the less functional, more social apps/components. I can't imagine how they could pull this off for a full version of Excel or even Word or PP..

      • seanmcdirmid 10 days ago

        They are doing some of those tricks now with the current office 365. I assume they just want to migrate away from those tricks because they have drawbacks.

        Besides, office currently isn’t written. In .net, they would be migrating away from C++ code.

      • naikrovek 8 days ago

        Really? Is there a link to this demo anywhere? Seems neat

shrumm 10 days ago

Surprised they didn’t opt for Typescript. Then again, it’s a tweet - looking forward to a longer blog post with technical details when they’re willing to talk about it more.

  • dspillett 10 days ago

    > Surprised they didn’t opt for Typescript.

    I assume that they have. Typescript compiles down to Javascript so the tweet is technically correct (written in TS, executed in JS) and there are many out there who won't have a clue what TS is but have at least some grasp of what JS is so JS was probably stated instead of TS to avoid confusion amongst the unwashed masses.

    • sesutton 10 days ago

      The tweet mentions Visual Studio Code which uses Typescript.

  • coryfklein 10 days ago

    Oh god please I hope they have. In my experience, dynamically typed scripting languages struggle to keep up with the rigorous structure enforced by statically typed languages once the project gets large enough.

    Yes, in theory you _can_ write big projects well in dynamically typed languages, but in practice you get a mess of undocumented interfaces and unit tests that don't quite catch the plethora of errors not present when a static type system is in place.

    I think Typescript is a great middle ground between the loose running JS hipsters and the Haskell loving Hindley-Milner type system CS researchers. You can enforce the type restraints that you want (I personally am strict about explicit "string | null" declarations) but you're still hip enough to draw the JS talent.

    • seanmcdirmid 10 days ago

      Typescript doesn’t have much Hindley Milner in it since it has way too much sub typing (even if it’s all structural).

      • wtetzner 10 days ago

        Too bad they didn't go with row types instead of structural sub-typing. Though that might not have matched with their goals of being able to type existing JavaScript. Not sure.

        • seanmcdirmid 10 days ago

          Exactly. Going structural was purely to match JavaScript interop. Heck, even Dart went with nominal sub typing, it isn’t a very common choice fo an non-functional language.

  • sebazzz 10 days ago

    Javascript can still mean that Typescript is used.

    • Sammi 10 days ago

      I'm willing to bet money that MS is actually using Typescript for almost all their Javascript.

      • hellofunk 10 days ago

        I accept that bet! Let's discuss offline.

    • sno0ks 10 days ago

      But if somebody writes in Objective C, the C parts don't make it C.

      • crest 10 days ago

        They do. Objective C is a superset of C.

        • sno0ks 10 days ago

          C++ used to be a superset of C too before they diverged, but Objective C and C++ are/were viewed, correctly, as different languages from the same family.

  • qubex 10 days ago

    Or most likely WebAssembler...

rbinv 10 days ago

Office for Windows (WIN32) will be an Electron app? I have no words.

edit, since there seems to be some confusion: I am explicitly talking about the WIN32 variant, which he confirmed to be based on Electron.

  • vesak 10 days ago

        "No they are not electron apps. They are compiled to native code.
        
        It's now finally one toolchain(#webpack)
        It's one codebase and it compiles to:
        
        Web
        Android
        IOS
        MacOS
        UWP
        WIN32 (only one that uses electron)
        7:52 AM · Jun 13, 2018"
    
    https://mobile.twitter.com/TheLarkInn/status/100676113439583...
    • rbinv 10 days ago

      He says so in another tweet/reply.

    • awinder 10 days ago

      comment seems to be saying -- in modern windows (UWP) it'll be using native code, but microsoft is taking the easy path on win32. i guess some people are surprised that despite years of telling people that win32 is going away microsoft is finally making good. but I am not, I'm more excited than anything at another good sign that Microsoft is finally done with legacy windows.

      • wvenable 10 days ago

        > Microsoft is finally done with legacy windows.

        It's kind of sad; all the good stuff I use is basically legacy Windows. None of what Microsoft has done since Windows 7 has appealed to me.

        • AnIdiotOnTheNet 10 days ago

          Yeah, it's all been less functional and slower. That's the future of computing now.

      • emodendroket 10 days ago

        Hell, I hate all my old software just working too. I'd much rather get half-baked versions of everything that don't have all the same features.

  • IMcD23 10 days ago

    I’m an engineer in Office. This is not the case. The desktop app’s are fully native, and will remain so. They utilize React Native for a few components, but otherwise are written in C & C++.

    • 4ad 10 days ago

      Thanks for clarifying this nonsense.

      So, what the hell was this guy tweeting about?

      • contextfree 9 days ago

        In my experience most people in Microsoft have only a vague idea of what other teams are doing, even when none of it is really secret. If Office is starting to adopt React Native for some of its new UI components, and meanwhile there's a lot of work happening on the Office 365 web portal and Office web apps, internal telephone rumor circulation can morph that into "all of Office is being rewritten in javascript"

        • not_kurt_godel 9 days ago

          Nobody who truly participated in or contributed to the "complete" rewriting of Office in JS would be capable of expressing the positive emotions the subject of OP does...their soul would have been drained of the capacity to express joy long before the project would be completed. The tone smacks of the delusional cluelessness that MSFT's culture seems to uniquely foster.

        • exikyut 9 days ago

          Hmm.

          Whoever makes the first neural model capable of returning interesting insights after being installed in the telephone switchboard/backbone is going to have a most unique life.

          Edit: Just realized ISPs have probably been trying to do this for years. I'm talking about the first individual. It'll probably happen routinely in 20 years or so.

          • contextfree 9 days ago

            I was referring to the metaphorical game of "telephone", not literal telephones.

    • statictype 9 days ago

      Office for Windows has components written in react-native? Really? Any examples?

  • seba_dos1 10 days ago

    The whole thread and all later clarifications just look like a guy spewing random stuff loosely related with what he's working on at Microsoft. There's not much meaningful information to take from there.

  • maaark 10 days ago

    Nah it's fine, just upgrade to Win10 and buy your license through the windows store! UWP isn't using electron!

    What's that? Win32 a second class citizen? Never!

    • cm2187 10 days ago

      UWP doesn't run on win7. If you think getting rid of WinXP was hard, wait to see the phasing out of Win7. If you write for the desktop, chances are you are writing an internal app. Lots of large enterprises (including my present employer) just switched to Win7. Win10 is a looong way ahead. A significant part of your userbase won't be able to touch a UWP app for a long time.

      • atesti 10 days ago

        I wish Win10 never happened, but: How does your employer aquire hardware for win7? We have trouble buying Thinkpads that still run win7.

        It was a very smart move of MS to kill newer chipsets :-(

        If they hadn't done that, win10 would have completely tanked

    • jessaustin 10 days ago

      Isn't it about time? The "32" ought to be a clue...

      • gruez 10 days ago

        So? When were the POSIX APIs designed? Probably before 16 bit was common. By that logic we should migrate off that as well.

        • the_trapper 10 days ago

          In all fairness there are a fair number of POSIX APIs that are dangerous and need to be deprecated and removed.

  • Maarten88 10 days ago

    From what I understand they are using React Native.

    I too find it hard to believe they would drop the native Windows and OSX versions of Outlook, Word, Excel, for apps written in React Native. But Microsoft has offered many surprises lately...

    • Dinux 10 days ago

      We're talking 50M SLOC and 20+ years of development for native platforms. I highly doubt that they will let that go in favor of an JS app.

      • imtringued 10 days ago

        If they can charge for a subscription they will let all of that go in favor of an JS app.

      • rubidium 10 days ago

        Outlook on the web is certainly better than the application on windows... word won't be too hard. Now excel, that's the one I'd be surprised to see.

        • catmanjan 10 days ago

          Try doing a mail merge in owa

  • ealexhudson 10 days ago

    This isn't Office for Windows the suite. WIN32 is a platform they're not really supporting any more, I think they're basically saying if you're on WIN32 then you're getting the web version in future, not the real deal.

pandasun 10 days ago

I wonder how often NoScript maintainers just feel like throwing in the towel.

  • TeMPOraL 10 days ago

    I often wish we could just fork off the modern web and redo things the right way.

    • evv 10 days ago

      If you figure out how to build a cross-platform application distribution mechanism that is better than the modern web, please do let us know!

      • TeMPOraL 10 days ago

        I sure will.

        The challenge here is social. The Web has fist-mover advantage. Also, I fear that doing it the right way would be equivalent to forcing standardization on a single operating system (or a family of systems).

        • Waterluvian 10 days ago

          "Doing it the right way" is a fictitious concept in software development.

          You will have built a beautiful language/Web for today's needs, 10 years too late. And as the needs mutate you'll try to mutate with it, and that's how we get JavaScript.

        • dredmorbius 10 days ago

          The Web has fist-mover advantage.

          Typo reveals essential truth.

        • ManFromUranus 10 days ago

          You would inevitably just end up re-implementing a shittier Web with less features and no adoption. A waste of time.

          In the best case scenario you implement something almost identical to the current web which is only slightly better, and therefore not worth moving the entire world over to your stack just to get these minor improvements.

  • JCSato 10 days ago

    Ahahahaha

ksec 10 days ago

One Day Microsoft made VSCode and everyone loves them.

The Second day Microsoft decide to buy GitHub and everyone were flocking off to Gitlab, everyone hates them.

Now they are moving to the biblical end of computing era by making every Javascript.

May be they will even Open Source the Windows Kernel some day.

amiga-workbench 10 days ago

Are they trying to give hardware sales a nudge by writing everything as inefficiently as possible?

danso 10 days ago

The tweet that the OP is quoting/responding to is interesting:

https://mobile.twitter.com/jdgarciauc3m/status/1005768121230...

> Tip of the day.

> Scripting languages as first programming language for CS bachelors are WRONG. You are not able to write an OS, a DBMS, or even an Office suite with an scripting language.

I honestly thought this was a satire tweet. I guess I just don't associate even a CS bachelor's degree with writing that kind of software. I mean, it can, but there are more theoretical tracks that don't involve writing a OS/DBMS.

  • arghwhat 10 days ago

    I very much agree that this is a broken line of argumentation.

    However, I find the opinion to be correct: Scripting languages might not be a good first programming language for a CS bachelor, where priority is deep learning of programming. I'd also argue that JavaScript would be a bad candidate, as it is a very "unclean" language, being a poor way to teach language/compiler theory.

    As a first practical programming language for a non-CS bachelor, scripting languages are fine. Without CS courses to support you, other approaches might be too difficult, while scripting languages often let you get (terrible) programs up and running (ish) while ignoring basically all CS aspects during the learning phase (only while you're not making anything big, though—the "high level" illusion breaks down fast as things grow).

    (Also, yes, you can write a DBMS or an Office suite in a scripting language. I can't possibly comprehend why you'd want to do something like that, but it's very much possible. Bringing OS's into things is cheating, as most compiled languages can't be used there either, and those that work often only work with a subset of the full language.)

    • geofft 10 days ago

      You can't deeply learn programming in a language like assembly or even C. You don't have enough expressiveness to tackle large-scale problems (like office suites or DBs!) within the scope of what one person can work on in one semester; you'd be spending your time thinking about how to implement a hash table instead of how to use one.

      One of the nice things about so-called scripting languages is the breadth of library support. If you want to put together a GUI that displays some word-wrapped text, you can do that within the first hour of using the language, if you have some homework instructions you're following. At that point you can think about the interesting parts of writing a word processor, and not just how to put a window on screen (which tends to be more about docs and APIs and not about actual computer science). Also, importantly, at that point you've successfully done something, which is pretty important for the learning process.

    • chrisseaton 10 days ago

      > for a CS bachelor, where priority is deep learning of programming

      The priority is deep learning of computer science, not of programming.

      I think JavaScript is a fine language for teaching a lot of CS basics. For example you could run a course based on SICP using JavaScript instead of Scheme, I believe.

    • cgh 10 days ago

      I get the depressing feeling that a lot of Javascript programmers have no formal CS education at all.

  • DC-3 10 days ago

    At least here in the UK, all high-quality CS courses emphasise a functional language in the first year. The rigour and purity is important for teaching abstract concepts.

  • laurentl 10 days ago

    Most of the CS tracks I've seen recently (and even back in my days) have an "introduction to C/Linux" module which requires writing common command line tools, starting easy and gradually ramping up to a basic shell, a web proxy, etc.

    Not exactly OS/DBMS but still pretty low-level.

  • cgh 10 days ago

    I had to take a mandatory course where we wrote a simple flat-file db in x86 assembly, complete with a simple console-based interface. I’ve rarely needed to even look at assembly professionally, let alone write a real db, but I fully agree with the tweet.

DougN7 10 days ago

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)

  • hellofunk 10 days ago

    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.

    • Amezarak 10 days ago

      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.

      • brundolf 10 days ago

        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.

        • hellofunk 10 days ago

          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.

          • brundolf 10 days ago

            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.

            • hellofunk 10 days ago

              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.

              • brundolf 10 days ago

                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.

    • TeMPOraL 10 days ago

      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.

      • hellofunk 10 days ago

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

        • Sylos 9 days ago

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

  • megaman22 10 days ago

    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.

    • danmg 10 days ago

      2007 because of docx support.

  • wilsonnb2 10 days ago

    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.

    • AnIdiotOnTheNet 9 days ago

      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?

    • sp332 10 days ago

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

    • thorin 9 days ago

      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.

    • Sylos 9 days ago

      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.

candiodari 10 days ago

Let's all have a minute silence for all those software developers at Microsoft. Much evil has been inflicted on them in the past, ... and now this.

majidazimi 10 days ago

Time to apply for a 20M dollar loan to buy a semi supercomputer in order to run skype, slack and office all together. Any remarks on cray supercomputers?

  • setquk 10 days ago

    Err yeah, get your three phase power fitted now :)

  • IncRnd 10 days ago

    Exactly. Microsoft won't tell their enterprise customers that their crypto now runs in a browser and is no longer compliant with the standards of their industries. They would lose almost all of their sales revenue if they did that.

zihotki 10 days ago

I wonder, is it actually JS or they are using TypeScript? VSCode is written in TypeScript but it was mentioned there that it's JS, did somebody mixed things up?

  • fhrow4484 10 days ago

    Yeah, we can verify the validity of the statement since most of these project are open source. It's all Typescript, not JavaScript. according to the OP:

    >> Those are one in the same thing (compiled) :-). But us TypeScript in majority at Microsoft in almost all the projects I've seen or been apart of.

    Using the same logic, could we say that all windows is written in assembly ? When looking at JavaScript output of a Typescript program, it does really look like JavaScript is treated as assembly.

    One almost never edits the JavaScript code when using Typescript, especially if the mapped ts files are available when debugging in F12.

cm2187 10 days ago

Excel is already a dog in term of realculating large spreadsheets. I think we will need Intel's 28 cores at 5GHz monster!

  • bitL 10 days ago

    Maybe they'll just make it as slow as Open/LibreOffice's recalculation to be competitive...

    • chris_wot 10 days ago

      Do you have an example spreadsheet that shows the slowness in LibreOffice?

      • F_r_k 10 days ago

        Try plotting a 2x10000 range in libreoffice. Takes > 2 Mon just to render the graph. I'd be happy to provide the CSV to anyone interested

        • dm319 10 days ago

          I've found the speed relates to the fileformat it is saved in. Might well still be slower, but in terms of speed ods > xls > xlsx for some reason.

          • bitL 10 days ago

            I had it slow with plain CSV...

            • jackvalentine 9 days ago

              Plain CSV is ‘slower’ for whatever reason in my experience.

              (I have no idea how other formats are structured)

        • chris_wot 10 days ago

          I know this is impertinent, but can you lodge a bug with the project?

  • Sylos 9 days ago

    Even just scrolling is laggy in Excel to the point where it makes it hard to scan through data. LibreOffice does not have this problem.

  • ekianjo 10 days ago

    If you use Excel for large spreadsheets you are probably not using the right tool.

    • cm2187 10 days ago

      You and I know how to code. Most excel users do not. There is just simply not enough programmers in the world to do what all business users achieve and run on Excel.

    • bitL 10 days ago

      Pandas is slow. Hadoop is slow. Spark is slow. R is slow. What else is there?

      • ekianjo 10 days ago

        R is miles faster than Excel on large data tables.

      • et2o 10 days ago

        data.table in R is blazing fast

emodendroket 10 days ago

Oh, just what Office needed: a rewrite that will almost certainly not even approach feature parity

  • wilsonnb2 10 days ago

    Actually, I think the opposite is true. Instead of seeing new desktop versions without feature parity, we will finally see the iOS/Android/MacOS/Web versions of the Office Suite get feature parity with the Win32 versions because they will all be built from the same codebase.

    I know that it's common for rewrites to not approach feature parity, but I think Microsoft is aware of how much people rely on Excel and Word and will make feature parity a high priority because of that.

    • emodendroket 10 days ago

      I find it hard to believe they will ever duplicate all the edge cases. I mean in some cases it's literally impossible because IIRC VBA can actually hook into Win32 functions (I mean I guess you might argue that feature is a bad idea)

      • oceanswave 10 days ago

        If VBA can hook into WIN32 functions, why do you think a VBA parser/interpreter written in JavaScript using a native module that exposes the same WIN32 functions couldn’t do the same

        • emodendroket 10 days ago

          I suppose that's true; I just imagined it was going to be sandboxed to be browser-compatible.

  • AnIdiotOnTheNet 10 days ago

    Par for the course with everything else they've rewritten then.

chrisseaton 10 days ago

It says that the the JavaScript is compiled to native code. That's not something you get from React Native today is it? Have they implemented a new native code compiler for JavaScript? I wonder what compiler technology it uses.

  • thelarkinn 10 days ago

    This is right, its more nativeish apis and webview for UI and friends. Worthy Snipe and misinformation on my part in thread.

    • samueldavid 10 days ago

      wait.. so its using a webview for UI with native calls like cordova and pals?

  • tluyben2 10 days ago

    I was wondering that after reading more of the tweets; React native doesn’t compile the JS to native, so not sure what they are using to do all of that? Bit worried about the far superior languages C# and F# if they are not even dogfooding anymore.

    • ygra 10 days ago

      There has been a constant divide between the developer tools division (where C# comes from) of Microsoft and the OS/Office divisions. They both have worked very differently in the past and not at all in the same directions.

    • sebazzz 10 days ago

      It is not a question of dogfooding, it is a question of re-use. Office also needs to run in the web browser (Sharepoint, OneDrive)

      • solarkraft 10 days ago

        But C# can run on WebAssembly!

        • jhall1468 10 days ago

          Which is fine if you don't need your app to run in IE. They probably do.

    • contextfree 10 days ago

      Office client never used .net or C# to begin with

dvfjsdhgfv 10 days ago

I'll wait until it's done, released, and I have the opportunity to actually use it. Skype is already much worse than the original, so I really hope they don't go this way. I'm definitely not going to buy a 32GB notebook just to be able to use the most recent version of MS Office. (32 GB is nice BTW but a huge battery drain.)

cmjqol 10 days ago

Most of the comments seems to say "it's a bad idea" , keep in mind Microsoft is now using React very intensively for most of their projects as well as angular (VSCode , Windows Server etc... )

Meaning it's not the language the real issue , it's what you do with it.

Also Junior at school are less and less trained with Java and C# but straight up with JS or PHP , so it will be much easier to integrate juniors on this re-written version of office rather the pile of legacy C++ / COM / C# bridges mess they have right now.

  • walshemj 10 days ago

    Mail is one of the key parts of the internet no offence you don't want someone straight out some boot camp of dubious provenance having any input into what language or the spec of a MUA or MTA.

    Any new developers on this need to have experience working with email standards and a good knowledge of C++ / C not some fracking scripting language!

    And as some one who used to do international interconnect I think I have some valid input here - this has shades of the amusing project spitfire fiasco in the late 80's.

    • pducks32 10 days ago

      This is literally the same argument of the tweet's first poster (to which the linked tweet is a reply). This is just simply not true. I know many people who make mail apps for some big big companies. They have CS degrees and would admit they suck at C++ (I wouldn't even mention C) but they are great at Python

      • walshemj 9 days ago

        I was talking about outlook and exchange not writing some trivial script to send a registration email here.

    • cmjqol 10 days ago

      > no offence you don't want someone straight out some boot camp of dubious provenance

      None taken .

      My point is Microsoft is shifting to make it easier to separate their apps into clear layers . Coders from bootcamps can deal with the UI and some logic , C++ Engineers will deal with back-end and the mess that office is, and expose some API in JavaScript for them.

      • AnIdiotOnTheNet 9 days ago

        > Coders from bootcamps can deal with the UI and some logic

        Great, so the UIs will continue to get slower and more broken. What a glorious future we have to look forward to.

nickpp 10 days ago

Other tweets in thread are interesting too:

  No they are not electron apps. They are compiled to native code. 

  It's now finally one toolchain(#webpack)
  It's one codebase and it compiles to:

  Web
  Android
  IOS
  MacOS
  UWP
  WIN32 (only one that uses electron)
  • cm2187 10 days ago

    another tweet on that thread:

    > how is that even possible? there are tons of legacy features in there, COM/OLE APIs, SDKs, plugin architecture, macro system, VBA interpreter, VBA IDE, graphing components etc. Almost 30 years of development. No way MS is going to rewrite all of that. (Maybe the "mobile" version)

    I think this is a strong indication that all these technologies are going away.

    • Amezarak 10 days ago

      This would be suicide for Office. I struggle to believe that Microsoft is replacing the full Windows desktop version of Office with a version rewritten in JS. It makes no sense. Many, many, many businesses absolutely rely on the features you're mentioning, and many others that would be a tremendous undertaking to re-implement. There has to be something that's not being communicated right here. Maybe they mean the "lite" versions of the programs.

      • osullivj 10 days ago

        Strongly agree. Backwards compatibility has always been a strong suit for MS. Changing that stance is a major strategic shift, and IMHO would be a huge error, similar in scale to IBM's open PC architecture.

      • chrisseaton 10 days ago

        I also think it’s extremely unlikely MS is announcing an new native code compiler for JavaScript, something I’m not sure anyone knows how to do with reasonable performance, with a Tweet this casual.

        • jhall1468 10 days ago

          Web Views with native API's. So not truly native compilation.

          • cmjqol 10 days ago

            Has been said many many many times , it's not electron for Windows 10 , it's React Native .NET which bridges the built in Javascript VM with WPF. So it's not a web view for UWP, it's 100% native code.

            • chrisseaton 10 days ago

              > it's 100% native code

              He's said it's not compiling the JavaScript to native code - it's running it in a normal JavaScript JIT. It's not 100% native code.

  • ekianjo 10 days ago

    No mention of Linux despite how much they claim to "love" it.

    • thelarkinn 10 days ago

      If by "They" you mean me, someone who doesn't work on the project itself, but is advising over a toolchain for it.

      Also, I do not know what the Linux plans are (but hey maybe a great time to voice that special love you have for Linus T. and his masterpiece)!

      • donquichotte 10 days ago

        I don't understand what you are trying to say in this comment, can you elaborate? Where should gp voice their "special love" for Linux?

      • stoptekingdrugs 10 days ago

        Have you even read the comment you're replying to? Where the hell did you read that OP loves linus torvalds or linux. Microsoft is the one that claims to "love" linux [1], yet they don't release a linux version of office despite it being programmed to be platform independent. Why are you intentionally trying to misrepresent what OP said?

        [1] https://cloudblogs.microsoft.com/windowsserver/2015/05/06/mi...

brundolf 10 days ago

Re: the original tweet

JavaScript is a real language now. It's powerful and performant and uses modern paradigms, in addition to its sheer relevance.

That said, I am glad I was taught using C++ in college. Not because I plan to ever write an OS or DBMS, but because it taught me valuable lessons about pointers, how memory is managed, how arrays and lists differ, and other computing fundamentals that still inform you when writing in higher-level languages, even if you don't have to deal with those concepts directly.

  • ATsch 10 days ago

    This is true, but people like the orginal tweeter often pretend that this learning order is somehow the only "real" way to do things. I don't see why it isn't equally as valid to learn high-level concepts first and then learn the gory details later. I'm confused why there seems to be such a large number of low-level people so stubbornly insisting their order is the right one.

    • eropple 10 days ago

      From both my own experience and the experience of teaching people, those "gory details" are the nouns and verbs that compose higher-level abstractions. I haven't written C++ in anger in a decade, but it informs what I'm looking at when I'm reasoning through how V8 or the JVM is going to handle my code.

      I've been required to teach people in the top-down manner that has left knowing gaps and rendered them without the tools necessary to solve their problems. That's not to say somebody who eagerly learns on one's own may be fine. Of course they might, so long as they have a way to determine what they need to learn. But most people don't eagerly learn on their own, and so a prescriptive "start at the bottom and build up" provides the necessary knowledge and grounding despite themselves.

    • brundolf 10 days ago

      It can be a more difficult transition to go from high to low than from low to high. Not impossible, but frustrating and confusing.

      But also - not to stereotype too hard - but low-level people often have that crusty-old-sailor syndrome where they've been doing things the hard way since before these youngun's even first saw code, and if they can manage their own memory for performance then god-dangit everyone else should have to too.

mping 10 days ago

From the tweet author:

>It is. But @typescriptlang is just a static type linter that compiles to JS.

Hell, any language is just an assembly runtime plus a grammar. TS is a language that happens to be compiled to Js, I bet in the future it will be wasm.

davidhyde 10 days ago

As if they didn't learn their lesson with skype for business.

  • avryhof 10 days ago

    There's a Skype for Business written in JavaScript? I know there is Skype, but it doesn't talk to our Skype for Business (Lync) server.... I have to use Pidgin for that. (Linux)

    • megaman22 10 days ago

      Definitely not. Unless it's the godawful Mac client that doesn't work for most things, which is possible, since it's using UCWA under the covers.

      The Skype for Business Windows client was barely reskinned from the Lync 2013 client. I think they are still only a couple dozen patch revisions apart on the version number.

      • avryhof 10 days ago

        That's what I thought. It's tough to use Linux in a Windows shop. I have most of it figured out, though.

        It would just be nice to be able to join Skype/Lync meetings with Screen sharing.

  • thelarkinn 10 days ago

    I don't think I mentioned Skype for Business anywhere did I? :-)

yitchelle 10 days ago

Is this the "real" reason why they bought Github? They want to migrate their entire office products to use the ElectronJS. VisualCode and others were like the guinea pigs before going fully in with their office products. /end_speculation.

adreamingsoul 10 days ago

Seriously? This is a bad idea, and I say that as a engineer who writes a lot of JavaScript.

  • youdontknowtho 10 days ago

    They are using TypeScript for large scale projects.

    • andrewmcwatters 10 days ago

      Which is an even worse idea. In widespread practice, I regularly work with developers who can't even master JavaScript. To blithely toss another CoffeeScript in the mix is foolish if you ask me.

      • crooked-v 10 days ago

        You may want to actually learn what Typescript is before blithely making such comments.

        • andrewmcwatters 10 days ago

          Yeah, I know what Typescript is. It's another transpiled language. I don't care what the syntax looks like, the point is you've added a secondary level of knowledge required to operate in a codebase written in it, and most don't fluently know the first. Please tell me more about what I don't know.

          • rawrmaan 10 days ago

            Well, if you remove your assumptions about how incapable people are, TypeScript is the way to make large JS code bases maintainable. It doesn’t even change any of the JS syntax, it just adds to it. It’s the opposite of CoffeeScript in many ways.

          • Dylan16807 10 days ago

            Typescript is pretty much just annotations and linting. Most of the syntax features have been folded into javascript by now.

            In other words it's not a "secondary" level, you only have to learn one level to use it.

akerro 10 days ago

>It's one codebase and it compiles to: Web Android IOS MacOS UWP WIN32 (only one that uses electron)

Ah yes, you can see here the strong love of Linux in Microsoft.

bitL 10 days ago

Oh well, the kool-aid is strong. Next round of what Intel giveth, Microsoft taketh away...

Can somebody please design even worse language so that we can progress by reimplementing everything in it, keeping us occupied for the next 20 years?

  • capelio 10 days ago

    How much more real world evidence does HN need to see before the "JS isn't a real language" meme is abandoned?

    Pretty sure we're up to billions of real world value created by software written in Javascript. If you're still dismissive at this point, it's time to catch up. You've missed the boat.

    • arghwhat 10 days ago

      It's a "real" language, it's just not a terribly good or fast one. It's works decently when its use is limited to what it was made for: manipulating web pages. For anything else, the "designed on the back of a used piece of toilet paper" starts to shine through.

      And no, a JIT can't save you from this, it can only make things acceptable.

      That it can create "real world value" is an extremely low bar, which is passed by any turing complete language. COBOL creates "real world value".

      • nawgszy 10 days ago

        >it's just not a terribly good or fast one

        From everything I've seen, its performance sits just below Java (4x slower, perhaps) on some standard algorithms or tasks, and significantly faster than languages like Ruby, Python, etc.. I never see hate for those languages like for JS, so I'll disregard that.

        >not terribly good

        This one never has made sense. What is it missing that makes you hate it so? I think it has rather robust asynchronous handling, 'everything is an object' has lots of nice implications when paired with functionality like Object.keys / .assign, ... So what are the issues you see that make it 'bad'?

        • arghwhat 10 days ago

          > (4x slower, perhaps)

          "4x" is a lot slower, and a lot of things are much worse than this. You have to have deep knowledge of the VM (such as knowing how "hidden classes" work in V8) to be able to get JS close to Java.

          > so I'll disregard that.

          You shouldn't. Claiming a JIT'ed language is fast due to being faster than Python, an entirely interpreted language, is like saying a moped is a fast vehicle because it's faster than biking. Apples and oranges.

          Being faster than PyPy, the JIT'ed Python implementation, is a more interesting thing, but this is still very far off "fast" languages.

          > What is it missing that makes you hate it so?

          Most language features, really. "Everything is an object and objects are hashmaps, EVEN ARRAYS" (terrible for performance, type safety), "array of int16" strings with totally broken unicode codepoint handling (ES2016 brought new ways to deal with codepoints, but the standard way is still broken), the "Number" type which is totally retarted, the terrible "prototype" system, the malice that is "this" and how any bare function expression had its own this context (arrow functions are a good workaround now), and god I could go on.

          "Everything is an object" is only useful if you either actually need a hashmap (then use one!), or you have sloppy types.

          JS, as a langauge, is not well designed. I'm not saying it had to be Haskell or Rust, but JS is far below average.

          It works, and does it job decently due to the very hard work of JS engine implementors trying to make this crazy thing fast, but that's not the same as being good.

          • jhall1468 10 days ago

            > 4x" is a lot slower, and a lot of things are much worse than this. You have to have deep knowledge of the VM (such as knowing how "hidden classes" work in V8) to be able to get JS close to Java.

            That's a solid argument for only programming in C and Assembly because they are often 4x faster than anything.

            > Most language features, really.

            AKA, your preferences are "language features".

            > Everything is an object

            So you don't like Python. Or Ruby.

            > the "Number" type which is totally retarted

            Very technical argument there.

            > the terrible "prototype" system

            So you prefer classical inheritance. Cool. Doesn't mean prototypal inheritance is a bad thing.

            None of what you mentioned are missing features, they are personal preferences stemming for your own language preference that differs dramatically from Javascript. I'd start by disassociating your opinionated stances from actual weaknesses in the language, of which there are many, and none of them are what you mentioned.

          • bitL 10 days ago

            > objects are hashmaps

            But you still have to compute hashcode yourself :D

          • xamuel 10 days ago

            >Most language features, really.

            Name a few.

            >terrible "prototype" system

            >malice that is "this"

            It sounds like you are talking about ES5, not ES6+

            • bitL 10 days ago

              Can you guarantee all ES6- code to disappear immediately? Or are you forced to dive deep into warts when you have to work on some older JS project?

              • jhall1468 10 days ago

                Wow, now we're complaining about the outdated versions of a language? Come on man. Nobody is going to write a modern application in ES5 and there are plenty of warts in old Java, C and Python applications as well. That's the nature of them being "old".

              • shawnz 10 days ago

                Why does that impact whether or not it's a reasonable choice to use the language today? Old libraries I could understand, but old independent projects? How do they affect the current state of the language?

                • bitL 10 days ago

                  Isn't it obvious? You apply for a job, company that isn't a startup has code that is likely written with old JavaScript whose replacement is not economical, so even if you do everything new in ES7, you still have to wade through old ugly code, likely everyday.

            • StavrosK 10 days ago

              > Name a few.

              He did, literally exactly after that sentence.

              • xamuel 10 days ago

                No, he listed some things that he thinks are broken, he didn't list missing language features

                • StavrosK 10 days ago

                  I read it that he meant "fixes for these things are missing and that makes me hate it", i.e. I read it as the answer to your question. He doesn't hate it because it lacks features, he hates it because the existing features are badly implemented/thought-out.

        • FridgeSeal 10 days ago

          If I threw billions of dollars of vested interest at Python/Ruby/COBOL/(insert language of your choice) we can probably make those run at JS speeds as well. Does that solve the fundamental drawbacks of the languages?

          Nope. No it does not.

          JavaScript is particularly egregious because of it's weird behaviour about types and coercion and you know, just silently failing, behaviour that I wouldn't want going on in any proper system that handles anything important. Other people have written at great length about JS's many failings.

          JS is not the only language with nice async support, practically every mature language has async support and a good number of the compiled ones have proper parallel support as well.

          • cmiles74 10 days ago

            I think this is a really important point. Every browser vendor has spent huge amounts of dollars to increase the performance of Javascript. I don't know if there's another language that has enjoyed this level of investment... Maybe Java is closest, there are multiple companies working on their own VM implementations.

            The reason so much has been spent on Javascript: it runs in the web browser. For sure, people have found other reasons to like Javascript but at the bottom of the pile, money was spent because it was in the browser and the browser vendors wanted the browser to do more.

          • workinthehead 10 days ago

            every dynamically-typed language has "weird" behaviour around type coercion, that's simply the nature of the beast.

            sure wish i knew what you are talking about w/r/t "silently failing". JS has working exceptions just like 99% of widely used languages.

            I'm very glad that you've been omniscient enough to determine what "proper" parallel support is, though. How's that working out for you? Meanwhile, those of us using JavaScript simply run one process per core and never worry about contention, deadlocks, or race conditions.

            • pdpi 10 days ago

              > every dynamically-typed language has "weird" behaviour around type coercion

              Do they now?

                  $ irb
                  irb(main):001:0> "0" + 1
                  TypeError: no implicit conversion of Fixnum into String
                          from (irb):1:in `+'
                          from (irb):1
                          from /usr/bin/irb:11:in `<main>'
                  irb(main):002:0> ^D
                  $ python
                  >>> "0" + 1
                  Traceback (most recent call last):
                    File "<stdin>", line 1, in <module>
                  TypeError: cannot concatenate 'str' and 'int' objects
                  >>> ^D
                  $ node
                  > "0" + 1
                  '01'
              
              > Meanwhile, those of us using JavaScript simply run one process per core and never worry about contention, deadlocks, or race conditions.

              If you never worry about those things, then you're either not sharing any resources at all (in which case threads are also dead easy), or you're failing to deal with the shared resources properly.

              • StavrosK 10 days ago

                I know you know this, but for the GP or anyone else: "Dynamically typed" doesn't mean "strongly typed". Python and Ruby are strongly typed, JS is weakly typed.

                • pdpi 10 days ago

                  Yeah, went for the "picture is worth a thousand words" approach to explaining the distinction :)

                  • workinthehead 10 days ago

                    and yet you still managed to misunderstand the point :)

                • workinthehead 10 days ago

                  In your rush to be an asshole you completely missed my point, smart guy.

              • workinthehead 10 days ago

                Thank you for illustrating my point. All of the dynamic languages made different decisions on how to handle type conflicts, there simply is no right or wrong answer.

                Oh, and JavaScript is single-threaded. It's impossible to share resources in a single process.

                • pdpi 10 days ago

                  > Oh, and JavaScript is single-threaded. It's impossible to share resources in a single process.

                  DBs, files, etc etc. in-process memory isn't the only resource you're sharing.

                  • workinthehead 10 days ago

                    You really don't have a solid understanding of how computers work, do you?

            • dragonwriter 10 days ago

              > every dynamically-typed language has "weird" behaviour around type coercion, that's simply the nature of the beast.

              No, that's not true at all. Dynamic languages don't necessarily have type coercion at all, much less weird behavior around it (and, conversely, statically typed languages they have coercion may have weird behavior around it; there's just no link between dynamic typing and weird coercion behavior.)

              • workinthehead 10 days ago

                Who's to say not doing type coercion isn't weird? Every dynamic language treats things slightly differently.

                • dragonwriter 10 days ago

                  > Who's to say not doing type coercion isn't weird?

                  Well, if someone has to do it, I will: not doing type coercion isn't weird, and doing inplicit type coercion (not strict promotion[0]) is both weird and dangerous.

                  But, in any cases that's not really the point. The point is that in this...

                  > Every dynamic language treats things slightly differently.

                  “dynamic” is irrelevant. Languages have a wide variety of approaches, doing promotion, coercion, neither, or both (though where both are done, it's often just called coercion even when it is promotion), and dynamic vs. static is mostly irrelevant.

                  [0] that is, where the “from" type has a range that is a subset of the range of the “to” type.so that there is never a change in meaning resulting from the conversion.

            • tom_ 10 days ago

              Probably this thing, easy to spot in isolation but much harder when part of a larger system:

                 > x={}
                 > x.fred
                 undefined
              
              Actively unhelpful!
            • FridgeSeal 10 days ago

              > I'm very glad that you've been omniscient enough to determine what "proper" parallel support is, though. How's that working out for you? Meanwhile, those of us using JavaScript simply run one process per core

              Yeah, and I can do the same thing in Python, and it will be equally as lame: both languages are fundamentally single-threaded.

              You act as if JS has all problems solved: Erlang/Elixir/Golang have far superior async & parallel stories and will happily thrash JS/Node in performance and efficiency.

              How’s it working out for me? Well I do a lot of stuff in Haskell and Rust now, so pretty great actually.

        • thomascgalvin 10 days ago

          > What is it missing that makes you hate it so?

          1. Type Safety. TypeScript helps, but until strong typing is mandatory in the language, I can't fathom using JS in any sizable project. This is also true of Python, et al.

          2. A sane dependency management framework. Maven solved this problem a decade ago. Gradle is trying to fix Maven's XML mistake. But the fact is, if I need a dependency in Java, I know how to get it. And as a bonus, Maven Central isn't going to go down next Tuesday because Timmy in Alberta threw a temper tantrum or something.

          3. A sense of stability. Javascript's framework churn is just exhausting.

          • snorremd 10 days ago

            2. After the npmjs.com registry became immutable and npm got lockfiles I feel npm is pretty much there as far as dependency management systems go. I'm not sure if npm shares the cache across projects (like the ~/.m2/repositories folder for maven/gradle/leiningen), but you can get that with the yarn client if saving disk space is important.

          • jmull 10 days ago

            > ...until strong typing is mandatory in the language, I can't fathom using JS in any sizable project.

            There are quite a large number of counter-examples to show type safety isn't especially important to the success of large projects.

            I think the guarantees it provides are far too limited and weak to support large software systems. It relies on static code analysis, which doesn't mean much unless your app is a single build and runs as a single instance. That's more of a '90's style Microsoft Word type of app than what a typical large software project is today. Meanwhile the guarantees it does provide are only helpful to the extent developers can map their domain problems to the capabilities of the type system. Sometimes there is a nice natural fit, but usually the typesystem is both too weak (doesn't provide a convenient and natural way to impose the constraits of your problem domain) and too strong (imposes constraints your don't need or want, encumbering your development process).

            Not to mention that when it comes to Javascript, you can opt-in to about as much static code analysis, including type-safety, as you want.

          • jhall1468 10 days ago

            > until strong typing is mandatory in the language, I can't fathom using JS in any sizable project.

            There are massive JS projects in production today, but that's moot. It's never going to be mandatory because that ruins the point. Typing isn't a requirement of a language.

            > A sane dependency management framework. Maven solved this problem a decade ago.

            A Rube Goldberg machine that solved a problem? Maven's goals may have solved the problem, but its implementation did not.

            > A sense of stability. Javascript's framework churn is just exhausting.

            Feature, not a bug.

        • cm2187 10 days ago

          What creates hostility is the sentiment of being forced to use a bad language. There are many alternatives to python or php but none really to javascript (transpilers hacks apart). Webassembly might change that.

          The only other language that I have seen generating as much hostility is vb6, and also I believe because some developpers found themselves forced to use it.

          • paulie_a 10 days ago

            Also VB 6 syntax was complete shit.

            • cm2187 10 days ago

              Pretty much any old language has an odd and inconsistent syntax. I am getting into python now and it feels so much like doing VBA.

              • bitL 10 days ago

                Oh yeah, just wait until during a job interview somebody complains that you aren't "pythonic" enough, i.e. don't use some weird inconsistent syntactic wart somebody learned to love.

        • throwaway13456 10 days ago

          Have you ever used a language like Elixir? After using Elixir, my first thought was "why the f would anyone even use JS in 2018?" That's how poor the design choices of JavaScript are. Not to mention that the name itself is trademarked by the biggest troll (Oracle corporation).

          After using something like Elixir, you'll even wish if Javascript could be permanently banned from the Software industry for ever.

          I use Elixir + Ruby + Coffeescript and I still wish JS was never invented.

          https://twitter.com/bendhalpern/status/578925947245633536?la...

          • always_good 10 days ago

            Honestly your post just reeks of amateurism.

            I used to think the same thing back when I used Clojure + ClojureScript. Hah, what idiot would choose Javascript over my god tier Clojure/Script setup?

            Well, one day I actually tried to build a company and my cofounder just couldn't be fucked to learn Clojure. We decided on Node. I was forced to learn how to play nice with Javascript where I learned how to appreciate it.

            Nowadays, I have a hard time justifying something like Clojure/Script over Javascript. Same with Elixir. And I am very wary of people who can't spot trade-offs since that was how I used to be, and I was wrong. I just didn't have enough experience.

            There is no best. There are only trade-offs. Elixir/Clojure might be a good business decision for your project, but if you can't concede any positives to Javascript, I don't think you have a firm grip. And in the end it's always a business decision, not a technical one.

          • bitL 10 days ago

            That tweet was golden!

      • em500 10 days ago

        > It's a "real" language, it's just not a terribly good or fast one

        "There are only two kinds of languages: the ones people complain about and the ones nobody uses."

        - Bjarne Stroustrup

        • gizmo 10 days ago

          "There are only two kinds of file systems. Those that corrupt your data eventually and those nobody uses."

          Luckily, filesystem designers worked hard at making their filesystems journaling, fault tolerant, and more. And we stopped complaining angrily about filesystems ruining weeks (or months) of work, because it stopped being a regular occurrence.

          We still complain about the flaws of C++ because they are a constant source of pain.

          Stroustrup is arguing that if something is popular criticisms against it must therefore be invalid. He's wrong.

          • osrec 10 days ago

            I don't think he's saying the criticisms are invalid, but just that they are at the forefront of more people's minds because the respective language is more prevalent. Languages that are barely used also have their problems - they are just undiscovered or spoken about less.

            • gizmo 10 days ago

              If he wanted to make the really mundane point that people don't complain about things they don't use there would be absolutely no reason to bring C++ into it. He could just remark that nobody complains about the bad handling of the Model T anymore because nobody drives it. It's true but why is that relevant or at all interesting? Do we really believe this is the mundane observation Stroustrup is making?

              No. Stroustrup uses his snarky retort to deflect criticism. When C++ is criticized by (academic) language designers, his comment reads as "and yet people use my language and not yours". And that's pretty immature.

              Popular tools have to meet a high quality standard because every wart in the language affects millions of people.

              • osrec 10 days ago

                Perhaps we should reflect on why people do indeed use his language, warts 'n all?

                Are you suggesting C or Haskell are without their problems? What is your definition of a "good" language?

                • gizmo 10 days ago

                  Good languages are local maxima in the language design landscape. C is a good language. As is Python. And C#. There are many projects for which C or Python or C# are fine language choices.

                  Other languages have great ideas in them, but the languages themselves are a mixed bag. Perl, Java, C++. Perl inspired Ruby. Java inspired C#. But we haven't seen a good successor to C++ yet, probably because building a systems language is much more difficult than building an interpreted/scripting language.

                  • bitL 10 days ago

                    > good successor to C++

                    Maybe D, but outside Facebook nobody really uses it.

      • mcphage 10 days ago

        Not only is JavaScript a “real” language, it’s also a real language.

      • Brass 10 days ago

        Why the shot at COBOL here? COBOL's creation of "real world value" by comparison is hardly a low bar: https://thenewstack.io/cobol-everywhere-will-maintain/

        • pdpi 10 days ago

          COBOL was the state of the art when it was designed, but any evolution on top of that is, by necessity, limited by a 60-year-old core design. While it _has_ produced a lot of real world value in the almost 6 decades of its existence, starting a new project in COBOL would be ill-advised.

          Existing projects were written in whatever language for whatever reasons, it's "Would I start a project in this language today?" that's the bar to beat in terms of language "quality" and, in that sense, COBOL is a fairly low bar for most domains.

      • codingdave 10 days ago

        "real world value" is a completely fair metric. You might be able to argue that different languages offer more value than JS, for different use cases. But mocking the idea of "real world value" seems to completely miss the underlying point of app development -- which is to deliver value.

        • TeMPOraL 10 days ago

          Again, "delivering value" is a ridiculously low bar, when you measure "value delivered" by revenue. We ought to do better than that.

          Some extra hoops to jump above "delivering value (measured in revenue)" are:

          - Not creating extra problems for yourself down the line (maintenance costs, complexity, technical debt).

          - Not creating extra problems for everyone else (promotion of technologies causing problems if adopted).

          - Not dumping externalities on other people (inefficient solutions causing worse UX, more frustration and extra electricity usage).

          - Delivering actual value, as measured on the user end (whether or not the software makes them more productive), instead of revenue end (i.e. did we manage to trick enough people to pay us?).

      • ksec 10 days ago

        I wonder if they are using TypeScript.

        The old Javascript were very bad, recent Javascripts were bad, today's Javascript are OK, future Javascript / TypeScript is actually pretty decent.

        Of course I do hope something else has taken its place.

      • tinus_hn 10 days ago

        What part of ‘acceptable’ is unacceptable to you then?

    • pjc50 10 days ago

      It's very much in the same state that VB was, or even "Excel programming" is today: it certainly works and it certainly produces a lot of business value. It's just that the downsides appear further down the road; maintainbility and scalability issues, or intrinsic conversion causing data loss. That kind of thing.

      Every time someone waits for an Electron app to load, or watches it eat their ram? That gets added to the prejudice scale. Every overly-slow page load that eats mobile battery. The feeling that "it doesn't have to be this way" is very strong.

      • jhall1468 10 days ago

        These aren't Electron apps. They are applications written in Javascript and compiled to native via ReactXP and react-native-windows.

        Maintainability is a problem regardless of language, scaling is moot as these run native code, scalability is an odd word choice given we are talking about desktop apps, and intrinsic conversion can be solved via TypeScript, Flow or any other typing framework. C, Java and C# all have their own set of downsides as well, but we don't pretend those aren't "real" languages.

        You are correct that "it doesn't have to be this way" which is why native compilation exists and is continuing to grow.

      • scq 10 days ago

        I don't think JavaScript itself is the problem here. Electron is slow to load and uses a lot of memory because it's loading an entire multiprocess Chromium runtime with all of the Web platform implemented, optimized for speed and security rather than memory usage.

        Microsoft are using React Native here (aside from the Win32 build), which is going to be a lot more lightweight because it relies on the native platform for the heavy lifting.

    • cm2187 10 days ago

      Let's not confuse popularity (as in lots of users) and popularity (as in lots of love). Death and taxes are popular too! People write javascript because they have no other choice to run in the browser. I don't see that as a testimony that it is a great language.

      • actsasbuffoon 10 days ago

        If your only concern is the ergonomics of the language then there are lots of compile-to-JS languages. Some of them also compile to WebAssembly, which allows them to bypass the GC. It’s still not native speed, but it’s close enough for many applications.

        There are pros and cons, but within the next few years it could become common to write in your language of choice, compile to WebAssembly, and ship an app that’s within roughly 50% of native speed.

        I imagine JS will still be hugely popular even in that scenario, but that’s a different topic.

    • cirgue 10 days ago

      I will abandon my skepticism of JavaScript as soon as JavaScript boosters abandon their infomercialesque “millions of people can’t be wrong!” attitude and make a compelling case for the language itself. JavaScript is all we have for web dev which is why it’s so popular. That doesn’t mean it isn’t a fundamentally flawed language, it just means that no one has been able to popularize better solutions because of network effects.

      • titanix2 10 days ago

        JavaScript is so good Microsoft created Typescript to avoid dealing with it directly. (edit: wrong parent)

      • htor 10 days ago

        the millions are not saying it's perfect. that would be wrong. as you say what we have is js, so let's move on and make something useful with it instead of complaining about it being flawed. it is evolving, being standardized and getting new features. its not going to go away anytime soon, so instead educate yourself into avoid the pitfalls that exist in the language and have fun being productive.

      • kozhevnikov 10 days ago

        What is the fundamental flaw in JavaScript language?

    • emodendroket 10 days ago

      Nobody is claiming you can't write real software in JS. What they're saying is that it is a waste to do so when so much better tools are available. When you're in the browser there are such huge benefits that it makes sense. Elsewhere I find it hard to understand JS mania.

    • osrec 10 days ago

      It's about prevalence. The more prevalent a language is, the more the complainers come out in force. PHP is another language that has created billions of dollars of value, yet it doesn't stop the computer science purists from bashing it every other day. Just ignore the negativity and keep writing code in what makes sense to you.

    • bitL 10 days ago

      JS empowers beginners and disempowers advanced developers. If you are learning programming, JS helps you, if you need sensible pro-level features, you are out of luck.

    • redleggedfrog 10 days ago

      "Pretty sure we're up to billions of technical debt created by software written in Javascript."

      There, I fixed that for you. I didn't miss the boat. I've had to maintain mountains of awful code written by careless programmers in a pathetic language with a morass of constantly changing libraries for run-times (web browsers) that can't even be counted on to interpret the code the same.

      • dkns 10 days ago

        As opposed to The One Language that is perfect and doesn't incur technical debt when programs are written in it.

        "There are only two kinds of languages: the ones people complain about and the ones nobody uses." - Bjarne Stroustrup

    • throwaway13456 10 days ago

      Funnily enough, there's another post on HN's front page that (self) explains why JS is a flawed language:

      https://blog.bitsrc.io/11-javascript-utility-libraries-you-s...

      It's too big for a TLDR;

      But, just #1 in that list - You need to use a utility library to work with data types in a normalized form? In 2018?? Let that sink in. I hadn't had to do this with any other language.

  • nawgszy 10 days ago

    >even worse language

    What's wrong with JS, exactly, that isn't made up for by its advantages?

    I see these 'kool-aid' / 'JS is cancer' comments all the time, but they don't come with any real details.

    I feel like you've probably never really used JS, if I'm being honest.

    • arghwhat 10 days ago

      I wrote crypto algorithms and protocols, compression algorithms, browser engine sandboxes and similar in JS professionally for 5 years (don't ask why), and often had to deal with fun things like mis-compilations from JS engines and other fun bugs. I'd argue that I have quite extensive knowledge of JS, far beyond the average JS programmer (but far from the highest of experts, of course).

      JS's only unique, redeeming quality is its availability through the deployment of web browsers, and the benefits that come with such widespread use. JS wins marketshare because it has marketshare. Any language could have taken JS's place, and most would have been better. WebAssembly, when DOM integration and others become a thing, might allow us to throw JS off its throne.

      JS doesn't have advantages on its own to make of for its disadvantages, and relies heavily on extremely advanced JITs to make it borderline acceptable. The language itself still has very clear signs of having been designed on the back of a used napkin (its number type, its "array of int16's" string, "this", "prototype", ...).

      I would like to acknowledge that ES2016 brought some things that did remove some retarded areas of JS (like arrow functions, which do not have its own "this" context, unlike the old function expression, class definitions that can briefly make you forget the terrible underlying "prototype" madness, and ways to access proper unicode code points in strings), but we are very far away from having actual advantages here.

    • bitL 10 days ago

      Kool-aid in the sense that JS is extremely attractive to MBA types that don't have to write anything with it. There is a huge pool of JS developers (quality is questionable but price range is mostly low), browsers run everywhere, Node.js made it possible to run the whole stack on it, so that's a win for MBA types and a great value proposition. The fact that it's a historically atrocious language doesn't matter as they have peasants (i.e. us) to deal with it (to be honest, it got much better since async/await was introduced, but hacks/warts are still there to be abused in horrible ways).

      I wrote bleeding-edge games and other crazy stuff in JS you might be using right now in your business, so my opinion is not unfounded.

      • wiz21c 10 days ago

        Best comment so far

    • setquk 10 days ago

      We're mostly just bitter from years of being beaten with it. I can't actually face using node.js as an example. It is physically painful compared to other options that I have dealt with (flask, asp.net). Also for me, I've been burned before. Do you remember when everyone jumped on the PHP bandwagon? That. Again. Look where we are now.

      On the web, and now suddenly on the desktop, velocity is not what we need. We need quality and consolidation. Down the line can you see any ES6 based API lasting as long as win32? Hell no. Why would I want to risk building a major capital product on such guarantees?

    • Sammi 10 days ago

      JS has bad parts. That's why there is a popular book called Javascript the Good Parts. So sure old-school JS could be gnarly, but as the book says, you just use a linter and ignore the bad parts, and what you're left with is a very straight forward, clean and practical language. And now with Typescript on top too, we got the wonders of static typing also. What's not to like?

    • zippy5 10 days ago

      I think most devs who dislike it because it reduces the barrier to entry which undermines both their own prestige and quality of coworkers. Its similar to dislike of outsourcing in many ways.

      From a technical perspective, there are couple disadvantages in the long run that can make large codebases unmaintainable. In particular JS and PHP are resistant to static code analysis since they support functions like exec. So it becomes difficult to deprecate functions because the references are not necessarily explicit, thus can lead to tech debt buildup. ES6 does a better job but its backwards compatibility can leave the code vulnerable.

      • FridgeSeal 10 days ago

        > I think most devs who dislike it because it reduces the barrier to entry which undermines both their own prestige and quality of coworkers.

        I think the prestige comment is a bit unfair, but today at work I had to educate a JS dev on what headers are in a HTTP request/request and some other pretty basic things (a dictionary/record type object and a JSON string are not the same thing for one). They were like "I know I've got to do these things, but I don't know why/how they work".

        So yeah, I don't think disliking it because that's the average quality of JS dev I see is an unreasonable position. I'm sure there's some great ones out there doing impressive things, but I'm sure you could point them towards nearly any language and they'd produce something equally cool.

        • bitL 10 days ago

          > produce something equally cool

          I'd say they'd produce something massively cooler ;-)

    • dagw 10 days ago

      What's wrong with JS, exactly

      The language has some very ugly warts (although ES6+ fixes many things), I find that the quality/maturity/stability of third party libraries lags behind other languages, and the whole build/dev environment best practices is constantly in flux and breaking things all the time. Also Electron, for all it's advantages, is renowned for being a massive resource hog making what is otherwise a fairly fast and efficient language appear horribly slow at times.

      That being said, developing in JS today is a lot better than 3-4 years ago, and I suspect that that pattern will continue.

  • setquk 10 days ago

    Not only that, billions of hours of invested time and knowledge will be thrown out of the window instantly and everyone who integrates anything with Office will have to start again from scratch. Literally at least a third of the world is built on bits of spaghetti and duct tape on Office.

    For developers though, this is chargeable so I'm on the fence :)

    • bitL 10 days ago

      Nobody is going to pay you $1200/day to write JavaScript. The converse is true, there is an overload of low-paid JS devs.

      • setquk 10 days ago

        You're right actually but I suppose it'll keep the low paid javascript devs out of my market.

  • htor 10 days ago

    this js-is-not-a-real-language stand is only to be expected from someone like a professor or a computer science student. universities and educational institutions in general will always be the last ones to adapt to changes, after the rest of society has moved forward, and they will try imposing those conservative opinions on everyone who are not in their camp. times are changing, computers are becoming more complex and we need more abstractions too. and the ignorant js-is-only-a-scripting-language statement is simply not true anymore.

    • gizmo 10 days ago

      Except computers have not gotten more complex. We are dealing with the same kind of filesystems, virtual memory, relational databases, encryption, compression, and network stacks as 20 years ago.

      Objections against javascript are not Luddite objections against all types of higher level abstractions; the complaint is that javascript is not suitable for the creation of complex high quality software. If you beat your head against the javascript walls long enough can get something to work eventually, but that's not much of an endorsement.

      The only thing javascript has going for it is the delivery mechanism, and that is what makes it so compelling for business use. But this is not because javascript is so good, it's that the other methods of packaging/delivering software are so painful.

      The total absence of high quality software written in javascript is sufficient evidence to conclude that javascript is not a tool suitable for serious application development.

      • htor 10 days ago

        > The total absence of high quality software written in javascript is sufficient evidence to conclude that javascript is not a tool suitable for serious application development.

        a little overstatement, but okay. js is very suitable for this in my opinion. i don't what counts as "serious" application development in your world, but i've seen quite many good, performant applications around written in js. and servers too!

coinerone 10 days ago

That could lead to a possible "good" Linux version of Office 365? That would be Awesome imho. AAAnd hopefully they kill VBA and replace it with JavaScript :D. Like Building Forms with JS in Adobes Lifecycle Designer but in a good way.

  • alfredallan1 10 days ago

    That’s a good thought. As bad as JS is, I’d still prefer it to VBA.

    • dentemple 10 days ago

      Having had to write both, professionally...

      You've just never seen the monstrosity that is enterprise-level VBA.

      Javascript is a godsend over VBA.

setquk 10 days ago

This is good news for those of us who have to deal with VSTO, MSI packaging and all that cack. At last it might not feel like being buggered by a traffic cone repeatedly.

  • cm2187 10 days ago

    The ideal of an IT dept is to force all of their users to use only a locked down ipad. Of course they won't be able to achieve any work on them, and productivity will go down the drain, but that's not the problem of the IT department.

bhanu423 10 days ago

My hunch is probably there will be 2 versions maintained separately like visual studio and vs code. The version built in javascript will probably be free for personal usage, can have lesser features and probably fight for marketshare against google drive, libreoffice etc. I wouldn't be surprised if they even keep the source open. PR and market wise, this would be a great move.

  • wilsonnb2 10 days ago

    This was kind of true with OneNote up until recently. There are currently two desktop versions. One that comes with Office and looks/feels like the rest of the Office suite, and one that is made with UWP and available for free from the Windows Store. That one looks/feels a lot like the Android/iOS OneNote app.

    However, they've announced that they're EOLing the Office version, with bug fixes through 2020 and security updates through 2025, and are continuing forward with the UWP version.

    Perhaps we will see a future where they EOL the other Office applications in favor of new versions that are more similar to the iOS/Android versions. The iPad versions of Excel and Word are already pretty good.

    • TensorMetric 10 days ago
      • wilsonnb2 10 days ago

        Well that's disappointing. The simple ribbon in the new OneNote feels like such a step back from the ribbon UI in OneNote 2016.

        It does say users will be able to enable the full ribbon UI still, so I suppose I will have to do that. Hopefully they don't deprecate that feature.

        • ygra 9 days ago

          In the past the reasoning to replace the menu system with ribbons completely and not allowing to switch back is the understandable desire to not having to maintain and test two different UIs all the time. Two different ribbons may still work, as the ribbon already has information about "importance" or "prominence" of each item, but I fear eventually there'll be only one remaining in the future.

tenryuu 10 days ago

Wouldn't mind comparing battery life of this against current office 365 on my Gen1 Surface Pro

Half the battery goes to edge alone on a good day

spicymaki 10 days ago

FWIW, I personally like the direction Microsoft is going in. I look forward to seeing where this transformation leads.

  • cm2187 10 days ago

    The positive side of breaking compatibility with all legacy technologies (COM, VBA, XLL, etc) that currently force large companies to stick to MS Office is that it has the potential to reintroduce competition in the office-like software space. And in my opinion Office is the main reason why large enterprises stick to Windows. Most internal apps are moving to the web. If office backward compatibility goes away, then it's not clear that Windows is an obvious choice anymore.

    And it is kind of consistent with Microsoft's new strategy to de-emphasize Windows.

    • pjmlp 10 days ago

      Not sure if employees will enjoy the return to the days of time-sharing and remote X-Windows sessions though.

      Which is the end result of Webification of our tools.

    • h1d 9 days ago

      How is it the reason to stick to Windows when MacOS has had Office for quite a while?

      I think it's just people are used to the OS itself. I've seen people stick to Windows just because even in small companies.

anfractuosity 10 days ago

For skype I'm curious how much will be written in JS, I'm assuming crypto won't be?

I could well be wrong but I thought with an interpreted language it would be very hard to protect against timing attacks?

Wouldn't a lot of the network communication also be utilising compiled libraries?

stunt 10 days ago

Reminds me Gary Bernhardt's "The Birth and Death of JavaScript" talk.

pimmen 10 days ago

Why is this trend going on with using js in domains where it previously was not a component?

Is it to ease shipping new features? To make it easier for contributors once they make the application open source? Good PR?

  • dagw 10 days ago

    Why is this trend going on with using js in domains where it previously was not a component?

    Office products need to be on the web these days. Having a common code base between desktops, mobile and web makes that much easier and in that world JavaScript is the lowest common denominator.

  • discordance 10 days ago

    Aside from the view layer, probably due to the motivation to have a common code base across web, iOS, Android, Windows, Mac and Linux.

  • bitL 10 days ago

    JavaScript developers are cheaper and a legion.

JustSomeNobody 10 days ago

I want to see a breakdown of resource usage (RAM, CPU, etc.) before I cry too loudly. Office 2016 is a beast, so here's hoping (but not holding my breath) that they'll improve on it.

keriati1 10 days ago

Is it now TypeScript or JavaScript? It's a huge difference...

daemin 10 days ago

That explain why the Office windows are laggy as hell when being moved. It's like they're not processing window messages quickly enough or something.

FridgeSeal 10 days ago

So of all the good, far more suitable languages they could use, we're getting it written the flaming pile of trash that is JavaScript? Why though?

  • PunchTornado 10 days ago

    because it is not a pile of trash. the programmer can be a pile of trash though.

    • cirgue 10 days ago

      So I think “pile of trash” might be a bit too far, but JavaScript is a weird choice for one major reason: most languages have several objective technical and strategiec advantages. JavaScript has exactly two: it is the only language available in a browser, and it is on a large number of people’s resumes. There is no technical dimension of JavaScript that makes it the best choice for any task outside the browser, and the commonality advantage is shared by many other languages. If anyone has a good counter argument, I would love to hear it. I’m not saying that to be snarky, I genuinely want to hear perspectives in defense of JS other than “well it’s a good language because so many people use it and it’s better than it used to be”

      • always_good 10 days ago

        >There is no technical dimension of JavaScript that makes it the best choice for any task outside the browser

        Seriously?

        How about async-everything?

        • FridgeSeal 10 days ago

          JS is not the only language with async capabilities.

          Any number of other mature languages have async (and parallel, unlike JS) tools available.

    • slig 10 days ago

      > because it is not a pile of trash

      For instance, see the `Set` implementation here <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... and note that it doesn't even has `union` and `intersection` in the standard library. You have to copy/paste some code and place somewhere to have a minimum usable `Set` implementation.

      Pretty much a "pile of trash" in my opinion.

      • jhall1468 10 days ago

        This thread is getting weird. Now we're arguing an entire language is trash because the Set type doesn't have native methods you want? Really?

        • slig 10 days ago

          It's just a tiny example of how silly this whole thing is. What's the point of having a committee to draft and design an language that can't even be bothered to have a working Set implementation? It simply doesn't make sense.

          • jhall1468 10 days ago

            It's a pointless example that's trivial to fix. There are actual problems with Javascript. The examples you and many other detractors mention expose the actual problem: You have no idea how to use the language because you don't use it. Instead you whine about some trivial things (At a method to the Set type... it would take minutes), or things you don't understand (prototypal inheritance).

            • slig 10 days ago

              It's not about adding a method or two, I showed one symptom of a much larger problem. Of course one can add a method, but then why bother with the default crippled implementation in the first place? I'd rather have nothing and go find a third party library than having a half-assed one that's almost useless.

              > You have no idea how to use the language because you don't use it.

              I do use it daily for more than 15 years.

      • always_good 10 days ago

        That's such a weak example that it reads like a parody of the people who call Javascript a pile of trash.

        You're basically praising it with such faint condemnation.

        And by your own metric, I can't imagine how bad you think Golang is.

  • bitL 10 days ago

    MBA revenge on nerds...

  • KenanSulayman 10 days ago

    Recruiting is incredibly simplified

    • FridgeSeal 10 days ago

      Because recruiting devs for any given language is a block for the like of Microsoft right?

  • nawgszy 10 days ago

    >good, far more suitable languages

    Can you give a simple analysis on what weaknesses JS has that other languages would avoid with no pitfalls of their own?

    • cgh 10 days ago

      Why not take the opportunity to learn other languages and see for yourself rather than ask someone to hold your hand? Show some initiative.

      • nawgszy 9 days ago

        How on earth am I the one who needs to "[s]how some initiative" when some guy literally just says "JS is a flaming pile of trash" and gives no justification?

        It was an ad hominem and I asked him to expound on it.

neals 10 days ago

The Javascript is compiled to native code, apparently. Maybe there's a Typescript to Cpp transpiler that I haven't heard about?

rado 10 days ago

The sky is falling

tluyben2 10 days ago

Seems like a very strange move... But it’s a tweet. Might not mean anything really.

  • cm2187 10 days ago

    My first thought was an April fool joke that got lost in a queue or as a result of a bad network connection...

sonnyblarney 9 days ago

I hope to god they mean to say 'TypeScript'.

Otherwise, they'll never finish :)

discordance 10 days ago

Atwood's Law - "Any application that can be written in JavaScript, will eventually be written in JavaScript."

  • FridgeSeal 10 days ago

    Can we skip to the bit where we start re-writing software that we re-wrote in JS in other, more appropriate languages? :P

    • JustSomeNobody 10 days ago

      Not yet. Let's wait a little longer, that way those of us who would do the writing will be more valuable.

    • theandrewbailey 10 days ago

      My hunch is that those other languages don't exist yet, but afterwards we'll realize that those were even less appropriate than JS.

chaz6 10 days ago

I am slightly surprised by the choice to use ECMAScript instead of WebAssembly.

  • harrygeez 6 days ago

    You can't access DOM ATM. That's not to mention how large of an initial download it would require to put it on webasm. If they're gonna build only a thin client, JS is the best bet

arisAlexis 6 days ago

anybody knows details like if they use typescript or vanilla or some framework

starpilot 10 days ago

Title is missing the word "in." Come on.

anfilt 10 days ago

No! Bad MS! Stop it!

captainbland 10 days ago

I for one welcome our new Libre Office overlords.

  • moolcool 10 days ago

    Does LibreOffice still look like a Windows 3.11 application?

Fulck 10 days ago

download link anyone?

0xcafecafe 10 days ago

I wonder how much of global warming is caused by inefficient code written in higher level languages requiring more powerful hardware to run. It might be infinitesimal but still non-zero.

  • JCSato 10 days ago

    "Javascript is literally killing the Earth" might be the most HN comment I've ever read

    • slig 10 days ago

      The NoScript crowd must be proud.

  • thelarkinn 10 days ago

    Technically JavaScript is only ~7% slower then C++ to execute. But snipe away at that stats with real data.

    • TeMPOraL 10 days ago

      Technically, maybe. In practice, each language has its culture, its ecosystem. Its set of tools to pick from. Is it reasonable to expect the JavaScript Office will really just bind directly to all the native APIs it was using before, thus incurring only 7% penalty (+/- FFI)? Or is it more likely that it'll have web rendering shoved in everywhere, and then layers upon layers of off-the-shelf JS libraries, thus incuring more like 700% penalty in resource use?

    • 0xcafecafe 10 days ago

      Doesn't it depend on the benchmark? Yes, for some numeric problem as described here (https://www.linkedin.com/pulse/algorithmic-performance-compa...), the 7% figure seems reasonable. But for a real world app with object creation/deletion, the C++ memory model at a lower level would provide a much better performance over a garbage collected higher level one.

      And even if (hypotheically) the performance difference a constant 7%, that is still a tangible cost.

    • xeeeeeeeeeeenu 10 days ago

      The real problem is DOM, not the language or its implementations.

Melchizedek 10 days ago

This guy confirms all my prejudices against JavaScript hipsters, ruining computing for everyone since 1995. The beard, the super-fun-happy demeanor instead of thoughtfulness and competence.

Please Wasm, save us from this nightmare! And nuke the hipsters from orbit.

  • jmull 10 days ago

    You're using an ad hominem argument in the cause of thoughtfulness and competence?? Hm.

  • JCSato 10 days ago

    I know, right? Friendly, bearded, probably lives on the west coast and uses a Mac. Ugh. Can't wait for new technology to make these pathetic hipster devs hired by Microsoft for their abject lack of competence to go out of work.

    • jjeaff 10 days ago

      Ya, we all know that the only truly competent developer is socially awkward and difficult to work with, unwilling to compromise and writes everything in assembly.

      Sort of the developer version of "Nick Burns, Your company's computer guy"

      • dijit 10 days ago

        You wrote this comment thinking that you're right; that the only thing that is not hipster is ASM and being socially awkward.

        But you're both wrong, and I know it's obvious to everyone reading this comment but I'm spelling it out for you and OP specifically because nobody ever calls anyone out correctly.

        There is a nuance to technology; it's not black and white and leaping to the extremes is not helping.

        Is Javascript a "good" language by the classical definition of "good", well, no, not really.. but it's "good enough" for enough stuff and the ecosystem is the healthy part of it.

        My point is (if I'm trying to make one), making things natively is certainly better for users RE: desktop software. So if you care more about your users time and their resources than you do your own development time then it makes sense to do it in a native language. (Not ASM, that's facetious)

        The question invariably becomes: "Yeah, JS is /classically/ a bad language, mostly known by people who aren't formally qualified programmers who understand systems"

        vs.

        "Yeah, but can you imagine making something cross platform in C++ in 2018! talk about foot guns!"

        There is middle ground here, but unless we can talk about it professionally and with charity to the "other side" then we'll never get anywhere.

    • scrollaway 10 days ago

      Sarcasm or not, how did you and the parent commenter write this and think "Hm, yeah, this is a high quality HN comment that is sure to elevate the discussion"?

OnlyRepliesToBS 9 days ago

Don't break your arm patting yourself on the back.

The language is irrelevant to the users.

The UI is made with evil anti-user dark patterns because of... Microsoft.

draw_down 10 days ago

Compare the JS talk here to how sanctimonious everyone gets when PHP comes up. Then it’s “right tool for the job”, “don’t hate on something just because you don’t prefer it”, et cetera. When JS is the topic, well, see for yourself. Amazing.

gaius 10 days ago

Brendan Eich is our generation’s Thomas Midgley.