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
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?
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.
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.
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 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.
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.
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.
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.
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.
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...
You might find my picture interesting: linkedin.com/posts/adderek_activit...
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'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.
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.
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 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 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.
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.
tooling is not a problem. the problem is misunderstanding of what JavaScript is and what it's used for.
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.
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.
Types are tests. After compile time, you don't want tests. I will never be shipping JavaScript bloated with tests to the browser.
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.
"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.
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.
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
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.
Write tests people. You don't need any of this.
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.
I won’t say gb to TS no matter what, this proposal is just a small drop in the ocean..
You can already do this by setting “checkJS” to true in VS Code!
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.
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
I don't really understand how software engineer can hate typing.
Wow
the title for the article is misleading and kinda clickbait. this proposal is not to get rid of typescript.
One word: deno
Couple more words: deno transpiles your TS code to JS before running it
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'm definitely going to love it. It will definitely decrease the level of complexity when you want to use types.
Great! Definitely can't wait to use it.
No.
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
This looks promising!
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.
TypeScript offers not only typings.
the article title is misleading
I prefer TypeScript as it erases from resulting bundle by default. Therefore, it doesn't add weight to payload.
as a priority: first this and then global warming