I fully remember picking up coffeescript because Dropbox had used it. I only ever used it on one project. I try and remember that every time I have the urge to go with Reason, Elm or even wasm compiling things. Long live JS.
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!
Alas, this requires training of the road not taken.
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.
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.
“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.
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.
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”
I doubt it, because HOFs are hip in React-land right now and I don't really give a shit, personally, so I usually do whatever my team-mates find idiomatic in their current coding style and preferences, which means implementing and using HOFs, for now. Plus React picked "awkwardly add state and object-like functionality to functions by partially re-implementing objects" over "use built-in object system better, but tie react more strongly to OO-style programming" when they realized they had to pick one or the other to fix some problems, so React's even more functional now than it was before and is only heading farther that way as their chosen way forward continues to accrue functionality that OO-style React doesn't have.
Regardless, I haven't found TS to impede the writing of HOFs, and certainly not the use of them. I've been favoring them for a while even server-side just because it's "the thing to do" and other JS devs are familiar and comfortable with them these days and, again, I don't really care one way or the other. If I find myself on a team that prefers classes and objects, I'll use those instead in places where either would do.
Anyway, I'm more of a composition than inheritance guy when writing OO code. And I'd be more likely to define an interface than an abstract class. Not that I'd never, ever use the latter, it's just not something I reach for very often, especially in TypeScript.
[EDIT] actually, TS is part of why I no longer have significant preferences for how I write Javascript. Before, the only Javascript style I found not to be hair-pulling-out stressful and unproductive was about as C-like as possible, favoring a procedural style and aiming for zero indirection or "cuteness". Of course this was a popular JS style approximately no-where so this translated to my hating Javascript. TypeScript saves me from having to care. I'll write whatever, just give me types so I don't have to go read (or, god forbid, execute and poke around in) your code to figure out WTF you're doing even at the most fundamental level.
Edit: Found the 2012 post, pretty useful for doing a postmortem https://dropbox.tech/application/dropbox-dives-into-coffeesc...
It wasn't until 2015 that es6 came around, and we saw how things could be better; and typescript didn't have much momentum until 2015 either. Without a crystal ball, it'd have been very hard to predict this shift.
ReasonML is used by Facebook. Elm used to get more attention on HN.