
The Two Pillars of JavaScript: Part 1: How to Escape the 7th Circle of Hell - cpeterso
https://medium.com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3
======
Elrac
Elliott certainly knows a lot about programming JavaScript, but reading his
piece I have no way of knowing whether he knows a lot about programming in
general, or architecture.

He tells us, again and again, that it's best to avoid trying to emulate
inheritance in JavaScript, because that often goes horribly wrong - in
JavaScript. I'm not sure it's valid to extrapolate his experience to outside
JS. I get the impression he's teaching us how to avoid problems that we
wouldn't have (or less so) if we weren't saddled with JS.

His enthusiasm for JS, meanwhile, seems a little misplaced. A language riddled
with many horrible gotchas that inspired Mr. Crockford to write a book on how
to avoid them? Why should we need to tiptoe around the fact that "this" means
different things in different contexts? The "prototypal functions that happen
to contain data" idiom is refreshingly different and interesting, but does it
really offer advantages not found in "conventional" OOP or FP?

JS commands a huge following. But as Elliott hints at the beginning, its
popularity is not a matter of choice. Netscape saddled us with a legacy where
the API of every browser is necessarily JS. JS is the best language for
programming browsers simply because it's the only one. That it's not a
universal favorite is evidenced by the many projects that offer a "cross
compile to JS" option. The users of those products would rather code in a
different language.

All that said, a disclaimer: Though I've read _The Good Parts_ and other JS
books, I avoid JS, I barely know JS, I have next to no experience with it and
I suck at programming in it. So the foregoing is an opinion not backed by a
wealth of knowledge and experience. I submit it as a kernel for discussion,
hopefully by more knowledgeable people.

~~~
throwawayaway
it's depressingly good at deployment though isn't it. there's nothing easier
to "port". it's the write once run anywhere that's been promised so many
times. i just don't feel like writing anything in it!

i don't think that this is a great article because there's a lot of bloat
around the content to wade through and filter.

~~~
jared314
> it's the write once run anywhere that's been promised so many times.

It has yet to even obtain Java-level "write once, debug everywhere". Most of
the people talking about "isomorphic JS" and "JS is everywhere" use, and
expect, a single javascript VM implementation (V8).

~~~
throwawayaway
i was under the impression that jQuery had taken care of that, perhaps i was
mistaken. certainly a url is quicker to deploy than a jar.

with the exception of jQuery: i appreciate your point, even within the same
browser, different js engine versions have wildly different behaviour.

------
CmdrKrool
I'd love to stop using 'new' and embrace a more basic, less side-effect-laden
and ultimately more flexible way of creating and returning objects in
Javascript, such as Object.create(), object literal plus setting __proto__, or
whatever. Unfortunately, all of these methods are still massively slower than
'new' \- like, three to thirty times slower. (Sixty times, even, if you're on
Safari!)

[http://jsperf.com/object-create-vs-crockford-vs-jorge-vs-
con...](http://jsperf.com/object-create-vs-crockford-vs-jorge-vs-
constructor/58)

Since he mentioned HTML5 games and trying to improve perfomance by avoiding
the garbage collector, well, the above benchmarks are not the kind of thing
you would want to compromise on either.

------
bsaul
The mantra "inheritance is the root of all evil" starts to bore me. Dot net
framework is object oriented and uses inheritance. Java core API / standard
lib is object oriented and uses inheritance. Every single iOS framework is
object oriented and uses inheritance ( the ones written in Objective C at
least). Android api are object oriented and use inheritance. Even Operating
systems have been built with object oriented designs from scratch and ended up
working quite well ( BeOS).

So please, next time you say that it's impossible to build anything big and
reliable with this design because _YOU or people you know_ ended up in a mess,
think again whether the problem really comes from the language, or the people.

~~~
fsloth
I think there is a difference in inheriting from an abstract interface and
constructing deep inheritance trees. The former is great in .Net for e.g
constructing iterable collections and as such are more like glue between the
language syntax and a concise implementation.

Deep inheritance trees, on the other hand, are difficult to use beautifully
but yet are often portrayed as a first class design pattern which often ends
up in mess. A priori designed inheritance trees without experience how such
designs evolve in production are probably one of the biggest issues, I would
imagine.

I think deep inheritance is an expert design tool that is easy to get wrong...
therefore I kinda agree that the first advice "don't use it" is not misplaced
but should be probably followed with "unless you really know you need it".

Since Javascript is a dynamic language it is easy for me to imagine deep
inheritance trees will lead there to a terrible mess quickly since there is no
static type system to enforce the design constraints.

~~~
calinet6
I think people make mistakes in the architectural design part, often
attempting to object-orient things that are not related in the strict way
inheritance implies.

So, put more simply, don't make an Animal class if you have a Cow and a Tree,
or you might end up treating legs and trunks the same. It should be no
surprise, then, that bad things happen.

This is not the fault of the concept of inheritance, it is a fault in your
thought process and the resulting design.

------
pcthrowaway
I'm honestly really confused by this article, and would love if someone could
clarify this for me (no pun intended). The author mentions that classical
inheritance is to be avoided and prototypal inheritance is one of the
language's best features. Then he goes on to state that the _constructor_
pattern is also to be avoided and suggests that this is something people use
in an attempt to use JS in an object-oriented way.

Correct, me if I'm wrong, but using the constructor pattern (and new) in
Javascript is the only real way to create an object that has a prototypal link
to the constructor function's prototype. So what does this have to do with
classical inheritance?

~~~
esailija
You can also use Object.create, __proto__ setter or a custom abstraction.
However the constructor pattern is in practice used everywhere and I find
nothing wrong with it, in fact in the next language version it will get first
class syntax through the `class` construct. People need to accept that same
keywords mean different things in different languages, just because Javascript
`this` and `new` are not like Java `this` and new` doesn't make it better or
worse.

~~~
pcthrowaway
Ok, but wouldn't Object.create be more useful for when you _are_ trying to
shoehorn classical inheritance into Javascript? I still don't understand why
he's implying (if I'm reading correctly) that using constructors is bad
because you end up with the gorilla-holding-banana-and-forest problem that (he
argues) comes with classical inheritance.

~~~
jimmaswell
That gorilla-holding-banana-and-forest problem is more of a boogeyman than
anything.

------
andrea_s
Wait, what? What decent programmer will ever find herself with N slightly
different copies of their classes instead of planning ahead or doing some
basic refactoring?

~~~
Spearchucker
" _planning ahead_ "

Whoa, that's fighting talk. Next we'll be doing big design up front and (god
forbid) beginning with the end in mind.

That was tongue-in-cheek, only because everywhere I go these days I see people
bowing down at the altar of refactoring, rather than doing a bit of planning
and getting it right first time.

~~~
robmccoll
Of course - planning is anti-"agile". You're supposed to run around in a
constant state of chaos beating on everything with a hammer until a usable
product magically pops out.

------
Kiro
This is missing some code examples. I just want to know what to use instead of
constructors.

------
al2o3cr
"If you put the frog in cool water and gradually increase the heat, the frog
will boil to death because it doesn’t sense the danger. In this story, we are
the frogs."

Indeed. And the fire IS Javascript...

The beginning of the article reads like care instructions someone would leave
for the person they hired to babysit their pet velociraptor. "Now, here are
all the things you shouldn't do or else Rapty will literally rip your face
off"

------
ExpiredLink
A praise of 'prototypal inheritance' in 2014? Doesn't sound like an escape
from JavaScript hell.

~~~
niklasni1
I've been writing JS for a few months, after years of hating it from a
distance. I must say it's not as bad as I expected, inasmuch as you can
basically pretend it's a somewhat wonky Scheme.

The nicest part of it is the built-in hash table type and the related
syntactic sugar that everyone for whatever reasons insists on calling
"object".

One thing that makes me freeze right up, though, is I hear they're adding
classes and inheritance and that whole OO clusterfuck to what's a nice, trim
little dynamic language.

Like the article, I think it's possible to write good code in JS as it is, by
accepting what it is, rather than trying to force it to be an OO language, by
emulation or extension.

~~~
anon1385
>The nicest part of it is the built-in hash table type and the related
syntactic sugar that everyone for whatever reasons insists on calling
"object".

People call it an object because that is what it is. If your code is using
Javascript objects as general purpose hash tables with the normal syntactic
sugar then your code is broken[1]. The correct way to use an object as a hash
table involves a bunch of ugly extra syntax that makes it more verbose than
hash tables in any other language I'm aware of.

[1] [http://www.devthought.com/2012/01/18/an-object-is-not-a-
hash...](http://www.devthought.com/2012/01/18/an-object-is-not-a-hash/)

~~~
nateroling
Object.create(null) creates an empty object with no prototype that you can
safely use as a hash, as mentioned in the article you linked.

------
bitanarch
I was already expecting he'd talk about favoring composition over inheritance
1/3 the way into the article... which he finally does in the 40 minute+ videos
after the end of the whole article.

There're a lot more problems with JavaScript than that. It's not even the most
important problem IMHO.

------
calhoun137
Javascript is a great language, and people who hate on it are very often just
mindlessly repeating what they heard somewhere.

A person I used to work with liked to hate on js constantly. Then I looked at
his code. He was trying to write js like it was java, because that was his
background! If I wrote js like that, then I would hate it too.

If you don't know the fundamental concepts of a language, then you are clearly
not in a position to take advantage of it's built in characteristics.
Different languages have different "natural logical patterns" that take
advantage of that languages design choices. By learning these patterns in one
language, then when working in a different language if you get stuck you will
have them available.

This article makes the point that you should avoid trying to do standard OOP
in js, and I would generalize this idea as follows:

Every programming language has its own unique attributes, conventions,
patterns, etc... when working in a new language, it's important to learn how
to write _in that language 's style_, instead of imposing a different
languages style.

------
uaygsfdbzf
"What you think is a tool is actually a footgun" This man has a way with
words.

------
netghost
If you're interested in some actual code, take a look at this stampit
library[1] on github.

[1]
[https://github.com/ericelliott/stampit](https://github.com/ericelliott/stampit)

------
sctb
[https://news.ycombinator.com/item?id=8538793](https://news.ycombinator.com/item?id=8538793)

------
sighsigh
If JavaScript was so simple that we could force it into a singular model of
ontology and be done with it once and for all, we would be so simple we could
not.

Simply put, prototypical methodology reflects the mutability of reality.
Object-oriented methodology reflects a visualization of reality.

