A recent article popped up in my inbox touting an alternative to the overly complicated world of client-side apps. Modern Rails! was the rallying cry. To be fair, modern Ruby on Rails is a cool piece of technology. So are many other backend frameworks. I’m not here to suggest otherwise. What I am here to do is to have yet another go at putting this idea that front-end engineering is unnecessarily complex to bed, or at least that the reasons given for it’s unnecessary complexity are misinformed. If history is any indication, I am destined to failure — or at best short lived success.
Forgive me if I seem a bit weary. As an industry, we’ve had essentially the same discussion many times in the last decade. I suppose it’s been a few minutes since we’ve had the last one, so let’s have another go at it.
I understand the desire to have a simpler solution to a hard problem. Believe me, we front-end engineers are well versed in that space. Delivering a webpage to a user sounds like a deceptively simple thing to do. But where so many go wrong is with the underlying assumptions that software development is software development. It’s all just code isn’t it?
If there is one thing I hope to get across to you, dear reader, it is this. Concerns on the back end are not the same as the concerns on the front end. It’s as if much of the complaints I hear from software engineers who don’t spend the majority of their time in the front-end space (and some that do) begin with the assumption that modern approaches to delivering websites to browsers arose because someone thought it would be a neat trick to write an application in the browser, and we all just got carried away after that.
Is it easier to write a server rendered app? You bet your sweet tea it is! It always has been. But that is not, nor has it ever really been the first priority. Single page apps arose out of necessity because delivering a brand new, fresh app for each screen, became an obvious waste of end user resources. And there’s the thing that is the first and last concern on the front end. The end user. The person using the browser that the app is running on or delivered to. Nothing else really matters in comparison. Every thing that SPAs tried to accomplish, the reason isomorphic applications are a thing, the rise of so many javascript applications, the reason we can’t seem to settle on “one way of doing something”, the reason there will continue to be new approaches to front end development is in pursuit of that end. Whether it be time, bandwidth, memory, money, attention, or whatever else we are taking away from end users in exchange for what we are offering them, EVERYTHING is in service to that end, respect for the end users resources.
So, what makes concerns on the front end so blasted different from those on the back end? It can be summed up in one word, “control”. More specifically, who is in control. Everything on the backend is under the software engineer’s control. From the databases used to the application language(s) chosen, the versions of those languages, what libraries and frameworks are present and available, the operating and file systems, even the hardware the servers are running on is all controlled and known from the outset by the engineers working on the system.
Everything, let me repeat that for emphasis, EVERYTHING changes once any piece of data starts heading for a browser. Control completely inverts. No longer does the engineer know what browser is being used, let alone what version. There is not foreknowledge about what language version will be available, we can’t even be sure there will be a language to use. We cannot be confident that our software is being used on a beefy multicore PC, smart phone, feature phone, smart watch, bot, screen scrapper, teletype, screen reader or some other unfathomable end user interface, or even rendered on a headless browser on a server somewhere and delivered to a severely limited Silk or Opera-Mini browser. We have no way of knowing if our information will be sent over fiber optics, cable, DSL, landline, 4g, 3g, 2g, Wi-Fi, bluetooth, li-fi, Wi-Max, mesh, peer-to-peer, tor, FM radio, wire or some other wild new deliver mechanism that is being planned or ported to. There are no guarantees whatsoever that what ought to be available will be available.
Presumably, users will have to interact with our web pages on some level, but with what? Mouse, touch, multi-touch, variable pressure touch, keyboard, “digital crown”, infra red, joystick, dpad, thought, fine control, coarse control, remote control, speech, hand gestures.
Added to all these, preferences users may have added to enhance their experience. Ad blockers, disabling javascript, blocking 3rd party scripts, blocking cookies, content filtering, user-stylesheets, or something else yet to be created.
Now, take all those unknowns, and add to them the rapid changes in everything between the application server and the end user. The “last mile” is in constant flux. Cellular networks are constantly evolving with changing dead zones, tower upgrades, infrastructure upgrades, tower lease agreements, etc. Bandwidth over copper continues to advance, fiber-optics are getting more throughput, ISPs are throttling and accelerating speeds for various reasons. Browser vendors are on a 6 week release cycle, meaning what was was slow last month, may be the optimal code path this month — and sometimes vice-versa. Browser vendors rise and fall and rise again. New browsers are introduced and older browsers play catchup. Websites are rendered in webviews within apps.
On top of this, we neglect security at our own peril. DDOS attacks, man-in-the-middle, CSRF, cookie hijacking, malicious ads, unsafe 3rd party scripts, even unsafe CSS!
We can begin to see why the browser has been described as “the most hostile software engineering environment imaginable.”¹ It’s not just the browser though, it’s the entire “last mile” of delivering web pages.
Why do front end engineers seem to make things more complicated than it seems it needs to be? Perhaps because most engineers don’t actually understand the problem space. This is not an accusation. There is far too much for any one team member to be well versed in. That is why we specialize. The concerns on the back end are different than the concerns on the front end. A single engineer might be able to write an entire application that eventually gets in front of an end user, it does not follow that that approach will be in any way satisfactory to the user or scalable.
Front-end development is hard. But it is not hard for hard’s sake. The problem space itself is hard, and has yet to be completely figured out, with more and more variables to balance all the time. So yes, bring your server-side solutions, let’s add “Modern Rails” or what ever other innovative solutions we can come up with into the mix of possibilities. Let’s see how much we can solve with these solutions. We all want whatever is best for the user. But while doing this, let’s also acknowledge the complexity of the problem at hand, and the history of our attempts to solve them. It’s unlikely there will ever be a silver bullet solution, only informed tradeoffs.
