4 ms·

I think it's interesting how JavaScript has gone full circle on classes. At one point a decade or so ago, classes became vilified as substandard syntactic sugar

I think it's interesting how JavaScript has gone full circle on classes. At one point a decade or so ago, classes became vilified as substandard syntactic sugar on functions. That combined with a surging interest in pure functional programming lead to devs using functions for everything and libraries like underscore to assist. Just five years ago, React added hooks as a way to avoid classes all together. Now classes have been super-charged in the latest JavaScript proposed standards, with the addition of syntax for private and static variables, getters and setters, accessors, decorators and more. All of which are either in engines already, soon will be, or adopted by TypeScript or other precompilers. I think it's interesting because TC39 decorators which Lit is now using aren't usable with functions yet, only classes and class methods. The standards groups seem to be at odds with the general JavaScript community consensus on dev patterns. But with classes becoming so much more central to how JS is structured, I guess we're going to see a lot more class-centric JavaScript. Which is OK, I guess. I just hope it doesn't turn into Java.

claytongulick 3y ago
I like a lot of the concepts of FP, but once you get past the "new shiny" aspect of it and start writing applications, the warts start to show. It's really like anything - extreme/purist FP can have terrible application performance with limited benefit. Same with extreme/purist OOP. JS classes hit a sweet spot for me. They are minimalist, composable, easy to duck-type, and are basically just a convenient unit of code organization more than anything. I never really jumped on the "pure fp" bandwagon. It gave birth to monstrosities like RxJs - which some people actually use, and I don't understand how or why. Same for me with React - class based components are a lot less magical than all the useEffect and use* stuff. They're easy to reason about, and self-contained. I never really understood the drive for "pure functional components". There's so much cruft and artifacts that arise from that, it interferes with application feature deliver and performance. You end up spending your days doing crazy Redux or RxJs like things, increase complexity by an order of magnitude, all for very limited actual benefit (like theoretical time rewinding during debugging - which I have never actually had a need for).

claytongulick 3y ago

I like a lot of the concepts of FP, but once you get past the "new shiny" aspect of it and start writing applications, the warts start to show. It's really like anything - extreme/purist FP can have terrible application performance with limited benefit. Same with extreme/purist OOP. JS classes hit a sweet spot for me. They are minimalist, composable, easy to duck-type, and are basically just a convenient unit of code organization more than anything. I never really jumped on the "pure fp" bandwagon. It gave birth to monstrosities like RxJs - which some people actually use, and I don't understand how or why. Same for me with React - class based components are a lot less magical than all the useEffect and use* stuff. They're easy to reason about, and self-contained. I never really understood the drive for "pure functional components". There's so much cruft and artifacts that arise from that, it interferes with application feature deliver and performance. You end up spending your days doing crazy Redux or RxJs like things, increase complexity by an order of magnitude, all for very limited actual benefit (like theoretical time rewinding during debugging - which I have never actually had a need for).