31–40 of 52 posts
I can't remember the last time I even considered using inheritance in javascript ... except to consider it unnecessary and strewn with mines.
Earlier quoted context omitted.
There is no judgment in what I said. DK is a fact of life and we will all experience it at some point. I know I have, and quite badly. I wish when I was younger someone had told me "look, you don't really know what you're talking about, here's how things really work". If no one tells you, how long does it take for you to realize and how much time do you waste thinking you know what you don't know? Again, the author i…
Okay, "You don't know what you're talking about." :) There is a clear judgement on your part. For me my own recent DK-moment was I'm learning a foreign language and in a shop asked for a simple item with a simple phrase, sure I had it right. They had no idea what I meant and I got angry because I thought you were just trolling me. Relating situation to a friend who let me know my accent was just wrong, so hard to und…
>you yourself may be mistaken in your JS criticism
It should be easy to verify I'm not. `__proto__` is indeed bad practice [0] and I'm pretty sure criticism of `var` vs. `let` and `const` is a Google search away. Same idea for the other problems I listed, but the details are besides the point.
>There is a clear judgement on your part
I'm not sure what makes you think there is. It was important to first point out that this contribution to HN is a rather poor one on technical grounds. People might have taken away bad practices from the article. Then, I felt it would also be interesting to share my suspicion about the author's state of mind. This is after all what commentators of all kinds do, from movie critics to sportscasters.
>sharing your own [...] shows you speak from experience, and engages someone emotionally into feeling for you rather than just being defensive
This rings true and I could be a better communicator if I applied this advice. So here goes: this [1] is my most upvoted SO answer that I wrote years ago. The code I suggest is rather bad, as I'm sure any experienced C++ dev would agree, and I find the style pompous. It makes me cringe a little, but that answer also demonstrates an interest in technical topics and an eagerness to share, just like the author's article.
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[1] https://stackoverflow.com/questions/4788965/when-would-anyon...
As someone new to JS, a friend of mine insists that I always use classes and inheritance, and that functional style / composition is bad. However, most of the newer libraries I read through all seem pretty functional, whereas the older ones are full of classes. Personally, I find myself writing everything with factory functions and composition because it feels natural to the way I think about code. Am I wrong, and sh…
I certainly am not opposed to using classes. If the problem begs to be thought of as a noun, then I will reach for a class to represent it. Especially if we have a collection of nouns, which are related.
But in general I prefer to code in verbs, piping data through a series of functions and then mapping over them at last to produce components, for instance.
As someone new to JS, a friend of mine insists that I always use classes and inheritance, and that functional style / composition is bad. However, most of the newer libraries I read through all seem pretty functional, whereas the older ones are full of classes. Personally, I find myself writing everything with factory functions and composition because it feels natural to the way I think about code. Am I wrong, and sh…
Pure functions, polymorphism, inheritance, composition, factory functions, classes... All of those are tools. They have benefits and drawbacks that are circumstantial (they depend on the language, the problem, the time pressure to ship, the skill level of the team, and many more other factors). Extremely successful codebases have been written using almost any combination of those tools. What those codebases have in c…
As someone quite in love with functional programming (background in Haskell and Scala), one thing that seems quite obviously missing here and in my Javascript experience so far is the use of typeclasses as a form of ad-hoc polymorphism. Is there a nice (i.e. not too much boilerplate) way of using them in the land of Javascript/Typescript?
As someone new to JS, a friend of mine insists that I always use classes and inheritance, and that functional style / composition is bad. However, most of the newer libraries I read through all seem pretty functional, whereas the older ones are full of classes. Personally, I find myself writing everything with factory functions and composition because it feels natural to the way I think about code. Am I wrong, and sh…
I can't remember the last time I even considered using inheritance in javascript ... except to consider it unnecessary and strewn with mines.
This seems unlikely. Almost every modern Javascript framework uses it. ie) class MyComponent extends React.Component {}
As someone new to JS, a friend of mine insists that I always use classes and inheritance, and that functional style / composition is bad. However, most of the newer libraries I read through all seem pretty functional, whereas the older ones are full of classes. Personally, I find myself writing everything with factory functions and composition because it feels natural to the way I think about code. Am I wrong, and sh…
With that said, in real-world projects, the bigger problem is to find the "greatest common divider" - which are the most common skillsets people are familiar with and settle with that. For example, in many full-stack projects, people are more familiar with the backend language which is mostly OO, and it might be a good idea to settle with OO style in the front-end as well. If the functional style is desired in the future, make sure to educate everybody, have a plan, set the direction so everybody can head toward it.
Some Scala projects are struggling with this issue. It results in mixed codebases, where OO guys cannot understand half of the codebase, and the functional guys are angry at OO guys who wouldn't learn, while keep introducing new novelty every month. Operating a team is more than technology, a key part is to keep everybody aligned, and make sure everybody was well taught with the knowledge they need.
Earlier quoted context omitted.
This seems unlikely. Almost every modern Javascript framework uses it. ie) class MyComponent extends React.Component {}
Even React is de-emphasizing class inheritance in favor of more function components.
Earlier quoted context omitted.
I'd say that inheritance, with method overriding, is the worst anti-pattern of mainstream OOP, which contains a number of otherwise sound ideas, like encapsulation. I like the Go's approach to that (taken from Oberon), and the Rust's system of traits. In one large codebase I saw there was a rule to make classes either abstract (without implementation of key parts), or final. Everything else is done via interfaces and…
Hooray Traits! Love them, they are even in PHP so I can use them in these older apps I maintain.