The difference between back-enders and front-enders is that the first work in only one environment, while the second have to work with myriad of environments that may hold unpleasant surprises.
Even worse, where back-enders hold that they’re better in creating complex applications than front-enders — and they may even be right — some show an unwillingness to learn about the front end.
The combination of an insistence on being right about application structuring with a casual dismissal of front-end techniques aimed at catering to myriads of challenging environments makes the archetypical back-ender come across as arrogant. If you want to teach, be prepared to learn.
This article has been translated into Japanese.
In my Angular article I talked about front-enders and back-enders without properly defining what they are. I was criticised for that, and it’s a fair point.
So here it goes. Many thanks to Robson Sobral, whose tweet clarified this important point for me.
Fair warning: the rest of this article features an archetypical back-ender who is gently chided by an archetypical front-ender. That’s not fair to those who are fluent in both types of development and have managed to avoid the pitfalls mentioned here, but it allows me to get my point across much more easily.
The original version of the article didn’t have this section. I added it when I found that some back-enders misunderstood how hostil front-end environments are.
I got a few reactions with things that can go wrong on the server. Unexpected OS, PHP, MySQL versions, weird cloud software, root certificate problems, kernel panics, oh my! This stuff isn’t easy, but it’s also not exactly what I mean.
Let’s try an analogy. Imagine having to design a server-side business application that
Compared to the front-end world, the back end is a safe haven of quiet. Keep that in mind as we go along.
(There’s an exception: open source software may have to deal with several server environments. Point taken. But this article mostly talks about enterprise Java.)
I feel that the front-end approach is the only one that’s suited to the web — and by the web I mean any sort of application, from a nearly-static HTML page to a full-bells-and-whistles single page interface with dozens of views, that runs in a browser. If you want to run your code in a browser, you’d better know all about this most hostile development platform in the world, as Douglas Crockford calls it.
That’s why I disagree with this otherwise interesting article that proposes to redefine front-end as
You should know why querying
offsetWidth is potentially dangerous, when which events fire (and don’t fire) in several types of browsers, and the performance consequences of the way in which your code approaches DOM manipulation.
Even if you outsource these concerns to a framework, you must know how the framework performs across a wide range of environments, and not just your preferred one. In the future this problem could be solved by a new generation of frameworks that cater to front-end and back-end sensibilities, but right now these are thin on the ground — or at least underreported.
The archetypical back-ender tends to see the browser as a monolithic application platform running on a modern computer. This may have been the case three or four years ago, but today it’s only true on an Intranet. Elsewhere it’s false. The advent of mobile browsing forces us to consider a very restricted environment that may lack the power to run complex scripts — or where the browser is good enough but the network is crappy.
Take the front-end custom of providing two or three different ways of doing the same job. We don’t do that because we cannot construct applications properly, but because we need to cater to myriad numbers of environments our code may run on, and certain categories of environments need a different approach.
“But these crappy mobile browsers aren’t on our Supported Browsers list,” I hear you say. To which I reply: “Who created that Supported Browsers list?” If you start from the assumption that your application should run only in environment X, it becomes very alluring to take all environments that aren’t X off of your support list. That, in turn, makes it much easier to decide on one single-page app without fallback, since it only has to run on X anyway.
My conclusion is that the archetypical back-ender sees the entire web application and the environment it will run in as a monolithic whole, instead of as comprised of lots of different environments that the app may need to cater to in different ways.
At the same time, back-enders commonly hold that they’re better than front-enders in structuring applications. For all I know they’re right. For all I know, I could learn a lot from them.
The problem is a lack of balance. Back-enders want us to understand their arguments without making an attempt to understand ours. Berating the Other for not agreeing to your viewpoint while casually dismissing his viewpoint comes across as arrogant.
It’s this apparent arrogance, more than any technical detail, that annoys me — and has annoyed me for the past fifteen years. If you want to teach, be prepared to learn.
If you like this blog, why not donate a little bit of money to help me pay my bills?