Front-end vs. Back-end? Should there be a difference?

Thursday, September 1, 2016 | 4:03 am

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.

CanJS is a dream come true, but…

Thursday, September 26, 2013 | 2:31 am

I started working with JavascriptMVC about 7 months ago. I have to admit, at first I was a little skeptical about using a completely front-end system to run the user experience. I was concerned about possible security issues or just general functionality problems that would rear their ugly, yet very familiar, faces. However, I was pleasantly surprised to find out how extremely flexible and accommodating a front-end MVC can be. There have been many growing pains, namely because the framework is still in its formative years. To go along with that, the creators of the JavascriptMVC decided to rename their creation to a more “buzz-wordy” sounds: CanJS.

I started writing that about 11 months ago. I have to say that my attitude hasn’t changed a lot towards front-end MVCs but it has grown and matured. I’ve been using a front-end MVC for a little 1.5 years now and I’ve found a lot of good and a lot of bad that goes with it. When I first started working with CanJS, I dove headfirst. Sad thing is, I didn’t listen to what my dad taught me about that when I was a kid: don’t do it.

Don’t get me wrong, CanJS is a phenomenal setup, bad thing is it tries to be every and anything all at once. Now, my experience is a little dated, mind you. The version of CanJS  that the system I’ve been working with was from a few months after I started working with CanJS. So, my take on it is a little behind the current version.

At the time that I started writing the above, CanJS was going through some major growing pains. The developer, Bitovi1, was in the middle of remaking the whole shebang. They were remodeling the way that the framework was put together, the way that the supporting inclusion library: steal, and just rethinking the way the whole system should even work. Now, time for a shameless plug here and a little candid disclosure, I had a small hand in some of the rethinking. Very small, mind you. I was a part of the CanJS community for about 6 months and was even approached by the good fellas at Bitovi to join their development team. Sadly, that didn’t work out for either of us. Ok, end shameless ego boost.

I do still believe that front-end MVCs and full-fledged applications are the way of the future, it’s the major trend and has been for the past couple years. You have major applications like Twitter, Facebook, any Google tool/app, you name it, someone’s doing it. The plain truth of it is that everything is becoming decentralized and more spread-out into the … shiver … “cloud”. Yes, I said it. I used a “buzzword”. In all honesty, I hate using buzzwords, they send a cold chill down my spine. Listen to any recruiter, manager or product owner for an hour or two pitching you their idea or product and you’ll understand why.

Sadly, my torch for CanJS has dwindled so a smoldering heap of ash. Again, I’m not saying that it’s a bad product, far from it, I still a lot of promise there for the framework and give the guys at Bitovi and in the CanJS community my support and hopes for the future. For me however, less is more.

When front-end MVCs were really first coming onto the market and gaining attention, there was one that stood out: Backbone.js2. At first, it was clunky and didn’t work well, but that’s to be expected. Now, it’s a completely different story. The simplicity and lack of over-architecture makes it a much easier framework to develop with and build complex applications. When I first came back to Backbone, it took a little getting used to, admittedly. I had become accustomed to the bells and whistles that CanJS had given me. “Where’s the routing?!”, I angrily asked, at first. “Where the hell is the view compiler?!”, I complained. Well, took me a little bit (very little, mind you). “RTFM!”, I replied to myself after a little thinking. So I did. And, lo and behold, I saw the light.

I was really amazed at how quickly I was able to put together a fairly complex system without any real loss of performance from what I had seen with a more encumbered setup with CanJS. I was able to setup my routing, controllers, views, event listeners, et al, without much fuss. What seemed even more amazing was the seamless integration with my new favorite back-end MVC, Symfony2, but we’ll that to another post.

I will admit that there are a lot of nice things that come with CanJS that make some parts of the process a whole lot simpler and easier to manage. Sadly, a lot of those same nice things make a large portion of the rest of the process much more cumbersome and difficult. One main issue that I’ve run into with CanJS is the teardown of controllers. This was an issue that I had to come to grips with, and write workarounds for, a long time ago. Now, that’s not to say that the issues that I’ve come across haven’t been addressed or even fixed in the more recent releases. Sadly, I can’t really use them as, with anyone that has built a complex enterprise system knows, once you choose your tech, you’re stuck with it until there is enough time to plan for a major upgrade and/or overhaul.

So, in the end it all comes down to personal taste, honestly. Some developers will like the cool additions and sleek trickery of CanJS. While others, like myself, will gravitate more towards something that allows them to determine how and when things are processed. So I say to those that are about to dabble in the new age of front-end applications or to those that have been at the bold new frontier, choose carefully, you never know what’s gonna come back to bite you.


[1] Bitovi,
[2] Backbonejs,

Mozilla Firefox’s Runaway Versions…

Wednesday, July 18, 2012 | 12:44 pm

I’m a big proponent of Mozilla Firefox. I’ve used it for years and I tell everyone I know that they should use it or Google Chrome, two of the top industry browsers. However, it seems that Firefox has been having a bit of a growing spurt lately. Firefox has gone through 5 major version releases in the past 4 months. That’s a huge deal. What makes it even odder is that there were, at most, only 1 minor version releases before the next major version release (with the exception of the ESR version releases). Since March 2012, there has been almost a major version release per month, except in May. I guess the guys at Mozilla decided to celebrate Cinco de Mayo instead. Joking.

Why am I bringing this up? What is the point? Well, it’s a little concerning to see a major browser, of which many developers use as a baseline, go through so many drastic version changes… without actually going through version changes. For those who are unfamiliar with how software versioning typically works, I’ll give a quick overview.

Let’s start with the typical version layout: 1.0.0 – The version number is broken up into 3 parts: the major number,  the minor number and the revision number. Typically, the revision number can be a fairly large number given that this is usually the number that changes when addressing bugs and defects. The minor version tends to be updated when minor patches or “tweaks” are released. The major version number changes when there is a major release. Go figure, huh?

So, with that quick (and succinct) overview, you can see why Firefox’s recent fascination with reinventing its “age” is odd, if nothing else. Yes, there have been advances and changes to the browser. Mostly dealing with more adaptation of HTML5 and CSS3 standards, with a little usability and performance enhancements. However, this doesn’t constitute a major release; these are all minor (at best) changes. I’m not saying that the developers at Mozilla are ignoring versioning standards or that they have no clue what they’re doing, but what I am saying is that it’s odd. I would definitely have to say that: odd.

So, that’s about the end of my rant. Oh, what brought this on, you ask? I was just a little surprised to startup Firefox today to see yet another “Welcome to Firefox” screen…

If you’re curious, checkout Wikipedia’s Firefox Release History. It shows an interesting trend in the graphical representation.

To Java or Not To Java: Not Really a Question Anymore

Friday, October 29, 2010 | 12:59 pm

Well, I've decided to finally take the plunge and brush-up/relearn Java. It's been almost 9 years since I've even looked at anything Java, but it has become abhorrently apparent in recent months that I need to pick up the Java-cup and take a heaping slurp.

What prompted me to take on, yet another, language, you ask? Well, it seems that to have any kind of chance with large, corporate development you need to have Java on your resume. Sadly, since it's been so long, I can barely remember anything Java. I know I won't have an issue picking it back since I've been programming in some form of a C-language or C-derivative since I decided to leave the world of BASIC behind many, many years ago.

Also, since it has been so long, I've decided to just go back to basics. The bad thing about this is that I hate going back to basics. Even the phrase. But, go back to the beginning I must. Given that the language has most definitely evolved over the last decade warrants this, too. Even if I tried to jump in head-first, I'd most likely smack bottom and have a cracked skull.

A bad trait of mine is that I hate learning from a book. I've always had trouble with that. All the programming I've ever learned has been by doing and trial-and-error techniques. Thankfully, over the years, and through the trial-and-error, I've learned better programming techniques and practices which has helped me to better learn new languages. I've only recently tried to learn from a technology from a book. And that was my short foray into the world of 3D programming, but that's another post.

So, given my lack of patience to textbook-learning, I've done what I typically do and find some nice online sources. I love the internet, most likely the main reason why I'm in the business I am.

I've found a few Java IDEs that look to be nice, but until I actually get in them and play around, I won't know which one I'll be using from now on. The one that grabbed me as being the most familiar was NetBeans . That name just jumped out as something I remember from somewhere… but can't quite put my finger on what or where. We shall see.

Second, I found one that I couldn't tell if it was really a good IDE or not, but it seems to have some nice utilities and functionality that I will be able to use. It's from a company I've never heard of but, by the design of the site itself, looks to be made by good programmers. You can always tell how much of a back-end programmer someone is and how deep they are into coding by the lack of any creative design. I know, I know, that sounds harsh, and it is. It's from a company called JetBrains and the IDE is called IntelliJ IDEA . See what I mean by lack of creativity?

Now. I know you're thinking, "Man, saying that someone is a good coder by the lack of creativity is a really harsh statement." And, I agree with you. I, myself, have struggled for years (and still do) to have any kind of creative aspect to my site designs. My first designs were so devoid of creativity, they looked like Lego blocks stacked on a web page. So, when I say that, I'm not doing it without any personal experience.

Back on topic. Java development, yes.

I'm hoping to be able to find some decent examples, more tutorials and products to play with and learn more about Java as I go. If anyone has examples, links or just advice, please feel free to comment.

My new favorite YouTube video

Wednesday, August 11, 2010 | 3:59 pm

A co-worker forwarded this to me today. Since I am a Web Designer, I just about busted a gut laughing but found myself going “Oh yeah, boy-eee” LOL!