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 😄
Top comments (150)
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.
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...
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.
Maybe it turns your code into a garbled mess, but please don't speak for all of us :D
This is like comparing git to Dropbox..
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...
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.
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.
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.
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.
Agree.
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.
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.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/
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.
Could someone explain which specific annoying tooling this proposal is going to free us from? Will it free us from the bundler like Vite? Is it supposed that we ship unminified JS together with the types right into production?
Everyone is very happy about the proposal with this new syntax for comments, but I can't get what the point. Maybe people don't realize that this is going to change absolutely nothing, and we will keep using all the toolkits we already use, and will use TS to check for type errors, tsconfig for specific compiler configs. What am I missing?
TS will check your types without you running a command line tool. It does it live, in the editor, without needing to generate a distribution (or go through the process thereof). So why would a developer, just starting out, need to run a bunch of dev processes, if the things the dev needs are already accounted for? Moreover, why would they need to start on their production build pipeline, just for the sake of starting to prototype?
Nobody is talking about shipping typed code. Nobody is talking about shipping unminified code. But it's not production that this is for, but rather development/prototyping and atypical usecases, where you probably aren't focused on JSX UI components (because you are doing WASM, or WebGPU, or compute-based ML, or whatever).
I actually follow the way you described by using swc which is just getting rid of types, and letting my editor to check for errors. For solo projects this approach works, and I rarely find type errors, however I do sometimes. But for working in a team it is too fragile, you know, editor only checks open files, and when you change something in one file it can break other files without you realizing it.
If you're going to build the code for production, that means you have to install a build tool. Build tools nowadays are very simple and in many cases they just work out of the box. Developing with a framework like React, Vue, Svelte, Solid would require a build tool anyway. So the scope of this proposal is a Vanilla JS projects. Okay, so you are doing a Vanilla JS, and you have a bulid tool for production, what's the problem to use this tool also for development?
Using a GitHub Action pipeline, or a Circle I pipeline on your local box is non-trivial.
Don't use them on local, they are meant to be used on the cloud server
But that's the prod bulpd pipeline that many places use. Or Jenkins + SonarQube, or anything else of the sort, with a little bit of Artifactory bolted in for good measure. Your question was "why don't the devs run what runs for prod" and the answer is because what runs for prod is really complex, and often quite complicated.
A pretty common error that I have run into with clients is that their processes diverge pretty heavily between dev and QA and staging/UAT and prod... to the point where you can't be certain that the artifacts that are deployed to one are deployed to the next... and that is an issue for predictability, reliability, and security.
Your question is basically "we have to do a dozen things to prepare for prod, so why shouldn't each dev also have to do a dozen similar but different things"... and there's little basis for asking that question, aside from the fact that it's what we generally do, and we don't usually have better options.
No, by build tools I mentioned vite, also there are: webpack, parcel, snowpack, rollup. For compiling typescript we have: tsc, esbuild, swc.
So that you mentioned CI looks like a straw man argument. My point is that if we already use vite, webpack, tsc, something else for compiling for prod, that means we already have tools which can do compiling, and using them for development should be dead simple. And it's unavoidable in case of frontend frameworks.
Ok. So if I am making an Electron app which is a multi-threaded (via Workers) ES-Module based WebGPU game engine which parses the Constructive Solid Geometry of Quake-1 era .map files from editors like TrenchBroom, while also reading all of the binary data of Quake / Half-Life era .pak files, where it automatically watches the file location and updates the playable map in real-time...
...which one of those is most appropriately suited?
Just because this is of limited use, when used directly, for my day job, or my team's day job, does not mean that it is useless in all cases. I guess we should just toss out WASM and WebGPU too? Because Vite isn't practical for those, either.
I don't know why are you arguing in sake of arguing, but I have that senseless habit to argue too :)
I was working on couple of Electron projects, one used Webpack, second used Vite. Electron is using JS on both back and front ends. So the tools designed for bundling JS are still applicable for Electron. There is a Tauri alternative for Electron which has Rust back and JS front, in this case Webpack or Vite could bundle front-end side of it.
That's your guess, I never said or thought so, straw man arguments again?
Webpack is an ungodly nightmare when it comes to supporting ESM WebWorkers, unless something changed in the past year. Same deal with Parcel and friends. And if my goal is eventually to get people into modding then I really don't want to be the guy that says "and here's a link to a 20,000 word blog on how you can also make Webpack work for hot reloading multiple bundles, across different threads, with different entry points, in real-time".
The goal is the built-in JS feature of ESM imports. They work great for the task, and run more than fast enough, compared to all of the other things going on, which still allow for cold booting into the Quake 1 start map in ~200ms... and that's not from the bsp, that's compiled to run in-game. That's straight from the raw CSG that defines the map, that usually needs a long compile process. The point being that literally all of this is possible in current native tools, without any of the optimizations we normally do; just careful engineering and architecture, and being intentional with hand-optimization (like the math libs, and MAP and MDL transformers). Vite has literally no place in that, until talking about making UI scenes and overlays, which will have no logic except to tell me which button was fired or which field had a value changed; it's all WebGPU, JSON, gltf/glb, and bare files from either compiled idTech games, or from the tools used to make idTech games. Even using dynamic
import()statements to load the AI for different enemy types, and different level scripts, as described in JSON manifest files. And that's the way I want it, for extensibility. As such, there is literally no required build process until I am ready to publish. Even then, I wouldn't want it all to be compiled into a single .exe, unless I expect the product to be unmodable.I like Tauri in theory, but until MS Edge and Safari have actual support for WebGPU, without requiring the end-user to install nightly/tech-preview versions of their browsers, it's a non-starter.
All of this means that either I kick off a whole bunch of TSC processes, with a whole bunch of entry/exit points, myself, by hand (like, dozens of these things), do a different process to just convert every file, in place, and mirror the directory structure elsewhere, on a few different folders (the game, engine lib, math libs, client bindings, etc are all different "roots" defined in an import map, which again, is dynamically imported and appended, so the HTML page isn't responsible for the dependencies of the game code)...
...either I do literally none of the things that I am doing that are all working great, and shave off tons of time and code cruft and headaches...
...and submit to way too much pointless debugging and rewriting, to shoehorn in tools I don't need, that do things that I do not want, and cause problems that I shouldn't even have, and have architected expressly not to have...
...just so I can have TypeScript...
...or I don't get to have TypeScript, which would really come in handy to have type safety on the structs that I am pulling out of binary files, and pulling off of JSON manifests which allow for a data-driven ECS.
I don't get how it is so surprising that you can very easily accomplish a lot without Vite / Vercel / CRA / ng-cli / Next / Nuxt / etc...
and that it would be lovely if that last piece slid into place without wasting dozens of hours giving up on all of the modern browser features that just work, for free, with no npm requirements (technically I would include the @webgpu/types .d.ts file to reference, but as an include, not npm ... maybe also gl-matrix, as it's a lot of work to write the backing math, and even if it can't do CSG intersections or CSG to mesh transforms or CSG to UV mapping directly, it would still take care of the lower-level stuff), just for that one feature.
There is a good talk from the actual proposal author.
youtu.be/8EXuuLtYFY0
You are partially right. You can ship uncompiled typed JS to production, but you shouldn't. Like with comments. You can ship prod code with comments but that's shipping unnecessary bytes. So are the proposed types.
It's mainly for DX. You can write typed JS and test it without the need to transpile after each change.
Once you are happy you strip out the types and ship to production.
So it's mainly to speed up the development process and project setup.
I watched this talk before, but still didn't get the point. How exactly does it improve DX?
If we are writing TS for browser, we use bundlers like Vite anyway, or frameworks like Next.js, which does all cumersome stuff for us. So no gains for the frontend.
If we are writing TS to run on a server, we just use ts-node or some similar, also deno and bun already can run TS and they probablly could become more mature and popular earlier than the given proposal will be implemented.
If we want to write a quick script in TS, just use ts-node. There is a chance that node.js will gain ability to run TS directly earlier than this proposal will be implemented.
So the whole point of bringing it to the language standard, therefore to browsers and to node, adding one extra step and extra bloat to JS engines, is to let us skip 5 seconds of installing ts-node? Or to allow us to quick test some code in browser console? Do you think it is worth all the effort and the hype around it?
IMO there is a hype around it only because they say "adding types to JS", which is not true and many people are cheated by this clickbait title, you can even see this in comments nearby, some people assume they are really adding types. More honest definition would be "adding new comments syntax". It looks like everyone are lying about it, just as the title of this post, and people really start thinking that build steps won't be necessary, and interpreted language could check types at compile time which it doesn't have by nature.
Im totaly on you side that lots of this is clickbait and "adding new comments syntax" is a much better description.
You are also right on server development or large scale application development.
But I don't think that's the biggest part of web development.
I work at a web agency and we often have to work on third party systems were integrating a build system is simply not possible or complete overkill for adding a few extra scripts. There this proposal would solve a daily problem we have.
When we start a new project from scratch we would use TS and build systems anyway so there is no benefit from the proposal. And I don't even see a pain point there.
What I don't understand is why so many people have such strong feelings against this proposal. If you don't like it you simply don't have to use it.
And I don't think adding a new comment syntax will even make a measurable difference on JS engines.
For me this proposal changes nothing, so that's right I could just walk by and ignore it.
Strong feelings against are because of the hype around it which is based on lying. Hype itself is fine and a normal thing, but when it's producing false expectations among less experienced developers, that's not right.
Also, the case you have described about legacy systems without a build step, this proposal won't help here either. That maybe okay for such system to serve unminified JS, not a big deal. But how about backward compatibility? If this proposal will be implemented in few years, it will take even more years for people to update their browsers, so you could use new comments syntax without worrying not sooner than 2030. By that time legacy systems have changes to be updated or abandoned.
I had similar thoughts on the impact of shipping typed code to the browser @romeerez but you made it much clearer. Tooling to transpile this is what we're ALREADY doing
I think it's pointed to make TypeScript native browser language, which would be perfect, actually.
This won't give you any of the things you're hoping for. This will not remove the build step, which exists for 100 other reasons besides type checking. JSX anyone?
You show an example of "what types will look like". I'm sorry, but I don't think you've understood much of what's being proposed. No type syntax is proposed. This proposal only carves out a space for possible type syntax.
"Goodbye Typescript"? Most likely this headline is click bait. If you think this changes the status of Typescript at all, you don't understand what this feature is about.
The whole thing is pointless. Who is this for? Types are a developer feature - they should not be deployed. For developers, we already have tools you can set up in minutes. For end users, why would they want to spend time downloading and parsing dead code?
If you wanted to run Typescript in the browser, practically every sandbox/playground tool already does that - with type checking. If you want to actually write Typescript, you'll still need a compiler.
So what problem does this solve? For whom?
The proposal in its current form doesn't even allow all of Typescript. Just certain features. Which will make things even more inconsistent.
The only thing this feature will accomplish, is adding still more confusion and fragmentation to an already heavily encumbered platform.
This is another bad idea in a long, sad history of bad ideas. You won't get any of the things you think you will get, you will just get more problems. I wish you would all snap out of it.
This is what I don't understand about what's being proposed...as you say, types are for developers... so what are browsers going to do with this type information? How does baking in more for the browser to parse help anything?
Seems like we'd still require a build step to remove all the native typing in order to optimise things, much like how we use build steps to minify code, remove comments, etc. - which raises another point, a lot of comments are happy about no build step, but how exactly do they go about optimising their code for things such as minifiying or browser feature support? oh that's right... with a build step.
Seems the only benefit to having native types is you could technically develop without a build step (but you'll still need one for production) which is nice as long as you get a 1:1 output.
Even then, you couldn't develop without a build step - you would still need access to NPM packages, and most serious front-end work involves JSX. Practically every real world project uses loaders of some sort, for SASS, or CSS modules, etc. - almost no one writes vanilla CSS these days.
So no, there is literally no real world use case - not even for learning purposes, as that would raise the same problems this proposal claims to resolve. Not that anybody would open their DevTools console in the first place and expect to learn programming there - if you're a complete beginner, you're most likely starting out with CodeSandbox or StackBlitz etc. where you'd have full IDE and TypeScript support, with access to production grade development tools and features, loaders etc., with no effort and zero setup.
This idea isn't solving any real problem, for anyone.
It has no merit.
None.
I was working on a WebGPU, browser based engine for running Quake .map files and reading through the .pak data files. Not the compiled Quake maps, but the raw map editor files, without compilation. Now that real-time lighting is trivial, it would be nice to have near real-time feedback in CSG-based game editors.
It's temporarily shelved while I do some meat-space debugging... but it's a passion project.
I would love to be able to write TS that is just straight TypeScript, with no TSC compile step (because everyone has live language servers in their IDEs, these days), and use simple, straightforward, ESM to list dependencies... which solves a problem that most bundlers have, regarding splitting code between Workers.
At the moment, using Snowpack or Parcel to give me TS means wading through hell for being able to write Workers which import the same ESM libs as dependencies.
So it's either no TS and then don't need a bundler and everything but types works...
...or use Parcel, but then go through hell supporting ESM Workers which are supposed to load the same source files as dependencies, but not share the same instance of the module code...
...or hand-configure individual TS builds for each Worker entrypoint, and run all of those dev builds, or write a daemon to watch all of those sources and then rebuild all of them...
I have done dev, lead, architecture, dev-ops, etc, for really a lot of sites / apps for a lot of different clients with a lot of different needs. Yes, your case is true, there is no reason that production code should be shipped with comments or type annotations... but my case is also true. And while it is a long way from the typical React / React Native / Angular / Vue / Swift / Kotlin / etc, case, it's nonetheless still valid.
Not only that, but I would suggest that it would open the doors to easier support for more visual-based editors, closer to what the game industry gets to use, without the need to run multiple heavy build commands... that said, esbuild and the like have made strides to reduce those times, but all of the different types of packaging needs are still a headache, unless I have missed something in the past couple of years.
Even worst, I think this proposal just adds confusion (like you said) and delays the real debate about how to make JavaScript evolve so that it could actually support real runtime types, which should also be optional to preserve backward compatibility.
Yes, that is one of the big reasons this should be rejected. If this gets accepted, that essentially means JS can never have runtime types - because that would be a breaking change. 😣
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!))
That's nice to see... but what's the point ? We already had annotations through JSDoc, that didn't prevent the rise of TypeScript. So now what? Did things have changed? Nope. I think at this point, putting more sugar won't change anything.
JSDoc is big and bulky, and doesn't support the level of type algebra that TS does.
It's fine if your code looks like C. It's insufficient if your code looks like F# or OCaml.
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.
Just more confirmation that TypeScript was 15 years ahead of its time.
Back in the 1985 TCP obliterated SNA. IBM tried to provide its own Anynet as a counter architecture, but TCP disrupted SNA. All mainframes today use TCP by default.
The goodness of TypeScript for those who can't see it. is that Javascript-only people hate it. The same was true for SNA only people.
Going back further was the transition from Assembly languages to 3rd Gen languages. Assembly programmers hated it at first.
Even with types in JS there would need to be a build step. Minification would be even more important because now the parser would have to do tonnes more work. And the files would be significantly bigger. There would also be lots of runtime type checking overhead if it's not done at build time, so I imagine to speed up code people would use a build step to trigger the type checking and remove them, just like TS does.
The way TS does it isn't an accident, it's build time only because JS is already slow. A run time typing system will add a massive amount of overhead
It's not runtime type checking. It's running a valid TS / Flow file as JS, in the browser, and the browser treating all of the type information as comments.
And this isn't for prod, it's for prototyping/dev/tooling.
I missed that bit. I suppose if you could effectively run TS in the browser whilst developing it would be positive, but as you'd need to set up a prod build pipeline anyway there's doesn't seem to be that much benefit?
If it's a GitHub Actions pipeline, or a Circle CI pipeline, or a Jenkins + SonarQube + Artifactory pipeline, etc, that's either going to require you to set up a minimum of two different pipelines, that do two different sets of things, in two different ways (one for dev, one for prod... let alone PR/QA/UA/staging/blue-green/etc)... or that one single build pipeline is going to be really, really complicated/expensive to get those prod tools working for your actual local dev builds.
I’m not saying we don't already do these things, but those differences in pipelines (between dev and prod) can be a consistent source of bugs and delays, and generally, life would be easier with fewer moving pieces, rather than more: especially when those moving pieces get thrown out, or configured completely differently for later phases of delivery.
Maybe you are lucky and you have an architect, or dev-lead or dev-ops or dev-ex that already planned all of this out, versus monkey patching a terrible collection of mangled processes that run completely differently, with different teams of people managing those different built pipelines for the same product...
...but as the lead / architect / consultant dropped into massive legacy apps with hundreds of contributing developers, I can tell you that's not the norm.
So the fewer moving parts need to be accounted for, the easier it is to build on top of.
Possible you've misunderstood me. I don't think having two different pipelines is good. I too have been a consultant for years and I understand the value of simplicity, especially in pipelines
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.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.