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.
That's just more buzzwords though. I mean, why do I even need model view data binding? I'm not saying it's not nice to have, but I've written some pretty complicated applications and I never really found data binding to be some sort of killer feature. It's generally struck me as a great demo feature that in reality I'll pretty much never use.
I guess I'd find these things more convincing if they showed me some sort of problem they're solving by showing how awful it would be without what they're doing -- because without seeing the actual problem they're solving, it kinda strikes me as the work of architecture astronauts. It all sounds great on paper, but when I go to use it I can't imagine even needing most of the features this article describes.
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.
It's like Rails vs. a custom web app. If you asked me to maintain an existing Rails app, I would feel pretty comfortable just knowing that it's Rails. If you asked me to maintain your web app that you build from scratch that doesn't necessary follow standard patterns like MVC, I'd have a much harder time.
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.
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.
Sorry for copy-pastaing my reddit comment on this same article, but I think it's relevant to your point.
---
I feel very strongly about this, and I agree entirely. I think projects should go one step further. For something like forem, I think it makes sense to have a gem called forem_auth, and for the installer to give you an option to install the engine as a standalone app. If you choose to, it would include the forem_auth gem in the Gemfile, and you'd get auth built in. Otherwise, you configure it for your own auth.
I think refinery and spree should adopt identical stances to forem in this regard. I also plan to take this a bit further in all of my engines going forward, and defer the persistence decision entirely, making it trivial to switch out ActiveRecord or mongoid or csv files or whatever. Experimenting with this on internal apps presently, and it shows comically awesome amounts of promise.
I think it's a relatively normal thing for lispers to defer decisions like that until they no longer have to decide - that's what we've been doing.
---
I've been thinking about rails engine interoperability for quite a while, as have the spree/refinery/other forem guys, and I've got a very solid mental model of what it needs to be to make plug-and-play a possibility with these style components. It is definitely within reach, and we need some other people to get on board with these ideas to make it the obvious choice for future engine makers.
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'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 while back there was a post about how great http://teamtreehouse.com 's tutorials are. I added the following comment:
"But don't you think in an industry like software development, you need to be able to self-educate. Software just moves too fast. So a person that needs hand-holding is not going to 'get' what it takes to be a good programmer."
I got downvoted for it =)
So I think people are all over the map when it comes to how to learn and how to teach. But in the end, I maintain that you only get good by being self-motivated and driven - no other way.
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.