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.
I am sorry but...Front-of-the-side-of-the-up-of-the-what?
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.
This is not crazy, it's been this way in any app of scale for a very long time.
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.
Anyone who says front end isn’t bloated and it just feels like coding backend really haven’t tried either one of these or both.
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.
I have been coding UIs for over 20 years on and off, and I've done everything.
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.
It's true, frontend is complex. User interfaces and interactions are full async and all behavior needs to be captured and tested. Server side code can get complex but there is a lot less externalities and requirements are well defined.
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.
Keep it as simple as possible and focus on the experience not the technology.
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 can guarantee the opposite for any front end code, even Angular projects
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.
Not fair. Upgrading java libs like spring is just as laboursome given enough major releases have lapsed. Backenders need need to get their oumf out of their oumfs, and realize this is all about what you’re used to. Upgrading spring if you know spring is not as hard as upgrading React when you have no clue about React. There’s no significant difference.
I’ve never experienced these problems, and I run productionized apps from 2016 still. What kind of feature sets were you trying to achieve?
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.
Interestingly, I spent more time fighting gems and nuggets than npm, despite spending vastly more time with npm.
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.
>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.
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.
My experience is that fundamentally, usually good backend developers are not good UI developers. They don't know or care about how to write nice-to-use interfaces.
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 understand your view, but it's just a lens you are used to looking at. At the bottom of the rabbit-hole, you model data and state like you do on the backend and you map that via provided UI layer functions and objects to the renderer.
Yes, there are edge case quirks but most of them is stuff you don't need to care about, and when you do, are a google search away. A good frontend-of-the-frontend developer is great at state management and deriving state from the UI model the designer presented it and the data model the backend presented. I believe backend developers have the same skill, just lack experience/"passion" in applying it on the UI end.
I think this probably scales to team size more than the app scale itself. I've worked on high scale apps before where I was a full stack developer, because we only had a few engineers on the team.
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.
It seems that larger companies can afford the divide. But medium to smaller companies will want full stack.
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.
I think it's really interesting to compare the web to apps in this regard. In fact I wrote a blog post about this as a response to "The Great Divide"[0] a few years ago.
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.
Wouldn't the main difference be that iOS and Android come with a very complete and high quality default UI toolkit? It's easy to build a decent app using just the system libraries, whereas on the web you're pushed to reinvent the wheel from the very start (how do I load my CSS?). Technology churn is also minimal in comparison.
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.
You're right; the medium definitely shaped the message here. I've worked with and near many native and web teams, and have observed the engineering conversations of the folks from entry level to senior level. The difference in perspective and execution is notable each time. More interestingly, a transition transition from one side to another also changes perspective and conversation.
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.
Well it used to be that you would learn HTML and CSS, then some JavaScript for basic UI, dom interactions then later Ajax.
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.
Yeah, we used to call them "Web Designers" and "Web Developers".
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?
Every developer is a potential full stack developer, even if they don’t realise it. The user interface is just another interface, with its own set of rules.
It seems to me front end developer and backend developer still works, although front end developer role evolved, can’t see a need for this extra long names.
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.
As someone who is generally described as fullstack the problem with the term is what stack is that? When you say you're fullstack there are so many variables that come into play that it is unlikely you are going to be able to just be dropped in and work with any company's stack. Your full stack is not theirs.
Eh, beg to differ. There is certainly domain knowledge to be had, but the underlying principles behind any particular layer of the stack tend to be more similar than different across languages and frameworks. Everyone needs a database, authN & authZ, network requests, state management, pretty forms, error handling, optimized images, etc etc.
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.
this is true, but
>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".
For me, and the places I've worked, "Front-of-the-Front-End" is usually described as "UI Engineer". However, I am fully aware that can and does mean something different to other people.
I've noticed in more and more projects a trend for the front-end team to build a legit backend server as a facade interface for multiple other backends. So I guess this is the front-end-of-the-back-end-of-the-front-end?
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.
This type of bifurcation limits the growth of developers, and makes evolving inorganic. So how does one get better at either side of that coin? Talk to your boss and say ‘I need to do more front of the front work’, or ‘I need to do more of the back of the front work’?
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.
I consider it anything that doesn't take place in the user's browser. Writing the APIs, interacting with the DB, defining the backend data models, dreaming up the microservice architecture, whatever your workplace is doing.
If it's not responsible for generating HTML, CSS, or JS, I don't really consider it front end.
I've also noticed the trend that "Full Stack" now really means back end in job descriptions.
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.
But... why? Doesn’t all this seem needlessly complex? How are users better served by adding complexity to the front end?
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.
Agreed that it's complex, but I think the "needlessly" part is up for debate. Considering we're all here on hacker news, we're all used to and just fine with the idea that if you want fresh data, you refresh the page. I agree with you that for 99% of websites, this is just fine.
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.
Apollo client? you mean where the Meteor Dev team suddenly leaped to when it dawned upon the world that Mongo as a primary-store and a bizarre architecture that let you walk away with exactly one artifact towards your inevitable rewrite? (moustache templates!) was probably not going to take-off in a big way.
Awesome integration and polished docs etc.
Mini-mongo and pub-sub with websockets always for everyone? mmmm it ran rather slowly...
Put that at 30 degrees North North-West and integrate "what is good for a FAANG may bankrupt me and not provide foreign keys" lol..
Nothing against VC, but lets separate busy-work trends that mega-corps use in trench warfare of attrition (Google has more developers than you do.) from productivity tools.
GraphQL? I'd probably Postgrest if I were a one-human front-end/SPA shop
I mentioned it as an example of one of the more popular solutions available. Yes, it's complicated and requires a deep understanding of what it's doing - and even then it has warts that you have to work around - but we're talking about situations this complexity is necessary for the desired UX.
Whether the user actually desires this experience is another question entirely...
So, I’m going to fill you in on something. My snark level is at max this morning, so forgive me a bit if you can.
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.
Actually I'm thinking this is a good route, you can use a few simple standard backends (Firebase, Mongo) and all the work is just in one layer, the browser gui.
IMO, full stack is primarily "can write the business logic in both the FE and BE". Someone with CSS and design skill still needs to step in to makes things look great.
