4 ms·

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 j

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.

lstamour 4y ago
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.
- asddubs 4y ago
  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?
  - klodolph 4y ago
    Wouldn’t we remove comments from the language by that reasoning? Comments also do nothing.
    - krapp 4y ago
      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: function foo(bar /*TS:int*/, baz /*TS:int*/)
      - lstamour 4y ago
        Great. Now you’re reinventing JSDoc which is demoed here: https://code.visualstudio.com/docs/languages/javascript#_type-checking https://code.visualstudio.com/docs/languages/javascript#_typ... 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.
  - lstamour 4y ago
    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?
    - krapp 4y ago
      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.
klodolph 4y ago
> 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. https://auth0.com/blog/the-real-story-behind-es4/ https://auth0.com/blog/the-real-story-behind-es4/
- jmisavage 4y ago
  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.

lstamour 4y ago

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.

asddubs 4y ago
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?
- klodolph 4y ago
  Wouldn’t we remove comments from the language by that reasoning? Comments also do nothing.
  - krapp 4y ago
    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: function foo(bar /*TS:int*/, baz /*TS:int*/)
    - lstamour 4y ago
      Great. Now you’re reinventing JSDoc which is demoed here: https://code.visualstudio.com/docs/languages/javascript#_type-checking https://code.visualstudio.com/docs/languages/javascript#_typ... 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.
- lstamour 4y ago
  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?
  - krapp 4y ago
    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.

klodolph 4y ago

> 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. https://auth0.com/blog/the-real-story-behind-es4/ https://auth0.com/blog/the-real-story-behind-es4/

jmisavage 4y ago
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.