Why engines and components are not evil but distracting.
I’ve
been following the enthusiasm for engines, components, and bigger
plugins from the sidelines for a while now. It’s a subject of very
mixed emotions. On the one hand, I’m really glad to see that people get
so excited and start dreaming of bigger and better things. That’s
passion in the works and its great.
On the other hand, I think these developments are basically another name for high-level components. And you all know how I feel about those.
The short summary is that high-level components are a mirage: By the
time they become interesting, their fitting will require more work than
creating something from scratch.
But I start getting
really high eyebrows when I hear of “engines that depend on other
engines that can be swapped out with yet another engine”. Even plugin
dependencies are dangerously close to something I would consider unfit
for Rails. Simply because it encourages a style of development that I
find unhealthy.
So this is not a slam against the
technical merits or implementation of either engines or anything else
in the same boat. It’s a concern that they will distract people, that
they will appear as needed, and in turn, that they will take the
debacle that was Salted Hash Login to a new standardized level.
Rails
is all about making the simple things so easy that you need not
abstract them. It’s about making the creation of logins, of access
control, of content management, of all these business logic components
so very easy that you will treasure the application-specific solutions
of your own rather than long for The One True Login System.
So
what am I saying? That engines should be stopped? Of course not. But I
am saying that Rails will continue to send a signal with what’s
included in the core that this is a sideshow project. It satisfies some
needs for some people and that’s great. But the goal of Rails is to
create a world where they are neither needed or strongly desired.
Obviously, we are not quite there yet.
One way of getting
there is to do a better job of educating new comers in common patterns.
Answer the question “if engines and components are not the way, then
show me how!”. So this is a call to all those experts out there. Help
us spread the good patterns. Make videos, write tutorials, help newbies
on #rubyonrails, answer requests on the mailing list.
And
if you have a great idea for an engine, or a high-level component in
general, think about this: Is there a way I could abstract a smaller
slice of functionality as an independent plugin and then release that
alongside a pattern that described how to use it like the component
would have done all in software? More often than not, I think you could
find this to be true.
Note: James Adam, the creator of the engines approach, has a great post
on the mailing list for how he uses engines internally at his company.
That’s perfectly cool use. The trouble with high-level components are
solely related to making them generic. [Riding Rails]