Hacker News Reader

_getifyon Class Hierarchies? Don't Do That

OK, draft figures posted now.

https://github.com/getify/You-Dont-Know-JS/tree/master/this%...

_getifyon Class Hierarchies? Don't Do That

A super quick, simple illustration of the difference, which comes down to the fact that delegation is differential, whereas composition is complete:

https://gist.github.com/getify/9895188

For a bit more "real world" of a scenario, you can also compare the `LoginController` / `AuthController` mechanism here, first shown with inheritance+composition, and then shown with simpler OLOO-style delegation:

https://github.com/getify/You-Dont-Know-JS/blob/master/this%...

_getifyon Class Hierarchies? Don't Do That

OLOO is quite different from both inheritance and composition. It embraces delegation rather than covering it up or running away from it. :)

_getifyon Class Hierarchies? Don't Do That

They're coming. It's an artifact of working with a book publisher and the art department and all that. Sorry for the confusion.

_getifyon Class Hierarchies? Don't Do That

Huge fan of this article. Makes some really great points! Wish I could share and vote it up a thousand times. :)

I have been writing about exactly this topic, of why classes don't make sense (specifically for JS), in my second title of the "You Don't Know JS" book series, "this & Object Prototypes".

In particular, Chapter 6 makes the case for an alternate pattern to class-orientation design, which I call OLOO (objects-linked-to-other-objects) style code. OLOO implements the "behavior delegation" design pattern, and embraces simply peer objects linked together, instead of the awkwardness of parent-child abstract class semantics.

https://github.com/getify/You-Dont-Know-JS/blob/master/this%...

_getifyon Should I Pick jQuery?

> In Q1 2013, average connection speeds on surveyed mobile network operators ranged from a low of 0.4 Mbps to a high of 8.6 Mbps. Only nine operators demonstrated average connection speeds in the aforementioned broadband category while 64 more operators showed average connection speeds above 1 Mbps.

http://thenextweb.com/insider/2013/07/23/akamai-average-inte...

My 80% number was hyperbole, but I do think the data supports that on world-wide average, mobile connections are drastically lower, and so making assumptions about a file size downloading quickly on fast broadband is ignoring an increasingly important part of the web traffic, which are years behind wired connections in terms of speeds.

_getifyon Should I Pick jQuery?

> Minified jquery is like 32kb. That means literally nothing in modern web. Unless you are from 1995 using 2G connection, this doesn't matter.

Or on like better than 80% of all mobile data connections in the world. But mobile is so niche, right? No need to worry about them.

_getifyon Should I Pick jQuery?

> it's fairly lightweight

Really? 93kb of code is lightweight? Yeah I know it gzips smaller, but that's still not what I'd call "ligthweight". It's not bloated, but it's certainly not a micro-lib.

> you might on the next

I think this might miss the point. If you're just writing code on sites, sure, consider jQuery. But if you're creating a library or framework that thousands of others may use, your decision to pick jQuery is making that choice for THEM, which means you should think about it a lot more closely.

It's not then about whether you might like it "next time", but whether the people using your lib/framework will likely need jQuery. That decision should not be made glibly or lightly.

Especially if you're only using a small portion of that 93kb of jQuery, and could just "do it yourself".

_getifyon Silly Rabbit... Frameworks are for Prototypes

See other comments here about NIH. To attribute my post to NIH mindset is laughable. You obviously didn't read it fully.

I use all kinds of public OSS'd libraries and tools. I just don't use frameworks that prescribe an exact way those should be glued together, nor do I stick my own opinions about how the glue should work out "there" to try and convince others they should do it exactly like I do.

_getifyon Silly Rabbit... Frameworks are for Prototypes

total strawman. language abstractions are not even remotely the same as framework abstractions inside of a language. apples and palm trees, at best.

_getifyon Silly Rabbit... Frameworks are for Prototypes

+1. totally agree with that sentiment.

_getifyon Silly Rabbit... Frameworks are for Prototypes

I post all my tools/libraries publicly on github. I would never have so much hubris as to post some "framework" I created for some site as "The Getify Framework" that everyone else should use. That's completely contrary to the message I'm trying to get out.

Ironically, the site I vaguely referred to in the post WAS actually fully open-sourced. But NOT so that people could look at that code and say "Ah, he's saying that I should always do that same thing with every site I build".

_getifyon Silly Rabbit... Frameworks are for Prototypes

At least you read the whole article. More than I can say for a lot of responses so far.

You said "almost entirely wrong". What did I get right?

_getifyon Silly Rabbit... Frameworks are for Prototypes

I use plenty of tools/libraries, some I've written (and OSS'd on github), some totally popular and widely used/tested.

What I don't use, nor do I try to force on others, is the best ways to glue these pieces together. I have my ideas of "best practices", but those ideas are highly adjustable per site/app, and also just my own opinions. No piece I bring into a project makes an intrusive assumption about how the rest of my code will work.

I love the assumptions that because I write any amount of glue code, the code I write must certainly be less tested and therefore less quality than that which shows up in a popular framework.

_getifyon Silly Rabbit... Frameworks are for Prototypes

The fact that I have not taken out the wordpress framework yet (because I've been busy with other "more important" things to do) doesn't mean that NOT doing so is somehow justifiable.

_getifyon Silly Rabbit... Frameworks are for Prototypes

First off, you can't just take the label "framework" and slap it on any arbitrary piece of code which works together for one or more tasks. By that logic, every site and app ever written is its own framework.

But...

> You know what I did? I wrote a framework for that site, and I called it “the site”.

The key differences between my "framework" and these popular frameworks:

1. I'm not holding out my "framework" for that specific site as some general reusable "best practice" for every other site on the planet.

2. It's highly customized, and customizable, to the specific site. When I don't like how events interact with views, I don't need to worry about forking some general framework project (and creating upstream update nightmares) and hacking into the guts of it to change the assumptions it makes. My "framework" is much thinner of abstraction, and far less convoluted.

Not because my "framework" is better. Just because my "framework" is specific to the task.

_getifyon Silly Rabbit... Frameworks are for Prototypes

I've been meaning to rip out the terrible "wordpress framework" from underneath my blog so that it doesn't suck when 20 people try to read it at once.

_getifyon Silly Rabbit... Frameworks are for Prototypes

If I really had NIH syndrome, I wouldn't use any tools/libraries. On the contrary, I use them quite frequently. And I build lots of my own tools/libraries on github.

What I don't do is make intrusive assumptions about the entirety of your application's architecture simply because you include my one little focused tool.

_getifyon Silly Rabbit... Frameworks are for Prototypes

Did you read the post? I said basically that. The difference is, I don't hold my "framework" out as THE general reusable pattern that everyone else should use. It's also extremely disconnected (without the glue code) and really makes no hard assumptions or influences over how you use it.

And, btw, it's not private. Most of my code is on github. I just don't try to force it down others' throats.

_getifyon Silly Rabbit... Frameworks are for Prototypes

No definition is perfect. I admit that. But I do think, as you say, it's a decent starting point, to reason about how intrusive/assuming (or not) a piece of code is when we build on it.

_getifyon Silly Rabbit... Frameworks are for Prototypes

...again, the FUD that if you go framework-less, you're automatically re-inventing the wheel. Total B.S.

_getifyon Silly Rabbit... Frameworks are for Prototypes

What on earth are you talking about? That comparison is from the looney bin.

_getifyon Silly Rabbit... Frameworks are for Prototypes

I am not reinventing "from scratch" every time. I rewrite a bit of light glue code to weave together various bits I copy-n-paste in from previous successful projects. That's hardly "reinventing the wheel".

_getifyon Silly Rabbit... Frameworks are for Prototypes

The fact that Dojo and YUI can be used like a framework (so can jQuery, with jQuery UI, etc) is not the point. The point is that, at the point-of-inclusion, those 3 tools/libraries are far less intrusive to the architecture of your site than including Backbone/Angular/Ember.

_getifyon Silly Rabbit... Frameworks are for Prototypes

...which "underscore"s the fact that you can make a great site prototype with frameworks (JS, CSS, etc). My claim was not that they have no use. But that you start with them, get a great site, then pull out the re-usable framework stuff and leave the customized stuff that makes your site/app so great.

_getifyon Silly Rabbit... Frameworks are for Prototypes

The pain of removing jquery is indeed a problem. So I can see the point from that angle. But the bigger point, about how much less assuming they are just by virtue of being included... that's the distinction I cared most about.

_getifyon I will not do a tech interview

I won't do tech interviews either, but not because I think I will fail at them. I think they are completely bogus and give totally the wrong signal. It's a waste of my time AND the company's time. I wrote up my thoughts on this exact thing a few months back: http://blog.getify.com/technical-interviews-suck/

TL;DR: Everything you need to know about if I'm a good fit is available online in my OSS (et al) track-records. If that's not good enough for you, that's not the kind of job I want anyway. I want to work for companies that value the full lifecycle of OSS work, which you can only see in such a way, and CANNOT judge via tech interviews.

By the time I walk in the door for an in-person interview, I expect you to already know that I am fully qualified (tech and otherwise), and you're looking now to judge my cultural fit by sitting me down in a real team meeting and seeing how it works, etc.

If I show up and you try to quiz my tech skills, you didn't do your homework on me, and I have no more time for you, so I'll just chuckle and walk out. Politely of course.

_getifyon "You Don't Know JS" book series kickstarter

thanks so much for the backing. really excited to get this off the ground! please help me keep spreading the word.

_getifyon JS Objects: De"construct"ion

The full "JS Objects" article series:

  * Part 1: JS Objects: Inherited a Mess [1]

  * Part 2: JS Objects: Distractions [2]

  * Part 3: JS Objects: De"construct"ion [3]

[1] http://davidwalsh.name/javascript-objects

[2] http://davidwalsh.name/javascript-objects-distractions

[3] http://davidwalsh.name/javascript-objects-deconstruction

_getifyon JS Objects: Inherited a Mess

I'm not sure the actual history bears out your assertion that 1995 was the fix-point date for all/most of these concepts.

AIUI, functions were not originally first-class citizens. My understanding is (and I may very well be incorrect), in these very early days, functions not being objects precluded an awful lot of what we currently "know" to be true about how JS emulates "classes" with function.prototype. I tried to find good citations for this fact, but I'm having trouble finding good "early JavaScript" history.

I do know that at least as early as ES1, in mid-1997, we had constructors with prototypes and "new". [1]

In any case, besides `Object.create()` which you've noted, here are some other milestones in the evolution of "OO in JS" I could find:

`instanceof` was added in JavaScript 1.4 [2], which was sometime after Oct 1998 [3], probably officially in ES3.

`Object#isPrototypeOf()` was added in ES3 [4], which was around late 1999.

`Object.getPrototypeOf()` was added in ES5 [5], which was around 2009.

[1] http://www.ecma-international.org/publications/files/ECMA-ST...

[2] https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...

[3] http://en.wikipedia.org/wiki/Javascript#Version_history

[4] https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...

[5] https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...