DEV Community 👩‍💻👨‍💻

Christopher Kade
Christopher Kade

Posted on • Updated on • Originally published at christopherkade.com

Goodbye Typescript, hello native typing for Javascript ✨

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;
}
Enter fullscreen mode Exit fullscreen mode

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 (143)

Collapse
 
dperrymorrow profile image
David Morrow

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.

Collapse
 
shadowhand profile image
Rhanath Shadowhand

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.

Collapse
 
marcussa profile image
Marcus S. Abildskov

You can't compare JSDoc to TypeScript... 🤦‍♂️

Thread Thread
 
lassazvegaz profile image
LassazVegaz

Exactly

Collapse
 
0wx profile image
Gilang Ramadhan 🈯️

Good luck with generic type

Thread Thread
 
intrnl profile image
intrnl

Typescript-powered JSDoc supports generic type via the template tag

Thread Thread
 
seahindeniz profile image
Sahin D.

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

Thread Thread
 
intrnl profile image
intrnl

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.

Thread Thread
 
seahindeniz profile image
Sahin D. • Edited on

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...

Collapse
 
brunoenribeiro profile image
Bruno Ribeiro

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

Thread Thread
 
ianldgs profile image
ian.tsx • Edited on

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.

Thread Thread
 
brunoenribeiro profile image
Bruno Ribeiro

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.

Thread Thread
 
ianldgs profile image
ian.tsx

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.

Collapse
 
jordancyera profile image
Yarden

This is like comparing git to Dropbox..

Collapse
 
benny00100 profile image
Benny Schuetz

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.

Collapse
 
brense profile image
Rense Bakker

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...

Collapse
 
webjose profile image
José Pablo Ramírez Vargas

ou have to set it up and make sure your tooling is working correctly which can add a layer of frustration to any project.

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.

Collapse
 
christopherkade profile image
Christopher Kade

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

Collapse
 
yuxblank profile image
Yuri

Typescript license is free. if someone doesn't like Microsoft direction you can spawn forks out of it.

Collapse
 
webjose profile image
José Pablo Ramírez Vargas

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?

Thread Thread
 
raibtoffoletto profile image
Raí B. Toffoletto

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.

Thread Thread
 
zugbahnhof profile image
Julian

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?

Thread Thread
 
webjose profile image
José Pablo Ramírez Vargas

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?

Thread Thread
 
webjose profile image
José Pablo Ramírez Vargas

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.

Thread Thread
 
theexplorer profile image
TheExplorer

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.

Thread Thread
 
webjose profile image
José Pablo Ramírez Vargas

Ok, so I have a few questions, not for you to get me answer, but for anyone to wonder about after reading your response.

  • Was Brenden threatened? Did Microsoft put a gun to his head?
  • Was the majority of the JS committee agreeing with not "fixing" whatever needed fixing? If yes, why? Who convinced the board? Was the convincing done at gun point?

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.

Thread Thread
 
raibtoffoletto profile image
Raí B. Toffoletto

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...

Collapse
 
seanmay profile image
Sean May

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.

Collapse
 
webjose profile image
José Pablo Ramírez Vargas

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.

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.

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.

Thread Thread
 
zchnim profile image
Zchnim

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.

Thread Thread
 
webjose profile image
José Pablo Ramírez Vargas

Sarcasm is the argument of the weak. Good luck through life with the attitude.

Thread Thread
 
zchnim profile image
Zchnim

Fanatical belief in quick fixes deserve no less. The world isn't perfect, and that's its strength. Streamlining takes centralization. I prefer not.

Thread Thread
 
webjose profile image
José Pablo Ramírez Vargas

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.

Thread Thread
 
zchnim profile image
Zchnim

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.

Thread Thread
 
webjose profile image
José Pablo Ramírez Vargas

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.

Thread Thread
 
seanmay profile image
Sean May

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.

 
zchnim profile image
Zchnim

Agree.

Collapse
 
jfbrennan profile image
Jordan Brennan

VScode like every other IDE understands .ts files. That’s all it does. It does not in any way set up TS for your app and it’s build process.

Collapse
 
stojakovic99 profile image
Nikola Stojaković

Type annotations will become native to the language, which definitely simplified things as no 3rd-party solutions will be necessary.

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.

Collapse
 
webjose profile image
José Pablo Ramírez Vargas

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.

Thread Thread
 
jfbrennan profile image
Jordan Brennan

Type annotations will become native to the language, which definitely simplified things as no 3rd-party solutions will be necessary.

Thread Thread
 
strongunsullied profile image
Kasope Johnson

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?

Thread Thread
 
seanmay profile image
Sean May

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.

Collapse
 
oanouman profile image
Martial Anouman

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.

Collapse
 
seanmay profile image
Sean May

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.

Thread Thread
 
kapouer profile image
Jérémy Lal

Indeed, comments in the github repo about that proposal hints at TC39 never letting it go through.

Thread Thread
 
webjose profile image
José Pablo Ramírez Vargas • Edited on

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!!

Thread Thread
 
seanmay profile image
Sean May

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.

Collapse
 
wilmela profile image
Wilmela

Hahaha, I like this.

Collapse
 
kentendo profile image
Kenny Cosca

LoL. Light years. Your argument is about as solid as the typescript code I saw at my last job.

Collapse
 
webjose profile image
José Pablo Ramírez Vargas

Based on your LoL, which is pretty much your entire argument, I am not surprised.

LoL

Collapse
 
romeerez profile image
Roman K

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?

Collapse
 
derappelt profile image
Simon Appelt

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.

Collapse
 
romeerez profile image
Roman K • Edited on

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.

Thread Thread
 
derappelt profile image
Simon Appelt

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.

Thread Thread
 
romeerez profile image
Roman K • Edited on

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.

Thread Thread
 
strongunsullied profile image
Kasope Johnson

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

Collapse
 
seanmay profile image
Sean May

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).

Collapse
 
romeerez profile image
Roman K

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?

Thread Thread
 
seanmay profile image
Sean May

Using a GitHub Action pipeline, or a Circle I pipeline on your local box is non-trivial.

Thread Thread
 
romeerez profile image
Roman K • Edited on

Don't use them on local, they are meant to be used on the cloud server

Thread Thread
 
seanmay profile image
Sean May

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.

Thread Thread
 
romeerez profile image
Roman K

Your question is basically "random statement I've never said"

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.

Thread Thread
 
seanmay profile image
Sean May • Edited on

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.

Thread Thread
 
romeerez profile image
Roman K

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.

I guess we should just toss out WASM and WebGPU too?

That's your guess, I never said or thought so, straw man arguments again?

Thread Thread
 
seanmay profile image
Sean May • Edited on

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.

Collapse
 
mindplay profile image
Rasmus Schultz

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.

Collapse
 
jamesthomson profile image
James Thomson

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.

Collapse
 
mindplay profile image
Rasmus Schultz

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.

Thread Thread
 
seanmay profile image
Sean May

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.

Collapse
 
opensas profile image
opensas

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.

Collapse
 
mindplay profile image
Rasmus Schultz

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. 😣

Collapse
 
jonrandy profile image
Jon Randy 🎖️ • Edited on

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.

Collapse
 
matthewbdaly profile image
Matthew Daly

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.

Collapse
 
kentendo profile image
Kenny Cosca

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.

Collapse
 
strongunsullied profile image
Kasope Johnson

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

Thread Thread
 
jonrandy profile image
Jon Randy 🎖️ • Edited on

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.

Thread Thread
 
strongunsullied profile image
Kasope Johnson

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

Thread Thread
 
jonrandy profile image
Jon Randy 🎖️ • Edited on

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.

Collapse
 
andykras profile image
Andrey Krasnov

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!))

Collapse
 
oanouman profile image
Martial Anouman

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.

Collapse
 
seanmay profile image
Sean May

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.

Collapse
 
eidellev profile image
Lev Eidelman Nagar

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.

Collapse
 
jwp profile image
John Peters

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.

Collapse
 
jfbrennan profile image
Jordan Brennan

Will happily accept any improvements to JS. I have zero interest in TS or CoffeeScript or any non-native language.

Collapse
 
mramadanahmed profile image
Mohamed Ramadan

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

Collapse
 
strubloid profile image
Strubloid

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.

Collapse
 
jwp profile image
John Peters

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...

Thread Thread
 
seanmay profile image
Sean May • Edited on

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.

Collapse
 
opensas profile image
opensas

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.

Collapse
 
liamjoneslucout profile image
liam-jones-lucout • Edited on

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

Collapse
 
seanmay profile image
Sean May

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.

Collapse
 
liamjoneslucout profile image
liam-jones-lucout

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?

Thread Thread
 
seanmay profile image
Sean May • Edited on

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.

Thread Thread
 
liamjoneslucout profile image
liam-jones-lucout

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

Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
ekeijl profile image
Edwin

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.

Collapse
 
strubloid profile image
Strubloid • Edited on

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!

Collapse
 
jared201 profile image
Jared Odulio

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.

Some comments may only be visible to logged-in visitors. Sign in to view all comments.

async await

Visualizing Promises and Async/Await 🤯

☝️ Check out this all-time classic DEV post