That's about what I was thinking, too. It might be good to explicitly say that they would have a lot of influence over the product, so it would ideally be well-suited to their needs. And, they would have special privileges/discounts/whatever, when it hits the market. What do people think about extending/stating those kinds of things, or does that set expectations too high?
Yeah, serving up two versions simultaneously and split testing them would be more scientific, but I appreciate the number anyway. It was an after the fact observation rather than an original goal, so I wouldn't expect him to go back and deploy the slower version just to test the number.
The hole here is whether or not they unknowingly got a new influx of traffic that was 5% more likely to convert, skewing his final observation, which I would say is unlikely. Your point is good in general, however.
FWIW, I really appreciated the post, Joel. I'm actually in the process of buying a lot of this stuff for myself due to accepting a new telecommuting job. I need to furnish my home office, and as understanding as my wife is, it's hard to explain to her why this costs what it does. I probably won't spend what you do at FogCreek, but it at least relieved me of the feeling that I was misspending our money. (My tentative stack for those that care: MacBook Air, Thunderbolt Display, GeekDesk, and ? for chair)
All of these arguments are the same arguments you need to think through when determining whether to make a web app vs. a native app on the desktop. They're identical, because the desktop is just another device.
I completely agree with all the arguments, except possibly that we should never use hacks. We used (and still use) hacks on the web for desktop use when browsers sucked, and we'll do it on mobile devices, too. It's the way the state-of-the-art is pushed forward; it's inevitable. I think he would agree with me, seeing that he pointed out Scrollability's use on the iPad being somewhat valid. That said, the author's underlying point examines why we use those hacks and to evaluate whether we're solving a non-existent problem.
Edit: I might clarify my hacks point. The reason they're inevitable is that they sometimes expose browser deficiencies. A current example would be web sockets. We've been using comet-type hacks in lieu of a real web socket solution (and Chrome has now implemented one).
Agreed. The minute you know the feature does have traction and won't go away any time soon is the minute you clean or rewrite that code.
This may be semantics at some level, but I think it's important to not imply you just don't care about the quality of your code. Prototyping intentionally sacrifices some quality to prove a point quickly, but once the point is proven, you throw it away and rewrite with your normal, high standards.
In addition to the argument for keeping your styles together, CSS is declarative while Javascript is imperative. There are just less moving parts in CSS, and the browser keeps track of any "state" that you would be tracking in Javascript.
Absolutely agree. I help move some of the poorer families at our church, and I'm always astounded at where their money is spent. One family wore hand me down clothes and had little else in their house, but they had a 60"+ TV in their living room.
Most families have a TV, and just about every TV you can purchase these days has HDMI. I'm incredibly sad when my teacher friends describe how few of their students have computers at home to do their work.
The only problem is that he's still stressing about money at that point. If he has even 300 people willing to pledge $8/month, he can bank on $2400/month and adjust his living expenses accordingly, if necessary. I'm sure there are people that would give $500+ in one shot, but then he has to set a runway, keeping asking, etc. in order to continue that. PG has talked about how much raising money is a distraction, too.
Not saying it's not a possibility, just saying there are advantages in not offering a one-time donation. If you still want to give, I'm sure he would accommodate you, if you contact him (he's very friendly).
After about a day of thinking on this, I think I've come around. I still don't think I would have pulled the trigger on this, but I respect the people that did.
And, again, I absolutely love CoffeeScript and support it 100%. I'm less infatuated with HAML and SASS, but it may simply be that I haven't used them enough. SASS in particular looks very useful.
Regardless, I agree with DHH's tweet yesterday [1] that Rails is a curated set of ideas/technologies. Pretty much by definition it's not one-size-fits-all. I think this is the first time I've found myself on the opposite side of a Rails technology switch decision, which is pretty amazing. I'm looking forward to giving it a chance, and I can always switch back, if it doesn't work out.
Totally agree - and the HAML/SASS argument is perfect. We talk a lot about web standards and doing things that are "native" to the web, but abstracting things like HTML/CSS/javascript (by default) don't fit with that mindset.
I like CoffeeScript, and it does feel Rubyesque, but I just don't support it being the default.
That said, I'm sure a core member will post about the decision, and I almost hope they convince me otherwise. I do really like CoffeeScript, and patio11's comment about HAML/SASS is a good one.
I think it's the layout of your site plus the brevity of the post that confused everyone (including me). I couldn't distinguish what I was supposed to look at, what was image and what was post text, etc.
It's cool to celebrate "small" contributions to OS projects, because it will encourage more to do the same. But, I'd write up a bit more explaining that, especially for HN.
I forwarded his recent TED Talk to several of my teacher friends, and many immediately thought this was supposed to be their replacement. So, I'm assuming the first (mis)conception is valid at the very least.
That's the opposite of how I read that. I take it as a comfort that they're doing their best, and they're the best at what they're doing. If they needed food or money, I would gladly send it, but he's saying they don't. Great!
[1] http://en.wikipedia.org/wiki/Arc_(programming_language)