FacebookTwitterGoogle+

For years I’ve gone back an forth on this question: Should my server-side code generate any actual HTML? I’ve gone from believing that the back-end should be the one and only source-of-truth for the site, to believing that you should have two separate applications: a front-end app & the server-side API/service, and to now believing that it should actually be a mixture of both.

Let’s face it, building web applications is an ever-evolving area. Whether it’s whatever library is the most popular at any one time, or what language you should be creating your next app with. It’s always changing. You’ll find a plethora of articles that will tout one way of thinking or another on any number of topics. Well, this is mine.

I’ve worked on applications that completely separated the front-end and back-end from each other, which did provide for some nice benefits. Namely, separated improvements and releases. Basically, you could give your application a new look or snazzy new features without needing to re-deploy an unchanged back-end. Of course, that was usually the plan. Normally, though? You ended up with back-end code that needed changing because of the front-end changes. So, you ended up with two release anyway. Go figure, right?

I’ve also worked on applications that had almost everything generated on the back-end, with only a minute amount of javascript. These typically weren’t very feature-rich applications and tended to be plain. While they usually didn’t have many bugs crop up on you, they did tend to leave the user wanting for functionality.

To add to this laundry list of ideologies, I have also worked on applications that have tried to merge the two together. Of course, these tend to be a lot more interesting to work on and to use. Sadly, finding technologies that work well with this style has, traditionally, been difficult. Thankfully, though, in more recent years it has become easier. With the advent of standardized libraries like Angular, Backbone, and React (not to mention the numerous other Javascript frameworks out there), the task of creating a front-end application that works better with a back-end generated interface has become much easier.

With that all said, there still isn’t a front-end library/framework that makes it easy to pass data from the back-end to your front-end application, sans API calls. There is usually some JSON-encoding required that has to write to a Javascript variable/function to later be picked up by the front-end application. While this can be cumbersome, it is obviously an inescapable route.

I have to admit that I have found myself going back to Backbone, for one particular project, for the simple reason that Backbone does not require you to render a DOM node or to modify one for it to pick-up control. This allows you to generate the HTML on the back-end and use a Javascript application to hand user interaction. Granted, there is still the case of needing to pass data in the event that you need to update/add anything.

There are ways to handle some of this if you are creating a NodeJS application, from what I’ve tested/played with in the past. Sadly, NodeJS is not always the best, or even available, option. Not to mention that OOP development is extremely difficult in a Javascript environment. Especially if you want to do it in a TDD cycle.