Classes Are Making Me Sad
gist.github.com
gist.github.com
To create a bit to the discussion, I feel like the class abstraction in ES2015 is mostly a mask that doesn't do people any favors - it makes one think they know what is happening but leads experienced programmers to false reasoning and much head banging. I've highly preferred a more functional style for most of my projects and teams - I wish there were better standard tools for enforcing style, as organizationally it's harder to get everyone on the same page than with more mature OOP tooling (which OOP patterns/strong typing makes easier to build).
Sure, there is some other wonky stuff, but the ease with which one can write bad javascript is the core issue.
I agree completely.
When I first read the ES2015 draft, I was excited to see the class syntax. I assumed that it meant that JS was getting "traditional" inheritance, and it seems like a lot of others did too. That illusion was shattered shortly after beginning to use it.
Now, instead of thinking "Hey, these weird objects that I barely understand how I created don't behave as I expect! Javascript is different.", I think a lot of less experienced developers end up thinking "Hey, these objects don't behave as I expect. Javascript sucks."
They had to add scripting capabilities, and be first at it (else MS would be the first). They had to make the language instantly understandable by an average programmer — that is, someone who has a Basic / Pascal / C / Java / Perl background, and an hour of time to get acquainted and like the language.
So they created a scripting language with a familiar C-like syntax, very few restraints, and a bunch of "convenient" magic that helped a person to create a simple animation in the browser on their very first day, by mashing things together.
This was a terrible strategy to create a nice language for safe and comfortable development of large applications, especially full desktop applications 20 years from the inception date.
It was a very well-working strategy to get mass adoption in no time, and own the market the same year in the face of mighty competition. This is what business cared about, and this allowed Netscape to stay successful for a few more years.
Alas.
Now we have WebAssembly (which resembles a stripped-down JVM from 25 years ago), and soon will be able to efficiently compile our favorite "real" language to run in the browser not through JavaScript.
https://news.ycombinator.com/item?id=9098367
Eich> I joined Netscape on April 4, 1995, to "do Scheme in the browser". Immediately I was out of luck on several fronts:
Eich> [...]
Eich> If there was to be a "scripting language", it had to look like Java.
https://news.ycombinator.com/item?id=2786720
Eich> Remember, I was recruited to "do Scheme", which felt like bait and switch in light of the Java deal brewing by the time I joined Netscape.
The thing I like about classes is I vaguely understand what is going on and why, coming from Java and similar. So I am using them, together with Flow typechecking.
I am not saying the javascript prototype logic is bad, just that I never understood it, even when I work in Javascript for years.
Sometimes I understand, for a brief moment, "how", but never "why".
More to the point, what is the reason for prototype-based inheritance, what is its benefit, what more can you do with it than with C++/java, where does it make life easier.
Edit: Funny to see someone else post a link to the same book at the same time :)
But by using classes, you're still using prototypes, it just isn't as immediately apparent.
(Of course, the details of how the feature is designed determine how leaky the abstraction is and how often you actually get the luxury of not thinking about the machinery.)
With that knowledge in hand, it immediately becomes obvious that:
bar.baz = function(){console.log(this.X)}
var foo = bar.baz;
foo();
But really, understanding that behind the scenes, member function calls change:
A.B(C)
into
B(A, C)
Whenever I need to export class function, I do
var foo = () => bar.baz()
Also with the ... notation, I stopped worrying about .call and .apply. So I can write
var someArray = [a,b,c]
var foo = () => bar.baz(...someArray)
Prototypes, constructors, and context are not that complicated; I encourage you to keep reading and trying things. You may be surprised how quickly you end up "getting" it.
> The thing I like about classes is I vaguely understand what is going on and why, coming from Java and similar.
No. The class keyword in JS is syntactic sugar around the same prototype stuff that already existed. It does not work like it does in Java, and you will not understand what it's doing unless you understand how the class keyword translates directly into manipulating the prototype chain.
Which, as above, is easy! But if there's one actual problem with the class keyword it's that it makes people who know Java think they understand JS inheritance.
The class keyword DOES NOT CHANGE YOUR CODE. If you didn't understand what was going on before you used the class keyword, you don't understand it after adding it in. (Conversely, if you actually do understand how the class keyword works, then rejoice, you now understand how prototypes work...)
Which is totally fine, as for all intends and purposes the behavior is the same. You create new instances, and you call methods on them.
The "movable" context (this) will be a little surprising, but for everything else one can write JS for decades with ES6 classes and "OOP", without having to know how the prototypes, objects and functions they de-sugar to work.
Nope :) They're apparently the same, which is not the same as "the same".
> The "movable" context (this) will be a little surprising, but for everything else one can write JS for decades with ES6 classes and "OOP", without having to know how the prototypes, objects and functions they de-sugar to work.
That's just the thing though - there isn't a "movable context", there is only binding. Binding usually happens implicitly, and most of the time things are implicitly bound to what you expect them to be if you're not aware it's happening.
... then comes the moment that you're in an instance's method, and `this` is pointing to an event instead of the object. Oh, boy.
In my experience that moment comes much more often than once every few decades.
- 'this' is based on how you call something, not what it is attached to. It's possible to have a.fn and b.fn be the same function with 'this' referring to each object in turn when you call a.fn() and b.fn().
- Function.bind muddies the waters a little bit, but basically that creates a wrapper that forces 'this' to a particular object.
- a 'class' in js is a function with a prototype property pointing to a parent object / parent class instance (not a class)
- new fn() creates an object, assigns the prototype, and runs fn.call(obj)
- obj.prop walks the chain of prototypes attached to obj until it finds 'prop' on one of the instances
As to the why, the idea is that the core object is the function, not the class, and prototypes are a way of conveniently determining the context a function is executed in. There is no such thing as a class in js, only a class-like syntax to wrangle functions and objects.
Also, what is the reason for the prototype style inheritance? What is the benefit? Why use it over "classic", java-style OOP?
Off the top of my head, arrow functions come in handy when you're defining an "instance method" that you want to use as an event handler; you want `this` to refer to the instance, not the event. That's 95% of the time you'd use an explicit call to `bind` anyhow.
Another case to use `bind` would be a generic function that isn't specific to the type of object you're acting upon. I wrote up a short example on jsfiddle: https://jsfiddle.net/LyndsySimon/5zqtjd82/
You can also use binding to create decorators that work on instance methods: https://jsfiddle.net/LyndsySimon/n57or0u5/
If you don't understand prototypal inheritance in ES5, you don't use it, and you stick with simpler concepts that work in a clean and elegant way that doesn't depend on OO-like trappings cluttering up your code unnecessarily.
But with that "class" keyword sitting there, it looks vaguely familiar enough, and you just start programming as if it were Java, and your code turns into this complex morass without you even realizing it until the pain starts.
Which is not new with Javascript in general. every single feature in javascript suffers from being strangely familiar while having a behavior specific to Javascript. Comparison operators, var declaration hoisting,function declaration hoisting, "this", "typeof" operators,type equality and coercion rules, and co, all require to actually learn how the language works. This isn't a very good argument against the class keyword. Yes, developers who use a language need to learn it before hand. It applies to all languages.
typeof (class {}) === "function"
I can already see that a big part of the appeal for classes is that they keep your code looking neat and succinct (as opposed to throwing .prototype and Object.create all over the place.
I'd much rather be writing code that looked something like the below, than having to think about super, static, own properties, constructors, private fields etc.
// provided by some view library
let Component = {
state: null,
setState(state) {
Object.assign(this.state, state);
this.forceUpdate();
}
// ...
}
let Counter is Component {
get state() {
return { count: 0 };
},
inc() {
let { count } = this.state;
let { step } = this.props;
this.setState({ count: count + step });
},
render() {
let { count } = this.state;
return <button onClick={this.inc}>{count}</button>;
}
}
render(<Counter step={2} />);
// let Counter is Component
let Counter = Object.create(Component);
I used Coffeescript classes in the old jQuery/Backbone days and they were useful only because the rest of the ecosystem was so terrible.
You can't NOT use classes if you use React. [Edit: For components with state] your syntax choices are:
Foo = React.createClass({})
class Foo extends React.Component {}
Edit: Fixed silly error; obviously you can use stateless functional components and I do all the time, but you can't avoid classes with React.
function Welcome(props) {
return <h1>Hello, {props.name}</h1>;
}
const Welcome = ({ name }) => (
<h1>Hello, {name}</h1>
)
const Foo = props => <div {...props}/>
For anyone convinced they hate JS, I encourage looking through Crockford's JavaScript: The Good Parts, in which he talks about the idea mentioned above, before swearing off JS forever.
Prototypical languages are a subset of OO languages, despite the fact the the industrial popularity of a handful of class-based OO languages (especially C++ and it's descendants) starting in the late 1980s have made it so that many people confuse OO with specifically class-based OO.
Only later when Self came out was the term broadened to include languages oriented around objects without classes.
Sure, we need to be more precise today and refer to "class-based object-oriented" and "prototypal object-oriented", but that's not a fault of the class-based languages. They laid claim to the general term first.
Before horseless carriages, all carriages had horses, so it seems unreasonable to expect people to have presciently called them "horseful carriages" even before automobiles were invented.
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."
Simula has classes, but Alan Kay's "object oriented" wasn't about classes at all.
Both Python and Ruby classes are implemented using prototypes. It doesn't make these languages less object oriented.
Prototypes are an implementation detail, they have a single goal: inheritance thanks to the prototype chain.
The fact is, objects are constructs that carry both behavior and state, in that sense JavaScript is capable of object oriented programming. And it has first class functions, which makes possible implementing some functional programming patterns.
Therefore
> JavaScript is not an object-oriented language
is a false statement.
We fix equality by using === instead of ==. == is so bad that it is not transitive if a==b && b==c you are not sure c==a
And everytime we use <, <=, >, >=, cmp we are back at using == implicitly, which triggers so many problems and bugs (and sort relies on them, thus sort is also broken).
If a language cannot do simple math correctly, it should never be used for stuffs related to commercial transactions or security... anything serious.
And they are in the spec. It's too late to be sad about that, people are going to use them and they should.
PS: This comment does not intend to be productive in any way.
There's no straightforward way to make nested record updates. You have to write separate setter functions for every step of the way.
If you don't list every single mutation in a single type, and have a single update function to handle them all, you're in for an exhorbitant amount of boilerplate to wire it all. Long, single file types and functions with Objective-C style namespacing are idiomatic.
All is good error wise, until you have to use the escape hatch to JavaScript, in which case good luck building a separate castle of abstractions to fit both of them together and debug it.
There's also the fact that the language creator has to bless a set of bindings before they're allowed to be packaged and uploaded. I do not know how this works out in practice, but it certainly made me raise my eyebrows and not in a good way.
In summary: It's a promising language, but using it to build large codebases either involves techniques the community doesn't know about or it's an exercise in masochism. Maybe in a few years it'll be good.
I might take a deeper look at it later, however. But I'm not interested in making a web application if I can't train a JavaScript programmer to be productive with it in a week. Elm did give me that, and I get the impression PureScript doesn't.
A pattern for this kind of thing in Haskell is Lenses/Prisms: http://adit.io/posts/2013-07-22-lenses-in-pictures.html
I'm going to give it another full week before going one way or the other.
Classes and objects are 100x better than the crap they've come up with to fix JS so far so stop complaining.
Oh no it's not functional???!!! Javascript never was. It was always supposed to be an OO language the implementation is just shit. For the love of God everyone just shut up and let them fix it. Trying to change JS from what it was meant to be into something else entirely is just going to make things even worse