This honestly seems needlessly arbitrary. If you’re the person whose job it is to write the component for a button making that button “work” (which almost always making a call to the backend and/or loading up an additional component or making changes to the current one) is not anymore complex nor is it really a different skill set. Front and backend makes sense as the two don’t even have to be the same language and front end is GUI work while backend is more number crunching, etc. “back of the front end” and “front of the front end” doesn’t have anything close to the same kind of compartmentalization. At least not in my experience.
It used to not be so, a front end developer at a typical web agency would just write HTML and CSS, maybe a sprinkle of jQuery, and any programming/logic would be done in the backend templates by someome else.
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!
I mentioned this in another comment, and it’s odd that this macro outcome is not more obvious. The ‘application’ industry didn’t disappear, it just packed up and moved into the browser.
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).
You can always continue to write JS as a static piece of code in your HTML, use raw CSS, and use imperative, lifecycle-agnostic libraries like jQuery; there is nothing stopping you, and nothing about that has changed. It’s just that there are better options now.
I do it for a living so that's not really an option. That's also where my perspective is written from, as an industry full stack dev turned contractor, commenting on the past. I wasn't trying to say one way is better than the other, it has just been a surprising outcome that's all.
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.
The assumption here is that the Web equates hypertext: hyperlinked static text documents sprinkled with images and a bit of Javascript.
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.
For static pages, the "front-of-front-end" developer is broadly the "web designer" and does CSS most of the time. As JS sites get more complicated, those buttons need behaviour which is generally also that person's job, so now they do JS.
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.
It's more efficient to do number crunching on the front end whenever possible.
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.
Some other reasons to do computation / business logic on the server:
- 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).
>- 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 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.
Not sure I agree, supporting multiple platform clients or having the ambition to support multiple clients usually means for me it's easier to do as much server side as possible.
Easier to develop for but in terms of raw computation costs and speed, client side wins.
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.
I don't really agree those are the only reasons. We keep as much of our logic on the server as possible - partly for the reasons you state, but also because
- 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
Sure but I was merely saying that the backend is more data focused (and should have worded that better) while the front end is more about displaying and interacting with that data.
> If you’re the person whose job it is to write the component for a button making that button “work” (which almost always making a call to the backend and/or loading up an additional component or making changes to the current one) is not anymore complex nor is it really a different skill set.
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?
There is a comparable divide between web-designers and web-developers.
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.
