3 ms·

If you are trying to build for a business, or something you yourself will have to maintain for years to come, vanilla JS seems like the way to go. Perhaps Type

If you are trying to build for a business, or something you yourself will have to maintain for years to come, vanilla JS seems like the way to go. Perhaps Typescript isn’t a fad to be abandoned, unlike say GWT, CoffeeScript, et al, but why risk it? Javascript doesn’t feel painful to me like Java does. I don’t have a lot of problems with it that need solving with an alternate front end. Long live JS!

Roboprog 6y ago
Once you stop making hundreds of classes with globally visible names and members, and start using function scope, functional programming, and mostly short lived value objects, much of the OOP induced pain of programming simply goes away. Alas, this requires training of the road not taken.
karatestomp 6y ago
AFAIK TS is pretty committed (at the expense of possibly-useful functionality) to being very, very simple to strip out, leaving vanilla JS in its wake. Unless you're minifying, the compiler output typically looks almost exactly like the well-formatted, sane, and readable JS you'd have written instead. That escape hatch is part of why I've not worried a bit about taking it up. Turning a TS project into a JS project, should you ever need to, is functionality that's essentially built-in, and you do it every time you run "tsc".
- dgoldstein0 6y ago
  Yep, you can turn it into modern JS with something like `tsc --module ESNext --target ESNext`. Part of our pain migrating off Coffeescript was that the compiler converted to ES3, not ES6. Which was fine for the browser, but not great for codebase quality.
- Roboprog 6y ago
  But I don’t write “classes”, and don’t want to be lead down that path. Allegedly TS has a solution for doing partial function application or currying, such as in the Ramda.js library, but the example that was provided to me a few weeks ago looked every bit as clumsy as the angle bracket stew in Java 8. I don’t remember the details, other than “I hope I never have to read that.” PFA is like dependency injection for functions, without needing all the “executioner” class trapping nonsense, and with higher order function composition replacing much of the need for subclasses. I guess deep down in my heart, I know that Typescript is coming to crush any joy out of working with JS. The industry of enterprise design patterns will demand it. Some of you will understand this, but most will probably just hate on the unenlightened developer who must simply be resisting The Future. A “future” inspired by Simula67, with beans replacing copy books, and IoC provided singletons replacing individual .COB programs. Meh. P.S. nothing personal. I’m simply terrified of the perception that TS is an unequivocal boon to programming-kind. It’s not, for all of us.
  - karatestomp 6y ago
    How does TypeScript push one toward classes any more than ES does? Does using typescript keep a person from using ramda? They list typescript typings on the ramda site.
    - Roboprog 6y ago
      https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/ramda/index.d.ts https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast... “Fun” stuff to read. So if I want to write higher order functions, rather than classes / interfaces, I have to write, and worse, READ, mass boiler plate like the stuff in the link. This feels like Java 8, to a large extent: you can use code that calls lambdas (e.g. Stream) but you don’t want to have to wade through such HOF code that has the needed cruft to use the callbacks. So in practice, people won’t create higher order functions and the like, as it becomes too much trouble to read and write.
      - karatestomp 6y ago
        What? Your tools do almost all the reading of types like that. It’s the entire point of using typescript: your tools tell you useful stuff with it. You’d never need to look at that file unless you found a mistake (bug) in the type definitions. Though yes when defining your own functions you might need to take a second to write down what you intend it to do in a machine-readable way, so the next person who uses them can let their tools tell them what you intended, rather than memorized convention or docs or a comment somewhere or (quite often) just reading and experimenting with the code because that info is found no-where else at all. When you’re calling such functions the “cruft” is minimal or totally absent. Definitions are where TS makes you put in a little extra work to get your intentions out of your head and down in the codebase for the benefit of your future self and anyone else who has to try to make sense of it.
        Roboprog 6y ago
        Would I be correct in guessing that you are more likely to write an abstract class in the next month than to write a higher order function? Part of the problem in these discussions is that there are at least 2 populations with vastly different work flows. Which would be less of an issue if I were part of the majority enjoying “mob rule”

Roboprog 6y ago

Once you stop making hundreds of classes with globally visible names and members, and start using function scope, functional programming, and mostly short lived value objects, much of the OOP induced pain of programming simply goes away. Alas, this requires training of the road not taken.

karatestomp 6y ago

AFAIK TS is pretty committed (at the expense of possibly-useful functionality) to being very, very simple to strip out, leaving vanilla JS in its wake. Unless you're minifying, the compiler output typically looks almost exactly like the well-formatted, sane, and readable JS you'd have written instead. That escape hatch is part of why I've not worried a bit about taking it up. Turning a TS project into a JS project, should you ever need to, is functionality that's essentially built-in, and you do it every time you run "tsc".

dgoldstein0 6y ago
Yep, you can turn it into modern JS with something like `tsc --module ESNext --target ESNext`. Part of our pain migrating off Coffeescript was that the compiler converted to ES3, not ES6. Which was fine for the browser, but not great for codebase quality.
Roboprog 6y ago
But I don’t write “classes”, and don’t want to be lead down that path. Allegedly TS has a solution for doing partial function application or currying, such as in the Ramda.js library, but the example that was provided to me a few weeks ago looked every bit as clumsy as the angle bracket stew in Java 8. I don’t remember the details, other than “I hope I never have to read that.” PFA is like dependency injection for functions, without needing all the “executioner” class trapping nonsense, and with higher order function composition replacing much of the need for subclasses. I guess deep down in my heart, I know that Typescript is coming to crush any joy out of working with JS. The industry of enterprise design patterns will demand it. Some of you will understand this, but most will probably just hate on the unenlightened developer who must simply be resisting The Future. A “future” inspired by Simula67, with beans replacing copy books, and IoC provided singletons replacing individual .COB programs. Meh. P.S. nothing personal. I’m simply terrified of the perception that TS is an unequivocal boon to programming-kind. It’s not, for all of us.
- karatestomp 6y ago
  How does TypeScript push one toward classes any more than ES does? Does using typescript keep a person from using ramda? They list typescript typings on the ramda site.
  - Roboprog 6y ago
    https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/ramda/index.d.ts https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast... “Fun” stuff to read. So if I want to write higher order functions, rather than classes / interfaces, I have to write, and worse, READ, mass boiler plate like the stuff in the link. This feels like Java 8, to a large extent: you can use code that calls lambdas (e.g. Stream) but you don’t want to have to wade through such HOF code that has the needed cruft to use the callbacks. So in practice, people won’t create higher order functions and the like, as it becomes too much trouble to read and write.
    - karatestomp 6y ago
      What? Your tools do almost all the reading of types like that. It’s the entire point of using typescript: your tools tell you useful stuff with it. You’d never need to look at that file unless you found a mistake (bug) in the type definitions. Though yes when defining your own functions you might need to take a second to write down what you intend it to do in a machine-readable way, so the next person who uses them can let their tools tell them what you intended, rather than memorized convention or docs or a comment somewhere or (quite often) just reading and experimenting with the code because that info is found no-where else at all. When you’re calling such functions the “cruft” is minimal or totally absent. Definitions are where TS makes you put in a little extra work to get your intentions out of your head and down in the codebase for the benefit of your future self and anyone else who has to try to make sense of it.
      - Roboprog 6y ago
        Would I be correct in guessing that you are more likely to write an abstract class in the next month than to write a higher order function? Part of the problem in these discussions is that there are at least 2 populations with vastly different work flows. Which would be less of an issue if I were part of the majority enjoying “mob rule”