Sounds like a bad idea. I get it that not specifying type syntax makes it the most flexible, but also prevents any actual checks and optimizations from being performed by the browser. So it’s just inflating bundle sizes for no reason. Might as well run them through something that checks then removes type annotations… which is what we already have
> So it’s just inflating bundle sizes for no reason.
When using a bundler, it will be trivial to remove the annotations in the build process.
Using a TypeScript transpiler in that process is also trivial you might say. But static typing syntax and tooling as part of the language itself is the way to go imo.
>But static typing syntax and tooling as part of the language itself is the way to go imo.
But if the typing syntax is essentially just comments in very specific places... what advantage does it bring? Sure one can use tools to interpret those comments and check types... but at that point, isn't just using typescript tooling much superior (interface declaration, type declarations, etc. not just a type between : and =)?
I will confess that I am guilty of having used JSDoc comments for quick and dirty .js scripts that I didn't want to grab the tsc compiler for, but still wanted vscode to check my types. But even being one of the likely users of this proposal, I feel that it's needlessly bloating the language.
The advantage would be, that static typing is part of the language.
Don't you find it odd to use another language just for a missing language feature? For me it feels somewhat hacky and '// temp. solution!!! fix soon!'-worthy.
But with this proposal, static typing wouldn't be part of the language. It's just a fancy looking comment. No different than using JSDoc with a nicer syntax
Ok agreed, i would also like to have the type checker build into the language as well. But in the end, this is a scripting language. Maybe it's not too bad to not enforce it being typed, but provide a baseline to have it being typed optionally, in form of an 'official' annotation syntax.
I just think it'd overcomplicate implementations. We already have typescript and such, and they work perfectly. It's my personal belief that integrating those things into the language would slow innovation.
But we are talking about a language that is streamed over the internet in absurd quantities, and thus has dedicated tools to make it unreadably small as to better utilize bandwidth. Adding any fluff that is not even useful/get utilized on the frontend side is not a good idea.
I mean, i like TypeScript a lot. I think i do find it odd, because i'm used to using languages, that are constructed with a certain feature set.
Obviously Java/ECMA Script evolved a lot more chaotic than most other languages.
Transpiling a superset of a language to its subset introduces indirection, which makes it feel hacky imo.
I feel like, if there is another language feature we want to add in the future, how should that be injected? In form of a superset of TypeScript?
I would be cool with TypeScript as the target language, though.
> But if the typing syntax is essentially just comments in very specific places... what advantage does it bring?
It means the supplemental information needed to run either static or dynamic type-checking is there & so that either browsers or toolchains can use it.
And it means that the code would just run on existing systems. For production we'd probably want to strip out comments, but for production we already often do strip out comments (which I wish could be "undone" on most sites by users wanting to know! View source!!).
Let's turn your question around: what advantage does existing typescript language have, over a backwards-compatible & type-carrying enhancement to JS?
>It means the supplemental information needed to run either static or dynamic type-checking is there & so that either browsers or toolchains can use it.
The format isn't specified, it's just a comment. Browsers can't take advantage of it. Toolchains already do cross-compiling when they're bundling anyway, so it's not required on that front.
>what advantage does existing typescript language have, over a backwards-compatible & type-carrying enhancement to JS?
Typescript is on a much faster release schedule than the standards. Just think of how slowly its (amazing) type system would've evolved if designed by committee.
I'd be all for a type system in javascript a couple of years ago. But seeing how fast typescript evolved when it's not limited by a committee, I think that keeping that separate of the main language is completely acceptable.
The authors intend to support a variety of type systems, such as TypeScript & Flow. That TypeScript would need to define it's own grammar doesn't seem harmful, & would surely be standardized quickly, exterior to this more general spec.
Latter you say: "Typescript is on a much faster release schedule than the standards." Well, since the format isn't specified, TypeScript is free to release at their leisure. Not bundling orthogonal concerns together, providing low-level extensible capabilities is a win.
> Browsers can't take advantage of it.
Why not? They could.
> Toolchains already do cross-compiling when they're bundling anyway, so it's not required on that front.
Ok, but you're ignoring the goal of this proposal: "The aim of this proposal is to enable developers to run programs written in TypeScript, Flow, and other static typing supersets of JavaScript without any need for transpilation"
They syntax isn't fully specified (it does some basic syntax checking on the top level, but doesn't check anything inside brackets). Asking browsers to support every variation of type declaration syntax that will come out is a lot (even if that turns out to be just typescript and flow). Why bloat the language and implementations?
Unless you propose an unified syntax for types... in which case it will hurt innovation as we won't ever be able to make backwards breaking changes, as people will rely on all sorts of quirky behavior.
>Ok, but you're ignoring the goal of this proposal: "The aim of this proposal is to enable developers to run programs written in TypeScript, Flow, and other static typing supersets of JavaScript without any need for transpilation"
Right, but why is this desirable? What does this bring to the table other than some convenience in exchange for adding more bloat to the language & implementations?
If you want browsers to also type-check, then you're also adding more complexity to implementations. In exchange of a small bit of convenience?
If you want the type-check to be used for optimizations, while a noble goal, would require some massive reengineering of current javascript engines. It's already possible to get optimizations that come from static typing by compiling things to webassembly instead (so they can use existing pipelines, like llvm. Assemblyscript comes to mind, it tries to be similar to typescript but with mandatory types).
A lot of optimizations might not even be possible to do even with type annotations, unless they're a lot more strict than typescript's. See the following examples:
This feels like enormous de-bloating of the developmemt experience at zero cost to the language.
A pragma at the top, "use typescript" that the browser could handle would bridge 98% of the rest of value while not overcommitting the language to a specific cause.
it should also be enforced by the language. and then you can still check and remove it using a transpiler, if you want (for smaller sizes + speedup due to lack of type checks). but if you're gonna add type annotations, they should do something
It would be great to be able to have access to types at runtime in order to change behavior based on types. That would make TypeScript so much more useful but it does require javascript support.
The compiler knows when this is used and can only insert type metadata when needed. io-ts and reflect-metadata are unwieldy crutches compared to a type system that's designed to influence runtime behavior (ie Rust, C++, etc).
https://github.com/tc39/proposal-decorator-metadata is where we'd probably need to begin to store this information. It's still need a transpiler to generate the necessary decorators. Decorators are still in progress (but kind of seemingly shaping up these days).
But if you're already transpiling/bundling your assets, why not use typescript? Instead of bloating the language and browsers even more. Not only that, but solidifying an interface there. Once it's done, it'll be very hard to change, as people will rely on all sorts of quirky behaviors.
footnote: Looking at my phone's browser history, I read the article at https://tc39.es/proposal-type-annotations when making this comment. Not the github repo. I hadn't dove too deep into it, but it does seem that it specifies a syntax for the top level type declaration. I initially believed it was entirely unspecified what the contents between the : and = were. But it does try to specify some rules, but leaving anything inside a {}, [], <> and such completely unspecified.
My feelings are still the same in that I don't support the proposal.
I don't want this. I want real types, that are checked and throw errors, or are at least coerced on being passed into/out of methods (preferably the former)
If you don't want to take the performance hit of type checks, you can still check and then remove type annotations during bundling. Having this would just mean that we will never ever ever get actual static typing in javascript, so it's actually worse than doing nothing.
We almost had it with JavaScript 2/ECMAScript 4, but Microsoft and Google killed it. One because they didn’t want to update their JS engine and the other had just released v8. Adobe implemented it as ActionScript 3 and Firefox had most of it done too. Everything since then has been about incrementally add similar features into the existing code base without fixing the foundation.
Okay, but also at the same time we had XHTML with strict errors that would crash the webpage. As a result, nobody used it or wanted it in practical, messy, real world code.
Since that backtrack, the Internet has always been about displaying something at all times.
Adding types to JavaScript and hard failing when they’re incorrect is not a JavaScript anyone wants to publish. We’d rather have the forgiving but messy JavaScript than the one that stops a webpage from working when it gets a different data shape from a JSON endpoint due to runtime checks.
Nobody actually wants runtime checks on the web unless you’ve a way to opt in to them. And guess what? You could. There’s nothing stopping you from writing a compiler that adds runtime checks to your code. In fact, that’s pretty much what code generators do for typescript when they create validation functions to make writing or working with APIs a bit easier.
adding type annotations to your code is opting in. if you don't want it, you can leave them out, or have them be removed during bundling. what's the point of having annotations that do nothing?
No, comments comment. They have a purpose, to communicate information to a reader. Moreover, they don't pretend to be syntax that does anything else. And we already have two ways to do comments in javascript.
Type annotations in a language that don't actually annotate types for an interpreter of that language literally do nothing. Might as well just use the existing comment formats to do the same thing, and be more syntactically explicit:
What we’re talking about, though, is the reason the ES6 arrow syntax exists. And it’s not just because of “this” binding. It’s because JS developers are lazy. What you’re suggesting is extra characters. And clutter.
These days if you pick a JS project or dependency and try to ignore the ones written in TypeScript, you’ll be left with very, very few viable alternatives. Do JS-only projects exist? Yes. Plenty. But the number of modern JS-only projects are far outnumbered by the number of TS projects, and the discrepancy is only going to grow over time.
What’s sealed the deal was TypeScript adhering as much as possible to JS standards and not inventing new runtime conventions and weird syntax. When they made that pivot, to a JS + types approach, that was genius. It helped everyone remind themselves that TS was JS with types, and not something different like Dart.
Taking this another direction, the power of TypeScript has been its ability to evolve as a language without breaking JS compatibility. If you bake types into JS, you risk breaking compatibility with some improvements to the type system. By keeping types out of the runtime, only the developer toolchain needs to worry what version of Typescript might be required to build a particular package. We don’t have to invent a way of marking some scripts as v3 and others as v4 TS.
Until now, JS has been largely future-compatible while TS has rapidly evolved and occasionally broken existing code. It’s of course possible to add types to JS, but are we convinced we have a perfect type system to do so now, or could it not wait and evolve a bit first?
We can always make a backwards-compatible language change later, such as a syntax to turn on or turn off runtime checks.
So we can run unmodified TypeScript code without needing to bundle inside Node.JS and other implementations of JavaScript such as JS Core.
By allowing but ignoring types, you get the best of both worlds - optional type checking and runtime compatibility - without further compilation.
Frankly I think of this feature as a Node.JS feature and a reduce-duplication feature. You can store and run the same TS syntax in a file with a .JS extension.
Today, I often find TypeScript samples that I copy into JS projects and then have to painfully remove the TypeScript bits to get it to run. This fixes that. Your IDE can benefit from reading the types and tell you about errors - that’s where you can fix them anyway.
If you want <script lang="TypeScript" … /> to work, with compile type checks and everything, that’s a different feature?
Why should javascript, as a language, care about Typescript? I know it's popular, but it isn't javascript, it's a completely separate language which just happens to compile to javascript.
Why should javascript add syntax just to make users of another language more comfortable?
>Today, I often find TypeScript samples that I copy into JS projects and then have to painfully remove the TypeScript bits to get it to run. This fixes that.
The purpose of typescript is to be compiled into javascript, it isn't meant to be run in a browser. If you're going to use it, use it properly, otherwise, "picking out the typescript bits" makes about as much sense as "picking out the C#" parts of some .NET code to run it in a C compiler.
> One because they didn’t want to update their JS engine and the other had just released v8.
ECMAScript 4 was canceled for a whole host of reasons. Trying to blame browser vendors is just bonkers. The standard made too many changes all at once and existing work on implementations had progressed too far.
I wouldn’t say its bonkers at all. That’s a good blog post not trying to lay a ton of blame on any one person. But having worked with Macromedia/Adobe and Mozilla engineers at the time who already successfully implemented a majority of the spec they were quite frustrated with everyone else looking for ways to slow things down or stop it wholesale.
We can’t change the past. Unfortunately we are reinventing a lot of what was done in that early work, but now with some strange syntax because of compatibility with dead features or 3rd party libraries that picked up the slack. At least we finally have a standard for importing packages…again.
You're free to go develop a transpiler that adds the guards/checks you desire to your code. Nothing stops you from building on this starting place. The data would be there.
JS engines could do the same!
Let's start with the first steps: getting the information.
the moment they add this to javascript, there will be people out there feeding strings to number-annotated parameters of functions (and so on). and then of course no one is going to want to break existing code. that's why doing this in a way that is not enforced is corrosive to having types in the language in the future.
I'm not sure I understand the concern. Static types are checked and emit errors, but they do so statically (i.e. at compilation time).
There's nothing I see in this proposal to prevent a user-agent from running a static analysis on JavaScript input into the console or DOM editor before trying to interpret it. If what you're saying you want is for the typechecking to be done by the user-agent for every piece of downloaded JavaScript... Why? I mean, a user-agent could be constructed to do that, but it'd be inefficient over just trusting the vended code (which, in a sense, we should probably just default to doing, because nothing stops the developer from type-asserting or omitting types so in the grand scheme of things, the code is exactly as provably sound if we typecheck it before running as if we don't).
What would "actual static typing in JavaScript" look like that this proposal isn't?
the proposal is for type annotations, which are to be treated as comments. i want type checking to be done in the browser, whether it's before the javascript is run or at runtime isn't important, the point is that i want the browser to explicitly be forced to do it. and then if I'm sure my types are correct and I want to speed things up, I can strip out the type annotations. but this means that for smaller scripts, or in general during development, you don't need an extra compilation step at all.
I want the browser to reject feeding a string into a number parameter of a function, at which point it does this isn't important to me as much as that it should be more than just a comment that is ignored completely.
If it's static analysis, then the browser can always execute it and throw it out after execution, that's the nature of static analysis.
There would absolutely have to be an escape hatch, or configuring one's browser in this way would make most of the web fail to work (and unfortunately, the golden rule for features in browsers is "if it breaks most existing sites, you can't add it because most users aren't savvy enough to understand what is happening and will uninstall your browser in response"). But I can't actually see anything stopping a given user agent from choosing to offer that as a development feature for a specific domain, which would be pretty swell.
well, if you don't have type annotations, nothing is enforced, obviously. but you can pretty easily make it legacy-code compatible by just having type annotations be optional, but enforced if present
Same. This proposal could be a chance to gradually move away from insane javascript typing. I think the first thing is to make effect manager and separate DOM API from anything else, and introduce sound typing language on pure side. This way is not messing with any underline engine but API. Webassembly text is a whole new language that can be compiled and interact with javascript. Why can't we have to new sound type language, it doesn't have to have many features since DOM API is still there.
> One can explicitly specify the type arguments of a generic function invocation or generic class instantiation in TypeScript.
// TypeScript
add<number>(4, 5)
new Point<bigint>(4n, 5n)
> The above syntax is already valid JavaScript that users may rely on, so we cannot use this syntax as-is. We expect some form of new syntax that could be used to resolve this ambiguity. No specific solution is proposed at this point of time, but one example option is to use a syntactic prefix such as :
// Types Annotations - example syntax solution
add::<number>(4, 5)
new Point::<bigint>(4n, 5n)
> These type arguments (::<type>) would be ignored by the JavaScript runtime. It would be reasonable for this non-ambiguous syntax to be adopted in TypeScript as well.
----
Hmm I didn't know this, so I tried it myself in Chrome's console... sure enough it works...
new DOMPoint<Number>(4,5)
Given that the above works in the browser, what exactly is it doing? I've never seen angle brackets used that way in vanilla JS code
It just evaluates to false, as this is just two comparison operations.
It's easier to comprehend if add a parentheses around first operation as such:
(new DOMPoint < Number) > (4, 5)
(new DOMPoint < Number) evaluates to true and it becomes (true) > (4, 5). Because (foo, bar, baz) syntax always evaluates the last item, we can finally simplify it into (true > 5), which surely enough in Javascript evaluates to false.
IMHO, the "turbofish" syntax (popularized by Rust) is ugly and should not be used. The reasoning of syntax ambiguity is also a lame one because C# manages just fine without it. But to then say that:
> The above syntax is already valid JavaScript that users may rely on, so we cannot use this syntax as-is.
What users would be using said syntax? Why would one compare a function to a type? If we're making a backwards incompatible change, just say that `func < type` is a syntax error unless immediately followed by the rest of a call. IMO, in any spec committee, if a naysayer says that "someone may be using that syntax", they should be required to prove it. Prove that someone is comparing a function to be less than a type, and why they'd do such a thing.
Honestly, I don't see how this can be done in a backwards compatible way short of type annotations in comments. Just rip the bandaid off and have WHATWG say that TypeScript is a valid runtime and allow `<script src="..." type="typescript">`. Deno manages to have a TypeScript runtime just fine.
Sure, but if a minifier/optimizer wants a “truthy” value, they can just use “1”. It’d be a pretty bad minifier if it turned something needing a truthy value into anything more than that.
Unless one can find some minifier producing said example, it’s a bad argument.
It's essentially unknowable if anybody has produced code out there that is like this, but the point still stands that it is valid code.
If you want to uphold a commitment to backwards compatibility, you simply cannot extend your language in a way that might possibly change the behavior of valid-but-nonsensical code in the wild.
> Given that the above works in the browser, what exactly is it doing?
Oh, buckle up!
new DOMPoint<Number>(4,5)
Let's first clean things up a bit: DOMPoint an Number are just identifiers. So, let's replace those with a and b:
new a<b>(4,5)
Let's also add some spacing around these tokens to distinguish them better:
new a < b > (4, 5)
Yep, those < and > are comparison operators.
And let's also add some parentheses to make clear the order of operations in these comparisons. The above expression is equivalent to:
(new a < b) > (4, 5)
Now, let's remember that a is DOMPoint, so `new a` is just instantiating a new DOMPoint object. Yep, the parentheses at the end of the `new Something` calls are optional if no parameters are passed.
(That's the result of trying that out on a JS console. The initial > on the first line is the REPL prompt, not part of the JS syntax. And the second line is what the REPL prints.)
So the < operator is comparing a DOMPoint object to b, which is Number, which is just a constructor function. IIRC, what JS does is these kind of situations is to convert both operands to strings and then compare those.
So the first < comparison is going to compare these two strings, and since '[' is less than 'f' (of course... ASCII), the < result will be `true`. The whole expression can then be reduced to:
true > (4, 5)
The right-hand side of this > operation, `(4, 5)`, is curious. The parentheses are just normal parentheses for grouping expressions, but what's inside of them are two expression joined together by the comma operator[1]! Basically, both expressions, 4 and 5, are evaluated, one after the other, and the result of the whole is the result of the last one:
> 4, 5
5
So, we're almost there! The whole thing can now be reduced to:
true > 5
Since one of the operands is a number, JS tries to convert the other one to a number too. `true` converted to a number yields 1, which is not bigger than 5 — finally, something that makes sense!
So now we know why the whole thing that looks like TypeScript but isn't, is valid JavaScript and evaluates to false :)
> Since one of the operands is a number, JS tries to convert the other one to a number too. `false` converted to a number yields 0, which is not bigger than 5 — finally, something that makes sense!
You meant that `true`, not `false` which doesn't appear in this partially evaluated version, is numified, right?
Adding (even a simplified version of) the Typescript typesystem to the Javascript spec is probably a bad idea. It's all the weird little complexities of Typescript that make it flexible enough to add types to most JS code.
Javascript as an untyped build target is fine. I'm opposed to adding (ignored) type hints to Javascript because they'd just end up rebuilding Typescript, but done poorly.
TypeScript doesn't have a language specification so there's nothing to merge. If you tell browser vendor X that they need to start supporting TypeScript, what does that mean?
I wouldn't hold the lack of a natural language specification against Typescript. Canonical open-source implementations work just as well in practice and tend to become de-facto standards: Microsoft's compiler is effectively a human- and computer-readable specification.
I can't come up with reason why you got downvote. This is a fundamental and basic thing on designing type. I'm afraid to comment "merge what?" (genuine question)
> The sunsetting of IE11 and the rise of evergreen browsers that implement the latest JavaScript standard means that developers can once again run standard JavaScript code without transpilation.
This is a wrong assumption. There are lot of smartphones that do not get updates and have browsers that can be several years old.
Therefore transpiling and polyfills are not going away anywhere soon.
Of course, supporting different browsers can insignificantly increase development costs. It might be impractical to try to support Internet Explorer 7. A safe and reasonable choice would be to make sure that site looks and works perfectly in any browser released 5 years ago and is usable in a 10-year old browsers.
Obviously there are cases when this rule can be amended, for example, if you are making a game requiring a fast GPU and a mouse, then you can ignore smartphones and old browsers. But for a general website, like a corporate website, an online store, a social network, this seems like a sane default choice. You can extend support to 12-15 years old browsers if you feel confident in your skills.
I think it doesn't really matter one way or the other, anyway. Even if it takes 10 years to proliferate, at some point in the future, it'll be 10 years from now, and we'll be able to use it. depending on your usecase, maybe sooner.
I still expect most people would bundle and minify the code shipped in production but removing the requirement to setup a transpiler for development would be a huge win for developer ergonomics.
For many smaller projects that bundling step may then simply be `deno bundle index.js` or similar.
I'm not sure this will help solve any of our problems.
Theoretically, there would be no more need for compilation tools after this change is implemented.
In practice, lambdas need to be bundled, frontends still need to be bundled and running typescript in node efficiently nowadays should be as easy as `node -r @swc-node/register path/to/file.ts`
So this will actually not ease the JavaScript tooling nightmare.
This makes both irrelevant, since you can already run code without bundling.
Obviously it’s not something you’d do in a normal production environment. It’s nice to be able to run code without any compilation steps if you’re working on something small (e.g. some demo on my personal website) or something in a development environment.
I’ve done this. Served up JS with “import” statements everywhere. The devserver just served JS straight from the filesystem without modification. When I change the JS, the browser just needs to reload—there’s no build process, no waiting. The production environment ran it all through Closure. Closure also ran in the dev environment, but it ran asynchronously, in the background, telling you what the errors are.
No source maps to deal with. No delays. The browser gets exactly what I write.
Sure, it's just that very few companies are probably going to be doing this outside of very early prototypes/toy examples. Load time is just too important
Not requiring bundling to be setup during development is a huge win for developer ergonomics. Though I prefer to write TypeScript I've avoided it in some small projects where I didn't want the hassle of setting up the transpiler / watcher / etc.
Production bundling can then be as simple as running `deno bundle index.js` or similar.
Looks like programmers wish their favourite language would adopt their new favourite feature right after they've just learned how to use it. Sure, it makes the language you use more sophisticated, but at the cost of raising the bar for everyone else to learn that language.
To continuously add features and complexity to JavaScript makes getting started with web development that much more cruel and arduous for our more junior colleagues.
If you like types (and personally — as someone who for the past several years has almost exclusively written Haskell and Elm professionally — I do), why not just pick a different language that has the features you want and compile it down to JavaScript?
I have a perception (and I'm sure some would argue it's inaccurate) of the web development community that likes to pat itself on the back for being smart enough to use JavaScript's [relatively] new spread operator, but at the same time whinging about Elm because its syntax looks weird.
> the web development community that likes to pat itself on the back for being smart enough to use JavaScript's [relatively] new spread operator, but at the same time whinging about Elm because its syntax looks weird.
It's probably more like that meme image from some TV show:
Elm user: I feel bad for you.
Enthusiastic JS/TS user: I don't think about you at all.
It's from "Mad Men" the TV show about a US advertising agency, initially on Madison Avenue in New York (hence "Mad Men" from both "Mad[ison avenue]" and "Ad[vertising]"). Don Draper the show's main protagonist dismissed the "I feel bad for you" comment by a minor character this way. Because Don is the protagonist the audience knows how they're expected to feel about that.
In the context of the episode Don Draper spent the entire episode thinking about the minor character constantly. When he says the line in the elevator we know it’s absolutely not true, especially when the character was asking Draper why he hates him; Draper makes the remark to be more hateful because the character has been occupying his mind for days.
Always funny to see “memes” evolve outside the original context.
I think you can always take this meme both ways, for example the Metric System / United States of America one, there are definitely Americans who never think about the SI system, and yet it's also true that America as a whole probably is thinking about it and doesn't like how that makes them feel.
[ Personally I like Natural units, ie. one of the systems where c = 1 like Planck or Stoney units. These are of course completely impractical for everyday use, but hey, what's not to like about the simplified equation E = m ? I also want French Revolutionary Months (Fructidor is a much better name for a month than "September" is) and the use of Kelvin rather than stupid °C with an arbitrary zero point ]
I don't think there is value in type hints that don't do anything. Especially because JS is sent over the wire. We already have a compile time type checking system called Typescript.
If you want JavaScript to enforce types in the browser that is a larger discussion.
JS build pipelines are an industrialized software shithole, & we're starting to look like the other worst offenders (python). relief is needed. js was, for decades, simple & easy & sparked joy. it can again. this proposal potentially liberates & eases enormous pains.
it also means we dont have armies of projects downcompiling to es2015 (unperformant) and/or cjs.
> js was, for decades, simple & easy & sparked joy.
This is total revisionism. Using JS to program anything substantial was a total nightmare in decades past. I've been building websites since the early 2000s, JS is more ergonomic and capable now than ever before IMO.
Trying to ease development burdens & generate more intercompatible ways of doing things, with less lift required to get going, while retaining the same benefits of types for those who want them, is 100% a superb & worthy idea.
It's great to see such developer-friendly compatibility & adaptability.
Top level comments so far (I have skipped two top level comments):
"I don't want this." "I'm not sure this will help solve any of our problems." "Sounds like a bad idea" "Nahhhh lets get the [non-type related foobar] proposal to land" "This is a wrong assumption." "Just merge with Typescript already" "there will be a flame war"
browsers are very conservative about breaking changes. javascript features that allow for loose and questionable usage is the thing that got us into this mess in the first place. once this is out there, there will be code using it in the most incorrect way it can get away with, and no one will want to break that code later on.
that's why it's not just important that we get "something", but we get it right.
> javascript features that allow for loose and questionable usage is the thing that got us into this mess in the first place.
And what "mess" is this? Again I think my previous advice is pretty on point: "Be happy!" Everything has only gotten better, from my perspective. That TypeScript exists & has grown up is yet more proof that incremental, ongoing, progressive advancement is amazing. I think if we'd tried to make everything all at once, it would have been a disaster.
> once this is out there, there will be code using it in the most incorrect way it can get away with, and no one will want to break that code later on.
This is a spec to let various typechecks be applied, but doesn't specify any specific type-system. I have a hard time visualizing whatever scary situation it is you are imagining. This seems low risk.
i've been doing this for over two decades, & the ability to sling async functions, w3c streams, abortcontrollers, modules, optional chaining,... everything is so kick ass better. my resistance to being convinced is going to be high, but heavens yes i'd love to entertain something higher & more illuminating than the general retrogressive cassally slanderous backhanding this language endlessly endures.
My argument is essentially that as the language has become more complex, it has become harder for more junior colleagues (and actually most programmers) to use the language effectively.
Do you buy the idea that a language might be better if it were designed to guide the user towards success? Or do you think it’s better to just throw everything possible into the language, warts and all?
> w3c streams
I know what a stream is, and I know the W3C is. What is a “w3c stream”?
> modules
My experience has been that the implementation of this idea in JavaScript has been extremely fragmented.
I’m fully with you. This greatly simplifies tooling by making transpilers entirely optional, meaning you don’t need a complicated setup just to get going. Developers get convenience, users aren’t affected, that’s a win all around.
People may not fully realize this, but the problem with the “just standardize TypeScript” suggestions is that TypeScript is a fast moving target. This is actually well argued in the proposal: lots of meaningful innovation is still happening in that space with more precise checks, which also means that small incompatibilities happen from version to version. That’s okay if we’re talking about dev tooling that a team can choose to upgrade at their own pace. It would be really bad to have browser upgrades affect the functionality of existing websites.
I have. But there's a pervading forrest of negativity, especially on js subjects, and trying to argue about each tree is only so helpful. The meta-attending to whats happening is direly needed.
Pasting bits of other people's comments out of context to sneer at them is plainly less helpful than not doing that, whatever you choose to meta-call it.
I think I've done a moderate & mild job of holding up a very reasonable mirror to what happens, broadly, in a lot of threads. This isnt at all unrepresentative of what's happening. In most cases it's people's first words.
This is long long overdue. Silence about this cavalcade cannot go on imdefinitely. This reaction you are having seems way way out of line for some pretty basic reflection.
How else might we try to meta-attend to our social problems?
Maybe it means that I don’t have to preprocess / compile TypeScript before running it. This is a genuine win for me. The TypeScript compiler can continue doing what it does best—type checking—and then I can just run the code. Running the TypeScript compiler from a cold start takes a surprisingly long amount of time.
Currently, I have to figure out how to get a build system that compiles TypeScript once for bundling to the browser and once for running in Node, and the user experience around setting this up is just incredibly bad. It sucks. I make some change to how I build for browser and it turns out to be incompatible with whatever system I am using for Node. This solves part of that problem, and reduces friction. Type annotations can be just part of the JS and stripped out by minification.
This is the reason I don't use the typescript compiler and instead use babel to strip the types out completely on compilation. I use vs-code's built-in type checking when coding in dev and then throw out types in prod. Fast dev builds and still get all the type checking I want. Optionally you can run the full blown typescript compiler as part of CI/CD if you want to ensure no errors or warnings hit prod.
For backend node, you simply edit a couple of lines in the package.json to use ts-node during dev, and run tsc for shipping builds (a bit more performant than ts-node).
For frontend usually you literally don't configure anything, Next.JS, CRA, or whatever already comes with typescript preconfigured if you select it. And if you do everything manually, considering you still need to setup babel, webpack etc, it makes almost no difference.
It seems quite extreme modifying javascript for this considering you still would want to remove types in order to reduce bundle size, and you would still need the actual compiler because you have things such as enums, annotations and more that JS doesn't support either.
How many years have you been doing this? How many hours have teams you've worked on spent configuring build pipelines? How many people have you seen to go other mentors or helpers in your org when they are setting up a new project? How many many times have you seen someone start from from nothing & be done in <1 hour?
This post feels like a trivialization of how complicated everything is, how complexly interlinked build systems are.
It also misses one of the biggest harms. It doesn't consider what a pain in the ass it is when the source/libraries you are consuming have already been downcompiled into lesser JS via someone elses perhaps-poorly configured build pipeline. I'd guess that >80% of TypeScript modules don't export ESM right now. TypeScript 4.7 is about two weeks old & it's the first time TypeScript and Node's ESM play well[1]. Because it all involves complex transpilation. How many modules do you think will get updated, ever?
You know what would be great? If we could just write code. If we didn't have to worry about build pipelines. If my toolchain could make what it would of other code, be it JS or JS+TypeScript Type Annotations or JS+Flow Type Annotations.
> "For frontend usually you literally don't configure anything, Next.JS, CRA, or whatever" "For backend node, you simply edit a couple of lines in the package.json"
The amount of dissympathy for the real complexity here, for how hard a couple specific projects have worked to make things "just go" is staggering. The amount of ink spread to support, the amount of stack overflow questions struggling through, is probably enough to reprint the Apollo Missions guidance software a couple times over.
This is hard stuff. It's complex & interlinked. There are not singular solutions; there's many many interlinked & complected tools & systems & options.
Easing the path back towards- it will work. Towards just being able to ship code, without necessarily needing to typecheck it, transpile it, downcompile it: it helps a huge range of people who are really really in need of help. Who don't have teams, companies, support. Who just want to start to learn, want to start to get going. This change may or may not (I'd argue more that it may but...) have huge impact on your life as a highly-late industrial supercorp developer, but it has huge impacts on the ecosystem, it's approachability, it's friendliness. Writing all that off, just pretending we have some magic wands we can wave & these dilemnas, these pitfalls, are not really here: woe be un to us if we are not willing to assess the real cost of this all. I can't see your post as taking for real the costs.
JS used to be extremely low cost & light weight to play with, to get started with. It used to be a joy. It still is, but the barrier to entry is much higher, using modules has never been the same dream as slapping some <script src="http://jquery.com/jquery.js"></script>'s down on the page (not a real link) and having it just work. This goal is fulfillent to a noble & excellent intent to once again spark joy.
Most people write code using esm for the past few years. If anything the problem is that shared libraries are only exporting esm so tools like jest that still require commonjs don’t work.
Just use Tsdx or other tooling to automatically expose the different bundle types.
Even still, if JS developers took the time to understand the different module types we would be in a much better place on the shared packages front
> Most people write code using esm for the past few years.
But what do they target? TypeScript projects targetting only es2015 or only cjs are all too numerous.
Much of nobility of this Type Annotations work is we could (potentially) stop transpiling. The source could be the source.
> Just use Tsdx
Just use ____ is the center square of the JS bingo game. It's a terrible answer, but it's almost always the answer, and the answer always changes.
That there's an ever rotating constellation of "just use" answers to newcomers questions, all of which are semi-required "zero configuration" "just works" new tools to fix the previous pile of cobbled together stuff: painfully Python-esque.
I agreed with every single thing you wrote until that last line. In what universe is the ever-changing mess that is the JavaScript ecosystem even remotely comparable to the Python ecosystem?
A not unreasonable call out at all. The multi-layers of pip, setuptools, easy_install, virtualenv stuff made me very sad at the time. Nodejs was such a relief at the time.
My understanding is recently Python docs have started to encorporate a little more guidance on handling dependencies in virtualenvs, and some specific suggestions & write up about tools. Which is great.
I think your right that JS probably has a lot more build/compiling/lifting machinery, & is much more confusing. To be fair, it also has a much harder job (since the build-target is only sometimes the local machine).
The confusing thing is that even though we have all been writing import statements in Typescript, that is not the same as ESM. Now, even though we all think we have been using ESM, when libraries only export ESM our tools/build chains are not compatible.
> This post feels like a trivialization of how complicated everything is, how complexly interlinked build systems are.
I know build systems can get very complicated, in fact it's part of my point. Which is that considering you already need to set up a build pipeline, adding typescript support is quite simple.
> You know what would be great? If we could just write code. If we didn't have to worry about build pipelines.
But that will not be the case. People are not FTPing their dev folders into prod anymore. Even with this change, you will still need a build pipeline, as everybody already does regardless if they use TS or not.
> JS used to be extremely low cost & light weight to play with, to get started with. It used to be a joy. It still is, but the barrier to entry is much higher, using modules has never been the same dream as slapping some <script src="http://jquery.com/jquery.js"></script>'s down on the page (not a real link) and having it just work. This goal is fulfillent to a noble & excellent intent to once again spark joy.
I disagree with this. That's probably nostalgia talking. Slapping some script URL and editing with Notepad++, having absolutely no IntelliSense, no errors/squiggly lines and having to F5 a browser after every change, trying to hit the code path in question and check the browser console for errors was awful.
Nowadays the editor will tell you what's wrong as you type it, the browser will automatically refresh the code while maintaining state and so on.
Your development bias reflects that of a decade+ wisened & mature developer, well set up, prodyctive with great tools in your toolbelt.
I think you conflate the development environment with the hypermedium. You stick lo-fi tools with shame, but you're not actually talking to the language & it's lightweight versaility & hackability. You're not talking to the editability, the malleability, & simplicity of the medium as it was, and which, if we can do just a little bit of healing, can be again.
> Even with this change, you will still need a build pipeline
Will we? Why? I tend to wager a decent static webserver (especially one that has decent cimpression built in) will be a very fine deploy target for many again, soon. ESM, early-hints, http3... it could happen. Yeah we probably should strip comments & these type annotations, but need to? Meh. I think we fret too much about the small stuff & havent spent nearly enough time conisdering incremental loading architectures & better use of service workers. The endless pish for optimizing what we have has been a race of folly ignoring the real peaks around us daring us to be summited.
JS can & should be less build intensive. Non-build module-using js was the high fantasy we were driving for a decade ago, when the idea of modules was new, & it's been slow, but that objective was there for really good & importamt reasons. A js which is naturally accessible, which is evident & real, is good for humanity & how the web reconnects with itself as a hypermedium, as more than just another shitty developer app-dev toolbox for nerds like us. We can be better. We can make the source real again.
> Will we? Why? I tend to wager a decent static webserver (especially one that has decent cimpression built in) will be a very fine deploy target for many again, soon. ESM, early-hints, http3... it could happen. Yeah we probably should strip comments & these type annotations, but need to? Meh. I think we fret too much about the small stuff & havent spent nearly enough time conisdering incremental loading architectures & better use of service workers. The endless pish for optimizing what we have has been a race of folly ignoring the real peaks around us daring us to be summited.
Even with http3 and so on, serving node_modules which almost always is 100k+ files would be awful. And of course, yes, you don't need npm. But I don't see people going back to the jquery days of having a single o no dependencies.
I guess the point stands for new people learning web development who are only playing on localhost and don't care yet about having something good enough for prod.
But I don't think people who are at that stage should worry about typescript. If they did and didn't want a build pipeline, they would just manually run tsc. Is adding a new feature to JS just so that beginners who want to use TS don't need to run tsc worth it? IMO no.
This is true (ish, sort of, today) when you work for a corporation & have either years of experience or people backing you.
It completely ignores what it takes to get started, or how alive & malleable the web is.
The domination of concerns by deeply deeply industrialized ways of thinking holds back the joy of the hypermedium we work. And it truncates human potential. Making code & coding accessible is a virtue. One that could cost us nothing.
I have been trying to get ts-node to work consistently for, like, five years and it’s always a fucking battle. I can only conclude that either I have miserably poor JavaScript skills or you only work on really simple code bases where this works, or some combination of the two. It’s not just ts-node—it’s Jest and other tools, it’s configuring ES modules to work in Node or deciding to use require(), it’s fine-tuning your TypeScript configurations (plural), it’s a bunch of stuff.
> For frontend usually you literally don't configure anything, Next.JS, CRA, or whatever already comes with typescript preconfigured if you select it.
My experience is that this stuff is always on the verge of breaking when you integrate it with some new dependency, when you have needs that are slightly different from the mainstream use-cases that the developers envisioned, or when you start going through and updating your packages.
I’ve been using JavaScript since the dark ages and the only way we can survive is by periodically cutting down some of the built-up complexity. We don’t need to cut it down for everyone, and not all at once, and no change is without its drawbacks. I’ve used create-react-app, I worked at a company that used machine learning in the JS build pipeline to do code splitting, I’ve used vanilla JS, and I’ve written some pretty damn cursed build systems for stuff like JS13K or 1K coding competitions. TypeScript sticks out as a rough spot in most build systems I’ve used, and the reason I still use it (most of the time—not always) is because the typechecking and IDE experience are just so damn good that it justifies the cost.
> It seems quite extreme modifying javascript for this considering you still would want to remove types in order to reduce bundle size, and you would still need the actual compiler because you have things such as enums, annotations and more that JS doesn't support either.
Not every change is applicable to all uses cases for everyone. That’s ok. If you decide to write TypeScript without enums you usually find that you don’t lose that much—it’s easy enough to do something like:
type LogLevel = "error" | "warning" | "info";
Obviously this is not a one-size-fits-all trick, but I find myself using TypeScript enums less and less these days.
There are also some dirtier TS tricks you can which let you create something kind of like Haskell’s newtype—pure type system stuff.
The last point you mention actually makes me think this is probably a harmful change, that could have a chilling effect. People only wanting to use the subset of TS that runs as JS, could hamstring future TS features, as well as limit current features usage for no good reason.
TypeScript used to have more sugar, and that sugar had been removed and merged with the equivalent ES functionalities. Dig through old TS versions and you’ll find obsolete syntaxes or semantics that have been removed.
Just to pick an example, TS had class before JS. IMO the ideal scenario here is that TS is just type annotations on top of JS, and any features you use which aren’t universally available, you polyfill/transpile as a separate step.
This means TS is just types, and your transpired/polyfills are just transpilers/polyfills. To achieve that, TS classes are modified to match JS classes.
My sense is that TS will not add new stuff not in JS any more. It’s simply not a direction TS is going. I also get the sense that enums are a mistake in TS’s design.
TS in some sense is a reaction to the lessons learned from its predecessors, like CoffeeScript.
TS replacing it's own custom features if JS implements them is the correct move. But in my opinion they shouldn't hold back from adding features if they are good features.
TS goal IMO should be to offer the best developer experience, while maintaining interoperability with the JS ecosystem. Not just limiting themselves to types.
Why do you think enums are a mistake? Enums allow you to have autogenerated mappings from symbols to integers. You can't do that with types as you showed in your example.
TS should absolutely hold back from adding new features that are not in JS. That’s TypeScript’s niche—we already have other languages with new features, TypeScript works better as a typing system and nothing else on top of an existing language.
That’s why enum should be avoided in TS or added to JS.
I can understand why people want TS to be a “better” language, but these days, ES is pretty good and a major part of TS’s success is that it follows JS semantics almost everywhere.
> we already have other languages with new features
Not languages that can interoperate with JS the way TS does (except for flow and similar type checkers).
TS success is that it's a superset of JS (unlike say CoffeScript). So you can throw some JS and it will be valid TS. The point of being a superset is that you can add new stuff. Types, enums, annotations.
So the only argument why enums are bad except for that it's not in JS? Why does it matter, just because a JS developer has to learn more things if they switch to TS? The whole argument hinges on the premise that TS should not add anything that JS doesn't have except for types, but why is that?
That ship has already sailed, the TS team have been clear about not wanting to add features that aren't purely type-level for a long time. The suggestion issue template has a checklist requiring you check off that "This could be implemented without emitting different JS based on the types of the expressions" and telling you it realistically won't be implemented if not.
I can't do much without some degree of pre-processing. The browser can't resolve NodeJS-style require's, so I'll need a bundler to serve my app in a manner the browser can understand. I imagine most use cases today face this dilemma. It wasn't the type annotations holding me back for requiring pre-processing, it was the ecosystem around how JavaScript is written that is the primary factor.
I haven’t used NodeJS type requires in new projects since Node 12 (which EOL-ed last april). Most code I write now uses standard imports. There is off course some issues around resolving from npm but there are mitigations, and going forward import maps (already supported by Chrome) will solve most of these.
Really the only reason to do pre-processing is if you want to do some optimization beyond what the browser can do, or if you want to write a syntax which is not supported by your target runtimes. And for many developers (including most library authors) this is not the case.
So the moment a single library author doesn't support a target runtime I have, I have to pre-process. It seems to further the point that pre-processing is a critical step for many that isn't going away. Some projects like Angular are using non-standards compliant decorators, so until they re-think that decision, it's an absolute must for them.
It's really hard to guarantee a world where my complete dependency tree meets my target runtime requirements (eg: I might also not be using nodejs-style require, but my dependencies could be), so pre-processing seems like something that will be with us for some time.
That’s your use case, but it’s not the use case the standards bodies have in mind.
ESM imports are the standard, unlike Node’s require. And you can now write ESM code that’ll run flawlessly on the backend and the front end without any transpiration. IMO that’s huge. Type annotations remove yet another blocker.
I’ve been writing Vanilla JavaScript with JSDoc annotations and using TypeScript as a type checker (as opposed to a compiler) for some of my hobby-projects, and it is amazing breath of fresh air from the bundler tool chains of the past.
As pointed out by this proposal the JSDoc annotations are—to put it mildly—a bit cumbersome. The more complicated types are close to impossible to figure out how to write, if they are possible to write at all. And on Q&A forums I constantly have to translate between the two syntaxes in my head, since most of the audience will probably not understand the JSDoc syntax.
Having a unified type annotation syntax which the runtime ignores will definitely make my life easier.
I think the first thing in design to have sane (sound) type is to separate effects from pure stuff. Browser engine is complex but API shouldn't be, right? It would be great if those compile-to-js lang authors folks also get involved. (those ML based and some others)
Immediate reaction is that this is a bad idea. Seems like it would result in a weird Frankenstein language that is neither fish nor fowl. The lack of prior art for this type of approach is particularly concerning.
> The proposal here differs significantly from Python's types, as the types in this proposal are entirely ignored, not evaluated as expressions or accessible at runtime as metadata.
So guess sorta prior art but quite different.
Reading the TC39 minutes for this proposal makes me think it’s highly unlikely that the approach as outlined here will go anywhere.
Isn't reverse engineering a code with annotations much easier than without them? And reverse engineering the code often takes significant time in large projects.
Everyone talking about how much this would simplify their workflow from going from development with type-checking to the browser ignores that you can run a single command and remove all type annotations already... I'm not sure what this proposal solves? Perhaps there should be an added item to vscode context menu that is "copy without type annotations". I feel this would be very easy to implement...
Folks who write JavaScript today might not remember a time when it was normal to write JS and ship the same files verbatim to end users. We’ve seen a Cambrian explosion of new syntax, new tools, and new ways to build applications using JavaScript in the last decade. Many of those features are now built into modern browsers, but static typing is one of the last Big New Ideas that hasn’t made it into mainline JavaScript.
We’re conditioned to expect there will be a compilation step between our source code and the code that runs in a browser. That forces many decisions about how we structure our projects and the kinds of tools we can use to deliver the software we write. Minimizing or eliminating the reasons why folks might need that build-the-code step between the code they write and the code their users run opens up doors and new ways of writing and delivering software, and that’s exciting!
Think, for instance, what would it take to get something like the TypeScript type checker in Chrome’s devtools? A first step would be to adopt the type annotation syntax.
even if we add types to js... minification, dead code elimination, and even precomputing or other performance optimizations will still require a compiler.
not sure what typechecking inside chrome would add....
maybe it could be used for faster js execution like how asm.js works
I dunno I think there is a lot of historical revisionism happening in regards to how joyous coding in JavaScript used to be. I've been doing web-dev since the early 2000's, JavaScript is way more usable today than it's ever been in the past.
Right, I agree it’s much nicer to write JavaScript now than ever before. Merely pointing out that it’s not meant to be a compiled language. As a community we continue to expect a build step to exist when it really doesn’t have to for a broad class of projects. Transpilers were never the end-goal.
It’s true that there are some optimizations done in the build step that benefit end users, and folks will probably (correctly) continue to choose to minify, tree shake, bundle + bundle split, eliminate dead code, etc. for serious applications.
But to be able to write a modern web app without having to npm install a single module would be stellar! And it’s becoming more and more possible. How do you teach someone how to write a JS project in 2022? I imagine it starts with, “Well, first you’ll need to install node and npm - that’s gonna run JavaScript on your computer but don’t mind that much for now. Now we’ll install some dependencies required to build your code…” and so on. It takes a while and many conceptual hurdles to get to the part where someone can run the code they wrote in a browser.
I feel that is unneccessary, because if I want type annotations, then I can just use TypeScript. Although adding them in Python didn't hurt and was a net win I would say. But I'm not sure how feasible it is, because you want backwards compatibility with JS, and if you have to preprocess anyway to remove the annotations, why not use TS proper.
But I like it for another reason. The single most frustrating thing for me in JS is the lack of operator overloading. Matrix operations become so ugly if you can't use infix operators. If you do complex graphical calculations it is really important that the calculations remain readable.
Custom operators and operator overloading require type-dependent dispatch. The types could be known at compile time in TS. But the developers will not add any such feature, unless JS has it. One of a few prerequisites seems to be that JS gets type annotations!
But honestly it seems I would have to wait until JS becomes TS, before we can overload operators. Maybe it is more realistic to add this via babel or so.
I would say it would be great to merge with TypeScript.
It would greatly reduce the need of those crazy building tools nowadays. Now we have HTTP2, if only we can write and serve a bunch of TypeScript files directly. Be it browser, Node.js or Deno, you could use the same script file without setting up M*N different webpack.whatever.config.js files.
And it will also open up the possibility of optional runtime type checking which JavaScript as a glue language really needs.
TypeScript has been very cautious about adding non-JavaScript features, and kept its promise on JavaScript compatible, so I don't see big problems merging them. It's just people will need to figure out a spec to formalize the type system for TypeScript.
The only risk is there might be clash of the communities. But it also might get us great results where the whole community working on a great project together.
175 comments
[ 2.9 ms ] story [ 256 ms ] threadWhen using a bundler, it will be trivial to remove the annotations in the build process.
Using a TypeScript transpiler in that process is also trivial you might say. But static typing syntax and tooling as part of the language itself is the way to go imo.
But if the typing syntax is essentially just comments in very specific places... what advantage does it bring? Sure one can use tools to interpret those comments and check types... but at that point, isn't just using typescript tooling much superior (interface declaration, type declarations, etc. not just a type between : and =)?
I will confess that I am guilty of having used JSDoc comments for quick and dirty .js scripts that I didn't want to grab the tsc compiler for, but still wanted vscode to check my types. But even being one of the likely users of this proposal, I feel that it's needlessly bloating the language.
The advantage would be, that static typing is part of the language. Don't you find it odd to use another language just for a missing language feature? For me it feels somewhat hacky and '// temp. solution!!! fix soon!'-worthy.
But i'm thinking out loud now.
No. Why do you?
For a language to not try and have all the features it possibly can is a feature.
I mean, i like TypeScript a lot. I think i do find it odd, because i'm used to using languages, that are constructed with a certain feature set. Obviously Java/ECMA Script evolved a lot more chaotic than most other languages.
Transpiling a superset of a language to its subset introduces indirection, which makes it feel hacky imo.
I feel like, if there is another language feature we want to add in the future, how should that be injected? In form of a superset of TypeScript?
I would be cool with TypeScript as the target language, though.
It means the supplemental information needed to run either static or dynamic type-checking is there & so that either browsers or toolchains can use it.
And it means that the code would just run on existing systems. For production we'd probably want to strip out comments, but for production we already often do strip out comments (which I wish could be "undone" on most sites by users wanting to know! View source!!).
Let's turn your question around: what advantage does existing typescript language have, over a backwards-compatible & type-carrying enhancement to JS?
The format isn't specified, it's just a comment. Browsers can't take advantage of it. Toolchains already do cross-compiling when they're bundling anyway, so it's not required on that front.
>what advantage does existing typescript language have, over a backwards-compatible & type-carrying enhancement to JS?
Typescript is on a much faster release schedule than the standards. Just think of how slowly its (amazing) type system would've evolved if designed by committee.
I'd be all for a type system in javascript a couple of years ago. But seeing how fast typescript evolved when it's not limited by a committee, I think that keeping that separate of the main language is completely acceptable.
The authors intend to support a variety of type systems, such as TypeScript & Flow. That TypeScript would need to define it's own grammar doesn't seem harmful, & would surely be standardized quickly, exterior to this more general spec.
Latter you say: "Typescript is on a much faster release schedule than the standards." Well, since the format isn't specified, TypeScript is free to release at their leisure. Not bundling orthogonal concerns together, providing low-level extensible capabilities is a win.
> Browsers can't take advantage of it.
Why not? They could.
> Toolchains already do cross-compiling when they're bundling anyway, so it's not required on that front.
Ok, but you're ignoring the goal of this proposal: "The aim of this proposal is to enable developers to run programs written in TypeScript, Flow, and other static typing supersets of JavaScript without any need for transpilation"
They syntax isn't fully specified (it does some basic syntax checking on the top level, but doesn't check anything inside brackets). Asking browsers to support every variation of type declaration syntax that will come out is a lot (even if that turns out to be just typescript and flow). Why bloat the language and implementations?
Unless you propose an unified syntax for types... in which case it will hurt innovation as we won't ever be able to make backwards breaking changes, as people will rely on all sorts of quirky behavior.
>Ok, but you're ignoring the goal of this proposal: "The aim of this proposal is to enable developers to run programs written in TypeScript, Flow, and other static typing supersets of JavaScript without any need for transpilation"
Right, but why is this desirable? What does this bring to the table other than some convenience in exchange for adding more bloat to the language & implementations?
If you want browsers to also type-check, then you're also adding more complexity to implementations. In exchange of a small bit of convenience?
If you want the type-check to be used for optimizations, while a noble goal, would require some massive reengineering of current javascript engines. It's already possible to get optimizations that come from static typing by compiling things to webassembly instead (so they can use existing pipelines, like llvm. Assemblyscript comes to mind, it tries to be similar to typescript but with mandatory types).
A lot of optimizations might not even be possible to do even with type annotations, unless they're a lot more strict than typescript's. See the following examples:
* https://www.typescriptlang.org/play?#code/G4QwTgBAZg9jBcEDOA...
* https://www.typescriptlang.org/play?#code/MYGwhgzhAEBiD29oG8...
* https://www.typescriptlang.org/play?#code/MYGwhgzhAEBiD29oG8...
JS engines already optimize number-heavy code when they can identify that variables are always going to be numbers.
A pragma at the top, "use typescript" that the browser could handle would bridge 98% of the rest of value while not overcommitting the language to a specific cause.
This is all free cheap easy wins. Easy.
yes maybe with a 'use typestrict' directive or something.
If you are going to transpile/bundle your assets, you're probably using webasm at some point...or not!?
And nobody forces you to have typed minified JS in your bundles?
My feelings are still the same in that I don't support the proposal.
If you don't want to take the performance hit of type checks, you can still check and then remove type annotations during bundling. Having this would just mean that we will never ever ever get actual static typing in javascript, so it's actually worse than doing nothing.
Since that backtrack, the Internet has always been about displaying something at all times.
Adding types to JavaScript and hard failing when they’re incorrect is not a JavaScript anyone wants to publish. We’d rather have the forgiving but messy JavaScript than the one that stops a webpage from working when it gets a different data shape from a JSON endpoint due to runtime checks.
Nobody actually wants runtime checks on the web unless you’ve a way to opt in to them. And guess what? You could. There’s nothing stopping you from writing a compiler that adds runtime checks to your code. In fact, that’s pretty much what code generators do for typescript when they create validation functions to make writing or working with APIs a bit easier.
Type annotations in a language that don't actually annotate types for an interpreter of that language literally do nothing. Might as well just use the existing comment formats to do the same thing, and be more syntactically explicit:
What we’re talking about, though, is the reason the ES6 arrow syntax exists. And it’s not just because of “this” binding. It’s because JS developers are lazy. What you’re suggesting is extra characters. And clutter.
These days if you pick a JS project or dependency and try to ignore the ones written in TypeScript, you’ll be left with very, very few viable alternatives. Do JS-only projects exist? Yes. Plenty. But the number of modern JS-only projects are far outnumbered by the number of TS projects, and the discrepancy is only going to grow over time.
What’s sealed the deal was TypeScript adhering as much as possible to JS standards and not inventing new runtime conventions and weird syntax. When they made that pivot, to a JS + types approach, that was genius. It helped everyone remind themselves that TS was JS with types, and not something different like Dart.
Taking this another direction, the power of TypeScript has been its ability to evolve as a language without breaking JS compatibility. If you bake types into JS, you risk breaking compatibility with some improvements to the type system. By keeping types out of the runtime, only the developer toolchain needs to worry what version of Typescript might be required to build a particular package. We don’t have to invent a way of marking some scripts as v3 and others as v4 TS.
Until now, JS has been largely future-compatible while TS has rapidly evolved and occasionally broken existing code. It’s of course possible to add types to JS, but are we convinced we have a perfect type system to do so now, or could it not wait and evolve a bit first?
We can always make a backwards-compatible language change later, such as a syntax to turn on or turn off runtime checks.
By allowing but ignoring types, you get the best of both worlds - optional type checking and runtime compatibility - without further compilation.
Frankly I think of this feature as a Node.JS feature and a reduce-duplication feature. You can store and run the same TS syntax in a file with a .JS extension.
Today, I often find TypeScript samples that I copy into JS projects and then have to painfully remove the TypeScript bits to get it to run. This fixes that. Your IDE can benefit from reading the types and tell you about errors - that’s where you can fix them anyway.
If you want <script lang="TypeScript" … /> to work, with compile type checks and everything, that’s a different feature?
Why should javascript add syntax just to make users of another language more comfortable?
>Today, I often find TypeScript samples that I copy into JS projects and then have to painfully remove the TypeScript bits to get it to run. This fixes that.
The purpose of typescript is to be compiled into javascript, it isn't meant to be run in a browser. If you're going to use it, use it properly, otherwise, "picking out the typescript bits" makes about as much sense as "picking out the C#" parts of some .NET code to run it in a C compiler.
ECMAScript 4 was canceled for a whole host of reasons. Trying to blame browser vendors is just bonkers. The standard made too many changes all at once and existing work on implementations had progressed too far.
https://auth0.com/blog/the-real-story-behind-es4/
We can’t change the past. Unfortunately we are reinventing a lot of what was done in that early work, but now with some strange syntax because of compatibility with dead features or 3rd party libraries that picked up the slack. At least we finally have a standard for importing packages…again.
JS engines could do the same!
Let's start with the first steps: getting the information.
or only warn.
i don't think anyone would consider turning it on by default everywhere. this seems like an extreme non-issue.
There's nothing I see in this proposal to prevent a user-agent from running a static analysis on JavaScript input into the console or DOM editor before trying to interpret it. If what you're saying you want is for the typechecking to be done by the user-agent for every piece of downloaded JavaScript... Why? I mean, a user-agent could be constructed to do that, but it'd be inefficient over just trusting the vended code (which, in a sense, we should probably just default to doing, because nothing stops the developer from type-asserting or omitting types so in the grand scheme of things, the code is exactly as provably sound if we typecheck it before running as if we don't).
What would "actual static typing in JavaScript" look like that this proposal isn't?
I want the browser to reject feeding a string into a number parameter of a function, at which point it does this isn't important to me as much as that it should be more than just a comment that is ignored completely.
There would absolutely have to be an escape hatch, or configuring one's browser in this way would make most of the web fail to work (and unfortunately, the golden rule for features in browsers is "if it breaks most existing sites, you can't add it because most users aren't savvy enough to understand what is happening and will uninstall your browser in response"). But I can't actually see anything stopping a given user agent from choosing to offer that as a development feature for a specific domain, which would be pretty swell.
I think we will never have enforced static typing in Javascript, because of legacy code.
The solution is to use something higher level. Maybe Elm.
https://elm-lang.org/
If you don't want to this, you can still build your own real types, that's the beauty of JS.
Has additional context on this proposal and has previously been linked here.
----
Hmm I didn't know this, so I tried it myself in Chrome's console... sure enough it works...
Given that the above works in the browser, what exactly is it doing? I've never seen angle brackets used that way in vanilla JS codeComma operator makes (4,5) = 5
https://astexplorer.net/#/gist/b0dff7bdaf1d8f9024fe18fda70a9...
> The above syntax is already valid JavaScript that users may rely on, so we cannot use this syntax as-is.
What users would be using said syntax? Why would one compare a function to a type? If we're making a backwards incompatible change, just say that `func < type` is a syntax error unless immediately followed by the rest of a call. IMO, in any spec committee, if a naysayer says that "someone may be using that syntax", they should be required to prove it. Prove that someone is comparing a function to be less than a type, and why they'd do such a thing.
Honestly, I don't see how this can be done in a backwards compatible way short of type annotations in comments. Just rip the bandaid off and have WHATWG say that TypeScript is a valid runtime and allow `<script src="..." type="typescript">`. Deno manages to have a TypeScript runtime just fine.
Aggressively minified and optimized JS code results in all sorts of weird things.
Unless one can find some minifier producing said example, it’s a bad argument.
If you want to uphold a commitment to backwards compatibility, you simply cannot extend your language in a way that might possibly change the behavior of valid-but-nonsensical code in the wild.
Apparently C++ parsing is undecidable, so building an AST requires arbitrary template instantiation (and C++ templates are turing complete).
The turbofish is a compromise that allows the parser to stay simple. I know there were efforts to remove it, but it appears to be here to stay.
https://github.com/rust-lang/rust/blob/master/src/test/ui/pa...
Possibly the people behind JSFuck and derivatives. :)
Oh, buckle up!
Let's first clean things up a bit: DOMPoint an Number are just identifiers. So, let's replace those with a and b: Let's also add some spacing around these tokens to distinguish them better: Yep, those < and > are comparison operators.And let's also add some parentheses to make clear the order of operations in these comparisons. The above expression is equivalent to:
Now, let's remember that a is DOMPoint, so `new a` is just instantiating a new DOMPoint object. Yep, the parentheses at the end of the `new Something` calls are optional if no parameters are passed. (That's the result of trying that out on a JS console. The initial > on the first line is the REPL prompt, not part of the JS syntax. And the second line is what the REPL prints.)So the < operator is comparing a DOMPoint object to b, which is Number, which is just a constructor function. IIRC, what JS does is these kind of situations is to convert both operands to strings and then compare those.
So the first < comparison is going to compare these two strings, and since '[' is less than 'f' (of course... ASCII), the < result will be `true`. The whole expression can then be reduced to: The right-hand side of this > operation, `(4, 5)`, is curious. The parentheses are just normal parentheses for grouping expressions, but what's inside of them are two expression joined together by the comma operator[1]! Basically, both expressions, 4 and 5, are evaluated, one after the other, and the result of the whole is the result of the last one: So, we're almost there! The whole thing can now be reduced to: Since one of the operands is a number, JS tries to convert the other one to a number too. `true` converted to a number yields 1, which is not bigger than 5 — finally, something that makes sense!So now we know why the whole thing that looks like TypeScript but isn't, is valid JavaScript and evaluates to false :)
1: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...You meant that `true`, not `false` which doesn't appear in this partially evaluated version, is numified, right?
Javascript as an untyped build target is fine. I'm opposed to adding (ignored) type hints to Javascript because they'd just end up rebuilding Typescript, but done poorly.
This is a wrong assumption. There are lot of smartphones that do not get updates and have browsers that can be several years old.
Therefore transpiling and polyfills are not going away anywhere soon.
Of course, supporting different browsers can insignificantly increase development costs. It might be impractical to try to support Internet Explorer 7. A safe and reasonable choice would be to make sure that site looks and works perfectly in any browser released 5 years ago and is usable in a 10-year old browsers.
Obviously there are cases when this rule can be amended, for example, if you are making a game requiring a fast GPU and a mouse, then you can ignore smartphones and old browsers. But for a general website, like a corporate website, an online store, a social network, this seems like a sane default choice. You can extend support to 12-15 years old browsers if you feel confident in your skills.
For many smaller projects that bundling step may then simply be `deno bundle index.js` or similar.
Theoretically, there would be no more need for compilation tools after this change is implemented.
In practice, lambdas need to be bundled, frontends still need to be bundled and running typescript in node efficiently nowadays should be as easy as `node -r @swc-node/register path/to/file.ts`
So this will actually not ease the JavaScript tooling nightmare.
That said, I'm not convinced this would actually remove one of them:
- It would mean shipping more code which is a no-no
- It probably won't ever cover the whole of typescript's features, so many people will continue to use that, and will still have to transpile
I'm sure this will help... somebody, but it's going to be a very narrow set of workflows that benefit
Obviously it’s not something you’d do in a normal production environment. It’s nice to be able to run code without any compilation steps if you’re working on something small (e.g. some demo on my personal website) or something in a development environment.
I’ve done this. Served up JS with “import” statements everywhere. The devserver just served JS straight from the filesystem without modification. When I change the JS, the browser just needs to reload—there’s no build process, no waiting. The production environment ran it all through Closure. Closure also ran in the dev environment, but it ran asynchronously, in the background, telling you what the errors are.
No source maps to deal with. No delays. The browser gets exactly what I write.
Prototypes / dev are important.
Production bundling can then be as simple as running `deno bundle index.js` or similar.
To continuously add features and complexity to JavaScript makes getting started with web development that much more cruel and arduous for our more junior colleagues.
If you like types (and personally — as someone who for the past several years has almost exclusively written Haskell and Elm professionally — I do), why not just pick a different language that has the features you want and compile it down to JavaScript?
I have a perception (and I'm sure some would argue it's inaccurate) of the web development community that likes to pat itself on the back for being smart enough to use JavaScript's [relatively] new spread operator, but at the same time whinging about Elm because its syntax looks weird.
It's probably more like that meme image from some TV show:
Elm user: I feel bad for you.
Enthusiastic JS/TS user: I don't think about you at all.
Always funny to see “memes” evolve outside the original context.
[ Personally I like Natural units, ie. one of the systems where c = 1 like Planck or Stoney units. These are of course completely impractical for everyday use, but hey, what's not to like about the simplified equation E = m ? I also want French Revolutionary Months (Fructidor is a much better name for a month than "September" is) and the use of Kelvin rather than stupid °C with an arbitrary zero point ]
https://github.com/tc39/proposal-record-tuple
If you want JavaScript to enforce types in the browser that is a larger discussion.
it also means we dont have armies of projects downcompiling to es2015 (unperformant) and/or cjs.
This is total revisionism. Using JS to program anything substantial was a total nightmare in decades past. I've been building websites since the early 2000s, JS is more ergonomic and capable now than ever before IMO.
It's great to see such developer-friendly compatibility & adaptability.
Top level comments so far (I have skipped two top level comments):
"I don't want this." "I'm not sure this will help solve any of our problems." "Sounds like a bad idea" "Nahhhh lets get the [non-type related foobar] proposal to land" "This is a wrong assumption." "Just merge with Typescript already" "there will be a flame war"
Mercy! Be happy!
that's why it's not just important that we get "something", but we get it right.
And what "mess" is this? Again I think my previous advice is pretty on point: "Be happy!" Everything has only gotten better, from my perspective. That TypeScript exists & has grown up is yet more proof that incremental, ongoing, progressive advancement is amazing. I think if we'd tried to make everything all at once, it would have been a disaster.
> once this is out there, there will be code using it in the most incorrect way it can get away with, and no one will want to break that code later on.
This is a spec to let various typechecks be applied, but doesn't specify any specific type-system. I have a hard time visualizing whatever scary situation it is you are imagining. This seems low risk.
Would you accept the idea that the language has actually gotten worse? What would it take to convince you?
arguments.
i've been doing this for over two decades, & the ability to sling async functions, w3c streams, abortcontrollers, modules, optional chaining,... everything is so kick ass better. my resistance to being convinced is going to be high, but heavens yes i'd love to entertain something higher & more illuminating than the general retrogressive cassally slanderous backhanding this language endlessly endures.
My argument is essentially that as the language has become more complex, it has become harder for more junior colleagues (and actually most programmers) to use the language effectively.
Do you buy the idea that a language might be better if it were designed to guide the user towards success? Or do you think it’s better to just throw everything possible into the language, warts and all?
> w3c streams
I know what a stream is, and I know the W3C is. What is a “w3c stream”?
> modules
My experience has been that the implementation of this idea in JavaScript has been extremely fragmented.
People may not fully realize this, but the problem with the “just standardize TypeScript” suggestions is that TypeScript is a fast moving target. This is actually well argued in the proposal: lots of meaningful innovation is still happening in that space with more precise checks, which also means that small incompatibilities happen from version to version. That’s okay if we’re talking about dev tooling that a team can choose to upgrade at their own pace. It would be really bad to have browser upgrades affect the functionality of existing websites.
This is long long overdue. Silence about this cavalcade cannot go on imdefinitely. This reaction you are having seems way way out of line for some pretty basic reflection.
How else might we try to meta-attend to our social problems?
Not by haranguing forth on HN, a site that's explicitly not for that kind of discussion.
Maybe it means that I don’t have to preprocess / compile TypeScript before running it. This is a genuine win for me. The TypeScript compiler can continue doing what it does best—type checking—and then I can just run the code. Running the TypeScript compiler from a cold start takes a surprisingly long amount of time.
Currently, I have to figure out how to get a build system that compiles TypeScript once for bundling to the browser and once for running in Node, and the user experience around setting this up is just incredibly bad. It sucks. I make some change to how I build for browser and it turns out to be incompatible with whatever system I am using for Node. This solves part of that problem, and reduces friction. Type annotations can be just part of the JS and stripped out by minification.
For backend node, you simply edit a couple of lines in the package.json to use ts-node during dev, and run tsc for shipping builds (a bit more performant than ts-node).
For frontend usually you literally don't configure anything, Next.JS, CRA, or whatever already comes with typescript preconfigured if you select it. And if you do everything manually, considering you still need to setup babel, webpack etc, it makes almost no difference.
It seems quite extreme modifying javascript for this considering you still would want to remove types in order to reduce bundle size, and you would still need the actual compiler because you have things such as enums, annotations and more that JS doesn't support either.
This post feels like a trivialization of how complicated everything is, how complexly interlinked build systems are.
It also misses one of the biggest harms. It doesn't consider what a pain in the ass it is when the source/libraries you are consuming have already been downcompiled into lesser JS via someone elses perhaps-poorly configured build pipeline. I'd guess that >80% of TypeScript modules don't export ESM right now. TypeScript 4.7 is about two weeks old & it's the first time TypeScript and Node's ESM play well[1]. Because it all involves complex transpilation. How many modules do you think will get updated, ever?
You know what would be great? If we could just write code. If we didn't have to worry about build pipelines. If my toolchain could make what it would of other code, be it JS or JS+TypeScript Type Annotations or JS+Flow Type Annotations.
> "For frontend usually you literally don't configure anything, Next.JS, CRA, or whatever" "For backend node, you simply edit a couple of lines in the package.json"
The amount of dissympathy for the real complexity here, for how hard a couple specific projects have worked to make things "just go" is staggering. The amount of ink spread to support, the amount of stack overflow questions struggling through, is probably enough to reprint the Apollo Missions guidance software a couple times over.
This is hard stuff. It's complex & interlinked. There are not singular solutions; there's many many interlinked & complected tools & systems & options.
Easing the path back towards- it will work. Towards just being able to ship code, without necessarily needing to typecheck it, transpile it, downcompile it: it helps a huge range of people who are really really in need of help. Who don't have teams, companies, support. Who just want to start to learn, want to start to get going. This change may or may not (I'd argue more that it may but...) have huge impact on your life as a highly-late industrial supercorp developer, but it has huge impacts on the ecosystem, it's approachability, it's friendliness. Writing all that off, just pretending we have some magic wands we can wave & these dilemnas, these pitfalls, are not really here: woe be un to us if we are not willing to assess the real cost of this all. I can't see your post as taking for real the costs.
JS used to be extremely low cost & light weight to play with, to get started with. It used to be a joy. It still is, but the barrier to entry is much higher, using modules has never been the same dream as slapping some <script src="http://jquery.com/jquery.js"></script>'s down on the page (not a real link) and having it just work. This goal is fulfillent to a noble & excellent intent to once again spark joy.
[1] https://devblogs.microsoft.com/typescript/announcing-typescr...
Most people write code using esm for the past few years. If anything the problem is that shared libraries are only exporting esm so tools like jest that still require commonjs don’t work.
Just use Tsdx or other tooling to automatically expose the different bundle types.
Even still, if JS developers took the time to understand the different module types we would be in a much better place on the shared packages front
But what do they target? TypeScript projects targetting only es2015 or only cjs are all too numerous.
Much of nobility of this Type Annotations work is we could (potentially) stop transpiling. The source could be the source.
> Just use Tsdx
Just use ____ is the center square of the JS bingo game. It's a terrible answer, but it's almost always the answer, and the answer always changes.
That there's an ever rotating constellation of "just use" answers to newcomers questions, all of which are semi-required "zero configuration" "just works" new tools to fix the previous pile of cobbled together stuff: painfully Python-esque.
I agreed with every single thing you wrote until that last line. In what universe is the ever-changing mess that is the JavaScript ecosystem even remotely comparable to the Python ecosystem?
My understanding is recently Python docs have started to encorporate a little more guidance on handling dependencies in virtualenvs, and some specific suggestions & write up about tools. Which is great.
I think your right that JS probably has a lot more build/compiling/lifting machinery, & is much more confusing. To be fair, it also has a much harder job (since the build-target is only sometimes the local machine).
This episode isn't 100% current, but still relevant and discusses this issue: https://changelog.com/jsparty/137
Over a decade, before all these tooling existed.
> This post feels like a trivialization of how complicated everything is, how complexly interlinked build systems are.
I know build systems can get very complicated, in fact it's part of my point. Which is that considering you already need to set up a build pipeline, adding typescript support is quite simple.
> You know what would be great? If we could just write code. If we didn't have to worry about build pipelines.
But that will not be the case. People are not FTPing their dev folders into prod anymore. Even with this change, you will still need a build pipeline, as everybody already does regardless if they use TS or not.
> JS used to be extremely low cost & light weight to play with, to get started with. It used to be a joy. It still is, but the barrier to entry is much higher, using modules has never been the same dream as slapping some <script src="http://jquery.com/jquery.js"></script>'s down on the page (not a real link) and having it just work. This goal is fulfillent to a noble & excellent intent to once again spark joy.
I disagree with this. That's probably nostalgia talking. Slapping some script URL and editing with Notepad++, having absolutely no IntelliSense, no errors/squiggly lines and having to F5 a browser after every change, trying to hit the code path in question and check the browser console for errors was awful.
Nowadays the editor will tell you what's wrong as you type it, the browser will automatically refresh the code while maintaining state and so on.
I think you conflate the development environment with the hypermedium. You stick lo-fi tools with shame, but you're not actually talking to the language & it's lightweight versaility & hackability. You're not talking to the editability, the malleability, & simplicity of the medium as it was, and which, if we can do just a little bit of healing, can be again.
> Even with this change, you will still need a build pipeline
Will we? Why? I tend to wager a decent static webserver (especially one that has decent cimpression built in) will be a very fine deploy target for many again, soon. ESM, early-hints, http3... it could happen. Yeah we probably should strip comments & these type annotations, but need to? Meh. I think we fret too much about the small stuff & havent spent nearly enough time conisdering incremental loading architectures & better use of service workers. The endless pish for optimizing what we have has been a race of folly ignoring the real peaks around us daring us to be summited.
JS can & should be less build intensive. Non-build module-using js was the high fantasy we were driving for a decade ago, when the idea of modules was new, & it's been slow, but that objective was there for really good & importamt reasons. A js which is naturally accessible, which is evident & real, is good for humanity & how the web reconnects with itself as a hypermedium, as more than just another shitty developer app-dev toolbox for nerds like us. We can be better. We can make the source real again.
Even with http3 and so on, serving node_modules which almost always is 100k+ files would be awful. And of course, yes, you don't need npm. But I don't see people going back to the jquery days of having a single o no dependencies.
I guess the point stands for new people learning web development who are only playing on localhost and don't care yet about having something good enough for prod. But I don't think people who are at that stage should worry about typescript. If they did and didn't want a build pipeline, they would just manually run tsc. Is adding a new feature to JS just so that beginners who want to use TS don't need to run tsc worth it? IMO no.
These hackernews developers always act like it’s the most blissful thing
“If only we could just write JS without running a special transpile command”
That’s actually a much worse developer experience. If you’re using any modern frontend technologies, you’ll want to have a dev server running.
Using hot module replacement at a bare minimum (where your browser updates the screen without doing a page refresh, instantaneously)
Is a much better experience, so you should already be running a dev server anyway if you’re being productive is the point…
It completely ignores what it takes to get started, or how alive & malleable the web is.
The domination of concerns by deeply deeply industrialized ways of thinking holds back the joy of the hypermedium we work. And it truncates human potential. Making code & coding accessible is a virtue. One that could cost us nothing.
> For frontend usually you literally don't configure anything, Next.JS, CRA, or whatever already comes with typescript preconfigured if you select it.
My experience is that this stuff is always on the verge of breaking when you integrate it with some new dependency, when you have needs that are slightly different from the mainstream use-cases that the developers envisioned, or when you start going through and updating your packages.
I’ve been using JavaScript since the dark ages and the only way we can survive is by periodically cutting down some of the built-up complexity. We don’t need to cut it down for everyone, and not all at once, and no change is without its drawbacks. I’ve used create-react-app, I worked at a company that used machine learning in the JS build pipeline to do code splitting, I’ve used vanilla JS, and I’ve written some pretty damn cursed build systems for stuff like JS13K or 1K coding competitions. TypeScript sticks out as a rough spot in most build systems I’ve used, and the reason I still use it (most of the time—not always) is because the typechecking and IDE experience are just so damn good that it justifies the cost.
> It seems quite extreme modifying javascript for this considering you still would want to remove types in order to reduce bundle size, and you would still need the actual compiler because you have things such as enums, annotations and more that JS doesn't support either.
Not every change is applicable to all uses cases for everyone. That’s ok. If you decide to write TypeScript without enums you usually find that you don’t lose that much—it’s easy enough to do something like:
Obviously this is not a one-size-fits-all trick, but I find myself using TypeScript enums less and less these days.There are also some dirtier TS tricks you can which let you create something kind of like Haskell’s newtype—pure type system stuff.
TypeScript used to have more sugar, and that sugar had been removed and merged with the equivalent ES functionalities. Dig through old TS versions and you’ll find obsolete syntaxes or semantics that have been removed.
Just to pick an example, TS had class before JS. IMO the ideal scenario here is that TS is just type annotations on top of JS, and any features you use which aren’t universally available, you polyfill/transpile as a separate step.
This means TS is just types, and your transpired/polyfills are just transpilers/polyfills. To achieve that, TS classes are modified to match JS classes.
My sense is that TS will not add new stuff not in JS any more. It’s simply not a direction TS is going. I also get the sense that enums are a mistake in TS’s design.
TS in some sense is a reaction to the lessons learned from its predecessors, like CoffeeScript.
TS goal IMO should be to offer the best developer experience, while maintaining interoperability with the JS ecosystem. Not just limiting themselves to types.
Why do you think enums are a mistake? Enums allow you to have autogenerated mappings from symbols to integers. You can't do that with types as you showed in your example.
That’s why enum should be avoided in TS or added to JS.
I can understand why people want TS to be a “better” language, but these days, ES is pretty good and a major part of TS’s success is that it follows JS semantics almost everywhere.
Not languages that can interoperate with JS the way TS does (except for flow and similar type checkers).
TS success is that it's a superset of JS (unlike say CoffeScript). So you can throw some JS and it will be valid TS. The point of being a superset is that you can add new stuff. Types, enums, annotations.
So the only argument why enums are bad except for that it's not in JS? Why does it matter, just because a JS developer has to learn more things if they switch to TS? The whole argument hinges on the premise that TS should not add anything that JS doesn't have except for types, but why is that?
Really the only reason to do pre-processing is if you want to do some optimization beyond what the browser can do, or if you want to write a syntax which is not supported by your target runtimes. And for many developers (including most library authors) this is not the case.
It's really hard to guarantee a world where my complete dependency tree meets my target runtime requirements (eg: I might also not be using nodejs-style require, but my dependencies could be), so pre-processing seems like something that will be with us for some time.
ESM imports are the standard, unlike Node’s require. And you can now write ESM code that’ll run flawlessly on the backend and the front end without any transpiration. IMO that’s huge. Type annotations remove yet another blocker.
As pointed out by this proposal the JSDoc annotations are—to put it mildly—a bit cumbersome. The more complicated types are close to impossible to figure out how to write, if they are possible to write at all. And on Q&A forums I constantly have to translate between the two syntaxes in my head, since most of the audience will probably not understand the JSDoc syntax.
Having a unified type annotation syntax which the runtime ignores will definitely make my life easier.
https://news.ycombinator.com/hidden
when logged in
Its even like "functional", you can turn it on or off at will, it can even do regular expression tests to validate string parameters.
I partially copied it for Javascript, https://www.npmjs.com/package/type-czech, it even runs in JsFiddle https://jsfiddle.net/steen_hansen/1Lshcept/?Example-Contents
> The proposal here differs significantly from Python's types, as the types in this proposal are entirely ignored, not evaluated as expressions or accessible at runtime as metadata.
So guess sorta prior art but quite different.
Reading the TC39 minutes for this proposal makes me think it’s highly unlikely that the approach as outlined here will go anywhere.
We’re conditioned to expect there will be a compilation step between our source code and the code that runs in a browser. That forces many decisions about how we structure our projects and the kinds of tools we can use to deliver the software we write. Minimizing or eliminating the reasons why folks might need that build-the-code step between the code they write and the code their users run opens up doors and new ways of writing and delivering software, and that’s exciting!
Think, for instance, what would it take to get something like the TypeScript type checker in Chrome’s devtools? A first step would be to adopt the type annotation syntax.
not sure what typechecking inside chrome would add....
maybe it could be used for faster js execution like how asm.js works
It’s true that there are some optimizations done in the build step that benefit end users, and folks will probably (correctly) continue to choose to minify, tree shake, bundle + bundle split, eliminate dead code, etc. for serious applications.
But to be able to write a modern web app without having to npm install a single module would be stellar! And it’s becoming more and more possible. How do you teach someone how to write a JS project in 2022? I imagine it starts with, “Well, first you’ll need to install node and npm - that’s gonna run JavaScript on your computer but don’t mind that much for now. Now we’ll install some dependencies required to build your code…” and so on. It takes a while and many conceptual hurdles to get to the part where someone can run the code they wrote in a browser.
85% of the typescript libraries I have run into output either old CommonJS or es2015. There's other changes too often.
But I like it for another reason. The single most frustrating thing for me in JS is the lack of operator overloading. Matrix operations become so ugly if you can't use infix operators. If you do complex graphical calculations it is really important that the calculations remain readable.
Custom operators and operator overloading require type-dependent dispatch. The types could be known at compile time in TS. But the developers will not add any such feature, unless JS has it. One of a few prerequisites seems to be that JS gets type annotations!
But honestly it seems I would have to wait until JS becomes TS, before we can overload operators. Maybe it is more realistic to add this via babel or so.
It would greatly reduce the need of those crazy building tools nowadays. Now we have HTTP2, if only we can write and serve a bunch of TypeScript files directly. Be it browser, Node.js or Deno, you could use the same script file without setting up M*N different webpack.whatever.config.js files.
And it will also open up the possibility of optional runtime type checking which JavaScript as a glue language really needs.
TypeScript has been very cautious about adding non-JavaScript features, and kept its promise on JavaScript compatible, so I don't see big problems merging them. It's just people will need to figure out a spec to formalize the type system for TypeScript.
The only risk is there might be clash of the communities. But it also might get us great results where the whole community working on a great project together.