6 ms·

JS is going to be so different in 2019 that I'm expecting a revised version of "The Good Parts"[1] [1] https://www.amazon.com/JavaScript-Good-Parts-Douglas-Cro

JS is going to be so different in 2019 that I'm expecting a revised version of "The Good Parts"[1] [1] https://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742 https://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfo...

eropple 7y ago
That book is of an era and hasn't been particularly relevant in quite awhile. The rise of classes as prototype sugar made a lot of the navel-gazing of object creation mostly moot. The rise of rigorous linting took care of the rest. TypeScript helped a lot, too.
- Roboprog 7y ago
  Some of us consider “class” a bad thing. I would rather work in a language/style that draws its inspiration from Scheme than Simula 67. Too bad more places are picking up TypeScript rather than ClosureScript.
  - orangecat 7y ago
    I would rather work in a language/style that draws its inspiration from Scheme than Simula 67. Then you should push for WebAssembly improvements so you can use whatever language you want. As long as JavaScript is a de facto requirement for web development it needs to be as approachable as possible to a wide developer audience, and that means looking more like Java than Lisp.
    - BigJono 7y ago
      Or we could've considered it an opportunity to move people away from classical inheritance and towards something that's conceptually much simpler? (which both prototypal inheritance and functional programming are)
      - pjmlp 7y ago
        Yet all successful functional programming languages do support doing OOP as well.
      - boomlinde 7y ago
        JS is and always was prototype based. The class keyword is as far as I know just syntax sugar that creates a prototype chain and a new-able function that assigns the prototype to self.
        jwalton 7y ago
        The '#privateVar' syntax means that classes are no longer simply syntax sugar, unfortunately.
        eropple 7y ago
        Private variables could always be simulated with IIFEs. I'm pretty sure that's actually how TypeScript does it if you compile down low enough.
    - jcadam 7y ago
      > and that means looking more like Java than Lisp. No. (No (No (No (No (No)))))
  - nine_k 7y ago
    Classes are fine! Inheritance isn't. You can mostly avoid using it, though. JS lacks homoiconicity and thus can't have a lot of nice things a Lisp dialect would, notably macros. With what we've got, I have more hope on JS eventually migrating towards a (more) statically typed language with ML influence; typescript sort of leans towards it, slowly.
    - sli 7y ago
      You're right about Lisp features, but CLJS macros are kind of bad at the moment. I have a fairly simple macro that works just fine in Clojure but does not compile in ClojureScript and I can't figure out why. It's probably a side-effect of how macros are handled in CLJS (they're part of a different compilation stage and must be written in CLJ or CLJC, hence :require-macros instead of just :require). If you're looking for an ML, check out ReasonML. It's really quite good, its output is quite good (and hotfix friendly), and its type system is far better than TypeScript's will ever be. Mostly because TS wants to stay close to JS. Too close, in my opinion.
  - eropple 7y ago
    You can consider it a bad thing, but 1) it's a really thin layer on top of prototypical inheritance, 2) it makes JavaScript more accessible to people who are used to conventional styles of language, and 3) it won, indisputably. ClojureScript didn't win, and never had a chance to win, because it's written for the small minority of Clojure people. It wasn't written for the overwhelming majority of developers. TypeScript was. So sorry that the existence of those day-to-day programmers puts a crimp in your utopia, but, enh. Personally, I'm glad we have tools to make it easier to write libraries to help that majority be more productive and to make their code safer and more correct!
  - sli 7y ago
    It really is a shame because ClojureScript is an absolute joy to work with. TypeScript and Javascript feel so incredibly tedious to write after using CLJS for a few months. I would really love to move into PureScript as well, but I haven't quite wrapped my arms around Haskell as a whole, yet. So maybe I should tip my toes back into Elm for a bit.
- jcadam 7y ago
  I do not use the 'class' keyword in Javascript and I never will. I mean, I don't like using it in Java either, but it isn't really optional there...
  - stevula 7y ago
    Not optional for React devs. Well... maybe now with hooks.

eropple 7y ago

That book is of an era and hasn't been particularly relevant in quite awhile. The rise of classes as prototype sugar made a lot of the navel-gazing of object creation mostly moot. The rise of rigorous linting took care of the rest. TypeScript helped a lot, too.

Roboprog 7y ago
Some of us consider “class” a bad thing. I would rather work in a language/style that draws its inspiration from Scheme than Simula 67. Too bad more places are picking up TypeScript rather than ClosureScript.
- orangecat 7y ago
  I would rather work in a language/style that draws its inspiration from Scheme than Simula 67. Then you should push for WebAssembly improvements so you can use whatever language you want. As long as JavaScript is a de facto requirement for web development it needs to be as approachable as possible to a wide developer audience, and that means looking more like Java than Lisp.
  - BigJono 7y ago
    Or we could've considered it an opportunity to move people away from classical inheritance and towards something that's conceptually much simpler? (which both prototypal inheritance and functional programming are)
    - pjmlp 7y ago
      Yet all successful functional programming languages do support doing OOP as well.
    - boomlinde 7y ago
      JS is and always was prototype based. The class keyword is as far as I know just syntax sugar that creates a prototype chain and a new-able function that assigns the prototype to self.
      - jwalton 7y ago
        The '#privateVar' syntax means that classes are no longer simply syntax sugar, unfortunately.
        eropple 7y ago
        Private variables could always be simulated with IIFEs. I'm pretty sure that's actually how TypeScript does it if you compile down low enough.
  - jcadam 7y ago
    > and that means looking more like Java than Lisp. No. (No (No (No (No (No)))))
- nine_k 7y ago
  Classes are fine! Inheritance isn't. You can mostly avoid using it, though. JS lacks homoiconicity and thus can't have a lot of nice things a Lisp dialect would, notably macros. With what we've got, I have more hope on JS eventually migrating towards a (more) statically typed language with ML influence; typescript sort of leans towards it, slowly.
  - sli 7y ago
    You're right about Lisp features, but CLJS macros are kind of bad at the moment. I have a fairly simple macro that works just fine in Clojure but does not compile in ClojureScript and I can't figure out why. It's probably a side-effect of how macros are handled in CLJS (they're part of a different compilation stage and must be written in CLJ or CLJC, hence :require-macros instead of just :require). If you're looking for an ML, check out ReasonML. It's really quite good, its output is quite good (and hotfix friendly), and its type system is far better than TypeScript's will ever be. Mostly because TS wants to stay close to JS. Too close, in my opinion.
- eropple 7y ago
  You can consider it a bad thing, but 1) it's a really thin layer on top of prototypical inheritance, 2) it makes JavaScript more accessible to people who are used to conventional styles of language, and 3) it won, indisputably. ClojureScript didn't win, and never had a chance to win, because it's written for the small minority of Clojure people. It wasn't written for the overwhelming majority of developers. TypeScript was. So sorry that the existence of those day-to-day programmers puts a crimp in your utopia, but, enh. Personally, I'm glad we have tools to make it easier to write libraries to help that majority be more productive and to make their code safer and more correct!
- sli 7y ago
  It really is a shame because ClojureScript is an absolute joy to work with. TypeScript and Javascript feel so incredibly tedious to write after using CLJS for a few months. I would really love to move into PureScript as well, but I haven't quite wrapped my arms around Haskell as a whole, yet. So maybe I should tip my toes back into Elm for a bit.
jcadam 7y ago
I do not use the 'class' keyword in Javascript and I never will. I mean, I don't like using it in Java either, but it isn't really optional there...
- stevula 7y ago
  Not optional for React devs. Well... maybe now with hooks.