
Dividing front end from back end is an antipattern - Kinrany
https://www.thoughtworks.com/insights/blog/dividing-frontend-backend-antipattern
======
d--b
No, it's not the division that's the problem, it's having one driving the
other.

The thing is front end dev is actually very different from back end dev.
Having done a lot of both, I can say that they require very different
skillsets and different knowledge, so it is quite normal that they're not done
by the same people.

Now, if your team is frontend first, you'll likely screw up your backend
design in the sense that you won't be able to define a nice API for it.
Similarly, if your team is backend first, you'll have a nice API, but probably
won't think about all the frontend needs, and will have to patch things
nastily down the road.

Truth is, coordinating people with different skills is hard.

Now this kind of articles take aim at teams that don't manage to make it work.
So yeah, not being great at managing teams is an antipattern...

~~~
Silhouette
_The thing is front end dev is actually very different from back end dev.
Having done a lot of both, I can say that they require very different
skillsets and different knowledge, so it is quite normal that they 're not
done by the same people._

I've seen this argument many times, but as someone else who has done a lot of
both, I've never really understood it. It's just programming, like any other
software project. Sure, you might use different languages and each might have
its own tool chain, but unless you're using radically different languages or
tools in the two cases, those are probably superficial differences. Most
experienced professional developers can probably work in several languages,
and you pick up a new tool chain in days if you need to. But the fundamentals
of programming are still much the same whatever you're building. Certainly
different _applications_ also have different knowledge and skills -- writing a
business automation tool is likely to be quite a different experience to
writing a control system for ABS in a car, say -- but for a typical web app,
the front and back ends are usually going to overlap a lot in this respect.

As I mentioned in another comment, the huge exception to this is junior roles,
because at that stage in someone's career they probably haven't gained much
diversity of experience yet and you probably should start by focussing on one
particular aspect. So if your project team consists of many relatively junior
people and not so many seniors with broader experience, sure, you're going to
put most people specifically on front-end or back-end, at least to start with.

~~~
murgindrag
Understanding how to, for example, efficiently organize a database is a very
different skill set from, for example, making a response, accessible CSS/HTML5
design. The core skill set is only vaguely similar. Doing back-end well
requires in-depth knowledge of algorithms, networks, systems, and computer
architectures. Doing front-end well requires in-depth knowledge of human
beings.

I think the problem here, though, is trying to overgeneralize. I've worked on
projects where you want to split things vertically (apps / plugins / etc.
which have isolated functionality and handle back+front end), and horizontally
(front-end / back-end split).

That comes back to what the system does, as well as the make-up of the team
(full stack developers will do different things well than teams of
specialists).

The danger comes in when you try to mix pieces of the two. I had a system with
a simple, elegant architecture with a vertical abstraction. A junior
engineering team came in, who had only seen horizontal abstractions. They
didn't understand it. They didn't get functional code either (they had only
seen OO). They decided it was all very confusing spaghetti code, broke all the
vertical abstractions, put in half-done horizontal splits, and the system
became unmaintainable.... You can blame that on junior team from the high-
level descriptions, but the deeper problem for that system was mixing
abstractions and programming models.

~~~
speby
I disagree here. I think the comment by Silhouette is still very applicable
and the context is within the realm of more senior folks. Understanding how to
efficiently organize a database and doing the necessary work on a front-end
web app to make it responsive, have a coherent SASS/CSS framework, etc., are
actually skills I would generally expect much more senior developers to have
if they have been doing web development for many years.

Yes, I have seen "senior engineers" who tend to be more biased in doing back-
end or front-end work, and in some cases, those same people actually prefer
one or the other, too, but to expect them to be ABLE to work efficiently up,
down, and around the entire stack vertically and horizontally is not at all
unreasonable. And yes, you have to know "a lot" to get there but that's what
years and years of experience gives you if you have successfully built working
software for a long time.

~~~
mercer
While I do not entirely disagree, I think a /very/ important caveat is that a
lot of these domains involve not a particular level of skill in itself, but a
lot of domain knowledge that is entirely a matter of 'knowing'. No shortcuts.

I've worked with really good senior engineers, but part of what made them good
was that they /weren't/ getting involved with the nitty gritty of centering a
div or making something work cross-browser. This was the domain of the front-
end-only masochists.

I sort of consider myself a full-stack developer, but I'm quite aware of the
lack of 'stuff I should just know' in all the stuff involved with that
(devops, front-end UI/UX, front-end 'making it looks right' CSS/HTML, back-end
DB design, back-end application structure, etc.)

My 'broad' knowledge is perfect for many of my clients, but I wouldn't sell
(or guarantee quality) to anyone demanding proper expertise in most of these
particular areas. I'll probably fuck up something setting up the Postgres db
that only becomes apparent under high load. I might forget some crucial
element about hardening the server(s). My JS knowledge is probably already out
of date because the last time I did serious JS development it was Webpack with
React (without hooks) and mostly no css-in-js. I'd probably still pick
sass/scss for comfort. And webworkers are fascinating but I never got to it.

Now I'm pretty smart, and as an autist I spend what my therapist would
consider potentially an unhealthy amount of time reading up on ALL of this
stuff. My work is my hobby. As I'm nearing my forties I'm definitely giving
that some thought, but I digress.

My point is that except for a few unusually gifted people, I find it truly
hard to believe that it's possible to be a full-stack web developer who is
actually /skilled/ at all parts of the stack. There's way too much domain-
specific knowledge (that is constantly changing and evolving) for a normal
human to be able to stay on top of, let alone be an expert in.

(again, with some incredibly impressive exceptions).

~~~
Silhouette
I think there's truth in the fundamental argument you're making, but I'm not
so sure about the little details argument.

When I was a junior programmer doing my first job, I knew exactly how to check
the length of a list in the language I was using, and hundreds of other
everyday little details like that, without needing to look anything up. But
back then, I was only using one language, and I was mostly doing basic
implementation work all day.

Fast forward a few decades, and I can't always remember those little details
any more. Sometimes I get them wrong or have to look them up. So am I a less
competent programmer than my junior self?

Of course not. It's easier to confuse details like that when you've seen
subtly different versions of them in each of the dozen or more languages
you've programmed in professionally. But is it really important to remember
many variations of each of a thousand little programming tasks, when I can
look them up in moments if I haven't used them for a while and then need them?
Would that really be a better use of my mental abilities than understanding
what makes a good abstraction or how to evolve a useful software architecture
or how to develop a robust testing strategy or how to quickly recognise a
missing edge case that could lead to a bug or how to design out that edge case
in the first place or how to find or build tools to help?

The reality is that Me 2020 Edition would outclass Me Junior Edition by a huge
margin in any skill that matters: productivity, code quality, communicating
effectively, anything. The extra depth of understanding and breadth of
knowledge _far_ outweighs the trivial effort of looking up a detail now and
then if I'm starting to work on something with a language or library or tool I
haven't used for a while. Those little details are superficial, and it's the
more substantial changes that really dictate how effective I am.

In fact, I'd argue that a pretty good benchmark of someone's level as a
developer (and probably a lot of other things, too) is where their threshold
for something being a superficial detail lies. What areas of understanding are
so simple to that developer that they don't need to know or remember them,
they can just pick them up quickly and reliably on demand whenever they need
them? To a junior front-end developer, that might be things like learning the
DOM elements for semantic markup. To a more experienced developer, it might be
remembering how `this` works in JavaScript. To a more experienced developer
still, it might be entire libraries and frameworks: it doesn't matter much
whether your project using Angular or React or Vue or TheNextOne if they can
just pick up whichever it is and be using it fluently within hours anyway even
if they've never touched it before.

------
tedk-42
Our cross-functional teams have both frontend and backend engineers working on
business goals for their team.

The skillsets of definitely different though and they both compliment each
other. I'm really not a fan of having 'full stack' engineers which do
everything. The truth is they are often stronger in frontend or backend, with
a few unicorns that excel at both. Frontend engineers know frameworks well -
angular, vue or react with other frontend concepts like cookies and frontend
security. Backend engineers don't need to know about cross-site scripting,
CORS and a bunch of other things that have been standardised and built into
browser security.

Backend engineers have used more languages outside of javascript and work with
a much larger set of technologies day-to-day (databases, queues, file systems,
other APIS, RPC etc). They see the client (frontend) like any other consumer
hitting their system.

They can't be unified because tech stacks and the web is so big and there are
so many ideas and new things coming out. I'm not sure if a browser could ever
do something like reading a message from a Kafka topic. A frontend dev should
never have to worry about that, so why on earth would they ever need to know
anything about Kafka? A backend dev might have to play with it though.

~~~
lolinder
The article isn't advocating having everyone try to be an expert in
everything, see his conclusion below. The article was prompted by an
interaction with a company which didn't want to spend time improving their
front end because they felt that front-end work was beneath them. The article
is basically saying to change that attitude:

> To be clear, I’m not saying that we all need to be experts in everything.
> That would be impossible. Today’s technology stack goes down a long way, so
> being a genuinely balanced full-stack dev is probably not the most realistic
> of goals — but staying open-minded is.

~~~
tedk-42
Yes and I agree with the writer on that. But I dislike his view that dividing
frontend and backend expertise is problematic

------
hardwaregeek
I agree with this article more than I expected. I suppose a more accurate
title would be "Dividing front end development from back end development is an
antipattern". At first I thought it was about the actual act of separating the
codebases.

I find it really baffling how much animosity there is towards front end.
Nobody goes out hating on back end. If I had to guess why there's so much
hate, I'd posit lack of control. Front end development requires relinquishing
a lot of control. You can't really choose your programming language. You can't
choose your styling language. Often times you're being told how something
should look by a designer, which can be a bit of a blow to the ego. Being
ordered around by a _gasp_ artistic person. The horror.

Even if you get to decide how things look, that's even worse in some ways. I
know I've spent hours slaving over designs that just don't look good. Maybe
you give up and resort to Bootstrap/Material Design, but that certainly feels
like defeat.

I'll admit. Front end takes some acclimation. I hated debugging JavaScript for
the longest time. But with modern tooling it's quite nice. Plus there's
something really amazing and challenging about having real, non technical
people interact with your code. Only developers will notice an API bug, but
everybody will notice a client side bug.

~~~
clintonb
My dislike of frontend work mostly stems from the fact that, at least when I
started, there were no generally accepted best practices. I started out with
Backbone.js, and it wanted to be “unopinionated” in things like directory
layout and the best methods refreshing data. Every tutorial I read did
something different. Compare this to a more mature framework like Rails or
Django, and you can see how one might easily waste time on some of the basics.

A few years ago, I built a small project using Nunjucks templates that needed
translations. There were a half-dozen different ways of extracting
translations, and most of them required some form of manual work. Coming from
Django, with a single best way of handling translations, this was annoying.

I prefer “batteries-included” frameworks that let me focus less on foundations
and more on the actual business. Angular was the only framework I used that
resonated with me in this fashion.

Now I use React, and spend most of my time debugging tests.

~~~
skeletal88
I have the same issue with frontend dev, or other "unopinionated" frameworks.

I just want to get started with something quickly, not spend hours or days
(when I'm doing something on my free time, not at work) reading about
different libraries or plugins that I have to choose from, to accomplish
something seemingly trivial.

------
Vinnl
> What does a frontend dev actually do that’s so different from a backender?

Deal with and pre-empt cross-browser compatibility issues, ensure
accessibility, iterate on the UX, deal with stateful-but-not-persisted
applications, optimise for constrained devices whose hardware you do not
control... And keep up with whatever technologies exist to help with those
challenges.

The article even mentions some of these. Yes, you could just say back-enders
should know about all that, but... There's a limit to how far a single human
can vertically integrate their knowledge. For example, the same argument could
be used to claim that 'developers' should be able to handle all the challenges
of the back-end, of database adminstration, of operations, and why not, let's
throw in business development, design and content strategy as well.

In the end, it mostly depends on what you can afford. If you're a small,
bootstrapped startup, you have a couple of people doing everything. But as you
grow, specialisation can become more efficient.

~~~
dragonwriter
> deal with stateful-but-not-persisted applications

No, they don't. The application is persisted. The store is one or more
external resources, but that's _usually_ the case with persistence, even on
the backend.

~~~
allover
Parent is simply referring to the front-end skill of building an app with rich
client-side state that isn't persisted to a backend DB.

~~~
dragonwriter
> Parent is simply referring to the front-end skill of building an app with
> rich client-side state that isn't persisted to a backend DB.

Frequently some or all of the state _is_ persisted to a datastore, whether
client-side or backend (which of those isn't really a substantive difference
in the skill involved, except that backend stores make planning around
communication failures more important), and even when it's not, “my internal
data structures don't also get loaded from and saved to an external store”
doesn’t add any additional required skill, it strictly reduces the set of
skills that need to be applied.

~~~
Vinnl
Working with partially-completed forms is a completely different type of state
management than storing and loading state from a datastore.

------
sroussey
Sometimes I stoke my gray beard and sigh.

It depends. Funny how such an indiscriminate answer is so acutely accurate.

Both sides (all sides really — hello devops), should have an appreciation of
the other.

But so much depends on team size. 3? 30? 300? 3000? 30000?

When a company is young, you hire generalists. Fullstack. But as you grow, the
dynamic changes. Fullstack devs end up doing more one side vs the other. You
hire more specialists.

Team dynamics, engineering structure, product embeds, matrix orgs... so much
can have an impact. What is your ratio of senior to junior? Do you document
like a remote first? How orthogonal is your problem space? So many things. Not
taking them into consideration is the real antipattern.

------
macca321
The title is correct, but the article misses the most important thing. The
reason you should not divide them is that delivery of a non trivial feature
requires change at each layer of the stack.

Conway's Law etc etc

------
christiansakai
As a fullstack dev, this article resonates with me. I was worried that being
Fullstack dev is a career killer (what I heard), but I found out its not true.
In my current company (one of the tech giants/unicorns), there are many small
independent teams that maintain stuffs themselves. In my team we maintain
everything, from frontend to backend to devops. Python, JS/TS, Go.

Not impossible to achieve, since frameworks/methodologies are transferable.
I.e., I use React, but I learned Angular2 in just a day or two and was able to
be productive right away for maintaining/building feature in some apps that
use Angular2. Backend we use Express, Flask, plain Go. ES, SQL, MongoDB,
DynamoDB. Doesn't matter. Granted, everyone in my team are senior devs, more
than 5+ years exp.

Besides, after a while doing just frontend or doing just backend you'll get
tired and sick of it and want some change. It is nice to just flip back and
forth, do database today, do css tomorrow, do API the day after tomorrow, do
buttons and forms next week.

We don't do Kubernetes etc though, too complex. Just plain old Ansible Jenkins
on real machines. And when we can, just use managed services.

~~~
axaxs
So, I really hope you don't take this as any kind of insult because I don't
know you. That out of the way, I've never met a perfectly competent "full
stack engineer.". Most seem to learn just enough to hack both together. Some
are frontend gurus who figure out enough NodeJS that things work. Some are
backend engineers that figure out just enough JS to make things work.

I'm in the latter camp. I gave up, I can't compete with good frontend devs.
But I've yet to meet a good frontend dev that competes in my domain. I really
think the two take different mindsets.

~~~
dakiol
I don't call myself a "full stack" engineer. I call myself a software engineer
(or software developer); this pretty much means: I am a problem solver. Do I
have to design a relational data model? Sure, there I go. Do I have to keep
the state of a client side app in sync with our server's database while client
is offline? Ok, let's do it. Do I have to design an api that exposes resources
to the public? I can do it.

If I don't know how to do something, I go and learn what's the best way to do
it (by reading documentation, books, or just be asking more experienced devs).
That's all.

If a company I want to work for is looking for "JavaScript" devs only (or
"Python" devs only), that's a red flag... But if I really want to work for
them, I would just apply because if you are a decent software
engineer/developer then it does not matter if the job involves JS or Python or
PHP. You can learn without too much trouble.

~~~
Aeolun
Most importantly, I think I know how to build things so that I can fix
whatever I do wrong later, without having to tear the whole thing down.

------
camgunz
This post is Javascript Rodney Dangerfield. I'm sure there are backend
engineers who think FE isn't real engineering, just like I'm sure there are
frontend engineers who think BE oughta be a $15/mo. service you pay for and
that's it. Let's not get too carried away with the endianness here. There's
complexity everywhere.

~~~
imheretolearn
To add to that, I think the challenges faced by FE engineers are different
from challenges faced by BE engineers or at least I think so. The article
incorrectly conflates the two.I'd like to know on a scale of 1 to 10 how
correct I am?

~~~
sixstringtheory
I agree and that was the thought that stuck with me through the article. Of
course they’re different. To be highly reductive, let’s just say backend
focuses mostly on data ingestion, transformation and storage, and fronted does
UI, graphics and event reaction. Yes, a lot of it looks similar from a far
enough height. Yes, they both have their challenges. No, they aren’t the same
thing. The work is different, and the tools and ecosystems have evolved
differently to cope with their unique aspects.

------
mouzogu
Thoughtworks consulted at the company I used to work at. I always had the
impression that they take these kinds of absolutist positions as a way of
projecting and convincing clients of their domain authority.

To say that it's an anti-pattern I have to disagree. You could just as easily
say that Combining front and back end is an anti-pattern.

To be honest, as a front end dev, I find it frustrating when trend setters
keep trying to squash my role into a broader field. Stop doing that!

------
baron816
Frontend development has gotten more difficult in recent years as the tools we
have available have gotten more powerful. Designers and product managers
demand more as they see other companies push the limits of what is capable.
There should be some corollary to Parkinson's law for this.

I generally disagree that having some separation between client and service is
undesirable. Everyone needs to be a generalist to some degree, but frontend
specialists are important (speaking as a frontend specialist). There's just so
much people need to know in order to be really productive and not make a mess
with JavaScript, frontend frameworks, and DOM APIs that I'm skeptical that
they'd be able to balance that with having a deep understanding and breadth of
knowledge of backend systems.

------
have_faith
> This conceptual split has evolved into the creation of specialized developer
> roles for each, which is still the norm throughout the industry

I think this is backwards. We have a conceptual split because people self
selected for front-end or back-end biased roles, nothing has ever stopped
anyone from bridging the gap if they wished. I'm a front end dev predominantly
and there's nothing stopping me from pursueing "full-stack" if I wished except
I feel much more naturally suited to solving the kinds of problems the front-
end expresses.

The scope for each respective stack is so vast these days that it's no wonder
people prefer to specialise just to have some focus.

------
m0llusk
Specialization is a critical element of our modern economy. It doesn't make
sense to expect that SQL and CSS experts should overlap and trade places now
and then, and there are more divisions than that in any deployed application.

~~~
humanfromearth
Exactly. Frontend frameworks are amazing these days and very hard to master.
It makes sense to split the two to reduce cognitive load for engineers.

------
imheretolearn
You can be a Full Stack Engineer if you want to hack together an application
that works. However, if you really want to do the interesting work, in both FE
and BE, you need to choose one domain and dive deeper. There is a difference
between building the next Kafka and the next React and it would be challenging
if not impossible for one person to be an expert in both domains.

~~~
nlh
I beg to differ with your assertion that "building the next Kafka and the next
React" is the interesting work. I, and I'm sure many, would prefer to build
(hack?) an end-to-end application that actually solves a business problem vs.
spend all my time building infrastructure tools.

I guess my point is: to each his or her own. Everyone finds different
engineering tasks interesting.

~~~
imheretolearn
I stand corrected. I agree to each his/her own.

------
snarfy
You probably don't want your primary physician to also be your surgeon,
anesthesiologist, endocrinologist, and any other specialty you need.

I'm sure there are some primary physicians that could pull it off and wear all
the hats. That's fine. The point is there are multiple hats. It doesn't all
fit in one hat anymore.

------
awesome_dude
Yick, as a user I refuse to install apps now, I don't need 8 zillion apps, I
just need a browser.

It's not a security thing, it's a plain and simple, I _only_ want one thing to
launch, that I can use for anything.

The only apps I install that aren't a web browser are ... an ssh client,
because then I can ssh to .. my VPS, work, whatever, and look at things, or
IRC, or, again, it's the whole single app multiple uses thing, and the damned
"smart" watch app, because it needs something on the phone to manage it :\

~~~
Shared404
> Yick, as a user I refuse to install apps now, I don't need 8 zillion apps, I
> just need a browser.

And then there's me on the other end of the spectrum.

I don't want a second OS. I would rather run my apps locally, where I have an
easier time monitoring/controlling them, then from someone else's machine.

edit: on -> from

------
djmetzle
I think the general idea is good, in that teams should be vertically
integrated. But it misses the mark. If you don't appreciate that there is
specialty in developing beautiful, responsive, cross-browser modern web-apps,
you're not paying attention to the very quickly evolving state of web
development.

There is an emerging trend towards "full stack frontend", where we have
someone who can design UX, and also wire together backing services like flux,
webpack, and APIs.

As a DevOps guy, you can definitely spend a serious effort to pipelining your
fronted testing, deployment, and monitoring. Setting up development
environments, Sentry, optimizing webpack builds, securing CDN distributions,
incorporating Analytics, etc.. these are "Frontend DevOps" kinds of tasks.
Hence, vertical integration is important. The frontend can be developed as an
independent service in of itself.

On the server-side, there is still a UX. We have API design, documentation,
and discoverablility as the "UX" of a "backend", now more appropriately
described as a "backing API", but a complete service in itself.

So i think this article is ignoring the emergence of JAM-stack and Edge
compute. I think it forgoes the robustness, and ability to quickly deliver
business value that these new platform paradigms can enable.

------
jiofih
Once you have merged developers into a single category, who will hold the
experience and knowledge to deal with:

\- browser compatibility

\- usability issues, affordance, animations, transitions

\- build and delivery, performance

\- CORS, CSRF, all the client side security aspects

These are all very specific domains on the client side and it’s simply not
possible for someone to keep up while at the same time doing k8s + Kafka +
datalog + Hadoop + java + whatever else.

To me this clearly spells a situation where UI/UX takes a backseat.

------
kutorio
Of course masters of their trade can create quality work by overseeing the
process from end to end.

That doesn't mean there isn't an opportunity to divide up tasks, build
assembly lines, and lower the job difficulty so it is accessible to more
people.

------
vertis
I really dislike the deciding something is an antipattern and then trying to
assert that everyone else should change and feel bad.

But then, I program a lot by my self, and still use Singletons when it's the
simplest way to get something done.

As someone who is fairly well a generalist polyglot programmer there is a
definite truth that I will never be as good as someone who specializes. Am I
capable of doing layout and custom stuff with CSS, yes. Am I great at it, no.

In a development team, I'm going to do the things that bring the most value.
That's going to mean doing things like GraphQL services and DevOps before I do
the "front end", design based work.

But then I'm also a heretic when it comes to software engineering. I'm far
more interested in getting a product out into the market and starting to learn
than I am making something gold plated with the newest hottest tech and
spending 18 months building a super resilient platform that does not have
product market fit (and will never have product market fit).

------
toomanybeersies
Just because front end development is adopting similar engineering practises
and rigour to server-side development doesn't mean that it's now the same
thing.

Testability and maintainability should be core competencies of any engineering
or technology role, whether it's front end development, back end development,
building IoT devices, or designing airplanes.

------
nodefortytwo
In some spaces it is required to split out the backend from frontends. We
support nearly 100 different native devices (web, mobile, tv, stb) there is no
way you could have a team own a feature from end to end, without having huge
teams with very shallow domain knowledge.

------
Silhouette
I don't disagree, but this article seems to be aiming at an old problem that
we might simply call "bad developers" and/or "bad management".

It has never been a good idea to artificially separate front-end and back-end,
or front-end design and front-end development, or back-end architecture and
database design, or just about any other two labels you care to assign. These
things have always been related, and a successful system combined all of its
elements effectively. But that doesn't just happen by magic, the people
involved have to actually think about it and communicate, instead of
dogmatically adhering to some fake silo arrangement that rarely helps anyone
anyway.

It has never been a good idea to artificially pigeonhole any given member of
your team either. Sure, everyone has to start somewhere, so maybe you start as
JS guy or DB guy or whatever, but that's for newbies. After even a few years
working in this business, no-one who's been paying attention truly has a skill
set that is only one narrow field but a bit deeper. Everyone is multi-skilled
to some degree, and often with experience people develop deep skills in more
than one relevant area.

Roles like "full stack developer" or "UI designer/front-end developer" are
just somewhat arbitrary labels for people who have a particular combination of
skills. People who say that you can't play these parts effectively, or that
no-one can possibly keep up with all of that so everything should be
specialised, are in my experience almost always trying to belittle someone who
has broader and/or deeper knowledge and skills than them, and that's not a
very nice thing to do. It's not a very smart one either, from a business
perspective.

I believe much of the time we would be better off if we just dropped almost
all of these specific-yet-somehow-vague titles, at least beyond entry-level
positions. You need someone (for a small project) or a team (for anything
larger) with enough of each relevant skill available to get the job done, and
you need everyone involved to know at least enough about what else is
happening to communicate effectively with their colleagues. How you divide
things up beyond that is almost invariably, again IME, best done based on the
individual people you have available and their personal strengths. As long as
you ignore the other common but similarly absurd premise that people working
in a huge and highly skilled industry are or should be interchangeable, you
can work this way just fine, and then the kinds of self-inflicted damage the
article is worrying about simply doesn't happen.

------
nilkn
Our product development teams are cross-functional and always involve both
front- and back-end developers. And everyone on a team is expected to have a
reasonable understanding of what everyone else is doing, even the designers
and PMs. You can be an expert in one area, but nobody gets a pass for being
clueless about the other relevant areas. On such a team, it’s also entirely
possible for a backend developer to contribute frontend code and vice versa if
it makes sense, but you’ll do so knowing there’s a functional expert on the
project who will review your work.

But these product teams are unrelated to our reporting structure in the
company. Products come and go. Teams to build them or improve them have to be
spun up and spun down. It doesn’t make sense to tie this too much to the
organization’s more static managerial structure. To be sure, some products are
so central and core that their delivery teams are essentially permanent, but
that’s far from always the case.

In this more static reporting structure, we have a much stronger split based
on functional specialty. Backend engineers tend to report up into chains of
mostly managers and senior managers who are experts on backend development.
The same is true of frontend engineers. This allows people to delve deep into
their specialty, and it allows engineering managers to drive change and
progress across all backend or frontend engineers at the company. For
instance, this makes it a lot easier to make sure that backend work on
multiple product teams is going to coordinate well.

We’ve found this works quite well in practice. In your day to day experience
you’re on a product team with frequent exposure to many domains. But you
report into an organization based on your functional specialty and area of
expertise.

------
cryptica
I think it's a mistake to divide them in terms of roles but it makes sense to
to divide them in terms of technology. From a security and performance point
of view, it makes sense to think about front end and back end as separate but
there are significant benefits (from an API design and application design PoV)
which can be gained from having the same people work on both the front end and
back end.

------
lewisjoe
I used to have this weird thought experiment: what if a front-end is just
additional "views" (think of SQL views) of application data, but scoped by say
a user or org. UI event handlers are just a way of mutating application data
and/or the "views" of application data.

Renderers should consume this "view" and render to their platform (browser,
android, desktop, etc) and just proxy back UI events.

#1 Such system will mandate a data mutation contract to be defined. Both
"back-end" as well as "view" related code will use the same contracts to
change application data.

#2 Such a tech will be batteries included, where one language/framework will
take care of business logic both in front-end as well as back-end.

#3 There won't be ten different layers to touch, when a change happens.

#4 Development teams will be all full-stack, i.e no distinction between front-
end & back-end teams. It's all just business logic at the core. Will
facilitate more work with smaller teams.

Of course I haven't thought through this fully, for example what are
animations in such a system? But it sure is interesting to think about.

------
emersonrsantos
It's just impractical to have a team do n-web/android/iOS and a multitude of
microservices, so that's why they divide them into teams. Applications and
business needs are increasingly complex for enterprise applications.

The result would be better (full-stack), but there's no time to deliver
features quickly by market standards.

------
hannasm
The problem as I see it is not in whether you divide front and back, but where
you divide it and why.

First hand experience passed down by my own teachers and clearly many others
is that that having your business logic mixed in with your UI CODE is a bad
idea. A lot of people take that lesson and fuck that message up and here we
are.

How many times do we write an angular app (using mvc separation). And then
connect to an mvc web server framework. And then have a separate backend layer
with a database behind that.

There is usually many more layers of mvc and separation added in once you look
at your class hierarchies and subsystem architectures.

Separating is very useful to a point and after that point you are just
creating needless overhead.

Unfortunately the only sure way to identify that point is by screwing up and
rewriting everything

------
nicolashahn
The one time I worked in an environment where the work was split up like this,
it honestly worked out great. The size of the team (2 FE, 2 BE engineers, PM,
designer) must have suited it well. The API boundary was a natural place to
divide work. PM and designer would come up with some sketches, we'd all get
together in a room, FEs and BEs would say "yep we can build that" or "no
that's not gonna work because..." to each feature/page. Then the engineers
would collaborate on a shared document to define the API. Once it was fully
negotiated, each side could operate pretty independently, and barring a couple
complications, it just worked in the end when each side's work was done.

It was a pretty good system, I honestly miss it a lot.

------
monkeycantype
ok I've re-read - I think he's just talking about roles not application
structure, so my comments below were off point.

As a consumer, I have more faith in the behaviour of a browser than I do of a
random app, or at least more confidence in the many eyes that will alert me to
problems by browser could pose, and from that more faith in my ability to
constrain the behaviour of a browser. So I would rather use a website than
install a native app. As a developer, I don't trust that any request that
comes to my API is an appropriate, well structured request that came from my
front end code. This is why I separate back from front. My front end is my
emissary to a potentially hostile land.

------
maxharris
I agree with this, but the case grows even stronger when you consider native
mobile applications. I think we're going to be seeing a lot more apps in the
future, and far fewer websites.

Why?

\- Power consumption is much, much lower in a native mobile app

\- SwiftUI is easier than React and CSS. I've used both, and I can't think of
a drawback. (Friends tell me good things about Flutter, though I have not used
it.)

\- Web-like linking is just going to keep growing in apps

\- App store guarantees that my parents won't get hacked via their iPad, but I
can't say the same about their old computers that run Chrome!

~~~
TheFullstackGuy
I personally feel like websites will win the war against native mobile apps in
the long run.

I read a while ago that Steve Jobs never wanted the idea of an App Store on
iOS, as he believed webapps and web based services would evolve naturally
without any added infrastructure, whereas an App Store would require extreme
development effort and infrastructure from Apple.

Obviously he was wrong, and the App Store exploded once it was added.

However, I believe long term his idea is correct, it was just wrong timing.
Webapps have only gotten more and more powerful as time has gone on, and they
do not require any explicit download from the user and can be updated
automatically by the developer. More and more access to the devices physical
resources is slowly being added as the years go on, and it’s only a matter of
time until more and more are added.

I will admit for scenarios like games or resource intensive computing where
access to bare metal is necessary, I’m not sure webapps will be able to fill
that void. But for most everything else I see the web as a the future, while
mobile apps are the temporary means to an end while browser APIs and
capabilities catch up

~~~
SPBS
Okay but web apps have no killer app to motivate switching to. Whatever killer
app that webapps can come up with, so can native apps.

The two benefits

\- webapps don't need to be explicitly downloaded

\- webapps don't need to be explicitly updated

Sound good but downloading and updating was never a problem in the eyes of the
general consumer. On the other hand

\- native apps are faster

And that's a compelling benefit for that even non technical people will prefer
native apps for.

~~~
flo123456
There are really many people who just do not install any apps. Reasons vary a
lot, but these people always have access to a browser and use webapps.

The other killer „feature“ of webapps is that you can have a single one for
multiple platforms.

~~~
bokwoon
> The other killer „feature“ of webapps is that you can have a single one for
> multiple platforms.

That's a feature for developers, not consumers. Consumers will be unhappy if
you tell them your mobile app doesn't exist on the app store and must be
downloaded from some third party website.

------
notsag-hn
It makes a lot of sense to devide front-end and back-end. Javascript is shared
but it is just a part of the stack, while there are a lot of specific
frameworks and libraries for one or the other that makes it really difficult
to share code. Also in general you can expect back and front to be separate
projects with their own best practices. At the same time, you end up doing
quite different tasks that provokes that people naturally want to stick to
their favorite one instead of trying to work on both of them

------
torgian
Ehh I’m not sure if this is necessarily true. You can, in fact, completely
separate front end from back end... but that distinction is very Blurred
nowadays due to front end frameworks requiring hundreds of Megs of code just
to work.

It’s still possible to keep things simple, serve data from the server to the
front end, and keep the front end purely visual.

Unfortunately this isn’t the case anymore; I think the current trend is making
things harder to maintain overall and lowers the user experience.

~~~
toomanybeersies
I feel like the distinction is more clear these days in the age of single page
apps, not less. You can write clearly defined APIs for the transfer of data
between the client and the server, and leave the implementation details to
each team. It's possible to create an entire web app without anyone on the
backend team communicating with anyone on the frontend team (although in my
experience, this is a really bad idea).

------
kissgyorgy
I agree that everybody should be open-minded. I disagree these roles can be
unified somehow. It is literally impossible to learn everything. I believe
there is no such thing as "full stack developer", because it would be such an
enormous area to learn, so many things would be required that only very few
people are capable to learn it.

~~~
cameronfraser
There are plenty of full stack developers. Just because you work on both
stacks doesn't mean you're expected to know everything there is to know about
frontend and backend. I've worked at both large companies and startups and I
can say that there are a lot of these types of people at startups, especially
early stage. It's all about whether you can move that needle forward vs being
an expert in everything FE and BE. Also it's worth nothing that most full
stack devs at startups can move at a much faster pace than their average FAANG
counterparts. Software development moves at a glacial pace at large companies.
As a result at startups you're also expected to know infrastructure as well.
So you have full stack devs at startups doing all three well enough to make
businesses money. More money than they would make paying 3 engineers to do the
same thing since at just a lower level of depth than their larger company
counterparts would be doing.

------
ulisesrmzroche
Wow that title is horrible, it actually makes you think the opposite of the
article. I thought they were arguing for monoliths

Im profesional programming, the front end often matters more than the backend
in that it is the part stakeholders see and understand. It’s not for technical
reasons.

I think the reason people who feel are too good for front end work or that the
UX doesnt matter is because they have a poor sense of aesthetics and business,
they are ideologues who probably dress poorly. For example, the person hating
on front end work in the article is a conference speaker, I haven’t met anyone
with a real job in the industry who thinks JS is a toy language since the
early 2010s, before SPAs were a thing, and even then it wasn’t hating on the
front-end, it was hating on the quality of the JS ecosystem itself. If you
really think the front-end doesnt matter then why should you care what your
code looks like? Feel free to write it as messy as you want, doesn’t matter as
long as it works, right? Stop refactoring, stop giving your variables
meaningful names, stop using classes, and so on. These are all presentational.

By the way, I actually think that technically dividing the front-end from the
backend, as in having them live in different repos and so on, is actually a
best practice.

------
beowulfey
Off topic a bit, but how long have the concepts of “full-stack”, “front-end”,
and “back-end” been around? In the old days, when websites were just static
html, I would imagine those concepts didn’t exist. Did they develop around the
same time that JavaScript did?

~~~
GordonS
This is an interesting question.

I started my professional development career 20 years ago, and there were
pretty much 2 types of developer: those that did embedded development, and
everyone else.

JavaScript was even more of a shit-show than it is now (except that npm didn't
exist), and browser support for, well _anything_ , was terrible and
inconsistent. Almost exclusively, server-side rendering was used (e.g. PHP,
CGI, dotnet when it arrived a short time later). JavaScript was used sparingly
to add interactively when needed.

It was only really when npm and specialised front-end frameworks started to
arrive that a distinction started to form. At the same time, browser
compatibility started to improve, and JavaScript, HTML and CSS finally started
to evolve and improve. With those additional capabilities came more
complexity, and so front-end has gradually became a more specialised field.

------
gamma3
Having both the frontend and backend in TypeScript helps.

------
philipov
Calling everything an antipattern is an antipattern.

------
swyx
calling anything an antipattern is an antipattern - focus on the reasons and
situation instead of blindly applying labels.

~~~
politelemon
Definition of antipattern:

> An anti-pattern is a common response to a recurring problem that is usually
> ineffective and risks being highly counterproductive.

Author has done no work to define the problem area, or why BE/FE is a solution
to that problem area, and why BE/FE is counterproductive/ineffective.

------
bob1029
I agree with the premise that front-end and back-end should not be divided,
but certainly not with the apparent implication that it should all be moved to
the client, or further into the domain of javascript.

The answer for me has become a very fervent belief that we should be doing all
of the rendering server-side. For most business applications, you can deliver
a very high quality experience to all platforms with a single, well-built PWA.

Pushing ever more demand onto the client devices and cloud services is
producing brittle, unethical applications. If I am running a business, I want
to impose as little on my customers as I can. I am tired of apps and websites
that are so bloated that my CPU fans have to spin up in order to compile 20
megabytes of someone else's shitty codepile, just so that we can determine
what initial UI I should be experiencing. And then, once it finally does load,
it runs like total garbage because every scroll event is blocking on some
monstrous javascript shadow dom state machine contraption.

If you fully embrace the server-side model and start to use something like
Blazor, you can find productivity gains that are unimaginable in a typical
api-in-the-middle UI approach. Being able to directly inject your business
services into your UI and use the same models as everything else is extremely
powerful. Writing scoped state services for each domain of UI, and then being
able to compose them with each other allows you to build a well-organized
hierarchy of state management that tracks a specific user's interactions
across the entire application. Hooking up a user's state management instance
into CLR events works just as well as you'd hope it would. Building extremely
complex business UIs is almost too easy once you figure out the pattern. Also,
because everything happens over websocket it "just works" and you don't even
have to think about wire-level contracts/protocols/etc. More brain energy can
be spent on cool features that build upon these powerful abstractions.

Scalability is always a concern when you are server-bound on rendering client
views, but servers are extremely fast now and I'd argue you should at least
make it work for 10 clients before you worry about 10,000,000. Iterate on the
points that actually fall over from real world testing. This will probably be
much more expedient than poking around in the jungle on hyper-scale
architectures from day 1.

------
k__
This.

Dividing by technology is often a bad idea.

Divide by purpose and then group tech that suites that purpose.

~~~
musingsole
...isn't the front-end back-end split about dividing by purpose? Front-end is
user interactions; back-end is about data retrieval and storage (some which
might be the user interactions supplied by the front-end).

Ultimately either can do analysis of data, though tradeoffs generally push
that to one side of the API or the other.

~~~
k__
I guess, the question here is: How to group tech to one solution?

Take Auth0, for example they give you a full stack solution for the purpose
"authentication".

But, yeah, the more low-level your purpose, the more technology specific a
solution you will be.

------
enahs-sf
This is a nice thought experiment if you work on a next.js app or similar and
bootstrap is doing all the heavy lifting, but falls apart when it comes to
writing CSS by hand or native apps that have any complicated functionality
that surpasses the performance capacity of react native.

------
rrdharan
Every backend is someone else’s frontend.

------
amelius
So Firebase is an antipattern?

------
contrarianmop
I am not sure how such posts make it in here, but if the author thinks the
writer of a complex API should posses the skills of a CSS and usability guru
then the writer is simply wrong. Also the notion that backend devs do more
“serious” stuff than front end devs may be common in toxic work environments,
but not so much in proper teams. Front end work is not just creating buttons
and setting styles. It is also about understanding users, a whole range if
devices, browsers, screens and many more things that simply cam’t be mastered
at the same time as one masters heck knows how many layers of apis services
and what else goes behind more than just a word press app.

~~~
Kinrany
"At ThoughtWorks, we think of our roles as fluid and non-exclusive areas of
championship.

[...]

To be clear, I’m not saying that we all need to be experts in everything. That
would be impossible. Today’s technology stack goes down a long way, so being a
genuinely balanced full-stack dev is probably not the most realistic of goals
— but staying open-minded is."

~~~
dakiol
It's impossible to be an expert in everything, but it's very doable to be
competent in many areas. I just don't see the problem in being quite
decent,for example, at Vue.js and Kafka and Postgres. Let's say you have been
working with Postgres during the last year: you are very competent at it. Now,
for reasons, you need to work on the client side app of your company: you
don't know Vue.js, but you go and read the documentation (as any competent dev
would do). You spent months learning and working on a SPA, and you spent less
time with Postgres. Done. Now you're competent at Vue.js (it doesn't take
years to get competent with Vue.js, but certainly it takes years to become an
expert). You go back to work on your daily tasks with postgres. And now... You
have to deal with Kafka. Rinse and repeat. Perhaps then later in 2 years you
have to work again in the front end, but this time with React: easy, you
already know Vue.js., so knowledge is transferred.

