Typing. Love it or hate it, it has many advantages: better DX (through intellisense auto-completion), better code documentation, less time consuming errors. Its benefits greatly outweigh its cost, so why do some people still avoid it? One word: Typescript. You have to set it up and make sure your tooling is working correctly which can add a layer of frustration to any project.
So what if I told you that native typing might be coming to Javascript? Christmas is right around the corner and boy do I have a gift for you 🎅
The proposal 📄
TC39 is the comity in charge of Javascript's specs - they help maintain and evolve the definition of JS. If you're curious, I wrote a section about them in a previous article.
They recently moved the Type Annotations proposal to Stage 1 (out of 4), which means it's time to widely speculate on the impact and implications of this feature !
As much as I love being dramatic, this will not sign the death of TS by any means, it will simply allow for cleaner and more reliable JS code for projects that don't plan on using TS or that wish to use both in conjunction.
What will native JS typing look like if this proposal passes?
It would be very close to what we currently have with Typescript and Flow, namely:
// both parameters are numbers, and this method returns a number
function add(a: number, b: number): number {
return a + b;
}
These annotations will not stop you from passing a string or any other variable type as parameter. They will be ignored at runtime and are just there as guidelines that can be used by 3rd party type checkers such as your IDE.
The argument for strict typing has its place in this discussion in my opinion. In its current proposal, these types are just type annotations, which is something we already have thanks to JSDoc. So the question remains: why?
What's the point? 🤷
We're in an odd situation: Javascript is one of the only languages that has us write in one language (Typescript) to then have it transpiled to another one (Javascript). These layers add complexity to any project, so the more tools we add to our default tool belt, the better.
The need for Typescript creates a form of monopoly on current available tooling, where each and everyone of them needs to evolve with TS in order to not be left behind. The State of the Octoverse 2022 shows the impressive popularity of Typescript in 2022, which means this need to evolve becomes almost mandatory for your linters, bundlers etc.
Having this feature already bundled with our dear Javascript will only make it a more complete package and help us slow down the obvious tooling bloat we're currently facing.
What do you think? Would you see yourself using this feature if it releases? What are the risks that come to mind, especially if you're an avid user of Typescript?
Feel free to follow me on Twitter (if it doesn't implode by the time you finish this article), it's always a pleasure connecting with some of you 😄
Oldest comments (150)
Thanks!
This would be a huge change.
Maybe the biggest that happened to the JS since it's inception.
Personally I think this is great. I don't have a problem with typing, I have a problem with build steps. Seems like every time we get closer to not needing one, some new reason comes out that extends the use of them.
Build step is exactly the reason why I've decided to use JSDoc strings instead. It literally does the same thing as TS' typing system without the unnecessary build step that turns your code into a garbled mess.
But how you hard-stop type errors going into Production? TS's build step can exit your CI/CD pipeline on type errors, a thing you cannot do with other tools like ESLint AFAIK
Of course you can hard stop your CI/CD with eslint :)
If there are any eslint errors (not warnings), the executable will produce an exit code 1, therefore failing the pipeline.
But you can also use the typescript compiler to check the jsdocs, and produce exit code 1 if there's an error. Look for the jsconfig.json. Note that no transpilation occurs in that case, only type checking. And you can import .d.ts files from jsdocs too.
Why would you typecheck jsdocs with the Typescript compiler? The whole point was to avoid installing TS in the first place. If it's still necessary for typechecking, might just go with .ts files and guarantee full-support.
My point is: to avoid TS, you need another tool on your pipeline able to typecheck and exit on type errors.
To get autocomplete while coding, type-safety, and to avoid having a compiler transform your final code into a "garbled mess".
You'll have to install dependencies anyway at some point, so might as well install typescript, which is useful.
You can't compare JSDoc to TypeScript... 🤦♂️
Exactly
Good luck with generic type
Typescript-powered JSDoc supports generic type via the template tag
You can't extend something with JSDoc generics. You can't use generics in the inner scope. There are other things too that I don't remember now. That's why people switched to Flow and then Typescript
is there a specific example you can provide? as I know it, the things you do on TypeScript with generics should work the same on a (TypeScript-powered) JSDoc.
It's been a while since I use JSDoc in an advanced way. Here are some issuse for you
github.com/microsoft/TypeScript/is...
github.com/microsoft/TypeScript/is...
github.com/microsoft/TypeScript/is...
This is like comparing git to Dropbox..
Maybe it turns your code into a garbled mess, but please don't speak for all of us :D
Exactly. IMHO every developer should be happy if there is less need of additional abstraction layers and/or other third party dependencies.
Stay as close as possible to the platfrom (ie. the browser) as possible.
In development you dont need to build. ts-node-dev exists and also deno can run typescript natively. Personally I dont have a problem with building for production either, the typescript compiler is really fast. The biggest time consumption during building/bundling doesn't come from tsc...
Personally I am very excited for this feature as it kind of meshes with the way we currently use TS at Zencity. The typescript compiler is slow so we use SWC to strip away all type annotations during the build and only use the typescript compiler in the CI pipeline to make sure nothing funky gets in.
Type safety without compromising speed.
How true is this? Because, for instance, Visual Studio Code comes set up for TypeScript out of the box. Literally no making sure the tooling is working correctly.
As for the topic in general, I think JavaScript should just graciously give the floor to TypeScript. Let TypeScript be the language. It's light years ahead of what the JS guys can come up with. Accept defeat, if you will.
Agree!
JavaScript is too far behind TypeScript and in my opinion this new proposal is just an evidence they are aware that TypeScript is what JavaScript should be.
TS only adds TC39 approved features. And generally (with a couple of exceptions) only stage-3 / stage-4. Those are features approved for JavaScript.
That means that anything TS can do, JS can do without types (aside from the enums, which are ungood, and the decorators which should be unnecessary... and also replaced with the final JS version of decorators) in the future.
Indeed, comments in the github repo about that proposal hints at TC39 never letting it go through.
You know you're in trouble when you have to type "(aside ...)" in parenthesis. So TS has all of JS, plus stuff. Let TypeScript take over the world!!
I’m not particularly in trouble.
Enums are generally not good. The TypeScript implementation of enums is also not good. Even if JavaScript disappeared tomorrow and TypeScript was the only programming language left in the whole world, you probably shouldn't use their enum implementation... and there are lots of ways of accomplishing similar things, without using them that you can already do; both in TS and in JS.
As for decorators and annotations, I generally find them to be less powerful versions of higher-order functions, and generally wouldn't use them, aside from projects that insist on using Angular.
VSCode comes with TS support; does the browser? Can you just use ES Modules and point the import statements to .ts files and expect the browser to be happy about it?
No, for that you need snowpack, or parcel, or vite, or you need an old fashioned webpack build, or you go back to grunt and gulp...
Or, you, by-hand write out your tsc build steps.
In order to start development, not shipping production code, you need to solve these problems. JS type annotations would mean that you could write JS with type annotations, and in VS Code you could run typescript validation on them, and as you are developing, all you need is for your index.html to point to the entry module, and it all works without running a "dev" mode for anything that doesn't need compilation (eg: JSX).
Also, TS features are based on the ECMAscript TC39 feature proposals for JS. Let me say that another way: TypeScript adds features that are JS committee approved features.
If you got rid of JavaScript, then there would be no JavaScript committee, scratching their heads, trying to come up with the best version of a feature to add. Which would mean that TS would need its own committee, and would need to add its own backwards compatibility layer, so that the entire internet didn't fall over and due, when all browsers switch to TS and your bank hasn't updated its website in 5+ years, and it will be 5 more in order to do the rewrite, because corporate software is a nightmare.
Great explanation. All that is unneeded if browsers start supporting TypeScript natively. This is what I mean by giving up the floor. Just have browsers support TS natively. Then you don't need to solve anything. You can then simply deploy .ts files.
I understand. I also understand that JS could just shut down and let TS take over, therefore being TS the one approving feature proposals directly.
Yes, TS could create its own committee, and browsers can support both JS and TS. You're making too much of a big deal for things that are really not show stoppers. Backwards compatibility with JS is almost trivial.
That's like... Very good theory. Let's email everybody that needs to be on board for it to happen. And take a year off to organize it.
Sarcasm is the argument of the weak. Good luck through life with the attitude.
Fanatical belief in quick fixes deserve no less. The world isn't perfect, and that's its strength. Streamlining takes centralization. I prefer not.
I wonder where you see a fanatical attitude in my responses. If anything, I am getting fan hate by the JavaScript lovers here. I am merely stating that JavaScript is and shouldn't be almighty or immortal or anything. In many people's eyes, TypeScript is the future, so why not fully embrace it? Yet people come say things like "yeah, let's stop the world for this" just because of one simple opinion. Truth be told, it is just a matter of will and popularity. If TypeScript surpasses JavaScript, why keep JS around? Yet people seem utterly offended by it.
You have answered your own question: opinions are divided. Will and popularity. Yet you seem to be offended by people not equally passionate about your quickfixes, "JS lovers" driven by fear. That's low.
"When" TS surpasses JS will be when enough effort has been put into proposals like this. Unless of course s.th else totally disrupts that again...
Anyways, have a great weekend.
I am not offended if you don't share my opinion. People get offended by reading mine. Feel free to have your own. All I say is: Everything is possible. It is possible for JS to completely phase out in favor of TypeScript if so deemed. It is true that this new revision will most likely accomplish nothing, as several others have stated. It is true that even if JS acquire types, people will still need their tooling to deploy, so it is, in my opinion a useless effort. It is more valuable, in my opinion to let JS die and move on to TS. TS is by all lights JS and more, it is ahead of JS and therefore, in my opinion, it is a better investment to spend time evolving TS, not JS.
Agree.
Would you like TS to continue developing quickly, or would you like it to start taking several years before features get added?
Because I like that TS evolves quickly.
That is going to go away, if it becomes the language that runs in every browser.
Also, no, TS is not backwards compatible... if browsers stop supporting.js files, then the whole internet comes crashing down. And if browsers need to keep both separate languages up to date, they just aren't going to. That's why Dart went nowhere as a JS replacement.
TypeScript is one of my favourite languages, given how ubiquitous it is, and yet, how much it feels like an ML (F#, OCaml, etc), but I don't want it to be stuck in a committee that makes it take 3 years for them to make a decision. And I don't want to break the whole internet, by ripping out native .js support. I would rather TS just improve the build tooling to the point where it is simple to do anything you want in TS, whether you are publishing an app or a library, and where the build time is basically instant.
Also, I don't want to waste time and data importing type files into a client machine, if there is no code needed in those files. There's no reason to load it, except that it would cause all kinds of errors when parsing TS on the client machine.
As much as I want to agree with you, I don't think a large corporation like Microsoft should be the sole owner of the n1 language for web development 😅 each step JS takes is one step towards not needing TS to have the best development practices possible
While I do get what you say, I wonder about the root behind the fear. Why is it so bad that a single company hold ownership of the #1 language in WWW? Do you feel the same for other things? What about the browser arena? Chrome is the virtual sole owner of the browser arena. Do you use Firefox to combat this? If yes, why?
Should we have One dictator or democracy!? ... same thought applied 😉. Not saying Microsoft is the bad wolf but it shouldn't be the only one dictating the rules. That always exclude people that has different opinions and the purpose of the WWW is to be inclusive! No matter your current place, a11y need, OS or IDE.
Your example with the browser (engines) is exactly the reason why more people should use all the other alternatives to chromium based Browsers (aka Firefox and maybe safari if you are an apple person). Do you really trust a company that much to basically give it control over the whole internet?
I see. Would you then be supportive of the idea that C# would have to be democratized and taken away from Microsoft? It is super popular now, and pretty much one of the best options for HTTP servers since it is so performant. Should we "the people" force Microsoft out of its own creation?
Didn't that already happen? Isn't Google the sole owner of all searches? I don't see any riots going on. I do see your point. I just think it's an overreaction.
Except Microsoft was the company who originally lobbied to prevent Brenden from actually fixing the bad parts of the language prior to it getting standardized which is why Typescript is so useful in the first place.
They're essentially getting rewarded for solving a problem they're mostly responsible for with 0 of the liability for the problems they caused.
Ok, so I have a few questions, not for you to get me answer, but for anyone to wonder about after reading your response.
If the JS board was convinced to do the wrong thing, isn't that a sign that the board is no good? I mean, save for convincing using a firearm, any other reason just makes the entire board look bad. Why is Microsoft the only culprit? All said Yes to the bad decisions, not just Microsoft.
Do you want a JS board that can be manipulated that easily anyway? This one feature may have seen some light. There's no guarantee, with this allegedly incompentent board, that others will follow. So what's the gain in having JS with an incompetent board around? In the end I would still support TS over JS.
Again, things for you and others to wonder about. I don't really care.
Nope, C# is a Microsoft product, you buy if you want. I think you missed the point that it's about having options, not revolution. You don't need to use chrome, you don't need to use google search, you don't need to code your http server in c#, use whatever. Privatization of an open technology is not the way. Now... if the board in charge works or not is another discussion...
Typescript license is free. if someone doesn't like Microsoft direction you can spawn forks out of it.
But their LSP's for it are constrained in usage.
LoL. Light years. Your argument is about as solid as the typescript code I saw at my last job.
Based on your LoL, which is pretty much your entire argument, I am not surprised.
LoL
Hahaha, I like this.
YEP!!! All wise words was said here \o/ Typescript should be the language directly ...
and no more talks, that's it, JS is weird, seems like was not finished, like in beta stage. Typescript fix this and give to it beauty lol :)
"Fact, no problems with TS in VSCode even for very simple things like plain HTML/CSS/TS:
tsc --init
tsc -w or tsc --watch
"
even for those who like to change some little things like me is very easy:
in tsconfig.json in my preference, because I like this way (me / myself):
"outDir": "dist", and "rootDir": "src", (for better organization folders)
and,
"removeComments": true,
"noImplicitAny": true,
"noEmitOnError": true,
(these 3 is my preference, not needed, but I like.
just this, easy, simple, good
\o/
This show how naive you are with Microsofts history. Embrace, Extend, then ...
Although I am for typing in JavaScript, I find TypeScript is too much of a Nazi. It just goes full ludicrous speed on the pursuit of purity and throws practicallity out the window. Some basic typing and interfaces is what most people need.
Then do your basic typing and interfaces and use
anyfor everything else. TypeScript has no speed. You constrain your code however you like.That is awesome! I am always using Typescript and I hope that proposal can see the light very soon. However that remind me the story of es4 that never get released for the same reason of typing.
By other words it will not be easy journey to implement it in the broswers and keep two flavors of typing and non typing because JS as we know today shouldn't be replaced.
Also if that happened it might need some kind of compilers like web assembly before the browser run them. I think running Typescript directly on the browser will be performance challenge for the browser
Yeah brotha... I think if we compile things in a browser level, will be an unnecessary action to do, why not we do the job and we serve a basic thing that any browser can understand?
Sometimes we can smell your fear of not knowing JavaScript.
I guess maybe you see no credibility in WASM. The dominant days of Javascript are over.
"WebAssembly | MDN" developer.mozilla.org/en-US/docs/W...
Far from over...
QT and DearIMGUI and Flutter and all of the rest have a very long way to go before they operate at the same level as browsers’ HTML renderers, when it comes to things like accessibility. And I don't know about you, but I would consider using C to write React, through a WASI binding, a living hell.
If you’re talking about making a game or an app, that's using WebGPU, then cool, yeah, Rust is great. No thank you for trying to make an accessible real-time web-app, though.
Starting out with strictly typed languages, coming to JavaScript was a breath of fresh air - I much prefer it. I'd really like to see this not happen. Programming with strict types feels like programming in a straitjacket.
My feelings on this subject are the opposite of that. I work mainly with PHP and using Psalm to catch type issues and enforce use of types has been incredibly useful - it's caught so many issues and made my code souch easier to understand. And any JavaScript type system will be optional, much like in PHP, so I don't imagine it will cause issues with existing code.
None of these developers seemed be around when there was no typescript and have no idea why JavaScript became the most popular language along with python. Magpies developers made Frontend coding the disaster that it is now.
I think with the large scaling up of javascript applications, types are 100% needed to eradicate a lot of bugs. That's not the only benefit but the key one. Mind you, javascript is way beyond just the Frontend.
Sorry but building real world, resilient & scalable applications require type safety. Thankfully there's fields like data science & cloud computing that I believe don't need this so you might enjoy those more in the long run if it's not your favourite
Define "long run"... I've been programming for 39 years, building real world desktop apps, websites, web apps etc. as a job for 28 years, and using JS for almost 26 of those.
Cool!
Please don't take this the wrong way but maybe that's the problem, you might be used to doing things in ways that are not suitable for the challenges the modern day web developer faces
How are the challenges I face on a daily basis in the 'modern day' software and websites I work on different from those of a 'modern day web developer'?
Using a typed language will not suddenly make your software bug free. Bugs are made by humans, and bugs are fixed by humans - they are not the fault of the language. If you understand the language you are working with, then you understand how to avoid its pitfalls, and how to take advantage of its strengths.
I used typed languages for a long time before coming to languages like JS, and the freedom and speed that is possible when you develop with them really is amazing, and truly liberating. Also, I cannot ever remember having any serious type related bugs in JS code that I've worked on.
If a lot of developers had really taken the time to really learn JS and work with it instead of fighting against it and trying to 'fix' it - I'm pretty sure front-end development would be a lot less like the unholy mess it is now.
yep, the same from my side. I came from low level, like asm/C/C++, then I did coding a lot in C# and now JS and Python. And boy should I say it's like a Christmas in July)) for those who are feel missing on strict typing just add C++ in your life, and you good to go!))
You might find my picture interesting: linkedin.com/posts/adderek_activit...
I think this would be absolutely fantastic. However, I wonder if this will ever be made since nobody from google is among the editors. This might sound like a weird observation, but since chrome has a quasi browser monopoly, google now dictates the RFCs. As long as they don't show interest in implementing in chrome, it won't come. IMHO they should make an RFC to directly support typescript natively as a whole 😂
I think is an extra work that will happen, I do not think that will be good or bad, one point that I am seeing is the confusion to know if was typescript or native.
Most of people's code now are very bad, I even found a course that the frontend is typescript because of angular, and backend it came back to normal JavaScript with no checks, even at the fucking course we need to fix it's ows stupidity.
Typescript is more than only a way to write, it involves lots of checks too, and when you build something with it, you stop to be so basic around classes, heritage and types.
I will still be using typescript for other reasons than Syntax.
Good luck JavaScript developers!
One word: deno
Couple more words: deno transpiles your TS code to JS before running it
Some comments may only be visible to logged-in visitors. Sign in to view all comments.