Separation of Concerns

So it seems like the theme for this year's holiday dev discussion (more like holiday nerd wars) is the recurring idea of separation of concerns. The community is divided into two camps: The camp that believes in separation by language and the other is the camp that believes in separation of responsibility. So here's my opinion on a few things.

Template languages aren't just interpolating

Some say templating languages are slow because it's doing string interpolation and HTML replacement. But the thing is, string interpolation and HTML replacement are properties of the compiler. The templating language has nothing to do with that. Ractive uses Handlebars-like syntax for describing the UI. But under the hood, it parses the template into an AST. JSX is no different when compiled with Babel.

Template languages aren't weak

Some say JSX is more expressive than templating since it's essentially just writing JavaScript. Again, it's just another property of the compiler and not the language. JSX allows supports JavaScript because the compiler supports it. Templating languages don't allow JavaScript not because it can't, but because the library didn't implement it that way. Ractive allows expressions in mustaches. It is no different from JSX doing JavaScript.

There's more than one way to do code co-location

Some say that they want code co-location, and that structure, styles and logic should go together. But the thing is, there's more than one way to do that than to just stick them in there. Ractive and Vue both do code co-location. Everything's still in one place, except structure, styles and logic are separated in the file into distinct sections.

How to separate concerns depends what is possible

In one of our projects, the client's "security team" controls the servers. The system is so locked down, the build servers have no access to the internet at all. This makes it hard to do CI and dependency management efficiently. This means we still have to write HTML, CSS and JS separately in the traditional manner and cannot use the new and shiny. That's the sad reality when working with legacy systems.

On the other side of the fence are greenfield projects, ones where we have opportunities to use new tools. I personally don't like jumping across files and traversing directories just to look for functionality. That's what attracted me to Ractive in the first place, and React when it went mainstream. I can have a huge, single-level directory of unique components, each a self-contained piece of functionality that's ready to use practically anywhere.

Conclusion

The nice thing about where I work is that I have exposure to different approaches and different kinds of systems. I am not locked into a certain way of thinking and a certain way of doing stuff. If I did, I'd constantly be seeing a lot of friction. Choose tools depending on the need, not because it's the newest, shiniest thing around.

That's also why I chose Ractive. It doesn't force me to a particular way of doing things. It is so flexible, I can make it do whatever I want. I can do two-way binding like Angular or disable two-way binding and write like React. I can write CSS in a separate workflow, or write component-scoped CSS like Polymer. The possibilities are endless.