First look: adding type annotations to JavaScript(2ality.com)
2ality.com
First look: adding type annotations to JavaScript
https://2ality.com/2022/03/type-annotations-first-look.html
240 comments
I disagree that TypeScript comes with only a marginal upside. In my experience TypeScript projects are much more approachable for contributors.
For example, I once was debugging an issue in a JS framework and while I knew what was wrong and where I could fix it I didn’t have any idea what existing tools I had available in that context to fix it. Having type definitions would have made that work much simpler by increasing the accessibility of the code base.
It’s experiences like this that have convinced me that if I’m writing code that any one will possibly read or need to modify later (including if it is just me) then I should be writing TypeScript instead of JavaScript. Or, more generally, that it should be typed.
For example, I once was debugging an issue in a JS framework and while I knew what was wrong and where I could fix it I didn’t have any idea what existing tools I had available in that context to fix it. Having type definitions would have made that work much simpler by increasing the accessibility of the code base.
It’s experiences like this that have convinced me that if I’m writing code that any one will possibly read or need to modify later (including if it is just me) then I should be writing TypeScript instead of JavaScript. Or, more generally, that it should be typed.
Raw JavaScript in any production app is an abomination. Constant issues because one of the variables had a errant character. Countless bugs because of the same or it not being defined. On top of all that how in the hell am I supposed to know what a parameter or return value is supposed to look like? I have other things to worry about. I think these type annotations would make everyone happy. The IDE can navigate and inform but the objects will still need to be defined somewhere. I assume we can define a custom type with these annotations?
You and OP are both right, because it really depends on what you're doing.
At the scale I operate, it would be corporate suicide to try and write this code in straight JavaScript without type support. But for smaller teams, more focused teams, and teams that use a heavy testing discipline or enforced naming conventions that supplement the lack of static typing, it's not a problem.
At the scale I operate, it would be corporate suicide to try and write this code in straight JavaScript without type support. But for smaller teams, more focused teams, and teams that use a heavy testing discipline or enforced naming conventions that supplement the lack of static typing, it's not a problem.
Your basic disagreement here feels like it would be obviated by the parents "I hope this makes its way into the ECMAscript spec"? I.e., you would get typing without any of the tooling Typescript requires; the parent's point was JS + typing would be a pure benefit compared to Typescript, and you've said nothing to disagree with that.
So while you technically are disagreeing with the parent, it's on the smallest of points, and completely disregarding the main one the parent offered (which, fair enough, but wanted to point that out)
So while you technically are disagreeing with the parent, it's on the smallest of points, and completely disregarding the main one the parent offered (which, fair enough, but wanted to point that out)
What does "while I knew what was wrong and where I could fix it I didn’t have any idea what existing tools I had available in that context to fix it" mean?
I couldn't disagree more with you... All i see when working with different levels of experienced contributors is param:any any[]. Even more when you want to interact directly with DOM instead of using an opinionated framework.
You‘re blaming the active misuse of a tool on the tool itself.
This is why "no-explicit-any" should be enforced in every project.
https://github.com/typescript-eslint/typescript-eslint/blob/...
https://github.com/typescript-eslint/typescript-eslint/blob/...
This is either just code that is too complicated or devs that aren't doing a good job of type hinting.
Everytime there is an any, it means that each developer reading or modifying this code has to find it out for themselves - every single time. Why not just type hint it correctly in the first place.
Everytime there is an any, it means that each developer reading or modifying this code has to find it out for themselves - every single time. Why not just type hint it correctly in the first place.
I'm one of those `any` developers, and can attest to the first scenario. Had a client ask me to fix a bug in a repo that I wasn't familiar with. I spin it up, start looking through the code, and it's this massively over-engineered beast. 27K lines of Angular code to support a 2 page SPA that's basically just a note taking app.
Anyways, it's TS, and I don't know TS but I know how typing works so I can make my way around. I need to alter an interface to fix the bug, but with all the code it's very difficult to tell whether the change will break something either in the compiler or at runtime. To add on top of all that, the client needed the change to go out that day.
So guess what's going to happen? I'm using fucking `any` and I don't care.
Ultimately, this is why I don't like TS. I think it's a great idea, but if you look at all the energy that has been spent moving code over to TS from JS, and all the type definitions that were written into existing NPM packages, I have to ask myself why we don't just pursue making types native to JS? I don't want to write a secondary language that compiles to JS.
Anyways, it's TS, and I don't know TS but I know how typing works so I can make my way around. I need to alter an interface to fix the bug, but with all the code it's very difficult to tell whether the change will break something either in the compiler or at runtime. To add on top of all that, the client needed the change to go out that day.
So guess what's going to happen? I'm using fucking `any` and I don't care.
Ultimately, this is why I don't like TS. I think it's a great idea, but if you look at all the energy that has been spent moving code over to TS from JS, and all the type definitions that were written into existing NPM packages, I have to ask myself why we don't just pursue making types native to JS? I don't want to write a secondary language that compiles to JS.
> Anyways, it's TS, and I don't know TS but I know how typing works so I can make my way around. I need to alter an interface to fix the bug, but with all the code it's very difficult to tell whether the change will break something either in the compiler or at runtime. To add on top of all that, the client needed the change to go out that day.
It is massively easier to make change to large TS codebase. Just because you never bothered to learn TS and you rush feature at cost to maintenance, do not mean it is TS fault.
> Ultimately, this is why I don't like TS. I think it's a great idea, but if you look at all the energy that has been spent moving code over to TS from JS, and all the type definitions that were written into existing NPM packages, I have to ask myself why we don't just pursue making types native to JS? I don't want to write a secondary language that compiles to JS.
Because native types would create even more fragmentation while being less powerful than TS. JS was never intended for application development, we either embrace compilers or move away from language that have pathetic standard library, dynamic and complex type coercion rules, no stable module system, lack of strong leadership and legacy of supporting IE.
It is massively easier to make change to large TS codebase. Just because you never bothered to learn TS and you rush feature at cost to maintenance, do not mean it is TS fault.
> Ultimately, this is why I don't like TS. I think it's a great idea, but if you look at all the energy that has been spent moving code over to TS from JS, and all the type definitions that were written into existing NPM packages, I have to ask myself why we don't just pursue making types native to JS? I don't want to write a secondary language that compiles to JS.
Because native types would create even more fragmentation while being less powerful than TS. JS was never intended for application development, we either embrace compilers or move away from language that have pathetic standard library, dynamic and complex type coercion rules, no stable module system, lack of strong leadership and legacy of supporting IE.
I used to feel the same way about TypeScript until I really gave it a try one season.
I feel like I was crippling myself for years, being an inferior developer wasting so much time with the things that TS guards against, documents, and autocompletes for.
I support any formalization of TypeScript that further tidies up the "add-on" nature of it. But to be honest, it's really quite fine already.
I feel like I was crippling myself for years, being an inferior developer wasting so much time with the things that TS guards against, documents, and autocompletes for.
I support any formalization of TypeScript that further tidies up the "add-on" nature of it. But to be honest, it's really quite fine already.
I work at a place that is full stack typescript with a legacy app that is Js/react (the kind of stuff I was writing in 2017-2018.) After using typescript and going back to fix issues on the legacy codebase I now understand why the industry adopted Ts
This isn't going to fix those issues.
Those issues aren't due to tsc. They're due to an ecosystem which refuses to recognize the realities of compilation and add first class support for it. Its also due to an ecosystem willing to break compatibility (and not just backward compatibility but compatibility to other tools) at the drop of a hat.
For example, the main reason I've seen why people began using bundlers for node recently is the fact that a lot of modules transitioned to pure ES6 without CommonJS support. In most projects, this means you have to use a bundler to be able to import those modules, or switch your entire codebase to ES6 (which is non-trivial due to changes in import path semantics).
If it weren't for the above, you could just run `tsc` to get a `.js` file in `dist` for every `.ts.` file in `src` and run node on those.
Those issues aren't due to tsc. They're due to an ecosystem which refuses to recognize the realities of compilation and add first class support for it. Its also due to an ecosystem willing to break compatibility (and not just backward compatibility but compatibility to other tools) at the drop of a hat.
For example, the main reason I've seen why people began using bundlers for node recently is the fact that a lot of modules transitioned to pure ES6 without CommonJS support. In most projects, this means you have to use a bundler to be able to import those modules, or switch your entire codebase to ES6 (which is non-trivial due to changes in import path semantics).
If it weren't for the above, you could just run `tsc` to get a `.js` file in `dist` for every `.ts.` file in `src` and run node on those.
> They're due to an ecosystem which refuses to recoginze the realities of compilation and add first class support for it.
IMO this is the correct path. Compilation should result in WebAssembly and it seems like the tooling is finally getting there.
IMO this is the correct path. Compilation should result in WebAssembly and it seems like the tooling is finally getting there.
> Compilation should result in WebAssembly
It... It really shouldn't. Especially not if the target is the browser as the bridge between WebAssembly and the rest of the browser is still "just pass these arrays of integers around".
It... It really shouldn't. Especially not if the target is the browser as the bridge between WebAssembly and the rest of the browser is still "just pass these arrays of integers around".
I do not think that is a goal of either project; I’m not even aware of a POC JavaScript to WASM compiler. AssemblyScript couldn’t work without strong typing semantics and doesn’t support many typescript features.
Of course, using a bundler means you'll face several other unpleasant realities. Like
- what about tests, how do they run
- source maps support in node being 3rd party and unbearably slow for any medium sized project
- edit: this has been fixed somewhat recently https://nodejs.medium.com/source-maps-in-node-js-482872b56116
- only the 3rd party bit, not the slowness bit https://github.com/nodejs/node/issues/41541
- also applicable when not bundling, albiet fewer reprcutions to turning off source maps
- poor native (C++) modules support in bundlers
- modules with really dynamic `require` statements being supported at varying levels by varying bundlers> To me, I see the TypeScript tradeoff as coming with only marginal upside, in return for a large downside as described above.
I've coded using static and dynamic types. C#, Java, Ruby, JS, etc. 20 something years doing it, mainly for business applications (opposed to system or embedded). My personal opinion is that types bring an elusive value of control and maintainability. Confronted with legacy / spaghetti code, developers with less experience will bring lint, code style, some layers and ... types, as a way to solve the problem of long term maintainability.
But unfortunately it does not bring that much value. Actually it brings costs to readability and unnecessary abstraction (interfaces, generics, etc) aka "fighting the compiler".
A better test suite can have exponential more value on maintainability than types.
> Static Typing was the most requested language feature in the State of JS survey in both 2020 and 2021. [1]
So when I see static types been the most requested feature I wonder how many of them know how to create a good test suit or a good architecture. If its behind this feature request is a different pain to be solved.
[1] https://github.com/giltayar/proposal-types-as-comments/#comm...
I've coded using static and dynamic types. C#, Java, Ruby, JS, etc. 20 something years doing it, mainly for business applications (opposed to system or embedded). My personal opinion is that types bring an elusive value of control and maintainability. Confronted with legacy / spaghetti code, developers with less experience will bring lint, code style, some layers and ... types, as a way to solve the problem of long term maintainability.
But unfortunately it does not bring that much value. Actually it brings costs to readability and unnecessary abstraction (interfaces, generics, etc) aka "fighting the compiler".
A better test suite can have exponential more value on maintainability than types.
> Static Typing was the most requested language feature in the State of JS survey in both 2020 and 2021. [1]
So when I see static types been the most requested feature I wonder how many of them know how to create a good test suit or a good architecture. If its behind this feature request is a different pain to be solved.
[1] https://github.com/giltayar/proposal-types-as-comments/#comm...
> A better test suite can have exponential more value on maintainability than types.
A lot of ink has been spilled over this question. The conclusion is: no, tests do not and cannot replace types. Types, in themselves, provide a layer of tests that nobody, typically, would think of writing (what if a function is called with fewer arguments? what if it receives a different type of argument from what it was expecting?) and eliminate a whole class of superfluous tests that are checking for things that are better checked with types.
The self-documenting property of types is remarkable. Jsdocs do not hold a candle to a typed codebase.
Plus, refactoring. Even with tests I would be scared of large refactorings if I didn't have a type checker to also hold my hand. Of course, maybe I just don't know how to write code properly.
A lot of ink has been spilled over this question. The conclusion is: no, tests do not and cannot replace types. Types, in themselves, provide a layer of tests that nobody, typically, would think of writing (what if a function is called with fewer arguments? what if it receives a different type of argument from what it was expecting?) and eliminate a whole class of superfluous tests that are checking for things that are better checked with types.
The self-documenting property of types is remarkable. Jsdocs do not hold a candle to a typed codebase.
Plus, refactoring. Even with tests I would be scared of large refactorings if I didn't have a type checker to also hold my hand. Of course, maybe I just don't know how to write code properly.
I always say that Types are not there for the truly expert programmer. They are there for the rest of us. It's a lot easier to pick up code and understand it when you at least have an inkling as to what a variable or parameters needs to have to function.
Can interfaces be confusing, and generics become difficult to read? Yeah of course, but that's not really the problem of static type system, that's a problem with the code. I've generally found if you're doing something where you're thinking "this is just getting the way", you probably need to rethink your approach. Clear is always better than clever.
Can interfaces be confusing, and generics become difficult to read? Yeah of course, but that's not really the problem of static type system, that's a problem with the code. I've generally found if you're doing something where you're thinking "this is just getting the way", you probably need to rethink your approach. Clear is always better than clever.
> I always say that Types are not there for the truly expert programmer.
Machine-verifiable documentation about the intended I/O of functions and shapes of structs and objects is hugely fucking valuable to everyone. Your documentation isn't good enough if it doesn't include that, so it may as well be in a format that a machine can read, validate, and use to help out every single person who ever has to read or touch that code.
Machine-verifiable documentation about the intended I/O of functions and shapes of structs and objects is hugely fucking valuable to everyone. Your documentation isn't good enough if it doesn't include that, so it may as well be in a format that a machine can read, validate, and use to help out every single person who ever has to read or touch that code.
I always say that Types are not there for the truly expert programmer. They are there for the rest of us.
I would say exactly the opposite - beginners pick languages without [much] typing because it is or at least it seems easier to get started. When you step out of toy program territory you will start to appreciate the value of types.
I would say exactly the opposite - beginners pick languages without [much] typing because it is or at least it seems easier to get started. When you step out of toy program territory you will start to appreciate the value of types.
> beginners pick languages without [much] typing because it is or at least it seems easier to get started
It's hard to tell whether the reason beginners pick languages is because they are not typed or because they are immediately practical (such as javascript, php or python). Christopher Allen's and Julie Moronuki's Haskell Programming from First Principles is targeted at complete beginners. Harvard's CS50, which starts with C (well, Scratch, technically; then C), also targets beginners.
You don't see much lisp among beginners, despite the absence of type notation.
It's hard to tell whether the reason beginners pick languages is because they are not typed or because they are immediately practical (such as javascript, php or python). Christopher Allen's and Julie Moronuki's Haskell Programming from First Principles is targeted at complete beginners. Harvard's CS50, which starts with C (well, Scratch, technically; then C), also targets beginners.
You don't see much lisp among beginners, despite the absence of type notation.
> It's hard to tell whether the reason beginners pick languages is because they are not typed
No, it is not hard to tell. Programming beginners positively do not choose languages by evaluating concepts that they have no clue about.
> You don't see much lisp among beginners, despite the absence of type notation.
Lisps are simply not widely promoted to beginners; there aren't enough people to do that.
Beginners end up learning whatever is thrust at them most frequently and loudly. Basically, the non-beginners more or less decide that for the beginners.
No, it is not hard to tell. Programming beginners positively do not choose languages by evaluating concepts that they have no clue about.
> You don't see much lisp among beginners, despite the absence of type notation.
Lisps are simply not widely promoted to beginners; there aren't enough people to do that.
Beginners end up learning whatever is thrust at them most frequently and loudly. Basically, the non-beginners more or less decide that for the beginners.
I think "truly expert programmer" is hypothetical. I don't think I encounter many programmers that prefer to eschew typing unless it's a quick one-off script. Typing your code takes maybe 1-10% of the time it takes to right (if that). It provides far more value than tests. Just like Rust's ownership model in the type system provides much better results than C++'s implicit ownership model + tests.
That's exactly my point. There are very few people that are real experts, people that can see code and reason everything in their heads with little or no help. There really aren't any. Everyone thinks they are, but they aren't. Having types helps the rest of us understand what is going.
no-one is a truly expert programmer 100% of the time.
Types catch a lot of stupid errors that anyone can make, regardless of skill level.
They also localize guarantees. If your data has a type, you don't need to understand the full path it took to arrive in your function to be able to work with it. With dynamic types, you can only hope that a value has the type you need unless you explicitly check every time.
Types catch a lot of stupid errors that anyone can make, regardless of skill level.
They also localize guarantees. If your data has a type, you don't need to understand the full path it took to arrive in your function to be able to work with it. With dynamic types, you can only hope that a value has the type you need unless you explicitly check every time.
> Confronted with legacy / spaghetti code, developers with less experience will bring lint, code style, some layers and ... types, as a way to solve the problem of long term maintainability.
> But unfortunately it does not bring that much value.
If you mean adding these things post-hoc, yes the value is limited. If you start with types, and you embrace them as a design and testing tool, they can literally change the kind of code you write in the first place.
People talk about how convoluted TS types are, but the reality is that’s because they’re describing convoluted JS. TS-first code tends to be a great deal more straightforward, because you define the interface before implementing it.
In other words, if you start out with static types and think about them first, you’ve likely already got a good architecture and test suite.
> But unfortunately it does not bring that much value.
If you mean adding these things post-hoc, yes the value is limited. If you start with types, and you embrace them as a design and testing tool, they can literally change the kind of code you write in the first place.
People talk about how convoluted TS types are, but the reality is that’s because they’re describing convoluted JS. TS-first code tends to be a great deal more straightforward, because you define the interface before implementing it.
In other words, if you start out with static types and think about them first, you’ve likely already got a good architecture and test suite.
I guess there are differences between how static typing is implemented.
I've been using Elm for the last 2 years and it's not that I don't fight the compiler, but I constantly use it to guide me while refactoring. Elm code is extremely readable and types (including Maybe, Result, etc.) just give so much confidence and control to the programmer. While working with an Elm code base, refactoring is a constant, joyful, safe act.
It is true that in many cases good tests help. However often when I work with Python (using type hints), I need to write a unit test just to ensure a contract that I could explicity state using types in Elm. It doesn't feel right.
I've been using Elm for the last 2 years and it's not that I don't fight the compiler, but I constantly use it to guide me while refactoring. Elm code is extremely readable and types (including Maybe, Result, etc.) just give so much confidence and control to the programmer. While working with an Elm code base, refactoring is a constant, joyful, safe act.
It is true that in many cases good tests help. However often when I work with Python (using type hints), I need to write a unit test just to ensure a contract that I could explicity state using types in Elm. It doesn't feel right.
Unit tests aren’t a replacement for static types. Tests aren’t machine readable so you lose all those nice IDE refactoring features and have to manually keep them up to date. Also running a test suite takes time, it takes a lot longer to run a test suite than it does to get live typecheck, which means you cannot use tests while you are editing. And you probably don’t want to clog up your test suite with endless “x is a Y” tests.
In general dynamic types incentivize the status quo and promote codebase ossification, and somewhat ironically make rapid prototyping harder.
In general dynamic types incentivize the status quo and promote codebase ossification, and somewhat ironically make rapid prototyping harder.
[deleted]
Do you write a lot of library code? I'm genuinely wondering in what kind of environment you would get "marginal upside" from having a good type system.
I've been coding JavaScript for many, many years. I've never encountered a situation where the lack of typing bit me in the ass. Not even once!
Having said that, it might be because when I'm writing JavaScript it's just me. Normally I'm the sole developer. So of course I know my own stuff! I'm not going to experience an error passing the wrong type to a function because I literally wrote all the functions myself. I even have enormous libraries of JS code that I use in my personal and work projects where I wrote everything.
This developer is probably in the same sort of situation. Type errors are the kind of thing you run into when you're working with large codebases that were written by lots of different people. It's not the type of thing you experience with your own code.
I've also written loads of Python and never experienced an error where the wrong type gets passed to a function (even working in a team). For years I couldn't even fathom how static typing would be a benefit other than maybe it can speed things up by giving a compiler/interpreter the ability to optimize things. Then at work--after nearly 20 years of Python--we finally had an issue where the wrong type was passed (float was inadvertently rounded because the function was made for integers and it wasn't obvious). It was caught before the code was sent to production (and it wouldn't have been a huge deal anyway) and I finally had a real-world situation where type annotations would've prevented an error.
It's just not something that happens very often. It's the type of thing that creeps up on you for sure but it's not a common, every day occurrence. Type-related bugs are really super obscure. They're far, far rarer than type-obsessed developers make them out to be.
Having said that, it might be because when I'm writing JavaScript it's just me. Normally I'm the sole developer. So of course I know my own stuff! I'm not going to experience an error passing the wrong type to a function because I literally wrote all the functions myself. I even have enormous libraries of JS code that I use in my personal and work projects where I wrote everything.
This developer is probably in the same sort of situation. Type errors are the kind of thing you run into when you're working with large codebases that were written by lots of different people. It's not the type of thing you experience with your own code.
I've also written loads of Python and never experienced an error where the wrong type gets passed to a function (even working in a team). For years I couldn't even fathom how static typing would be a benefit other than maybe it can speed things up by giving a compiler/interpreter the ability to optimize things. Then at work--after nearly 20 years of Python--we finally had an issue where the wrong type was passed (float was inadvertently rounded because the function was made for integers and it wasn't obvious). It was caught before the code was sent to production (and it wouldn't have been a huge deal anyway) and I finally had a real-world situation where type annotations would've prevented an error.
It's just not something that happens very often. It's the type of thing that creeps up on you for sure but it's not a common, every day occurrence. Type-related bugs are really super obscure. They're far, far rarer than type-obsessed developers make them out to be.
I've never encountered a situation where the lack of typing bit me in the ass. Not even once!
You absolutely have. At some point in your career, you've accidentally got the arguments to a function in the wrong order and had to debug what was happening. Or ended up with a `null` where you didn't expect it. Or used an invalid value for a string enumeration, made an inobvious typo in a field name of an options object, accidentally added brackets and called a function when you meant to pass a reference to it, failed to deal with the return type of a promise, or any number of other examples of mistakes that everybody makes all of the time.
These are all examples of common errors that can be caught by a type checker. It's totally valid to debate whether the cost of a type system is worth paying in the context of different environments, but if you're starting from the not-really-credible position of "I have never made a type error, ever", then it suggests that you're working with a set of faulty assumptions about what they offer.
(For my own part, as a Javascript user of some 20+ years now, picking up TypeScript has been the best boost to productivity and code quality I've had in my career. It's got to the point that I'd just point-blank refuse to work with a Javascript codebase now, because it's not worth it.)
You absolutely have. At some point in your career, you've accidentally got the arguments to a function in the wrong order and had to debug what was happening. Or ended up with a `null` where you didn't expect it. Or used an invalid value for a string enumeration, made an inobvious typo in a field name of an options object, accidentally added brackets and called a function when you meant to pass a reference to it, failed to deal with the return type of a promise, or any number of other examples of mistakes that everybody makes all of the time.
These are all examples of common errors that can be caught by a type checker. It's totally valid to debate whether the cost of a type system is worth paying in the context of different environments, but if you're starting from the not-really-credible position of "I have never made a type error, ever", then it suggests that you're working with a set of faulty assumptions about what they offer.
(For my own part, as a Javascript user of some 20+ years now, picking up TypeScript has been the best boost to productivity and code quality I've had in my career. It's got to the point that I'd just point-blank refuse to work with a Javascript codebase now, because it's not worth it.)
> I've never encountered a situation where the lack of typing bit me in the ass
Quite the claim! For me the moment I never want to look back to is to refactor a substantial part of the architecture of a JS app with more than 20k lines of code (And I did write most of it myself). If you don't do large scale refactorings or work mostly on smaller apps, then indeed, types won't be much of an issue.
But you should become aware about how often you see "undefined is not an object" and similar, that's a type error that is almost gone when using TypeScript.
Quite the claim! For me the moment I never want to look back to is to refactor a substantial part of the architecture of a JS app with more than 20k lines of code (And I did write most of it myself). If you don't do large scale refactorings or work mostly on smaller apps, then indeed, types won't be much of an issue.
But you should become aware about how often you see "undefined is not an object" and similar, that's a type error that is almost gone when using TypeScript.
I've got (too many) years of JS experience too, and I started a project in TS last November to see what the fuss is all about.
I have to say I'm a convert. Not so much because it's catching a ton of errors for me, more that it brings such a massive improvement in IDE autocomplete behaviour. TypeScript in VS Code starts to feel almost like C# in 'real' visual studio. (The errors it does catch in my code are usually potential null references which would probably have been fine, but I'm sure it's avoided a few bugs.)
The most interesting thing for me is that it allows me to feel safe doing things I would avoid in plain JS, like using literal union types (which would be magic numbers/strings without the typing).
I still write JS for small stuff, but when you're next starting a new project that'll go over a few thousand lines of code I definitely recommend giving it a try.
I have to say I'm a convert. Not so much because it's catching a ton of errors for me, more that it brings such a massive improvement in IDE autocomplete behaviour. TypeScript in VS Code starts to feel almost like C# in 'real' visual studio. (The errors it does catch in my code are usually potential null references which would probably have been fine, but I'm sure it's avoided a few bugs.)
The most interesting thing for me is that it allows me to feel safe doing things I would avoid in plain JS, like using literal union types (which would be magic numbers/strings without the typing).
I still write JS for small stuff, but when you're next starting a new project that'll go over a few thousand lines of code I definitely recommend giving it a try.
Have you tried type annotations in jsdoc?
Inline /* @type */ statements and jsdoc type declarations coupled with .d.ts files for complex types achieves the same thing for me without the extra compilation step.
Inline /* @type */ statements and jsdoc type declarations coupled with .d.ts files for complex types achieves the same thing for me without the extra compilation step.
Yeah that's what I do as well. I actually find TS uglier now. It ends up being full of really long lines like:
const myFunction(a: Long<TypeName>, b: Another<LongType>): FooBarIt’s never “just you”, though: it’s present you and past you. When I come back to code I wrote months or years ago, static types are super helpful as I try to remember what the heck I was doing. They’re at least as valuable for documentation as they are for catching errors.
Refactoring is much easier in a well typed codebase.
When refactoring is easier, it happens more often, which means code quality and readability are higher, which reduces the likelihood of every other kind of error.
When refactoring is easier, it happens more often, which means code quality and readability are higher, which reduces the likelihood of every other kind of error.
> I've been coding JavaScript for many, many years. I've never encountered a situation where the lack of typing bit me in the ass. Not even once!
Okay, well, here's an example of it leading to a CVE: https://www.mozilla.org/en-US/security/advisories/mfsa2012-7...
The way-and-how of it is that the then-new devtools team working on the then-new JS console lost track of what objects they were passing into a polymorphic function, which resulted in untrusted, content-supplied objects being treated the same as DOM nodes that were supposed to originate from within the JS console implementation itself (for its UI), which resulted in browser-level privileges being given to content authors of ordinary web pages.
Okay, well, here's an example of it leading to a CVE: https://www.mozilla.org/en-US/security/advisories/mfsa2012-7...
The way-and-how of it is that the then-new devtools team working on the then-new JS console lost track of what objects they were passing into a polymorphic function, which resulted in untrusted, content-supplied objects being treated the same as DOM nodes that were supposed to originate from within the JS console implementation itself (for its UI), which resulted in browser-level privileges being given to content authors of ordinary web pages.
> I've never encountered a situation where the lack of typing bit me in the ass. Not even once!
Maybe you just see the "cannot find property of undefined" type of errors as usual business, but this is the #1 kind of error I see in the logs of big applications, and TypeScript really helps to mitigate them.
Maybe you just see the "cannot find property of undefined" type of errors as usual business, but this is the #1 kind of error I see in the logs of big applications, and TypeScript really helps to mitigate them.
> Having said that, it might be because when I'm writing JavaScript it's just me.
Well, you don't need types because you only look at your own code. The advantage of having my IDE tell me what to expect when I'm refactoring a piece of code someone else wrote is a few orders of magnitude more useful and informative than having to jump through various functions and files to understand what's happening.
Years of writing code do not equate to proficiency and expertise. You may have been writing code for many years but I would go so far as to assume that you experience is actually very limited.
Well, you don't need types because you only look at your own code. The advantage of having my IDE tell me what to expect when I'm refactoring a piece of code someone else wrote is a few orders of magnitude more useful and informative than having to jump through various functions and files to understand what's happening.
Years of writing code do not equate to proficiency and expertise. You may have been writing code for many years but I would go so far as to assume that you experience is actually very limited.
Agreed on both counts. For me types are not very useful for catching errors. What they are extremely useful for is documentation and navigation of code. Primarily other people's code of course but also for my own code once a certain amount of time has passed.
This reflects my experience when working alone, but when working on a team the experience is drastically different.
[deleted]
I've often speculated that strong typing only seems like a win to the kind of developer who makes a lot of type errors, and a waste of time to those who don't (which doesn't mean they don't make other errors, of course).
> like a win to the kind of developer who makes a lot of type errors
Or just to the developer that likes to offload that cognitive load to their tools.
Why hold that in my head when the IDE can keep track of it for me? Why memorize every single attribute name when the IDE can autocomplete it for me? etc.
Or just to the developer that likes to offload that cognitive load to their tools.
Why hold that in my head when the IDE can keep track of it for me? Why memorize every single attribute name when the IDE can autocomplete it for me? etc.
This is about manually-written type annotations. About as far as can be from "the IDE keeping track of it for you".
You manually write the type annotation, and then the IDE keeps track of the rest.
Instead keeping track of the type annotation in your head, and then also keeping track of the rest of the stuff in your head too.
Instead keeping track of the type annotation in your head, and then also keeping track of the rest of the stuff in your head too.
Even developers who "don't make type errors" have to deal with bad and unexpected data, which may be in a different type.
If you don't validate that all untrusted data is off the appropriate type, security vulns or "garbage in - garbage out" bugs can result.
Then if you do manually validate the types of untrusted data, then you have to wonder of having built-in type support might be faster.
"Bad data" doesn't just come from the outside world. As teams start to use shared libraries written by other people, it's also valuable adds guards to ensure that shared functions are being called with the expected types.
My own experience is that it doesn't feel like type-related bugs come up often on my team, but when they do the problems they cause can be bad enough to make us wish more of our code had been ported to TypeScript.
Classic example: a CSV parser parsed numbers as strings because a particular spreadsheet quoted the number column. Result: "2"+"2" = "22"
If you don't validate that all untrusted data is off the appropriate type, security vulns or "garbage in - garbage out" bugs can result.
Then if you do manually validate the types of untrusted data, then you have to wonder of having built-in type support might be faster.
"Bad data" doesn't just come from the outside world. As teams start to use shared libraries written by other people, it's also valuable adds guards to ensure that shared functions are being called with the expected types.
My own experience is that it doesn't feel like type-related bugs come up often on my team, but when they do the problems they cause can be bad enough to make us wish more of our code had been ported to TypeScript.
Classic example: a CSV parser parsed numbers as strings because a particular spreadsheet quoted the number column. Result: "2"+"2" = "22"
I’ve speculated that a lot of developers don’t recognize type errors for what they are.
bringing in tooling to eliminate an entire class of potential errors sounds sounds like an easy decision to me.
Not if the errors are rare and the "tooling" slows down development.
Huh? Rebundling my 150kloc project takes about 2 seconds after I save a file and has already reloaded by the time I get to my browser window.
Why do you think it would slow down development? Serious question.
Those type annotations don't just magically appear. You have to write them.
Yeah, they're optional, but if you don't write them, there's no point in using TypeScript in the first place.
Yeah, they're optional, but if you don't write them, there's no point in using TypeScript in the first place.
Types are inferred even when you don't specify them; if you are using a library that has type specifications a lot of your code is going to be well-typed just as a consequence of using that library.
1) "Someone else wrote them" doesn't make them free. Given a limited amount of developer time, that means that the time spent on the annotations wasn't spent on other functionality.
2) If the types can be inferred, that should just happen. No objection there. But this piece is specifically about "adding (manually-authored) type annotations to JavaScript"
2) If the types can be inferred, that should just happen. No objection there. But this piece is specifically about "adding (manually-authored) type annotations to JavaScript"
I was shocked how slow tsc is. Got spoiled by using ReasonML before.
Alternatively, perhaps advocates of static typing simply see a larger variety of errors as type errors. In JS, if I typo a key of an object (e.g. `foo.excute()` instead of `foo.execute()`), I would call that a type error... or at least an error that could be caught by a static type system.
Or to the kind of developer that works in a big team for a big project.
For what it’s worth I agree with you: after spending years battling with Babel and all that nonsense it’s been amazing to be able to just write ESM JS and have it run both on Node and in the browser.
The real lightbulb moment for me was using JSDoc annotations with TypeScript types in JS files. It definitely isn’t as graceful as JS itself but it’s not that big of a deal, plus it encourages you to add comments. And any TypeScript editor will parse the code as if it’s TS, provide autocomplete, type checking etc etc as required.
The real lightbulb moment for me was using JSDoc annotations with TypeScript types in JS files. It definitely isn’t as graceful as JS itself but it’s not that big of a deal, plus it encourages you to add comments. And any TypeScript editor will parse the code as if it’s TS, provide autocomplete, type checking etc etc as required.
Found the guy who hasn't used Typescript beyond tinkering!
I kid... mostly. But in all honesty I have found very few instances of developers who have worked significantly with both languages and have come to the conclusion that TS has a marginal upside (though maybe they will come out in defense here!).
I kid... mostly. But in all honesty I have found very few instances of developers who have worked significantly with both languages and have come to the conclusion that TS has a marginal upside (though maybe they will come out in defense here!).
<raises hand>
I've worked extensively with both.
I find that ts normally brings a downside, actually. In one project I maintain, a solid 30% of the code is nothing but ts stuff.
It makes maintaining the code base excruciating.
Small changes between versions of ts or .d.ts files have caused hundreds of errors. A concrete example of this is the change in mongo driver that forced "new ObjectId()" instead of "ObjectId()" though functionally there was no difference.
I see massive bizarre and difficult to grok type declarations that grow in excruciatingly byzantine complexity just to satisfy the compiler for non-trivial flexible function definitions.
I see painful compilation times, a beefy laptop's CPU getting pegged and the fan whining while trying to do even minor updates.
Try to do a build while on a video conference? I see two to three minute build times.
I see a series of nonsense stories in sprints that are nothing more than activity over achievement. They don't drive product functionality, they are a bunch of make-work to satisfy the developer asthetic and the compiler.
The nightmare of "compiled" NodeJS production support is a dystopian hellscape that I'm forced to endure every day because of NestJS and typescript. And nothing in that has done anything to increase code quality or reduce bugs from the crappy offshore team that wrote it.
Clearly, I'm not a fan.
That being said, I think type comments in jsdoc are a honking good idea.
I use inline /* @type */ declarations and .d.ts files liberally.
If we could add to jsdoc the ability to document types and purpose of arbitrary js objects inline, at definition time, instead of an external .d.ts file, I'd be a happy guy.
An example of this would be sequelize schema defs, or mongoose schema defs, where I can have all my jsdoc code comments and type definitions in the same place as the code.
All that being said, I like the idea of this proposal. Especially if it could solve the schema definition issue above.
I think optional typing is a good idea to bake directly into the language. I thought AS3 did a great job of this.
I even think it would be great to have an equivalent of "strict" that would enforce typing at the module level to enable straightforward AOT / wasm interop (I know it doesn't solve the GC issue).
My beef is mostly with the extra compilation step and needless complexity of ts.
If we had simple (no generics) opt-in typing that was natively supported by the engine, I think it would enhance the language overall, like type hints have done for python.
I've worked extensively with both.
I find that ts normally brings a downside, actually. In one project I maintain, a solid 30% of the code is nothing but ts stuff.
It makes maintaining the code base excruciating.
Small changes between versions of ts or .d.ts files have caused hundreds of errors. A concrete example of this is the change in mongo driver that forced "new ObjectId()" instead of "ObjectId()" though functionally there was no difference.
I see massive bizarre and difficult to grok type declarations that grow in excruciatingly byzantine complexity just to satisfy the compiler for non-trivial flexible function definitions.
I see painful compilation times, a beefy laptop's CPU getting pegged and the fan whining while trying to do even minor updates.
Try to do a build while on a video conference? I see two to three minute build times.
I see a series of nonsense stories in sprints that are nothing more than activity over achievement. They don't drive product functionality, they are a bunch of make-work to satisfy the developer asthetic and the compiler.
The nightmare of "compiled" NodeJS production support is a dystopian hellscape that I'm forced to endure every day because of NestJS and typescript. And nothing in that has done anything to increase code quality or reduce bugs from the crappy offshore team that wrote it.
Clearly, I'm not a fan.
That being said, I think type comments in jsdoc are a honking good idea.
I use inline /* @type */ declarations and .d.ts files liberally.
If we could add to jsdoc the ability to document types and purpose of arbitrary js objects inline, at definition time, instead of an external .d.ts file, I'd be a happy guy.
An example of this would be sequelize schema defs, or mongoose schema defs, where I can have all my jsdoc code comments and type definitions in the same place as the code.
All that being said, I like the idea of this proposal. Especially if it could solve the schema definition issue above.
I think optional typing is a good idea to bake directly into the language. I thought AS3 did a great job of this.
I even think it would be great to have an equivalent of "strict" that would enforce typing at the module level to enable straightforward AOT / wasm interop (I know it doesn't solve the GC issue).
My beef is mostly with the extra compilation step and needless complexity of ts.
If we had simple (no generics) opt-in typing that was natively supported by the engine, I think it would enhance the language overall, like type hints have done for python.
> I see massive bizarre and difficult to grok type declarations that grow in excruciatingly byzantine complexity just to satisfy the compiler for non-trivial flexible function definitions.
Is this better or worse than no type definition? Whether or not a type is defined it is still consumed. I can totally understand that sometimes types can get a bit unwieldy, but those are the exact scenarios that save future-you from introducing a bug because you didn't know what a variable is (and is not). At the very least it may be an indicator of poor design/code smell when the above occurs.
I hear you on compilation/build process woes. That's the fairest criticism against TypeScript IMO (though it's a fairly weak argument as well).
Most of your other critiques aren't really levied against TypeScript, rather, your work environment (not that it makes working with TS any less painful!).
Is this better or worse than no type definition? Whether or not a type is defined it is still consumed. I can totally understand that sometimes types can get a bit unwieldy, but those are the exact scenarios that save future-you from introducing a bug because you didn't know what a variable is (and is not). At the very least it may be an indicator of poor design/code smell when the above occurs.
I hear you on compilation/build process woes. That's the fairest criticism against TypeScript IMO (though it's a fairly weak argument as well).
Most of your other critiques aren't really levied against TypeScript, rather, your work environment (not that it makes working with TS any less painful!).
What I'm referring to is non-trivial function definitions.
Things with optional parameters that can accept a wide variety of types, async callbacks and async variadic return types.
The hoops you need to jump through to make the compiler happy are absurd.
Things with optional parameters that can accept a wide variety of types, async callbacks and async variadic return types.
The hoops you need to jump through to make the compiler happy are absurd.
Functions like the ones you are describing probably shouldn't exist!
I have no doubt that a sizable portion of these functions' bodies is dedicated to figuring out which type each of our input variables represent (from our wide variety). So now instead of having our editor/compiler help us out, we are now actually writing code to figure it out ourselves... this is more absurd (and less efficient).
And FWIW, using union types makes it trivial to denote that a function can accept a wide variety of types in a type-safe way. But guess what you will be doing first thing in the function body? Discriminating that union!
I have no doubt that a sizable portion of these functions' bodies is dedicated to figuring out which type each of our input variables represent (from our wide variety). So now instead of having our editor/compiler help us out, we are now actually writing code to figure it out ourselves... this is more absurd (and less efficient).
And FWIW, using union types makes it trivial to denote that a function can accept a wide variety of types in a type-safe way. But guess what you will be doing first thing in the function body? Discriminating that union!
Sounds like a problem with some API trying to make everyone happy.
Could be avoided by having more functions, one for each case.
(Only if you control the code, of course.)
Could be avoided by having more functions, one for each case.
(Only if you control the code, of course.)
> find that ts normally brings a downside, actually. In one project I maintain, a solid 30% of the code is nothing but ts stuff.
That 30% number is almost certainly why. The experience with codebases with 100% type coverage / tight types have been glorious, and the ones with partial coverage / plain js files / lots of "as any" / lack of strict compiler flags https://www.typescriptlang.org/docs/handbook/compiler-option... have been miserable and a waste of time. Can't stress the strict flags enough.
One of the "pros" of typescript is its gradual typing, but I think it's a trap and forces poor impressions on people.
One of those reasons is how `any` works. In gradual adoption, lots of stuff turns into `any`. `any` is a contagious/viral construct where anything it touches could become `any`. And then you spiral out of control and the whole codebase gets nothing from typescript but gets all the operational overhead.
If your browser doesn't support text fragments, can cmd/ctrl+f for "contagious" and/or "gradual" https://www.typescriptlang.org/docs/handbook/typescript-in-5...
That 30% number is almost certainly why. The experience with codebases with 100% type coverage / tight types have been glorious, and the ones with partial coverage / plain js files / lots of "as any" / lack of strict compiler flags https://www.typescriptlang.org/docs/handbook/compiler-option... have been miserable and a waste of time. Can't stress the strict flags enough.
One of the "pros" of typescript is its gradual typing, but I think it's a trap and forces poor impressions on people.
One of those reasons is how `any` works. In gradual adoption, lots of stuff turns into `any`. `any` is a contagious/viral construct where anything it touches could become `any`. And then you spiral out of control and the whole codebase gets nothing from typescript but gets all the operational overhead.
If your browser doesn't support text fragments, can cmd/ctrl+f for "contagious" and/or "gradual" https://www.typescriptlang.org/docs/handbook/typescript-in-5...
I'm specifically referring to an extra 30% of LOC that does nothing other than type abstraction and provides no functional value.
30% is a conservative number.
30% is a conservative number.
Ah sorry, I misread your claim.
Sounds high but if it's true it's true.
Sounds high but if it's true it's true.
You're wrong - the benefits of Typescript are huge, and the size of the hoops people are willing to jump through to get those benefits should indicate how big they are.
I do agree it would be nice to simplify some of the tooling though.
I do agree it would be nice to simplify some of the tooling though.
Just finished debugging one of those ugly issues where it works fine for the developer but for some other person things are broken. it was a piece of code that assigned an Number to a property that should have been an object(the dev confused the property name). Because the project is complex and there is a lot of network requests and stuff running in different order depending on the user internet the bug did not happened to everybody. You could work aroudn this using setters and doing runtime checks but I have a feeling people that don't like types also don't like getter and setter.
Are you saying that if there had been type checking, this issue would have been much easier to detect and prevent?
How could it not be? With type checking, you wouldn't be able to set a variable to a number when it's supposed to be an object.
Yes a line like
stuff.anAccountTypeField = obj.aNumberValue;
Would cause an error in a typed language , something like incompatible type Number and type Account.
Maybe you were confused by my commnet about the network requests and different order of running code, this caused the error not to happen most of the time so it never crashed on developer machine.
stuff.anAccountTypeField = obj.aNumberValue;
Would cause an error in a typed language , something like incompatible type Number and type Account.
Maybe you were confused by my commnet about the network requests and different order of running code, this caused the error not to happen most of the time so it never crashed on developer machine.
I abandoned my attempts to make larger projects in pure javascript. I happily write larger projects in typescript. Typescript makes javascript feasible, usable for me.
Would you use type comments in your projects? Would you like pull requests adding them, or fixing them? What if the typescript checker and another checker have different semantics and you have fans fighting between `number` and `u8`?
You should try Vite - https://vitejs.dev/ - start a TypeScript project in under a minute - no annoying Webpack configuration needed.
Stop trying to make JavaScript into something it's not...
If you want a type system Typescript works great, and it's very easy to set up. You even get debugging to the original uncompiled source with sourcemaps.
If you want a strongly-typed static language, compile to a wasm target... That's what it is for.
Stop trying to change JavaScript into a language it is not.
JMHO
If you want a type system Typescript works great, and it's very easy to set up. You even get debugging to the original uncompiled source with sourcemaps.
If you want a strongly-typed static language, compile to a wasm target... That's what it is for.
Stop trying to change JavaScript into a language it is not.
JMHO
I mean, with all due respect, who are you to decide what Javascript is and is not? There's obviously a huge demand for type safety in Javascript, hence the existence and adoption of Typescript.
I don't know but I've been using JavaScript for a while now. It seems like a lot of the people that want JavaScript to look similar to other languages are coming from different programming fields, and want JavaScript to look more like their language of choice.
Most of the changes to JS in the last 20 years, have been serious improvements, but they did not change the fundamental characteristics of the language.
Believe it or not there are a lot of people that like JavaScript!
Most of the changes to JS in the last 20 years, have been serious improvements, but they did not change the fundamental characteristics of the language.
Believe it or not there are a lot of people that like JavaScript!
I'm on the fence about this one. On the one hand I would love strong typing in JS.
But the reason I never adopted TS is because one time I spent months converting Coffeescript back into JS once it fell out of favor. This was back when a bunch of Ruby developers decided that JS should look like Ruby.
If I'm writing Javascript, I'm writing Javascript, not something that pretends to be something else.
But the reason I never adopted TS is because one time I spent months converting Coffeescript back into JS once it fell out of favor. This was back when a bunch of Ruby developers decided that JS should look like Ruby.
If I'm writing Javascript, I'm writing Javascript, not something that pretends to be something else.
You can convert TS to JS at the drop of a hat. This is part of what’s required to get it to run a browser, which doesn’t understand native TS. It’s different to Coffeescript which was different syntax for JS. TS is additional, type-specific syntax but you are still writing JS.
I ran a team that had to maintain a large Coffee codebase, that we could never get the resources to move off. So I know that pain. TS is different, both in how it works and the level of adoption. Coffeescript was always niche, and some benefits were there but they weren’t game-changing for (eg) writing correct code or maintaining large codebases.
I ran a team that had to maintain a large Coffee codebase, that we could never get the resources to move off. So I know that pain. TS is different, both in how it works and the level of adoption. Coffeescript was always niche, and some benefits were there but they weren’t game-changing for (eg) writing correct code or maintaining large codebases.
You can generally migrate out of TS very easily if it was the wrong choice. You can mostly use the compiler output as a drop-in replacement for your source code. Depending on compiler options, it's quite readable.
One of the benefits of TypeScript is that it literally is just JavaScript plus some. You can literally run `tsc` and it will spit out JavaScript written the same way as you wrote it but without any of the types. The only things that might look out of place is things like enums or decorators but you can choose not to use them.
The good news is that you can take your time with it, only start using typescript in new files while converting older ones slowly. And even if you never do that, typescript tooling provides hints and autocompletion to vanilla J's files as well.
> but I've been using JavaScript for close to 20 years now
How dare you use JavaScript for anything else than validating forms!!! What is that jQuery thing??? Stop trying to make JavaScript into something it's not!!!
How dare you use JavaScript for anything else than validating forms!!! What is that jQuery thing??? Stop trying to make JavaScript into something it's not!!!
And most of the developments in Java, since 1.8, have been taking ideas from other languages (primarily Scala) to make the language better. Why is it ok for other languages to evolve but not Javascript?
Scala is a perfect example of an overly complex bloated mess with so many foot-guns I can't even begin to count them.
EDIT: I never said JS shouldn't evolve! JavaScript has evolved a ton! From better handling of asynchronous control-flow with promises and then async/await, to destructing, spreads, constant assignments, Map/Set objects, a number of other improvements I can't even begin to list. But none of these changes fundamentally changed JavaScript from being a dynamic weakly typed language.
EDIT: I never said JS shouldn't evolve! JavaScript has evolved a ton! From better handling of asynchronous control-flow with promises and then async/await, to destructing, spreads, constant assignments, Map/Set objects, a number of other improvements I can't even begin to list. But none of these changes fundamentally changed JavaScript from being a dynamic weakly typed language.
I actually write a lot of Scala and beg to differ. The chances for bad developers to write bad code in Scala are higher than most other languages but what you might call foot-guns are actually elegant ways at solving complex problems.
A lot of these "problems" (implicits, enums, etc) were solved with Scala 3 too. Another example of a language evolving and becoming better based on community feedback and thoughtful iteration.
A lot of these "problems" (implicits, enums, etc) were solved with Scala 3 too. Another example of a language evolving and becoming better based on community feedback and thoughtful iteration.
I would like to say that I have written js for a long time as well and I love it; but the thing that keeps me around nowadays is typescript. I would need to be paid much more to work on a non-ts js codebase nowadays.
> but they did not change the fundamental characteristics of the language.
FWIW, this proposal does not change the fundamental characteristics of javascript. It just adds a new comment syntax.
FWIW, this proposal does not change the fundamental characteristics of javascript. It just adds a new comment syntax.
There is no way this is where the buck stops... after comment syntax people will look at compiler optimizations. It will change the language.
But didn't he merely express his opinion about this?
I'm questioning their opinion, as we do on this site.
You asked: "who are you to decide?". That's not questioning their opinion but rather their right to voice their opinion.
Compare the lines of code (on Github, say) written in straight Javascript and the lines of code written in Typescript.
I do not think the demand is quite as huge as you think it is.
I do not think the demand is quite as huge as you think it is.
Every TypeScript project is going to have at least an equivalent amount of JavaScript code sitting in the repo from the output of the TypeScript compiler.
most people don't version control the output of their compiled build though.
This is like saying compare the lines using generators or proxies vs the lines using type annotations.
Just because a feature is not widely adopted it doesn't mean that is not useful to the people using it, especially when the feature is used to mitigate the entire "cannot find property of undefined" type of errors.
Just because a feature is not widely adopted it doesn't mean that is not useful to the people using it, especially when the feature is used to mitigate the entire "cannot find property of undefined" type of errors.
In the linked article, the author spends 1 sentence dealing with objections:
> I can understand if JavaScript developers are afraid of TypeScript taking over their language. However, this proposal will be as far as things will go w.r.t. adding TypeScript features to JavaScript
And in the next few sections it includes someone who wants to build on the proposal including using type hints to optimize code. I just think there's literally no way to guarantee that "this will be as far as things will go". Yes languages evolve and add new things all the time. But GP's point is that the language seems to be going toward what people want it to be coming from other languages.
I agree, stop trying to make JS something it's not.
> I can understand if JavaScript developers are afraid of TypeScript taking over their language. However, this proposal will be as far as things will go w.r.t. adding TypeScript features to JavaScript
And in the next few sections it includes someone who wants to build on the proposal including using type hints to optimize code. I just think there's literally no way to guarantee that "this will be as far as things will go". Yes languages evolve and add new things all the time. But GP's point is that the language seems to be going toward what people want it to be coming from other languages.
I agree, stop trying to make JS something it's not.
> And in the next few sections it includes someone who wants to build on the proposal including using type hints to optimize code.
This changes literally nothing about the JS language. JS engines already attempt to determine the types of things to optimize the code they generate. Type annotations would just allow them to make more aggressive optimizations.
This changes literally nothing about the JS language. JS engines already attempt to determine the types of things to optimize the code they generate. Type annotations would just allow them to make more aggressive optimizations.
> This changes literally nothing about the JS language.
Besides adding a bunch of new syntax, of which JS already has far too much.
Besides adding a bunch of new syntax, of which JS already has far too much.
> Just because a feature is not widely adopted it doesn't mean that is not useful to the people using it
But it does mean there likely isn't a "huge demand", which was the original claim.
You're attempting to move the goalposts here.
But it does mean there likely isn't a "huge demand", which was the original claim.
You're attempting to move the goalposts here.
I'm not sure that's a useful metric.
Did you read the article? All the proposal does is allow the javascript engine to accept typescript-style syntax, while erasing all the annotations at runtime. From the browser's point of view, it would essentially treat the type annotations and type declarations as comments. This combined with native Ecmascript modules means you could theoretically develop a typescript application with no bundler or other build tools. You'd be able able to use typescript autocomplete and linting in your editor, and just serve the files to your browser with a static http server. Some newer bundlers like Vite and esbuild greatly reduce the amount of configuration required to set up a typescript project, but being about to develop a project with nothing but an editor and a browser would be a huge win for small projects.
Since the proposal doesn't care about the semantics of the type annotations, it doesn't even necessitate typescript. It would work just as well with Flow typing or even a completely new type checker.
Since the proposal doesn't care about the semantics of the type annotations, it doesn't even necessitate typescript. It would work just as well with Flow typing or even a completely new type checker.
> From the browser's point of view, it would essentially treat the type annotations and type declarations as comments.
V8 still has to updater its parser. Other tools that handle JavaScript parsing need to do that as well.
> You'd be able able to use typescript autocomplete and linting in your editor, and just serve the files to your browser with a static http server.
Nope, it's not using TypeScript directly, but just another language very similar to TypeScript.
V8 still has to updater its parser. Other tools that handle JavaScript parsing need to do that as well.
> You'd be able able to use typescript autocomplete and linting in your editor, and just serve the files to your browser with a static http server.
Nope, it's not using TypeScript directly, but just another language very similar to TypeScript.
Out of curiosity, where do you stand on ES6 classes?
Certainly cleaner than using the old prototypal inheritance syntax.
However I'm the type of person that will only use React function components in my codebase. I don't think the object-oriented style has added much too my programming, except the temptation to reach for an unnecessary abstraction.
// Dog Class
function Dog(_name){
// call the parent constructor
Animal.apply(this,arguments);
}
// extends the Animal prototype chain
Dog.prototype = new Animal();
However I'm the type of person that will only use React function components in my codebase. I don't think the object-oriented style has added much too my programming, except the temptation to reach for an unnecessary abstraction.
The only constant is change! The "don't make JavaScript into something it's not" ship sailed decades ago when AJAX was thrust upon the world.
Besides, adding even more complexity to the JS ecosystem at this point is like pouring a cup of water into the sea.
Besides, adding even more complexity to the JS ecosystem at this point is like pouring a cup of water into the sea.
Do you remember Javascript from 1996? (I do.) Do yo think that all the improvements of ES5 (reflection, strict mode, JSON) changed it into what it was not? Did ES6 (classes, imports) change JS into something it was not, or should not be? Did ES2016 (async) do that?
I get that this is a humble opinion. And I respect that. But for a language that draws so much ire from the programming community, and yet demonstrates such an ability to change and morph over the years. Are you saying you do NOT WANT it to get better? (and I realize "better" is subjective).
The same is true of PHP. People hate it. People complain. PHP takes the criticism and makes updates. People complain more.
The same is true of PHP. People hate it. People complain. PHP takes the criticism and makes updates. People complain more.
Of course I want it to get better. I just don't necessarily agree that a type-system = better, particularly in the way in which it's been suggested. Especially when you aren't talking about changing the internals regarding how JS is executed or how data is represented, you are only talking about adding "comments".
JavaScript has evolved as an untyped language, it has type-coercion and a single way to represent (most) objects in memory. So regardless of what kind of syntax you add on top... it will still be a untyped dynamic language internally. Are we talking about changing this truth? Or just adding additional syntax for developers?
JavaScript has evolved as an untyped language, it has type-coercion and a single way to represent (most) objects in memory. So regardless of what kind of syntax you add on top... it will still be a untyped dynamic language internally. Are we talking about changing this truth? Or just adding additional syntax for developers?
It does feel like we have a problem saying no to language features, and it’s not just in the JS world.
Definitely, ES6 was great and it seems we've ramped up to add as many features as possible, which has produced a lot of churn and unused/hated features. A committee was formed to add new features when needed, and now they... just keep adding and adding even when not needed.
That ship already sailed. If we were just twiddling the DOM I wouldn't even be reading this thread right now but people are writing production back-end code for financial services companies in JS. Bring on the type system.
[deleted]
This argument could be used for literally any improvement to JavaScript.
I think this proposal is trying to keep in that spirit while making everyone happy, by only adding what is effectively another comment syntax to JS, instead of defining a type system for it.
I am mildly confused by your objection. It appears the proposal is to allow type annotations to appear as essentially no-op instructions. It isn’t adding a type system to JS.
partially agreed, I would love to see tools and supports of WASM being put on a higher priority and people improves dev experiences there. JavaScript syntax is already coupled with too many factors being a scripting platform or a compilation target.
Everyone keeps saying variations of "It would become possible to program (e.g.) TypeScript without compiling the source code." but that's not true. This proposal is only a subset of TypeScript, meaning that all of the existing TS infrastructure would remain and still be used. All this does is further bloat the ECAMScript for no gain.
I agree that there are problems with limiting this to a subset. But for the most part it’s a very good subset that mostly only removes features which would be rejected if proposed today, because they have runtime semantics. This would effectively deprecate those features in the real world. I’m in the minority who likes enums, but I can live without them. The real, big gap here is JSX. But that rightly should be a separate proposal. I just want them to consider it a prerequisite, to avoid fracturing that aspect of TS.
I agree. The TC39 committee process has had a lot of advantages in modernizing the language, but in the last 3-5 years we've seen the pace of merging new language features grow in an unprecedented fashion. There are advantages to evolving the language but there is also a risk that the syntax becomes bloated if there is not enough deliberation within the standards process.
I like the idea of TypeScript, and am learning it, but am disappointed that we're still using build systems for JavaScript. I thought modules, HTTP2, and evergreen browsers would allow us to write just plain JS (like the olden times!), and not have to worry about bundling, but I guess not.
You'll still want to compile (or more specifically, type-check and minimise), but you'll probably be able to run your TS code without compiling, if you stick to that subset - but that'll likely be pretty easy. I'm imagining lint rules like the ones we're using to restrict ourselves to const and let instead of var, and things we'll quickly internalise like avoiding enums, and things we're no longer using anyway, like namespaces. Yes, it's a subset, but includes enough that you don't need the infra to run it.
This was my first thought as well, but I do think it could still be useful, even if not all TypeScript can be run as pure JavaScript. There's a lot of use cases where some type hinting would be useful, but the full feature set of TypeScript is not necessary. Long term, I could see a world where these features effectively replace TypeScript, which could help simplify dev pipelines.
How would these features replace TypeScript? TypeScript is more than just a syntax as it also requires a compiler, config, IDE tooling, and typically additional plugins to make it compatible with testing tools and bundlers.
To be frank, I hate to be the typical HN luddite, but this proposal [1] feels like it will add too much parsing complexity to runtime JS.
The counter-argument to that is: everyone minifies code anyway, but this feels like a very poor argument. "Adding cruft is OK because most people have complicated build chains to get rid of it" is very different from "we've opted into a build chain (tsc) and now have access to adding cruft"; there's a default situation here, which is the many people who write JS (FE or BE) and aren't minifying it.
Additionally, their pipe dream of allowing TS to become standard JS "if they stick within a certain reasonably large subset of the language" (an actual quote from the TC) is... wild. Wild. No thoughts, just vibes. Typescript is an extremely mature, fast-moving, complex project. Their list of TS features not supported under this TC is only three items long (with enums and namespaces among the list, lol), but I guarantee there are TONS of very complex type-level assertions typescript is capable of which JS is years, maybe decades, from reaching considering the glacial speed ECMA moves at.
Typescript will always be a superset, which they admit. The problem is: I hold extreme doubt that JS/ECMA is even capable of communicating what that differential is to average users. Will JS support control flow analysis for dependent parameters, aliased conditions, and discriminants? Const assertions? Middle rest elements in tuples?
Typescript adds all these assertions, and more, every couple months, because it turns out that type systems are something of a pandora's box. Few language-level type systems remain at the simplicity of, say, Go; most become TS, or Rust, or Java. That's not a bad thing, but not everything should be that.
If this gets traction and built, JS will in-effect, though not in-requirement, turn from an interpreted language to a compiled language, whose compiler isn't even maintained by the core development teams. That's a major, major shift; and I'm not sure the proposers have even considered the ramifications of it.
[1] https://github.com/giltayar/proposal-types-as-comments/
The counter-argument to that is: everyone minifies code anyway, but this feels like a very poor argument. "Adding cruft is OK because most people have complicated build chains to get rid of it" is very different from "we've opted into a build chain (tsc) and now have access to adding cruft"; there's a default situation here, which is the many people who write JS (FE or BE) and aren't minifying it.
Additionally, their pipe dream of allowing TS to become standard JS "if they stick within a certain reasonably large subset of the language" (an actual quote from the TC) is... wild. Wild. No thoughts, just vibes. Typescript is an extremely mature, fast-moving, complex project. Their list of TS features not supported under this TC is only three items long (with enums and namespaces among the list, lol), but I guarantee there are TONS of very complex type-level assertions typescript is capable of which JS is years, maybe decades, from reaching considering the glacial speed ECMA moves at.
Typescript will always be a superset, which they admit. The problem is: I hold extreme doubt that JS/ECMA is even capable of communicating what that differential is to average users. Will JS support control flow analysis for dependent parameters, aliased conditions, and discriminants? Const assertions? Middle rest elements in tuples?
Typescript adds all these assertions, and more, every couple months, because it turns out that type systems are something of a pandora's box. Few language-level type systems remain at the simplicity of, say, Go; most become TS, or Rust, or Java. That's not a bad thing, but not everything should be that.
If this gets traction and built, JS will in-effect, though not in-requirement, turn from an interpreted language to a compiled language, whose compiler isn't even maintained by the core development teams. That's a major, major shift; and I'm not sure the proposers have even considered the ramifications of it.
[1] https://github.com/giltayar/proposal-types-as-comments/
Seems like you entirely missed the “as comments” part. In the current proposal at least, the type annotations are just comments that can not change runtime semantics.
No. They still need to be interpreted at runtime in unminified code, in order to determine that they are comments. This carries a cost; performance, sure, but more importantly it locks in a SWEEPING complex syntax change for decades which limits future language changes and significantly complicates the parser.
The fact that they by design have no impact on the runtime isn't really even a positive. That could be a large tactile benefit of this RFC; that suddenly JS is capable of communicating to its runtime what types different primitives are, such that the runtime can optimize their storage and usage. But, by design, they don't want this. Maybe that could change in the future, but I suspect it won't because the proposers have taken the stance that everyone minifies anyway so the syntax doesn't matter anymore.
The fact that they by design have no impact on the runtime isn't really even a positive. That could be a large tactile benefit of this RFC; that suddenly JS is capable of communicating to its runtime what types different primitives are, such that the runtime can optimize their storage and usage. But, by design, they don't want this. Maybe that could change in the future, but I suspect it won't because the proposers have taken the stance that everyone minifies anyway so the syntax doesn't matter anymore.
Erasable types are good enough with source mapping. TypeScript workflows are fine. ECMAScript really doesn't need to absorb a TypeScript syntax. It's not necessary to keep bloating the runtime with a feature only useful to the developer.
If the runtime is going to be fully ignoring these type annotations, what type of "bloat" are you worried about?
New syntax and concepts.
Larger file sizes.
Typescript, by the virtue of not being javascript, has evolved pretty rapidly, and has come pretty far. Would the addition of types to javascript and typescript's conformity to those type annotations slow down typescript's development? There's still some hope, at least on typescript's roadmap[0], for nominal types in addition to structural types. Will the standardisation of type annotations impose further constraints on typescript?
[0] - https://github.com/microsoft/TypeScript/wiki/Roadmap#future
[0] - https://github.com/microsoft/TypeScript/wiki/Roadmap#future
It's not the addition of types to JS, it's telling interpreters to ignore parts of JS source files that can then be used to insert type annotations into much like comments, e.g. for nominal types.
I'd be more optimistic about official type annotations for JavaScript if said typing was less like the particularly unique syntax of TypeScript and more like that which already exists in C-family languages. For instance, in Typescript, we can do this:
---
const user: User = {
---
Why couldn't this be more like C rather than this weird conflation with the existing colon token?
---
const User user = {
---
That might seem not as pleasing to those familiar with Typescript, but it's much closer to other existing syntaxes (meaning less of a learning curve coming from Java or C).
Same with function definitions:
---
function foo (bar: string, baz: boolean): Qux {
---
Versus:
---
Qux function foo (string bar, bool baz) {
---
I find the latter much more familiar than Typescript and less confusing. It's also slightly less verbose.
---
const user: User = {
...
---
Why couldn't this be more like C rather than this weird conflation with the existing colon token?
---
const User user = {
...
---
That might seem not as pleasing to those familiar with Typescript, but it's much closer to other existing syntaxes (meaning less of a learning curve coming from Java or C).
Same with function definitions:
---
function foo (bar: string, baz: boolean): Qux {
...
---
Versus:
---
Qux function foo (string bar, bool baz) {
...
---
I find the latter much more familiar than Typescript and less confusing. It's also slightly less verbose.
That seems to be mostly just a matter of taste, but is definitely off putting when coming from other languages. Interestingly other recent languages like rust, zig, and go follow a similar convention to type script. Go has a brief explanation of why they went with this approach [0] so I’d be curious if other langs have documented their decisions.
[0] https://go.dev/doc/faq#declarations_backwards
[0] https://go.dev/doc/faq#declarations_backwards
My completely subjective guess is that it might be to avoid ambiguity around reserved keywords. For example, the `void` keyword [0]:
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
void function () { return 42; }(); // returns undefined
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
: type syntax will be more familiar to rust, kotlin, and typescript devs. Why is c relevant?
The name is usually more important than the type so I like that typescript puts it first.
The name is usually more important than the type so I like that typescript puts it first.
As you say, it's just a matter of familiarity. Sounds like you just need exposure to more programming languages/paradigms, as it's a pretty common convention. I believe it comes from the ML family. OCaml[0] springs to mind. As others have mentioned, Rust[1], Kotlin[2], Haxe[3], Nim[4], Swift[5], Elm[6], Dhall[7], and Scala[8] all use this convention.
The current syntax seems better for type inference and gradual typing.
[0] https://learnxinyminutes.com/docs/ocaml/
[1] https://learnxinyminutes.com/docs/rust/
[2] https://learnxinyminutes.com/docs/kotlin/
[3] https://learnxinyminutes.com/docs/haxe/
[4] https://learnxinyminutes.com/docs/nim/
[5] https://learnxinyminutes.com/docs/swift/
[6] https://learnxinyminutes.com/docs/elm/
[7] https://learnxinyminutes.com/docs/dhall/
[8] https://learnxinyminutes.com/docs/scala/
The current syntax seems better for type inference and gradual typing.
[0] https://learnxinyminutes.com/docs/ocaml/
[1] https://learnxinyminutes.com/docs/rust/
[2] https://learnxinyminutes.com/docs/kotlin/
[3] https://learnxinyminutes.com/docs/haxe/
[4] https://learnxinyminutes.com/docs/nim/
[5] https://learnxinyminutes.com/docs/swift/
[6] https://learnxinyminutes.com/docs/elm/
[7] https://learnxinyminutes.com/docs/dhall/
[8] https://learnxinyminutes.com/docs/scala/
Actually, I would prefer a C/C++ dialect in TypeScript’s type notation. Parsing time/complexity would reduce drastically, and would allow type inference.
[deleted]
Yes exactly. There must be some good reason why TS chose the syntax they did, because a lot of it feels very old-school-java.
Type inference is one good reason. Similar syntax exists in a few modern languages, too: e.g. Rust and Swift. In languages with type inference it can be convenient that type annotations are in the postfix position relative to variable names:
let user = new User();
let user: User = new User();then we would have another type system....no just stick with typescript or none at all...
Well... yeah, I don't actually advocate for another type system, but more that if we have any type system at all for JavaScript then asking why we're going with one that overloads the colon token when it's already been sufficiently overloaded in the first place. Typescript already is what it is, and I think we should just stick with it, but if we are going to get yet another type annotation system then perhaps it might as well not be as novel as Typescript if there's a benefit.
Even better, make sure browsers typescript ready or fully compatible over time. In my opinion Typescript and Javascript should merge into one and gradually shift towards Typescript. I used to feel TS is just extra effort unneeded, after using it for a while, I found it so great I no longer want to code in JS, not at all.
The MS blog post, and actual proposal covers this fairly well imho:
Typescript's type checking is slow and doesn't need to happen at runtime. Additionally, it moves failures to users rather than developers and makes it incredibly difficult to change type semantics later on.
https://devblogs.microsoft.com/typescript/a-proposal-for-typ...
https://github.com/giltayar/proposal-types-as-comments/
Typescript's type checking is slow and doesn't need to happen at runtime. Additionally, it moves failures to users rather than developers and makes it incredibly difficult to change type semantics later on.
https://devblogs.microsoft.com/typescript/a-proposal-for-typ...
https://github.com/giltayar/proposal-types-as-comments/
Me, too.
I'm more and more thinking that JS is heading in the wrong direction. I'd opt for splitting up JS into two; one is a low level compilation target, something like... I forgot the name now, it was a subset of JS with hints in comments that allowed the interpreter to forego certain checks (mostly around the dynamic nature of e.g. objects) for speed, I believe this predated WASM and co.
Anyway, a simple version of JS or more like bytecode. Then developers can pick whichever language they want. Because these type annotations do not benefit execution, only development.
Anyway, a simple version of JS or more like bytecode. Then developers can pick whichever language they want. Because these type annotations do not benefit execution, only development.
I’d say WASM is the low level compilation target for JavaScript runtimes.
There is also a proposal for directly shipping ASTs instead of JavaScript source files for performance improvements [0].
[0]: https://github.com/tc39/proposal-binary-ast
There is also a proposal for directly shipping ASTs instead of JavaScript source files for performance improvements [0].
[0]: https://github.com/tc39/proposal-binary-ast
You're thinking of asm.js: http://asmjs.org/faq.html
> Because these type annotations do not benefit execution, only development.
Well this is why TypeScript was invented in the first place. Not to mention that "static-only" type annotations are being adopted in Python and Ruby as well. Clearly a lot of developers see a lot of value in them.
Well this is why TypeScript was invented in the first place. Not to mention that "static-only" type annotations are being adopted in Python and Ruby as well. Clearly a lot of developers see a lot of value in them.
> I forgot the name now, it was a subset of JS with hints in comments that allowed the interpreter to forego certain checks (mostly around the dynamic nature of e.g. objects) for speed, I believe this predated WASM and co.
You probably mean asm.js
You probably mean asm.js
Isn't WASM basically this low level compilation target you're talking about?
Before wasm there was asm.js [0]
[0] https://en.wikipedia.org/wiki/Asm.js
[0] https://en.wikipedia.org/wiki/Asm.js
No, it's the right way. TS is the future of the language. Besides JS is not sane enough to be a low level language. WASM is precisely that.
Then use TS if you prefer. There are plenty of people who prefer languages like that are type-less, and are plenty proficient in it.
If you want a strongly-typed static language, compile to a wasm target with typescript, or another language... That's what it there for.
If you want a strongly-typed static language, compile to a wasm target with typescript, or another language... That's what it there for.
Sure there is but I suppose majority are moving towards typed languages. Perhaps it's sad for some, but it's no fun having to guess types or console.log them because it's just not obvious. Good riddance I say.
I'd rather have a proper type-less functional language and it's impossible to create that from JS with its legacy baggage.
I'd rather have a proper type-less functional language and it's impossible to create that from JS with its legacy baggage.
Thought experiment If you could go back in time and replace Brendon Eich when he first created JS what would you propose?
Just ask him to make it more consistent and explain that people will one day create really big apps with the language. Not just little interactive widgets. And design the language from the point of view. Simpler and more scalable. Like having the optional types as proposed here.
Would you make the same argument if Chrome decided to flip the script and make TS the default browser language and if you wanted something untyped you had to use a compiler?
I'm not sure how you would go from a static untyped language to a dynamic typed language. Pretty sure only the opposite is possible. You could have type-inference... but this is different from having a weak type system.
I don't understand what this solves... source maps make debugging the compiled typescript easy in a web browser, and on the server you can use things like ts-node to run the typescript without compiling. Having type "comments" seems like way less utility compared to what typescript offers
> I don't understand what this solves... source maps make debugging the compiled typescript easy in a web browser, and on the server you can use things like ts-node to run the typescript without compiling.
As much as I love TS, integrating it into build or dev pipelines has repeatedly caused big headaches. Multi-stage source maps don't always get wired up correctly. Tools may understand TS or ESM, but not both.
I would very much like this proposal to get ratified, so that my pipelines can become simpler and more robust, and so I don't need TS flavors of normal JS tools.
> Having type "comments" seems like way less utility compared to what typescript offers
The proposal isn't taking away anything that TypeScript offers. It lets TypeScript layer its value (types enforcement) on top of plain .js files, without getting in between the source code and tools / runtimes.
As much as I love TS, integrating it into build or dev pipelines has repeatedly caused big headaches. Multi-stage source maps don't always get wired up correctly. Tools may understand TS or ESM, but not both.
I would very much like this proposal to get ratified, so that my pipelines can become simpler and more robust, and so I don't need TS flavors of normal JS tools.
> Having type "comments" seems like way less utility compared to what typescript offers
The proposal isn't taking away anything that TypeScript offers. It lets TypeScript layer its value (types enforcement) on top of plain .js files, without getting in between the source code and tools / runtimes.
You still aren't going to ship all those unnecessary types in your production app, so you'll be creating a complicated pipeline anyway. The big difference here would be that your pipelines will be radically different, so you wouldn't know about random breakages in the development pipeline until you deployed to production.
More importantly, this doesn't add all of TS, so you'd still have to run those tools and nothing changes except that JS is now locked in to a syntax that may or may not be the best for an actual type system in the future.
More importantly, this doesn't add all of TS, so you'd still have to run those tools and nothing changes except that JS is now locked in to a syntax that may or may not be the best for an actual type system in the future.
when i understood it correct it will enable you to use typescript-ish language features in standard node projects without a compilation step. which is pretty cool for small to medium size projects
Of all the new fangled crap to emerge in js ecosystem over past decade, typescript stands out to me as perhaps the best and least BS of them. I would love for typing to be supported by ecmascript but unless it arrives full featured I'm concerned it will then be typescript vs ecmascript types and landscape will simply be more cluttered with competing options. Just like how new browsers have half assed support for es6 modules. Free me from the toolchain hell of js, please, I'm waiting eagerly
But if the types don't impact the runtime, then putting them directly in the source code that would be transmitted to the client adds cost to bandwidth without benefit.
Or you pass the code through a preprocessor to strip out the types and squash it before sending it to the client. At which point you have a pre-processor in your tool chain, and it might as well be a compiler from your favorite language (such as TypeScript).
I think this might be reinventing the wheel to insufficient benefit.
Or you pass the code through a preprocessor to strip out the types and squash it before sending it to the client. At which point you have a pre-processor in your tool chain, and it might as well be a compiler from your favorite language (such as TypeScript).
I think this might be reinventing the wheel to insufficient benefit.
How is it reinventing the wheel if there are already millions of LOC out there that use it? This is a debugging/development feature. The pre-processor already exists, but if you can iterate rapidly without having to run it and without having to hassle with stuff like source maps, that's a huge workflow improvement. Even without these type annotations any production javascript of moderate size is already getting minified and compressed before deployment regardless of whether type hints are used.
Right now when I'm authoring typescript in vscode, I get live error feedback from tsc and eslint in the editor, so in practice I only need to run tsc to "build" because I need to strip out all the typescript syntax. If that syntax became usable in a modern browser I could skip that build step during development and only run it for deploys to CI, staging and production.
Right now when I'm authoring typescript in vscode, I get live error feedback from tsc and eslint in the editor, so in practice I only need to run tsc to "build" because I need to strip out all the typescript syntax. If that syntax became usable in a modern browser I could skip that build step during development and only run it for deploys to CI, staging and production.
Services like Netlify and Cloudflare already give you the option to minify your code when serving it. Removing the types as well is a pretty small step from there.
A lot of what’s happened in JavaScript is just retracing Adobe’s circa 2005 proposal that nobody wanted at the time: types, JSX…
Im curious what a proposal like this means for other compile-to-js languages. I'm assuming it really won't make any difference to those, but languages like ReScript, PureScript, or Elm, for example, all are statically typed and compile to js in the end.
CoffeeScript, for one, is already at least talking about emitting TS [1]. These kinds of changes are vigorously debated though, e.g. [2]. Once ECMA type comments get to stage 4, CS would probably also adapt the new syntax. Other compile-to-js languages that already ship with their own type system like Dart will probably be indifferent to the debated proposal.
[1] https://github.com/jashkenas/coffeescript/issues/5307 [2] https://github.com/jashkenas/coffeescript/issues/5394
[1] https://github.com/jashkenas/coffeescript/issues/5307 [2] https://github.com/jashkenas/coffeescript/issues/5394
> What about compatibility with ReasonML, PureScript, and other statically typed languages that compile to JavaScript?
> While these languages compile to JavaScript, and have static typing, they are not supersets of JavaScript, and thus are not relevant to this proposal.
https://github.com/giltayar/proposal-types-as-comments/#what...
> While these languages compile to JavaScript, and have static typing, they are not supersets of JavaScript, and thus are not relevant to this proposal.
https://github.com/giltayar/proposal-types-as-comments/#what...
I don’t think it means anything, since the JS parser will just ignore the type annotations.
that was my thought, as well.
curious to see, though, if popularity of other statically-typed compile-to-js languages will suffer if TypeScript syntax is adopted into the js spec (presumably causing TypeScript to gobble up more market-share).
curious to see, though, if popularity of other statically-typed compile-to-js languages will suffer if TypeScript syntax is adopted into the js spec (presumably causing TypeScript to gobble up more market-share).
This is essentially what Python did with its type annotations: add flexible syntax support and a standard library for e.g. Optional[dict], and let external tools like Mypy iterate on the actual type checking work.
https://peps.python.org/pep-0484/
It’s a fair compromise, though now there are two invariants: all untyped JS must be a subset of typed JS, which in turn must be a subset of Typescript. And if a JS builtin like Python’s “typing” module is added to make type definitions easier and standardized, there’s now two ways to define types in Typescript. Which is far from the end of the world… but still will be somewhat controversial.
https://peps.python.org/pep-0484/
It’s a fair compromise, though now there are two invariants: all untyped JS must be a subset of typed JS, which in turn must be a subset of Typescript. And if a JS builtin like Python’s “typing” module is added to make type definitions easier and standardized, there’s now two ways to define types in Typescript. Which is far from the end of the world… but still will be somewhat controversial.
And it works pretty well except for some minor annoyances about typing things which only exist in the mind of mypy having runtime costs.
Imagine all the time and energy wasted having all these popular programming languages re-inventing and -implementing the same features over and over again and people discussing and arguing about them.
Back then, type hints for ECMAScript worked out quite well with AS3 (ActionScript3). Maybe worth revisiting?
(It was also used for optimization.)
(It was also used for optimization.)
So this is one area where I think TypeScript made a mistake: it added syntax that wasn't compatible with Javascript. This means you couldn't seamlessly support JS and TS with the same repo.
Wouldn't comments be a better solution to this given the legacy?
Here's what I think the type system should allow at a minimum:
1. Scalar types (number, string)
2. Common union types (eg something that could be a number or a string)
3. This is a big one: nullability should be part of the type system;
4. Object typing that includes mandatory and optional keys and their legal types;
5. Array types (generics);
6. Dictionary types (generics); and
7. An unknown type (like "mixed" in Hack).
Part of this is you need the option of preserving types at runtime and doing runtime type enforcement. This should be optional to generate a "debug" build and can be stripped out. You should be able to assert types as well as turn on automatic type checking on entry and exit to function calls as a method of finding bugs.
These errors should also be available as a warning (ie print to console.log) or an error (fatal).
Lastly, you should be able to easily write a type error handler to capture such violations.
Wouldn't comments be a better solution to this given the legacy?
Here's what I think the type system should allow at a minimum:
1. Scalar types (number, string)
2. Common union types (eg something that could be a number or a string)
3. This is a big one: nullability should be part of the type system;
4. Object typing that includes mandatory and optional keys and their legal types;
5. Array types (generics);
6. Dictionary types (generics); and
7. An unknown type (like "mixed" in Hack).
Part of this is you need the option of preserving types at runtime and doing runtime type enforcement. This should be optional to generate a "debug" build and can be stripped out. You should be able to assert types as well as turn on automatic type checking on entry and exit to function calls as a method of finding bugs.
These errors should also be available as a warning (ie print to console.log) or an error (fatal).
Lastly, you should be able to easily write a type error handler to capture such violations.
> you couldn't seamlessly support JS and TS with the same repo
You could ... use a bundler, which would handle both js and ts files quite seamlessly.
You could ... use a bundler, which would handle both js and ts files quite seamlessly.
You can easily work with both. Disable strict in the options (that is why it is there), then replace .js with .ts and it still works. Except now maybe you get some errors because of type inference that detects things like calling .toFixed on a string.
The original proposal has lots of caveats, justifications, and pre-empts many comments and questions that people seem to be asking here, so I'd recommend people to take a look at that instead: https://github.com/giltayar/proposal-types-as-comments/
Also the announcement: https://devblogs.microsoft.com/typescript/a-proposal-for-typ...
And HN discussion: https://news.ycombinator.com/item?id=30618681
Also the announcement: https://devblogs.microsoft.com/typescript/a-proposal-for-typ...
And HN discussion: https://news.ycombinator.com/item?id=30618681
>> .d.ts files often won‘t be needed either.
.d.ts files contain a lot of things other than types for the emitted code. Interface types disappear completely when compiling TypeScript, but they are an important part of many .d.ts files, especially anything describing existing web APIs.
.d.ts files contain a lot of things other than types for the emitted code. Interface types disappear completely when compiling TypeScript, but they are an important part of many .d.ts files, especially anything describing existing web APIs.
During development it would be helpful to have type checking enabled at runtime behind some flag or configuration. I want code to fail fast and early in my development environment. In production the code will be stripped and minified.
I read the FAQ in the proposal but don't understand the challenges in adding type introspection at runtime. It seems weird to add all this syntax and not have any way to leverage it during runtime. Although maybe it wouldn't be that useful? Still making up my mind about this.
Glad to see that these questions are at least being considered and explored as part of the proposal.
Great job from everyone involved, this proposal shows a lot of promise and it makes me excited for the future of JS.
I read the FAQ in the proposal but don't understand the challenges in adding type introspection at runtime. It seems weird to add all this syntax and not have any way to leverage it during runtime. Although maybe it wouldn't be that useful? Still making up my mind about this.
Glad to see that these questions are at least being considered and explored as part of the proposal.
Great job from everyone involved, this proposal shows a lot of promise and it makes me excited for the future of JS.
> It seems weird to add all this syntax and not have any way to leverage it during runtime.
Just because they're not leveraging them today, it doesn't mean that they won't do it tomorrow. If a proposal requires a big effort to implement it, it will probably never become adopted.
Just because they're not leveraging them today, it doesn't mean that they won't do it tomorrow. If a proposal requires a big effort to implement it, it will probably never become adopted.
I think it means exactly that. If JS will get type hints that are not checked at runtime then we will never get runtime validation for these type hints since it will break a lot of existing code that has would have "wrong" type hints.
Maybe a special string flag like “use strict” — “use types”?
I personally do not want to give developers the option to make type errors a user problem.
Type errors are a user problem already, if they make their way into production.
Not necessarily — maybe the error is an incorrect argument to a function that’s never used, for example.
The issue is, what should the browser do if it encounters a type error? Should it just refuse to interpret the entire script? That’s super heavy-handed when it’s possible that the error doesn’t even matter in practice.
The issue is, what should the browser do if it encounters a type error? Should it just refuse to interpret the entire script? That’s super heavy-handed when it’s possible that the error doesn’t even matter in practice.
You still need some way to make typed javascript run on older javascript engines. This would become yet another babel preset you have to juggle.
Why not just use typescript directly in the browser?
Why not just use typescript directly in the browser?
You don't have to manage every feature in babel individually, just target browsers with babel-preset-env. Then there's not anything you have to do when new features get added.
It's still a compilation target that needs to be managed by a build system. It doesn't address the complexity of the ecosystem, and just adds to it.
This feels like added complexity to the runtime where the long term goal appears to make Javascript into a sort of opt-in Typescript runtime. Not sure if that's a good thing or a bad thing - but it certainly means added complexity. That being said, npm is a mix of both so it's not like you can be exclusively javascript only anyway these days (you have to be able to read and understand typescript as they are dependencies)
[deleted]
All this hand-wringing about types in JavaScript. If Chrome just put Dart into Chrome this question would have been settled years ago. Or at least provide some mechanism where any browser can be extended with a language processor that compiles the script into webasm. The ship for extending JS has sailed! Also as I understand it webasm is still crippled in the browser with respect to accessing the DOM. Fix it somebody!
> If Chrome just put Dart into Chrome this question would have been settled years ago.
Yes, but if you compare Dart to ES6, ES6 is a much nicer language, so we got lucky that they failed.
Yes, but if you compare Dart to ES6, ES6 is a much nicer language, so we got lucky that they failed.
Having used both a lot, I disagree that JS/ES6 is a nicer language. ES6 has a couple unique cool features, but also a decent amount of baggage from older JS.
What major features does JS/ES6 have that Dart lacks?
What major features does JS/ES6 have that Dart lacks?
You can totally compile Emscripten to wasm and do all of this as part of your application. No further browser support needed.
Don't think this should affect performance, so it's a win for devs at no cost to the execution. Should just be a good thing no?
Here’s why I support this:
I want to write, run, and debug a js file in node without intermediate files. Repl speed would increase a lot.
I want to write, run, and debug a js file in node without intermediate files. Repl speed would increase a lot.
It seems odd to go out of the way to not break older libraries like mootools by renaming built in functions only to now break all older parsers for hints that don't convert to any performance improvement. I love the idea, and use JSDoc comments for that exact reason, but it feels inconsistent.
Microsoft should add script/typescript support to edge with a checkTypes flag /s
It would be cool to have this, but i think that adding so many features at once to the language isn't going to happen, and adding one piece at a time doesn't make sense.
Also, the parser performance will probably take a hit.
Also, the parser performance will probably take a hit.
As someone who doesn't really work with neither JS or TS, the proposed JS type system looks superficially very similar to TS.
Is this "backporting" TS to JS or is there something else I'm missing?
Is this "backporting" TS to JS or is there something else I'm missing?
As far as I understand it, this is allowing TS types to be valid JS syntax that are just ignored by vanilla JS engines. So it is intentionally identical to TS, it just won’t have any affect on the execution of your code.
For perspective, this is more or less what Python did.
Originally Mypy was supposed to be a Python superset, like TypeScript, but instead its variable annotation syntax was adopted as Python syntax. It has been an interesting journey for Python, with a lot of ups and downs. Type hints, for all their productivity and bug-safety benefits in most cases, still feel like a bolt-on feature that requires developers to change how they write code, and in many cases favors less-performant idioms and/or extra boilerplate compared to un-hinted Python. Whereas TypeScript has a lot more freedom to mess with how things work, because it's a superset that compiles to JavaScript and not actual JavaScript.
So it's somewhat surprising to see this proposal for JavaScript, because the TypeScript model always seemed better in hindsight than the Python model! But maybe it's just a "grass is greener" situation.
Originally Mypy was supposed to be a Python superset, like TypeScript, but instead its variable annotation syntax was adopted as Python syntax. It has been an interesting journey for Python, with a lot of ups and downs. Type hints, for all their productivity and bug-safety benefits in most cases, still feel like a bolt-on feature that requires developers to change how they write code, and in many cases favors less-performant idioms and/or extra boilerplate compared to un-hinted Python. Whereas TypeScript has a lot more freedom to mess with how things work, because it's a superset that compiles to JavaScript and not actual JavaScript.
So it's somewhat surprising to see this proposal for JavaScript, because the TypeScript model always seemed better in hindsight than the Python model! But maybe it's just a "grass is greener" situation.
It's not identical as features that have a difference on the runtime behaviour / code generation such as enums are deliberately omitted. It's intended to be a large subset of TS at first. [0]
[0] https://devblogs.microsoft.com/typescript/a-proposal-for-typ...
[0] https://devblogs.microsoft.com/typescript/a-proposal-for-typ...
Yeah that's deliberate. They're proposing that Typescript should be valid JavaScript, just with the type hints ignored by JS engines.
Seems like a very reasonable proposal to me.
It is quite similar to Python's type hint system. Python's is kind of rubbish because there are multiple competing type checkers with different semantics and most people use the crap one (Mypy). I can't see that being a problem here - essentially everyone uses Typescript and it's very good.
Seems like a very reasonable proposal to me.
It is quite similar to Python's type hint system. Python's is kind of rubbish because there are multiple competing type checkers with different semantics and most people use the crap one (Mypy). I can't see that being a problem here - essentially everyone uses Typescript and it's very good.
>most people use the crap one (Mypy)
idk, I wouldn't go this far. Mypy is slow, but it's probably the most correct, and it allows for configurations pyright refuses to. For instance, the maintainers won't add an option to allow variable redefinition/shadowing, seemingly because they don't understand the difference between a variable and a binding (https://github.com/microsoft/pyright/discussions/2441). As for Pyre, last I checked it had a lot of false positives that Mypy doesn't.
Besides all that, some people want to use a checker that isn't exclusively developed by a huge company (Microsoft, Google or Facebook).
idk, I wouldn't go this far. Mypy is slow, but it's probably the most correct, and it allows for configurations pyright refuses to. For instance, the maintainers won't add an option to allow variable redefinition/shadowing, seemingly because they don't understand the difference between a variable and a binding (https://github.com/microsoft/pyright/discussions/2441). As for Pyre, last I checked it had a lot of false positives that Mypy doesn't.
Besides all that, some people want to use a checker that isn't exclusively developed by a huge company (Microsoft, Google or Facebook).
I dunno I've run into very basic bugs in Mypy and I even went as far as trying to fix them myself. If you had read the code you wouldn't have such a high opinion of it!
In contrast Pyright seems to get pretty much everything right, even really subtle things, and if it is really a bug then the guy that maintains it is insanely good at fixing them. Seriously check out how many open/closed issues there are.
As for variable redefinition, Python stupidly doesn't prescribe semantics so it's perfectly valid for it to behave like that. Definitely arguable which way it should go and I think for clarity it's much better to use different names anyway. It's not because they don't understand anything.
Mypy has way crazier behaviours anyway, e.g. implicit making types optional. Different behaviour depending on the syntax used to add types, etc.
In contrast Pyright seems to get pretty much everything right, even really subtle things, and if it is really a bug then the guy that maintains it is insanely good at fixing them. Seriously check out how many open/closed issues there are.
As for variable redefinition, Python stupidly doesn't prescribe semantics so it's perfectly valid for it to behave like that. Definitely arguable which way it should go and I think for clarity it's much better to use different names anyway. It's not because they don't understand anything.
Mypy has way crazier behaviours anyway, e.g. implicit making types optional. Different behaviour depending on the syntax used to add types, etc.
>If you had read the code you wouldn't have such a high opinion of it!
That's probably true of most code :P
>Definitely arguable which way it should go and I think for clarity it's much better to use different names anyway. It's not because they don't understand anything.
I agree it's debatable which behavior is better. The reason I claim a lack of understanding is because of a comment (albeit likely a flippant one) one of the maintainers made in the issue I linked:
>When a variable or parameter has a declared (annotated) type, it's the job of a type checker to validate that all values assigned to that variable are compatible with the declared type. This is how type checking works in all languages that I'm familiar with.
This just isn't true; many strongly-typed languages allow variable shadowing, especially within lexical scopes. Some, like Rust, even allow rebinding within the same scope.
That's probably true of most code :P
>Definitely arguable which way it should go and I think for clarity it's much better to use different names anyway. It's not because they don't understand anything.
I agree it's debatable which behavior is better. The reason I claim a lack of understanding is because of a comment (albeit likely a flippant one) one of the maintainers made in the issue I linked:
>When a variable or parameter has a declared (annotated) type, it's the job of a type checker to validate that all values assigned to that variable are compatible with the declared type. This is how type checking works in all languages that I'm familiar with.
This just isn't true; many strongly-typed languages allow variable shadowing, especially within lexical scopes. Some, like Rust, even allow rebinding within the same scope.
It's the TS team making the proposal.
this is common in ECMAScript. see coffeescript and arrow functions
It is proposing a subset of TS (type annotations) to become a part of JS.
Is there a way to say a variable can hold any type - eg for a log or print function.
TypeScript itself has two types for this purpose: "any" and "unknown".
"any" is the escape hatch and allows you to do anything with the variable. In essence it stops type checking entirely for that variable.
"unknown" takes the opposite approach and doesn't let you do anything with the variable value (other than pass it along to other "unknown" accepting variables/functions) until you have asserted its actual type with type guards.
"any" is the escape hatch and allows you to do anything with the variable. In essence it stops type checking entirely for that variable.
"unknown" takes the opposite approach and doesn't let you do anything with the variable value (other than pass it along to other "unknown" accepting variables/functions) until you have asserted its actual type with type guards.
That's the default
[deleted]
> Do you write minified code today? Definitely not.
False. I greatly enjoy writing minified code; not only is such golfing fun, you can regularly achieve drastically smaller results.
Automated JavaScript minifiers are a useful tool, but they all miss significant opportunities in even simple things like code reordering, because JavaScript’s semantics just don’t support that sort of thing.
It puzzles me, given how much effort has gone into making a slow language run faster than it has any right to, how little effort has gone into making any kind of optimising compiler, for both runtime performance and bundle size. GCC and LLVM put insane amounts of effort into optimising things, which work best when paired with something like Rust’s ownership model (… so long as rustc isn’t currently being conservative after having uncovered yet another bug in LLVM’s noalias!).
Meanwhile in JavaScript land, the main tool used is Terser, which is both simple and simplistic. It does very little in the way of optimisation, because it basically doesn’t seek to understand the code, and so can’t apply perform any operations that could change the semantics in such-and-such a situation that (if you tried harder) provably cannot occur. Long ago, Google made Closure Compiler, and it’s a good deal better, so long as you’re willing to humour the idiosyncrasies it requires in advanced optimisations mode, but it’s still far, far short of what GCC/LLVM can do. A few years ago, Facebook toyed with symbolic execution in Prepack, an approach with potential for building good tooling, but they gave up on it before it reached the point of being useful.
Then consider other popular tools in the ecosystem: Babel is stupid (by which I mean that it doesn’t attempt to understand the code) and generates significantly bloated code because it’s seeking to match semantics as perfectly as possible without questioning whether it needs to. Bublé demonstrated a different approach, where you say “eh, who cares about exact semantics, let’s just note down the caveats and generate simpler, smaller and faster code”. (For both of these tools, I’m talking about the old ES6+ → ES5 compilations, which are obsolete now; I’m actually not sure what people use Babel for now, and how much this judgement applies.) And for bundling, webpack, which… ugh, the code it generates is just wilfully inefficient. Rollup demonstrated a different approach, where you actually care about minimising code because it makes it smaller and faster.
So returning to the original point: I certainly write minified code sometimes. I have a few <script> blocks on my site (one on all pages, others on pages that use them), and those are hand-written, sometimes with an automated minifier’s help to rename variables for slightly better compression, but other than that, all manual. I’ve got a project I’ve been working on for doing DOM stuff off-thread with a tiny VM on the main thread to execute byte code, and in that I’m working the same way: I know I have to have a little main-thread JavaScript, but when automated minification can reduce my 5KB of nicely-factored code to 1934 bytes (~1185 gzipped), but manual minification can reduce it to 928 bytes (~417 gzipped) that will also run faster due to eliminating abstractions, well, I know which approach I’m going with. My way of working in these sorts of projects is that I maintain expanded and minified source codes simultaneously, and apply any changes to both.
You might say “why not work in semi-minified code, applying whatever minifying transformations you have except for variable naming and whitespace, then use an automated tool for that part?” and you would have a bit of a point, except that then I’d need to worry about naming things, which can be complicated by reusing variables. Eh. I enjoy it. It’s mostly fun.
A byte here, a byte there… ah, fond memories of my Casio CFX-9850GB Plus Color calculator too on which I spent hundreds of hours in my school days, often golfing my programs to save one or two bytes here or there, since I normally had at most a few kilobytes of storage space spare. I discovered at one point that they kind of had two instruction-ending characters, a line break, which was two bytes, and a 𝅍 sort of a character, which was one. Thereafter, all my source code was on one line. Those things were quite astonishing in their battery life, too; I would have racked up over 1,000 hours on it, but only went through four sets of four AA batteries. Meanwhile the newer model almost everyone else used, while about 4–10 times as fast depending on the operation, lacked colour and chewed through batteries around 40 times as fast. Then came CAS calculators, probably using 40 times as much power again…
I’m rambling, aren’t I?
False. I greatly enjoy writing minified code; not only is such golfing fun, you can regularly achieve drastically smaller results.
Automated JavaScript minifiers are a useful tool, but they all miss significant opportunities in even simple things like code reordering, because JavaScript’s semantics just don’t support that sort of thing.
It puzzles me, given how much effort has gone into making a slow language run faster than it has any right to, how little effort has gone into making any kind of optimising compiler, for both runtime performance and bundle size. GCC and LLVM put insane amounts of effort into optimising things, which work best when paired with something like Rust’s ownership model (… so long as rustc isn’t currently being conservative after having uncovered yet another bug in LLVM’s noalias!).
Meanwhile in JavaScript land, the main tool used is Terser, which is both simple and simplistic. It does very little in the way of optimisation, because it basically doesn’t seek to understand the code, and so can’t apply perform any operations that could change the semantics in such-and-such a situation that (if you tried harder) provably cannot occur. Long ago, Google made Closure Compiler, and it’s a good deal better, so long as you’re willing to humour the idiosyncrasies it requires in advanced optimisations mode, but it’s still far, far short of what GCC/LLVM can do. A few years ago, Facebook toyed with symbolic execution in Prepack, an approach with potential for building good tooling, but they gave up on it before it reached the point of being useful.
Then consider other popular tools in the ecosystem: Babel is stupid (by which I mean that it doesn’t attempt to understand the code) and generates significantly bloated code because it’s seeking to match semantics as perfectly as possible without questioning whether it needs to. Bublé demonstrated a different approach, where you say “eh, who cares about exact semantics, let’s just note down the caveats and generate simpler, smaller and faster code”. (For both of these tools, I’m talking about the old ES6+ → ES5 compilations, which are obsolete now; I’m actually not sure what people use Babel for now, and how much this judgement applies.) And for bundling, webpack, which… ugh, the code it generates is just wilfully inefficient. Rollup demonstrated a different approach, where you actually care about minimising code because it makes it smaller and faster.
So returning to the original point: I certainly write minified code sometimes. I have a few <script> blocks on my site (one on all pages, others on pages that use them), and those are hand-written, sometimes with an automated minifier’s help to rename variables for slightly better compression, but other than that, all manual. I’ve got a project I’ve been working on for doing DOM stuff off-thread with a tiny VM on the main thread to execute byte code, and in that I’m working the same way: I know I have to have a little main-thread JavaScript, but when automated minification can reduce my 5KB of nicely-factored code to 1934 bytes (~1185 gzipped), but manual minification can reduce it to 928 bytes (~417 gzipped) that will also run faster due to eliminating abstractions, well, I know which approach I’m going with. My way of working in these sorts of projects is that I maintain expanded and minified source codes simultaneously, and apply any changes to both.
You might say “why not work in semi-minified code, applying whatever minifying transformations you have except for variable naming and whitespace, then use an automated tool for that part?” and you would have a bit of a point, except that then I’d need to worry about naming things, which can be complicated by reusing variables. Eh. I enjoy it. It’s mostly fun.
A byte here, a byte there… ah, fond memories of my Casio CFX-9850GB Plus Color calculator too on which I spent hundreds of hours in my school days, often golfing my programs to save one or two bytes here or there, since I normally had at most a few kilobytes of storage space spare. I discovered at one point that they kind of had two instruction-ending characters, a line break, which was two bytes, and a 𝅍 sort of a character, which was one. Thereafter, all my source code was on one line. Those things were quite astonishing in their battery life, too; I would have racked up over 1,000 hours on it, but only went through four sets of four AA batteries. Meanwhile the newer model almost everyone else used, while about 4–10 times as fast depending on the operation, lacked colour and chewed through batteries around 40 times as fast. Then came CAS calculators, probably using 40 times as much power again…
I’m rambling, aren’t I?
You know you can already write doc comments in Javascript code. It doesn't require changing the language. IntelliJ parses these comments when providing code insight.
Yet in my entire career I have found that I am the only dev that writes these comments. I use to think this was just JS devs but I have found C#, Java, and indeed Typescript projects that I work on to be sorely lacking in comments of any kind. So, how does this adding complexity to the language standard change this?
Yet in my entire career I have found that I am the only dev that writes these comments. I use to think this was just JS devs but I have found C#, Java, and indeed Typescript projects that I work on to be sorely lacking in comments of any kind. So, how does this adding complexity to the language standard change this?
This adds risk with no reward.
People won't use it in production because it is too big. In development, map files work fine and people will still use them because this isn't feature complete with TS.
At most, it locks JS into an unchangeable type syntax that may or may not work out.
Instead, we need a `use type` mode that fixes more of JS. I want type coercion gone and the super-dynamic parts of the language restricted (this both makes types more simple and makes the language more optimizable). I'd also like to see Option and Either types baked in and have `null` removed or severely restricted.
People won't use it in production because it is too big. In development, map files work fine and people will still use them because this isn't feature complete with TS.
At most, it locks JS into an unchangeable type syntax that may or may not work out.
Instead, we need a `use type` mode that fixes more of JS. I want type coercion gone and the super-dynamic parts of the language restricted (this both makes types more simple and makes the language more optimizable). I'd also like to see Option and Either types baked in and have `null` removed or severely restricted.
Forking projects just to add type definitions, or else mega repos like DefinitelyTyped madness; bringing all of the terrible complexity that we love to hate in Webpack/ESBuild/Rollup/etc back over to Node.js with server-side tsc; drive-by PRs to all my open source projects from inspired people trying to add types and me having to disappoint...
I would gladly do without all of that. To me, I see the TypeScript tradeoff as coming with only marginal upside, in return for a large downside as described above. But, others passionately disagree and see a huge upside, and that's cool.
In the end, I want us all to be happy, and I think this proposal would have hope getting us there. For this to be really spec'd and standardized would be a green light even for skeptics to invest in deeply learning and internalizing. To get to avoid yet another build-time compilation step would be bliss. To have us all back in on the same team would be glorious.