Front-of-the-Front-End and Back-of-the-Front-End Web Development
bradfrost.com
bradfrost.com
I'm a small operation, but I'll spend entire days on the "frontend" where I don't actually open a web browser. I'm writing the code that does all the client-side computation from the data it gets from an API. I definitely see the distinction in my own projects and as teams grown, specialization becomes more important. So I can definitely see the distinction.
Now frontend development is so complicated that you need to be a programmer as well as a frontend developer to get anything done.
The first hint of deviation was when people started being called frontend engineers, we never needed that term before.
It is also my guess that this is why frontend developers went from entry level roles to the highest paid roles in most agencies I have worked at. A twist I never saw coming!
UI's 'used to be' thinks you installed not web pages!
That's what a lot of people are missing.
With complex UIs, which people see to have forgotten even exist (!) there's a big difference between front-of-the-frontend and back-of-the-frontend.
This is not new, it's 20 years old at least.
It’s like saying Talk radio is dead. No, it’s more alive than ever in the form of Podcasts.
There’s nothing niche about GUI application development, and has always been one of the staple exports of the tech industry. Yeah, it’s all JavaScript and CSS, annoying I know, but could be worse (Java, .net).
Ever since the inception of the Web by TBL, there was a drive to use the Web as a jumping board for "Rich Web Applications". Flash, Java Web Applets, Silverlight,... were all attempts to bring the functionality of native applications to the browser. They filled a space where browsers natively lacked API's.
They were also a threat to proprietary OS makers like Microsoft who sought to dominate the desktop space and what you could do with your computer in the late 90's early 00's.
It was the arrival of mobile devices around 2010 that upended the status quo. It created massive new billion dollar markets for new players like Google. It also introduced an entirely new technological paradigm which spawned competition between native mobile applications and web based applications.
All of that gradually coalesced around browser engines. These have evolved into incredibly complex beasts over the past 15 years with a cornucopia of API's and support for protocols. Just think about WebGL (look at the members of the Chronos consortium! https://en.wikipedia.org/wiki/WebGL)! Or how Microsoft decided to adopt Chromium for it's browser (https://www.theverge.com/2020/1/15/21066767/microsoft-edge-c...)
The end game here is much the same as it was back in the 90's: being able to control the sandbox in which both developers and users are playing. The difference being that you don't need third party plugins or whatever.
Front-end engineering is just an expression of this evolution. It's a specialist role who's goal is to build fully-fledged applications and UI's in the browser. And that's totally valid.
> highest paid roles in most agencies
Early agencies in the early 00's started out as "we build and maintain your website".
They were forced to pivot away from that pitch in a few short years. Either they moved towards integrated 360 communication, or they moved towards a specific niche e.g. mobile development, content strategy, UI/UX design, etc. This includes moving from building simple websites towards complex user interfaces to manage all kinds of data, content, and so on fluidly.
Sure, it's still possible to start a company that does "traditional" websites through frontend/backend development based on some CMS solution. There's still plenty of outfits who do just that. It's just that this type of engineering never did encompass the entirety of how the Web evolves.
I worked in a "traditional" agency around 2010. My former boss asserted back then that he doubted we would be doing the same thing, using the same technology, let alone we would still be around a decade from then. He was absolutely correct.
I think it's also worth remembering the context of old web tech. Computers were slow, javascript wasn't performant and backward compatability was still a huge issue. We did our best to use as little JS as possible.
When phones came along, computers got faster, and flash et al were earmarked for deprecation, there was a void of opportunity for javascript powered frontend frameworks, and the web industry started to build and embrace UI tooling albeit with a new lexicon.
This is untrue. Do you have cached data to show the next page while still retrieving it from your backend? When you retrieve data how do you cache them so you don't fetch redundant data? When the user is offline or on a spotty connection, how do you persist and reconcile whatever the user does?
The only reason you would do number crunching on the back end is if the information is private OR sending the low entropy information over IO is too costly OR the algorithm is to costly to run on the client side.
In most apps only the first issue applies. The later two issues arise when you try to integrate your app with analytics or data science.
So essentially for the most basic web app, most of the "number crunching" should live on the client side and the server is just storage.
- as a team, we generally prefer working in C# to JS
- there's benefit to having all your business logic in one place. It's easier to concentrate it in the back end than in the front end
- minor: we can roll back our server instantly, rolling back our client requires a user page refresh
If you want the maximum tradeoff for ease of development then having all of the UI rendered on the server is the ultimate solution in terms of ease of development.
- You can trust a server. Privacy is part of this, but there's other concerns as well - as an example, I would never trust a client to tell me how much an item costs on a purchase flow without double checking on the backend, because generally speaking I have less control over the front end and there's not much stopping someone from sending faulty data.
- The server is a guranteed environment. You know what's on your server, what its capabilities are. If something works in your tests, it's more likely to work in production. On the client, you're dealing with different browsers, capabilities, etc. Sometimes this doesn't matter much, sometimes it does.
- You can guarantee your server is always running the latest version of your code. That's generally not true on the client (or at least you need to put in a lot of effort to ensure that's the case).
- The server can scale in ways that clients can't. You can add more servers, you can add background workers, etc. Some of these analogues exist on the client, but you're fundamentally performance bound if your user is on an ancient phone or something, you can hardly spin up another phone and have it do calculations in the background.
- If you have different clients (mobile devices, APIs, etc.) you need to duplicate those calculations if they are being done on your client - which is a cost both in terms of duplicating the logic in the first place, and a potential avenue for issues if those calculations drift apart from each other.
- Generally speaking, it's easier (but by no means trivial!) to deal with race conditions and concurrency issues if the work is being done on your server (if only because you can be aware that that work is happening).
The price of a product would go into "storage" which means it's a server side calculation. Client side calculations that don't touch storage can stay on that side. So essentially thing of it this way... If something needs IO back to the server it means it needs to go into storage so that piece of data is a backend computation. If the data does not need to be rerouted to storage, the entire computation can live on the front end.
>- The server is a guranteed environment. You know what's on your server, what its capabilities are. If something works in your tests, it's more likely to work in production. On the client, you're dealing with different browsers, capabilities, etc. Sometimes this doesn't matter much, sometimes it does.
For computations it doesn't matter. Incompatibility issues are usually html/css related.
>- The server can scale in ways that clients can't. You can add more servers, you can add background workers, etc. Some of these analogues exist on the client, but you're fundamentally performance bound if your user is on an ancient phone or something, you can hardly spin up another phone and have it do calculations in the background.
The client side can scale in ways that the server can't. That's why you need to offload as much as possible to client side. If you have 1000 connections to one server, that's 1000 computers available for compute.
>- If you have different clients (mobile devices, APIs, etc.) you need to duplicate those calculations if they are being done on your client - which is a cost both in terms of duplicating the logic in the first place, and a potential avenue for issues if those calculations drift apart from each other.
Client side computation costs are essentially free. These are computers being hit by thousands of connections where every piece of processing power counts. You can offload stuff to the client side that can never be put in a web app.
>- Generally speaking, it's easier (but by no means trivial!) to deal with race conditions and concurrency issues if the work is being done on your server (if only because you can be aware that that work is happening).
I'd say it's easier on the front end. JS gets rid of a lot of issues related to concurrency due to it's concurrency model (lockless and single threaded). Additionally, concurrency issues arise mostly from shared state and shared State is more of a back end thing. Even in most web apps concurrency issues are delegated to the database where it's mostly only deadlocks that can leak over to the web app.
People can have both sets of skills and, obviously, there is an overlap BUT, in my experience, very few web-developers have good enough design skills to produce a professional looking UI. Most resort to pre-made frameworks like Material Design or Bootstrap in order to produce decent looking UI.
This is division of labor gone out of control.
Complexity doesn't get simplified by merely renaming things. Bloated javascript frameworks and associated "infrastructure" keeps requiring more and more people to manage them.
You can put a good backend guy on the 'back of the front end' no problem, it's sometimes similar work and it can feel like 'regular coding' - sometimes it helps to have the same team working both sides of the endpoint.
But the 'view' components usually require very specific knowledge of the component system and also the ability to work well with the design team, which is a different thing.
It's not really a stretch.
Have you tried upgrading your React app that was 1.5 years old? How many times upgrading anything in npm gives you the worst nightmares?
It’s not just bloat, it’s the stress that front end dev brings. It’s a chaotic world, constantly changing for god knows why and the entire ecosystem does not value robustness and longevity. In fact, they've made it cool to break things all the time. Robust tools are considered "old fashioned". Apart from Angular, which is a still finicky, the rest of the dependency management is a complete nightmare.
I can easily revive a 4 year old backend code. Most likely without a single error. With absolute and 100% certainty, I can guarantee the opposite for any front end code, even Angular projects. Node js, the backbone of managing js projects itself doesn’t value backwards compatibility.
React is a special beast, I don't like it, yes, it's a little bloated and no, I don't so much think it's quite suited to the front/back of frontend division.
Your problem with bloat and fragmentation though, is not about this particular form of division of labour.
Front ends change a lot more for a variety of reasons.
One reason the front end evolves more is there's more going on, and more detail. The backend is logic, which can be more succinctly articulated by code. That's what code is for.
Most code was never designed for UI, and even HTML/CSS was never designed to do what it's doing. A simple web form can involve a lot of cross-cutting artifacts and complex statefulness.
Even with a great set of tools it can be quite hard to get right, and requires a different way of thinking than on the backend.
Front end problems are usually however, narrow in scope - a screen can usually only ever be so complicated, whereas on the backend, true scale can make a lot of things hard.
My main gripe is the people behind major frontend projects - Node, npm, React, etc. and their overall philosophy. The community is a shitshow and I hate how unorganized, unplanned, broken the entire ecosystem is. The worst part is that this is celebrated.
For straight up web or small companies, Wix, Shopify or Wordpress is fine. Look how great HN is with minimal tech.
For 'Web Apps' it's obviously more difficult, and the current of tech is unavoidable, but if you stay in the middle lane and don't use anything to risky, certainly with 'backed' tech like React you should be fine.
If your business is Widgets, then everything else should be 'off the shelf'.
If your business actually is web-tech in some way, you can start to push the boundaries.
I wrote a collaborative model editor in React and MobX, using some nigh unknown JS library to manage collaborative aspects and d3 for visualizations. All while interacting with multiple services. I upgraded seamlessly across webpack versions, despite continuing to use legacy decorators.
Plus, churn in the front end is completely overstated. Most libraries from a few years ago have the exact same APIs, but perhaps also added a new way of working. You do not need to adhere to this new way of working, or you can progressively adapt it. Small libraries died, but isn’t it professional diligence to evaluate the likelihood of that happening and the risk you take in the first place not doing it yourself? Especially when it is simple.
A thoughtlessly npm’d together FE is a pain, as is any thoughtlessly bolted together anything. Granted, some things lend themselves more to disaster than others.
I think it’s a people thing. Hire lots of hardcore .net peeps to wire up a complete setup, and of course nuget will be solid and npm a flaming mess.
I'd say ESPECIALLY on Angular projects (or React or Vue). Look at the package.json of any JS "web app" in any of the popular frameworks. Now imagine how many of those packages will have breaking changes in 1 year. By 2 year mark, many of them will be abandoned completely forcing the app maintainer to replace, or continue using an old version if that is even possible.
They require an understading of UI basics and reading the documentation. That knowledge is rarely specific, it's mostly the same pattern applied in a different manner. If a "good backend guy" can't read that (usually super simple) documentation of the frontend framework and understand how to apply it, I would not call him a "good backend". Just like a frontend dev should be able to read and understand what a node server does, a backend dev should be able to understand basics of UI frameworks, otherwise, it's not a developer we're talking about, it's a glorified typewriter.
It's not a technical ability issue in general, though there are a whole bunch of quirks such as browser compatibility that it can seem a little unfair to expect someone who mostly deals with optimising database queries and algorithms to also have to learn.
There is always a gap between what the designer produces and what needs to be created to make a fully functioning application. A good frontend-of-the-frontend developer has the passion, experience and user empathy to fill in this gap and make a site that is pleasant to use.
I say all this as a backend/platform developer.
1) It takes time to get to know the framework, it's know-how, and often the docs are not clear.
2) Good UI work is almost always more than just 'stuff on a screen'. But it doesn't have to be if you have good designers.
When you have 20+ engineers, it makes sense to specialize. When you have 3, it's a huge hit to your productivity. The scale of the app is mostly irrelevant to this.
Good front-end devs are usually stronger with browser-side code. I usually see smaller html/css files, flex and grid being used and a11y reader and keyboard-nav issues taken care of. And the javascript is small and generalized (not much hard-coding). With full-stack devs I normally see a mess because they are just java programmers.
The core thesis of mine is that on the app side of things we've always had fairly thick clients where a lot of the "backend" complexity lives in the client. This has always worked, i.e. iOS developers are responsbile for and comfortable with both the UI/UX aspect of their job and the backend aspects. I don't really understand why the web would be different from iOS and Android in this regard. I suppose one stark difference is that both iOS and Android always had a turing complete programming language at the core of development, it simply isn't possible to learn "only" layout with iOS and Android. Although, storyboard and XML views are somewhat similar to CSS + HTML I guess.
0: https://hugotunius.se/2019/06/26/on-being-a-front-end-engine...
The community culture obviously also influences these discourse, but a surprisingly large chunk of the regard or disregard for UI/UX comes from using the tools you're provided by the platform, so much that unfortunately (or fortunately, if you've chosen the right platform), these factors influence one's learning and result much more so than even hard work and talent. A change of perspective is worth 80 IQ points, like Alan Kay said.
Anecdotally, my impression is that mobile-focused designers are much more attuned to interaction design than their web counterparts; much easier to build nice UIs when they have been fully thought out.
However now it seems people are learning React, Vue etc first and so to a man with a hammer every problem looks like a nail.
I truly believe we have lost sight of progressive enhancement in modern web dev. Especially with the business-oriented drive towards hiring full-stack, two for the price of one mentality but 9 times out of 10 you end up with someone who doesn't appreciate the subtleties of each layer of the UI and how they interact. And now with browser vendors pushing out new features faster than we can learn them, it really is becoming overwhelming, even if day to day things are still manageable.
When you have a million ways to do the same thing, each with its own trade-offs you can start to feel some career anxieties.
I fully agree with the sentiments in this article and hope it will be heeded.
This divide has always existed between those who were making the UI libraries (WinForms, Qt, Telerik and what not), and those using those libraries (app developers).
Because the browser allows for a lot more customization than WinForms or Qt, app devs get sucked into pixel alignment problems or crap of that nature.
If you met someone at a free cracker and dip event and they self-identified as one or the other, you could potentially network and collaborate and not step on each others toes. Even in Flash. One made art and masks and timelines and tweens, and one wrote actionscript...I think you get the picture.
The issue is more that the front and back end have divorced. As we all actually know, the backend receives a request and responds to it, some of which can be contextually appropriate to the particular source of a request, if you know what I mean, nudge is as good as a wink. Such a response, that probably has a "bundle.js" shoved up it's nether regions, actually constitutes a sort of tennis "serve" or volley, that may unleash a programmatic payload, via said javascript (no need for bundle.js. You can hard-code js and css right into server-rendered templates, voila scoped css lol) the interactions between this initial page rendering and the activation and machinations of said javascript are an implicit set of dirty activities folks often allude to in discussions of SSR and hydration and other such silliness encountered by running your entire webserver application on the dynamic single-threaded event-loop runtime known as "the web-browsers programmatic API, brought to you by javascript", and having the largest spyware erm browser makers scripting engine blessed with more money than most countries raise in annual GD whatever annually dedicated to the impossible task of making it map to how computers actually work, which it wasn't built to do, am I digressing here? I was trying to say that isomorphic code is not anything remotely desirable to most people for most things, as the real implicit goal on this tangent is that the server wants more intimate knowledge of what a client is doing in order to better provide the illusion of the user manipulating the data, etc, etc. RPC gui is different than remote folder browsing in a vast open scientific institutions network in which index pages provide valuable insight as to the sort of files/documents/data/research-papers/cat-pix available at said resource endpoint...ah such trust...was I digressing again?
We used to say "Web Designer" and "Web Developer" Does anyone have time to discuss our good lord HTTP?
Yes front end developers do more, than when the web was just html and tables, but that’s just evolution.
You want to focus on the UI only, UI developer fits. With complexity increasing, web developer title doesn’t make sense as it is too generic.
But backend, being it in java or node is a backend. I don’t see the need for this new categorisations.
I think the question arises from Fullstack term usage? fullstack front end and fullstack backend has been thrown around in job interviews, so fullstack alone without context doesn’t make sense: I don’t think it ever did.
Knowing how these layers work as concepts is a lot more important than deep expertise with a particular implementation.
From the perspective of a new hire, you'll spend easily as much time learning their idioms, mutations of the platforms, unique glue code and business logic as you will learning the platform.
unless that is a trivial amount of time, which it generally isn't (and obviously can't be if you are expected to learn a new platform in the same amount of time to a level of reasonable proficiency), then the amount of time that you would devote to the learning it is probably not that worthwhile for the company to let you lose on the platform you don't know.
Of course my perspective is as a consultant, so if I'm brought in for 6 months and I do not know part of their stack it is just not worthwhile for me to learn that part of their stack, they generally want me to be productive on the parts of the stack I do know. If I was going to be at a place for some years maybe the motivations would change, but bigger places tend to optimize and specialize their developers and not want people to be "full-stack".
The rationale is that it is often easier for the JavaScript to talk to one backend facade layer, and have that backend facade handle talking to the "real" backend servers. So think sequencing and/or parallelism of API calls, serialisation, transformation etc all happening on the backend server before sending only the final result as simplified JSON to the browser.
So now your front-end dev also needs to know java/go/c++ as well as html/CSS/JavaScript/typescript :)... We just call them frontend engineers and be done with it. The best engineers tend to have broadly applicable skills and can rapidly learn something all with a smile and good attitude. A sneering/condescending/moaning/complaining/whinging aversion or outright refusal for writing CSS/c++ (it cuts both ways) is usually a red flag IME.
It’s no good, and oddly it has been the go-to divide and conquer tactic I have seen in at least two of my previous companies. In fact, a very long time ago I had a company straight up tell me and other frontend developers that all JavaScript work was too advanced and will be handled by their ‘real’ developers (the backend people). It was just Jquery work at best, zero app architecture.
This happened again at another place where there would be people that would do the CSS and pass it off to people that hooked up the JavaScript.
I’ve been on both sides of the coin, and in both cases I either felt like it was complete bullshit for myself to be limited, and if I was on the more ‘favored’ side, I would feel absolutely sorry for the front-of-front people being limited.
Companies that have strict lenses to view developers in this way will always have a limited view on an employees potential. They also generally consider certain types of work lower class. So for example, they may think someone from QA can move up to front of the frontend, but the frontend person could never seriously move over to the backend. Both the QA and Frontend person are basically maligned to their caste with their potential capped. I am speaking very specifically of companies that have clear castes (there are many still), and not speaking of the new fullstack trend. You’ve been warned, you’re up against an insidious bias.
With all that said. One of the things that makes me semi decent at frontend work is that I know css and js well enough where I can find a solution that can use css in a way that minimizes JS. I couldn’t get there if stingy idiots force fed me one class of work all day, every day. This is a massive opportunity cost issue if you are facing this.
The prime directive for determining who is dope at one particular thing has only one use case - time sensitive delivery. If there’s a short timeline to get to prod, or a time sensitive bug, or critical deliverable, or critical architecture (you need the really good css people setting up your layouts for example, not the sql guy that knows some css), yeah, go ahead and discriminately delegate.
Otherwise, let the fucking developers grow.
If it's not responsible for generating HTML, CSS, or JS, I don't really consider it front end.
Front End has to be explicitly called out for developers that will be responsible for developing rich UX features.
Front End is gaining more prominence, as more companies are moving to Cloud services and want to leverage Front End for custom business logic, which in a way is moving the stack to Front End. In near future, there will be a job description for Front End Full Stack engineer. I'm all about it.
Certainly there are complex UIs that require sophisticated front ends, but you probably aren’t building one, even though you’ve convinced yourself it’s necessary.
But if the requirements are for less page refreshes and high interactivity with always-fresh data, then client side rendering with a client side cache and cache management become important. Like Apollo Client, or what have you. Does it add unbelievable amounts of complexity? Definitely. Is it needless? Depends on the goal.
I would argue it's easier than manually polling for new data, managing the cache by hand and ensuring that everywhere the data is needed has been updated, and updating the DOM as a response to that new data.
So to answer your question: when done right, the user is served by having the most up to date information displayed for them at all times, with the number of network requests for said data kept to a minimum.
Is it worth it? I don't personally think so in the big picture, but in my day to day having this complexity live on the client side gives us so much more control over the UX that it's necessary to build what is expected.
Whether the user actually desires this experience is another question entirely...
The desktop app is dead. There is only the web app. Remember all those complex desktop apps that existed? They are all web apps now, and what would have been a new desktop app will become a new web app.
The only other app game in town is mobile, and people still use web app technology to build that even.
Enjoy your UIs, because they ain’t going anywhere, ever. There is no more ‘why’ in this question.