JavaScript logo

The esteemed Dr. Axel Rauschmayer has written a blog post about a new proposal for JavaScript: Types as Comments. It definitely has got me thinking.

On the one hand, I’m a huge fan of JavaScript evolution over the last decade or so. Arrow functions, const/var, classes, modules – that’s all good stuff that has improved the language.

Typescript logo

Seemingly on the same side of this argument: I’m also a huge fan of Typescript. It changed how I do large-scale frontend development four or so years ago – static typing in a language helps me write clear code, catches a huge number of bugs at compile-time, and the tooling and overall ecosystem around it is top-notch. Kudos to Microsoft on this one.

But I’m not convinced the value of this proposal nets out positive. The proposal itself says that the primary motivation is to inch JavaScript evolution towards eventually supporting static types:

Does JavaScript need static type-checking?

“Given how much effort organizations and teams have put into building type-checkers and adopting them, the answer is yes.”

Why?

Tools

You have to accept that JavaScript is the language of the runtime. We shouldn’t be caring about types at runtime – that’s the job of the toolchain prior to deploying. That’s the way every other language works (feel free to tell me how wrong I am in the comments – I am no language expert!).

Static typing only helps developers, not users.

Think about it this way: what level of performance degradation are you willing to accept for full support of static types? Is it ok for the JavaScript parser and runtime to be 5% slower for every web page or 15% larger in code size? Of course I’m pulling these numbers out of my ass.

When I was first fanboying out on TS, I used to think “gee, wouldn’t it be really cool for browsers to support Typescript natively”. Wouldn’t that be an awesome way to learn and view source, etc. But you know what’s good for that instead? Super-fast and small JavaScript for best performance and if you want to share your developer brilliance, have an optional compile-mode and source maps that point to your awesome Typescript.

Patrick the Star

Another thing I don’t like about the proposal is that, while they are clearly heavily influenced by Typescript, they hedge:

How does this proposal relate to TypeScript?

“This proposal is a balancing act: trying to be as TypeScript compatible as possible while still allowing other type systems”

You are JavaScript – if you are adamant about eventually supporting static types, why not boldly point towards a “north star” of a language that has already proven itself? Is it that you don’t want to admit Typescript won? Is it lingering anti-Microsoft bias?

My opinion: If we are going to add static typing for web apps, we should just use Typescript as a new script type. <script type=”application/x-typescript”> seems a better option to me so that the browser can choose an appropriate parser, etc.

§1296 · March 10, 2022 · JavaScript, Software, Technology, Uncategorized, Web · · [Print]

1 Comment to “Types of JavaScript”

  1. John B says:

    var a = ‘string’;
    var n = 123;
    var my_array = [];

    I fail to see how JavaScript (from the few minutes I read about static typing) does not already explicitly declare what the types of variables and objects are?

    It seems like another convoluted mess like how some PHP programmers confuse code style with actual object oriented programming. You don’t need PHP classes to do OOP.

    That is all OOP programming is, not having to figure out the same variable multiple times.

    Let’s take the fools who created scrollbar-width: thin;. WTF is that? WTF is “thin”? WTF is “thin” to Apple? WTF is “thin” to Google? WTF is “thin” on Windows? WTF is “thin” on Linux? WTF is “thin” on Apple? WTF is “thin” on a phone? WTF is “thin” on a PC with an 80 inch screen? I commented and my comment was marked as “disruptive”. The problem is that the people running the world want useful idiots, not intelligent competent people. I honestly think that is the issue. Eventually I’ll have my own browser with a new rendering engine and I will straight up have the console flood with errors for invalid garbage.

    Another and much earlier issue: “collapsed margins”. So when you define CSS margin-bottom: 36px; and the browser instead renders margin-bottom: 0;. That is IMPLIED logic which is guesswork, it’s not direct logic; implied logic has no place in programming.

    I recently had a minor update to PHP that broke a $_SERVER variable! It turns out someone who clearly has ZERO comprehension that programming is about string manipulation was update that a version number was provided in something. Even worse: the PHP developers removed it! How hard is it to use PHP’s explode?! Why did the PHP developers fail to realize the level of incompetence and stupidity of the request and not only reject it though call that person out for the obscenity of dictating that a programming language tailor itself to non-programmers?

    If you want arrow functions and that fancy kind of stuff good, it’s becoming increasingly better supported. That being said there are only a handful of areas that code is lagging behind on. In general people really need to learn that code doesn’t exist for the sake of itself – it exists to serve the needs of non-technical people running businesses in order to support themselves and their families. People who do programming seriously need to start asking themselves questions like, “Is this a good idea?” and “Will this actually help someone?” instead of “This is a cool thing! It serves no purpose but it’s a cool thing!” No one cares about your cool thing, people care if it makes a meaningful, purposeful and positive impact on their lives, namely by saving them time and aggravation.

    I agree with the notion of creating a new mime if they want to garbage up JavaScript with this nonsense. I don’t see any purpose to it other than some people trying to enforce one language on another. Hopefully the gate-keepers aren’t bumbling fools though I can’t say I’m optimistic.