4 ms·

"Modern" Javascript essentially is Typescript without the type hints (e.g. if you ignore the historical baggage, JS is actually a fairly decent language).

junon 3y ago
I actually argue JS was a better language before all of the changes made, starting with const/let. The only thing I'd say makes sense are classes but the fact they aren't syntax sugar over prototypes was a mistake. People wanted a different language, they should have gotten more scripting languages in the browser. Not changing JavaScript so much that it's no longer JavaScript.
- flohofwoe 3y ago
  Coming into web development fairly recently (after 2013 or so) from the statically typed hemisphere and without closely following the Javascript history from the start I naturally cannot agree ;) (things like the scoping rules for 'var' is just bizarre, same with the concept of 'prototypes') Looking at typical "old-school" Javascript code gives me the creeps the same way as looking at K&R C code ;)
- baq 3y ago
  you can still write the old javascript. it'll feel very lonely, though.
- shrimpx 3y ago
  > aren't syntax sugar They aren't syntactic sugar? Pretty sure `class Foo { blah() {} }` is equivalent to `function Foo() {}; Foo.prototype.blah = function() {}`.
  - bornfreddy 3y ago
    > the fact they aren't syntax sugar over prototypes was a mistake Totally different meaning.
    - shrimpx 3y ago
      What else would 'syntax sugar over prototypes' mean?
  - zdragnar 3y ago
    There are a few very specific differences. In a subclass, 'this' doesn't exist until you call "super" for example, and the constructor will throw an error of invoked without the "new" keyword. [O] These differences let you extend built-in things that simply can't be done with old prototype constructor syntax. [1] [O] I should probably be using a more recent reference like MDN, but the 2ality series always sticks out in my mind whenever "just syntax sugar" comes up: https://2ality.com/2015/02/es6-classes-final.html#safety-checks https://2ality.com/2015/02/es6-classes-final.html#safety-che... [1] https://2ality.com/2015/02/es6-classes-final.html#subclassing-built-in-constructors https://2ality.com/2015/02/es6-classes-final.html#subclassin...
    - shrimpx 3y ago
      Thanks. It sounds like subclassing built-ins is where transpilers hit a hard wall. Other syntactic features of es6 can be transpiled.
      - zdragnar 3y ago
        http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/ This page lists features from es6 (and newer versions linked at the top) along with compliance to the spec. First column is the current browser, second is babel+corejs polyfills. Overall, babel gets about 70% of the way there.
  - cxr 3y ago
    The result of `let x = Foo()` when Foo is defined as a function is whatever Foo's return value is. Trying `let y = Foo()` when Foo is defined as a class throws a TypeError.
  - junon 3y ago
    They are not, no.
    - shrimpx 3y ago
      My example is incorrect because it doesn’t cover all the edge cases but you can desugar es6 to es5, except in es5 you can’t subclass builtins.
usrusr 3y ago
Yeah, having just jumped into ts after a long js hiatus since back when The Good Parts was still surprising, it's quite awesome to see how much of what I assumed to be "ts stuff" is actually just postdeluvian js. Makes ts more attractive, not less. I do wonder however of it was possible to identify parts of that language superset that are fully redundant (as in not even required for exotic edge cases) and let loose some draconian linter?
- jakubmazanec 3y ago
  You already can kinda do that using ESLint and rules like https://eslint.org/docs/latest/rules/no-restricted-syntax https://eslint.org/docs/latest/rules/no-restricted-syntax, https://eslint.org/docs/latest/rules/no-restricted-properties https://eslint.org/docs/latest/rules/no-restricted-propertie... or https://eslint.org/docs/latest/rules/no-restricted-imports https://eslint.org/docs/latest/rules/no-restricted-imports.
  - usrusr 3y ago
    Sure, but that's still seems quite mix and match, anything goes, choose your own adventure. There are many positives about this approach, but as a learner a little more common ground between codebases would certainly be appreciated.
    - jakubmazanec 3y ago
      True. I always thought that we should have additional mode stricter than https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe....

junon 3y ago

I actually argue JS was a better language before all of the changes made, starting with const/let. The only thing I'd say makes sense are classes but the fact they aren't syntax sugar over prototypes was a mistake. People wanted a different language, they should have gotten more scripting languages in the browser. Not changing JavaScript so much that it's no longer JavaScript.

flohofwoe 3y ago
Coming into web development fairly recently (after 2013 or so) from the statically typed hemisphere and without closely following the Javascript history from the start I naturally cannot agree ;) (things like the scoping rules for 'var' is just bizarre, same with the concept of 'prototypes') Looking at typical "old-school" Javascript code gives me the creeps the same way as looking at K&R C code ;)
baq 3y ago
you can still write the old javascript. it'll feel very lonely, though.
shrimpx 3y ago
> aren't syntax sugar They aren't syntactic sugar? Pretty sure `class Foo { blah() {} }` is equivalent to `function Foo() {}; Foo.prototype.blah = function() {}`.
- bornfreddy 3y ago
  > the fact they aren't syntax sugar over prototypes was a mistake Totally different meaning.
  - shrimpx 3y ago
    What else would 'syntax sugar over prototypes' mean?
- zdragnar 3y ago
  There are a few very specific differences. In a subclass, 'this' doesn't exist until you call "super" for example, and the constructor will throw an error of invoked without the "new" keyword. [O] These differences let you extend built-in things that simply can't be done with old prototype constructor syntax. [1] [O] I should probably be using a more recent reference like MDN, but the 2ality series always sticks out in my mind whenever "just syntax sugar" comes up: https://2ality.com/2015/02/es6-classes-final.html#safety-checks https://2ality.com/2015/02/es6-classes-final.html#safety-che... [1] https://2ality.com/2015/02/es6-classes-final.html#subclassing-built-in-constructors https://2ality.com/2015/02/es6-classes-final.html#subclassin...
  - shrimpx 3y ago
    Thanks. It sounds like subclassing built-ins is where transpilers hit a hard wall. Other syntactic features of es6 can be transpiled.
    - zdragnar 3y ago
      http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/ This page lists features from es6 (and newer versions linked at the top) along with compliance to the spec. First column is the current browser, second is babel+corejs polyfills. Overall, babel gets about 70% of the way there.
- cxr 3y ago
  The result of `let x = Foo()` when Foo is defined as a function is whatever Foo's return value is. Trying `let y = Foo()` when Foo is defined as a class throws a TypeError.
- junon 3y ago
  They are not, no.
  - shrimpx 3y ago
    My example is incorrect because it doesn’t cover all the edge cases but you can desugar es6 to es5, except in es5 you can’t subclass builtins.

usrusr 3y ago

Yeah, having just jumped into ts after a long js hiatus since back when The Good Parts was still surprising, it's quite awesome to see how much of what I assumed to be "ts stuff" is actually just postdeluvian js. Makes ts more attractive, not less. I do wonder however of it was possible to identify parts of that language superset that are fully redundant (as in not even required for exotic edge cases) and let loose some draconian linter?

jakubmazanec 3y ago
You already can kinda do that using ESLint and rules like https://eslint.org/docs/latest/rules/no-restricted-syntax https://eslint.org/docs/latest/rules/no-restricted-syntax, https://eslint.org/docs/latest/rules/no-restricted-properties https://eslint.org/docs/latest/rules/no-restricted-propertie... or https://eslint.org/docs/latest/rules/no-restricted-imports https://eslint.org/docs/latest/rules/no-restricted-imports.
- usrusr 3y ago
  Sure, but that's still seems quite mix and match, anything goes, choose your own adventure. There are many positives about this approach, but as a learner a little more common ground between codebases would certainly be appreciated.
  - jakubmazanec 3y ago
    True. I always thought that we should have additional mode stricter than https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe....