Office 365 is being completely rewritten in JavaScript

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.

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.

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.

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

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.

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.

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.

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.

Typo reveals essential truth.

But if an app does it "old school" then it can definitely be very slow.

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

"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.

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.

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.

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.

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...

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.

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.

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?).

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