Typing. Love it or hate it, it has many advantages: better DX (through intellisense auto-completion), better code documentation, less time consumi...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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!))
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.
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.
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!
The article says that those type annotations in JS will just be ignored. So maybe if you just want a bit of type-checking for a few functions and if your IDE is smart enough to do static code analysis, you can do it like that without the need to set up the whole TypeScript toolchain (which can get into the nitty-gritty when creating a production build, using third party interfaces, etc).
If the proposal also supports types and interfaces (not sure if it does), then that might be more powerful than just using JSDoc.
I think the title is a bit misleading. This proposal is far away from JavaScript supporting native types, it's just a proposal for Type annotations, more specifically for JavaScript "ignoring" type annotations instead of supporting them.
Personally I'd like JavaScript language to evolve, and to keep independent from any particular enterprise, specially Microsoft, that already controls so many aspects of the development cycle (github, npm, vscode, typescript).
I'm really disappointed to see so few people (almost nobody) discussing what I think JavaScript really needs, and what I think most devs are asking for, that would be optional "runtime" types for JavaScript.
I imagine it shouldn't be easy, and it would require lots of discussion and debates, but we will eventually need to start talking about it. And I think Typescript success really probes that it's feasible and that it is very much needed to advance the whole of JavaScript ecosystem.
You might find my picture interesting: linkedin.com/posts/adderek_activit...
I honestly disagree with this proposal, mainly that if we're going this route, we might as well make it actually useful for everyone (and not just users of TypeScript)
have them serve as runtime annotations that libraries and frameworks can tap into is one example
there's also questions about other typed languages that augments the JavaScript language, because there isn't just TypeScript here, there's Hegel and Flow as well
Runtime annotations could be added later, using the same language space (though would probably need an opt-in, like only working in ESM, like other modern features).
As for the space that is being carved out, it's the space that all of the languages you mentioned use, not just TS. The goal would be to run valid TS / Flow / Hegel in the browser without syntax errors.
I'm skeptical we'll see this pass, mostly on the grounds that Microsoft has invested heavily into making TypeScript a thing and they'll have influence within the standards bodies. But personally, I would welcome the simplicity if it did pass.
I have no issues with Transpiling - my production JS code has been transpiled for a decade anyways to minify and obfuscate the implementation.
Sooo, sounds like we are going to end up sending more bits through the wire if we don't have a build step that strips out all the annotations. At that point we might as well be using Typescript.
Nice work! I'm very keen on the proposal as it narrows the gap between TypeScript and JavaScript and hence makes it easier for people to use strong typing. So I think it's more likely to help adoption of strong typing. Interestingly, TypeScript have expressed willingness to change the nature of TS itself to assist:
blog.johnnyreilly.com/2022/04/16/t...
Now a days is really hard to avoid using some kind of build step for your JS projects. Adding TS transpiling to your current build is often trivial now as well.
You are not already using TS is probably because you don't care for it or haven't even try it.
TypeScript is not only about type annotations. Enums, tuples, generics, support for marking expression as constant thus narrowing it's type, conditional types, algebraic operations with types etc. If you're using TypeScript only for it's type annotations you're using only few percents of it's power.
I think the title is a bit misleading. This proposal is far away from JavaScript supporting native types, it's just a proposal for Type annotations, more specifically for JavaScript "ignoring" type annotations instead of supporting them.
Personally I'd like JavaScript language to evolve, and to keep independent from any particular enterprise, specially Microsoft, that already controls so many aspects of the development cycle (github, npm, vscode, typescript).
I'm really dissapointed to see so few people (almost nobody) discussing what I think JavaScript really needs, and what I think most devs are asking for, that would be optional "runtime" types for JavaScript.
I imagine it shouldn't be easy, and it would require lots of discussion and debates, but we will eventually need to start talking about it. And I think Typescript success really probes that it's feasible and that it is very much needed to advance the whole of JavaScript ecosystem.
I'm so looking forward to this because I have found TypeScript a mixed bag, sometimes holding back use of new language features and definitely slowing down development (if sometimes improving quality).
A good thing. I hope it happens.
I'm developing Custom Component and Frame of Javascript code so i'm used to coding directly in Js to avoid the bloated of too tooling and setting of Typescript ... so i'm enthusiastic about to have the choice to use the static typing and interfaces too! I like using the Interface when needed ... ; )
I think it's part of a bigger [much sinister] vendor or a consortium agenda. Remember Java and Visual Basic when it was duopoly of Sun Microsystems and Microsoft? And then Asynchronous Javascript and XML(AJAX) was introduced and they lost control of the duopoly and their successors are trying to take control back with Typescript and domain-specific design systems (check what IBM is doing with Carbon) that are based on Web Components open standard. They can try but those days are never coming back.
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 😂
Thanks!
This would be a huge change.
Maybe the biggest that happened to the JS since it's inception.
It depends of the project type, for some projects will be completely unnecessary, but for long projects with many contributors will be mandatory.
Looks like JS will face same what happened with PHP. Lot of verbosity for a programming language where being a dynamic untyped language was its major feature.
It is similar that you created a plane to be faster and aerodynamic, but you noticed that the plane can also work as a car and go through the highway, so you remove its wings and adapt it to run better in the roads. It works yeah! But you’re going against the nature for which it was created.
Python typing was very successfully implemented.
Let me laugh hard and harder...
The cost of abandoning ES4 back that day is damn expensive.
I mean long before TS and now the proposed typing on JS, ActionScript 3.0 has had such feature without the pain of dependencies, tools and other jokes.
Oh no. They actually went ahead and put this in as a stage 1!? crap this worthless shit dose not give any type system features at all. this is crap it's only annotation and seen as comments by the js engine. this is worthless!
I'm all for typing but this dosen't benefit us in any way! this proposal is actually better: github.com/sirisian/ecmascript-types
"Javascript is one of the only languages that has us write in one language (Typescript) to then have it transpiled to another one (Javascript)."
Most software is written in compiled languages, where you write in one language and it is "transpiled" into machine language.
Types are tests. After compile time, you don't want tests. I will never be shipping JavaScript bloated with tests to the browser.
tooling is not a problem. the problem is misunderstanding of what JavaScript is and what it's used for.
I'm a BIG TS lover, and I also really love tooling (the more daunting the better 😁)
That being said build tools add a lot of bloat in order to accommodate TS in different. Let's remember the value of KISS
My question is if this annotations are going into the browser engine, doesn't that mean we're essentially adding typed code transpiling to the browser and would that have impact on speed of execution?
No to adding types to the browser: JS will treat them like comments.
const x: number = 5;would be seen as
const x /* : number */ = 5;There is no understanding of the types, just a new set of keywords/symbols which trigger parsing content as a comment.
Regarding performance, it's the same as leaving comments in code. For your final build step, on a site where you have enough code for this to matter, you would still minify and all of the rest. But the development experience of not having to do all of that, just to start developing is a big deal.
I will still stick to using typescript. In no way built in typings will be mature enough since day one. Typescript is likely to keep being ahead in terms of typing support.
Same happened in python. Nobody stopping you from using latest python version yet even in the latest typings are quite premature. Imagine now this in javascript where you have to wait for browser adoption especially when used in a browser. So yes I don't see typescript being displaced by native typing support in the near future.
well, not really.
Typescript transpile is not what makes the build stack slow, but it's generally the light part. also tsnode can JIT transpile typescript to run it on the fly. even if JS had types, I would use a compiler/verifier to check code I'm not sure a linter can do the same of tsc, especially with generics or generators.
I see Typescript's value as being a tool to allow us all to try out new language features in real environments without having to wait until the feature reaches Javascript and it being available in 98% of installed web browsers.
Javascript should never catch up to Typescript. Javascript should only implement those features that show real value in existing Typescript applications and don't cause performance problems. Javascript should be very conservative about adding features from Typescript.
Phew. To me it looks like an addition to JS that is following TS syntax. So TS is based on JS and now JS is extending it's language features by something TS defined (const a: string) to not conflict with TS. From now on some changes in TS will require changes in JS.
Fair enough. Still, this proposal will not simplify anything, as it has been explained in a few other comments in this thread. Seems pointless from what I've been reading in the comments.
Wow
This looks promising!
Write tests people. You don't need any of this.
I'm definitely going to love it. It will definitely decrease the level of complexity when you want to use types.
No.
One word: deno
Couple more words: deno transpiles your TS code to JS before running it
the title for the article is misleading and kinda clickbait. this proposal is not to get rid of typescript.
You can already do this by setting “checkJS” to true in VS Code!
This sounds great.
Just look at Python and the improvement that type annotations, static and run time type checking, and gradual typing brings with it.
That would be a nice way to join typescript and JavaScript but without having an extra compile step. Especially if it’s ignored at run time
Great! Definitely can't wait to use it.
I'd like to think that at the end of 2022, we took the first step on a very long journey which will lead us, one day, to the point where we can write Typescript natively in the browser.
I won’t say gb to TS no matter what, this proposal is just a small drop in the ocean..
I don't really understand how software engineer can hate typing.
Typescript’s real power is in its inference. The reason why it’s pleasant to write TS today is that you often don’t need to write typing. I’m not sure how far JS native typing will go.
looking forward for this update . maybe i could build some webapp without any framework
as a priority: first this and then global warming
Im excited to start using native typing
How would it effect the performance as it will increase the overhead for parsing and execution?
I agree. Having all Typescript features in JavaScript empowers the language. But I feel it won't happen that easily and it would take long time in terms of the release cadence.
I prefer TypeScript as it erases from resulting bundle by default. Therefore, it doesn't add weight to payload.
TypeScript offers not only typings.
Inflammatory opinion, probably, but typescript is so good that you're really shooting yourself in the foot by not using it for a project of any moderate size or larger.
the article title is misleading