4 ms·

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

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.

jmisavage 4y ago
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.
- 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.
deleted 4y ago
[deleted]
rektide 4y ago
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.
- asddubs 4y ago
  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.
  - rektide 4y ago
    as others have stated, the answer seems to be to opt in: "use typechecks" or only warn. i don't think anyone would consider turning it on by default everywhere. this seems like an extreme non-issue.
shadowgovt 4y ago
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?
- asddubs 4y ago
  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.
  - shadowgovt 4y ago
    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.
danuker 4y ago
> Having this would just mean that we will never ever ever get actual static typing in javascript 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/ https://elm-lang.org/
- asddubs 4y ago
  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
  - deleted 4y ago
    [deleted]
h1fra 4y ago
Well a lot of other people want this. And both ideas are not incompatible. If you don't want to this, you can still build your own real types, that's the beauty of JS.
deleted 4y ago
[deleted]
Existenceblinks 4y ago
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.

jmisavage 4y ago

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

deleted 4y ago

[deleted]

rektide 4y ago

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.

asddubs 4y ago
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.
- rektide 4y ago
  as others have stated, the answer seems to be to opt in: "use typechecks" or only warn. i don't think anyone would consider turning it on by default everywhere. this seems like an extreme non-issue.

shadowgovt 4y ago

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?

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

danuker 4y ago

> Having this would just mean that we will never ever ever get actual static typing in javascript 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/ https://elm-lang.org/

asddubs 4y ago
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
- deleted 4y ago
  [deleted]

h1fra 4y ago

Well a lot of other people want this. And both ideas are not incompatible. If you don't want to this, you can still build your own real types, that's the beauty of JS.

deleted 4y ago

[deleted]

Existenceblinks 4y ago

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.