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