_getify

11 ms·

91.
Tale of Two -ends(blog.getify.com)
1 points by _getify 13y ago|0 comments
92.
by _getify 13y ago
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
93.
by _getify 13y ago
total strawman. language abstractions are not even remotely the same as framework abstractions inside of a language. apples and palm trees, at best.
94.
by _getify 13y ago
+1. totally agree with that sentiment.
95.
by _getify 13y ago
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
96.
by _getify 13y ago
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?
97.
by _getify 13y ago
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 togethe
98.
by _getify 13y ago
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.
99.
by _getify 13y ago
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
100.
by _getify 13y ago
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.
101.
by _getify 13y ago
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 th
102.
by _getify 13y ago
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
103.
by _getify 13y ago
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.
104.
by _getify 13y ago
...again, the FUD that if you go framework-less, you're automatically re-inventing the wheel. Total B.S.
105.
by _getify 13y ago
What on earth are you talking about? That comparison is from the looney bin.
106.
by _getify 13y ago
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".
107.
by _getify 13y ago
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 sit
108.
by _getify 13y ago
...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
109.
by _getify 13y ago
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.
110.
Silly Rabbit... Frameworks are for Prototypes(blog.getify.com)
18 points by _getify 13y ago|57 comments
111.
"You Don't Know JS" (book series) drafts posted(github.com)
10 points by _getify 13y ago|0 comments
112.
by _getify 13y ago
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 th
113.
by _getify 13y ago
thanks so much for the backing. really excited to get this off the ground! please help me keep spreading the word.
114.
"You Don't Know JS" book series kickstarter(kickstarter.com)
10 points by _getify 13y ago|2 comments
115.
by _getify 13y ago
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://davi
116.
JS Objects: De"construct"ion(davidwalsh.name)
8 points by _getify 13y ago|1 comments
117.
by _getify 13y ago
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 t
118.
by _getify 13y ago
To expound on the metaphor I put in this article about inheritance and my mother-in-law: > If you try to illustrate behavior delegation in terms of the "blueprint" metaphor, you quickly see how it totally breaks down. There's no way tha
119.
by _getify 13y ago
The fact that Objective-C has a term "delegate" does not mean I can't argue that "behavior delegation" is an accurate term for any prototypical-inheritance mechanism, specifically JS's. Objective-C taking a specific meaning for that term is
120.
by _getify 13y ago
I think you're going to see in part 3 (tomorrow) that it actually is quite simple and elegant to define "objects-only" delegation. You have to do away with constructors, "new", .prototype, and all that other stuff, which in part 2 (today) I

More ›