forkhammer

Well, they are buzzwords, yeah, but it's important to note that buzzwords become so because of their popularity and prevalence.

Why do you need model-view data binding? Emulating the responsiveness of desktop apps, for one, or having live-update capability. I wrote an app recently that let you add line items to an object, and the client wanted the cumulative fiscal information to auto-update without reload. I'd agree that the standard 'Hello, <your input content here>' example is overly contrived, but what about a field that calculates and updates tax owing as you type? That's not hard to write with just javascript, but when you do that about fifty different times in an application, having a convenient data binding mechanism is really convenient.

The other utility that I find quite convenient is DRYing up insertion logic--I hate that I often have duplication between server-side templates for existing objects, and some sort of client-side template for dynamically inserting new objects. Rendering it all client-side makes my life a lot easier when I want to add or change the surrounding template, and having the ability to do the initial render with a minimum amount of boilerplate is phenomenally helpful.

Those are two very real, very frustrating problems with which I feel any one of these frameworks helps a lot. I'm happy to go into greater depth if you'd find that helpful or revelatory.

Here's the brief answer, as I understand it: they're frameworks that provide model-view data binding, ease data/presentational decoupling, and (in some cases) provide single-page app (SPA) infrastructure in the mode of MV*. In short, they're designed to tackle some of the common complexities that arise when writing feature-rich multi-part SPAs.

You can do it all on your own, for sure, and I actually think that writing a complex front-end-heavy application without anything but jQuery is a really great way to show yourself the potential use of these libraries. It's not really super hard to write decent, well-structured and segregated code... but it does begin to feel, after a while, like you're spending your time hooking up wires you've hooked up before.

At that point, you either write your own abstraction, or you go looking for an abstraction that someone else (preferably smarter than you) will maintain.

Every time I see a new hosted CMS pop up, I wince and pray that this is not the day where some genius has revealed his brilliance and I will shortly be out of a job.

Hasn't happened yet, true, but it doesn't stop me from worrying.

Exactly! That's the reason I hate broccoli -- every person who tries to feed me it seems concerned that salt and vinegar potato chips are the only vegetable I eat. It seems to be part of their whole culture.

They're clearly just potatohaters.

As someone who has worked on all three projects — Forem, Spree, and Refinery — it's a pain in the butt trying to get them to work together. Forem's approach is brilliant, but it's also a user-friendliness issue to require them to provide their own authentication.

I agree with what the author has to say, largely, but I think there needs to be a way to provide a sane default.

I don't think that all of Rails is beyond beginners; and certainly, some people do manage to learn the prereqs while they learn Rails. But I'm advocating being blunt and telling people to learn the prerequisites, instead of mindlessly answering inane questions. People who try to bullshit program their way through an app aren't learning anything but how to copy and paste.

For what it's worth, I feel the same way: learning Rails has sent me down a lot of roads and inspired me to learn a lot of new, interesting, valuable things. I knew Ruby before I started... but even just the conceptual elegance of Rails has taught me something.

Definitely not, and I cut my teeth with Ruby on Windows, way back when. You can learn on Windows, but it is so much easier on a *NIX machine. As I said in the supplemental article that I wrote to go with this piece:

> [If you choose to use Windows,] you need to understand that Rails—and indeed, most modern, cutting-edge programming stuff—is not meant for you. Accuse me of elitism, sure, but it’s a simple fact of the matter that many, if not most big-name programmers program on one of these two platforms (or some more extreme variant). You can program and do Rails on Windows, but you are swimming against the current. You are going to fight battles learning to program, so ask yourself: is using this operating system the battle you wish to fight? The correct answer is no, but you might have your reasons. Nevertheless, you can download and install a copy of Linux so amazingly easy these days that you’re making it hard if you choose not to.

I support this wholeheartedly. A good mentor is absolutely critical.

I'm not talking about 'professional programming', really—I'm talking about being able to achieve a reasonable outcome in a reasonable amount of time.

I'm not even interested in people becoming good programmers. My point is that people who will spend the time to learn the hard parts will benefit more from learning from the lowest level that makes sense to them, rather than trying to learn Ruby and the CLI alongside Rails as they muddle through an app. We'll see better conversion rates if we encourage beginners to start from the beginning, and to spend even a modicum of time learning those technologies.

A few questions, then:

1. How much programming had you done before trying it? 2. How complicated was your application?