I'm writing a CSS book

JavaScript archives Compatibility Thidrekssaga QuirksBlog Donations CSS book Politics Mobile About COH

contact

Front end and back end

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.

I feel that the subconscious assumption that a complex JavaScript-driven web site or web app will run in only one monolithic environment is the root cause of many problems front-enders see in back-end-driven web-based projects.

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.

Definitions

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.

1. Back-enders work with only one environment, their server. They have the option of changing their environment; for instance by installing new software or upgrading the hardware.
2. Front-enders work with an unknown number of radically different environments, ranging from state-of-the-art desktop computer to three-year-old, crappy phones with limited memory and processor time. They cannot change these environments because they have no power over their users’ browsers. Still, their code should work in all of them.

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.

Explanation

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

1. must run on the five most common Java web server environments, three of which release a new major version every six weeks;
2. stores data across four cloud services, two of which have sucky APIs and severe downtime issues, but of course each needs its own custom solution;
3. uses three CDNs, one of which isn’t actually live yet but will likely have a lot of users six months down the line; and
4. needs two root certificates that are incompatible by design because the issuers hate each other’s guts.
5. And kernel panics happen on your users’ computers, and not on yours.
6. And good documentation exists only for two of the Java server environments and the new CDN. The rest is only sketchily documented by other developers.
7. And all of this changes every six months.

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.)

The most hostile development platform in the world

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

the parts of the app relating to user interface, rather than those that happen to be running in the browser's JavaScript VM.

I reject the artificial split between user interface and JavaScript. Anything that’s written in HTML, CSS, or JavaScript needs an appreciation of the many environments it could run in.

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.

Subconscious assumptions

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.

A good example is a no-JavaScript version of an application. Generally, back-end-conceived single page applications don’t provide one. This makes sense if you subconsciously expect your code to run in only one environment. Our environment is X (and only X), our application runs on X, so we’re done. Besides, nobody turns off JavaScript anyway.

These arguments miss the point of a no-JavaScript version. Although users who actually turn off JavaScript are fairly rare, the no-JavaScript version caters to browsers that support JavaScript and valiantly attempt to execute your code, but fail because they’re just too slow. In that case, a monitor script could conclude that the full web app is running too slowly and switch the user to the no-JavaScript version. Thus the no-JavaScript version is aimed at a different environment than the full version.

“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.

Lack of balance

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.