Dividing front end from back end is an antipattern | Hacker News Reader

Dividing front end from back end is an antipattern

thoughtworks.com

177 pointsKinrany177 comments

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

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.

i've worked with way too many programmers who were great at math but couldn't match their shirt and pants.

I think the issue that the article skirts around is that front-end work involves UI design and styling. So sure, both involve using sophisticated modern programming languages etc, but the presence of visual styling work is unique to the front end and specifically what a lot of back end programmers feel they are unable to contribute to. I know that many javascript engineers feel similarly about their design and styling skills, but still, in my opinion the presence of UI design and styling in frontend work is the main contributor to the cultural/team separation.

We have been rendering HTML and adding styling from the back end since long before JS was cool...

I think the real distinction here is between programming and interface design, which are also separate skills that any given person might or might not have, but that is true whether they happen be coding for the front or the back end at the time.

Well depends what you call "backend", I tend to think of it as the business code that the interface operates with. Namely the API. I work in finance, so there the backend consists of gathering data and applying statistics on it. The frontend is a presentation of the data and a way to interact with it.

The webserver code that renders web pages definitely belongs to frontend dev.

Personally I would call code running on the user's device the front end and code running on some server or other remote device the back end. YMMV.

Maybe this explains the difference in our perspectives. To me, other than perhaps the very first data collection where maybe the source is only accessible from the back end, whether things like statistical analysis or rendering of the results happen on the front or the back end is something you will decide on its merits for each project, not something that is necessarily tied to the mechanical programming skills or libraries on one suffer or the other.

This would mean server side rendering is back end development. Traditionally working in templated languages was considered a front end job despite being translated server side.

Perhaps, but once you start generalising there are lots of grey areas and overlapping possibilities, which I suppose is my main point here.

For example, say you're working on a web app that controls some device. On the back end, you might not be talking to a database, at least not in the sense of SQL or NoSQL we usually mean in the context of web apps. Maybe instead you're integrating with some internal API that controls the hardware.

In that situation, maybe you're exposing that internal functionality to the front-end web app via some HTTP-based API, which might be substantial but is mostly a wrapper for the internal functionality with things like security incorporated. Who should be responsible for that middle layer? Do you have a separate person/team whose responsibility is just to bridge between the front-end code and the internal API? Should the person/team responsible for the front-end also be responsible for the HTTP-based API it talks to, and hand off to some other person/team who work on the hardware-facing code behind the internal API? Should the internal team also be responsible for the HTTP-based API?

I don't think there are any "right" answers in a situation like this. You probably have people with front-end skills. You probably have people with low-level hardware hacking skills. Some or all of those people might also have back-end skills. You've certainly got three distinct but related areas here. Depending on the project and the mix of people you have available, there are several potential ways to handle this situation that might be effective.

I think of UI/UX designer as kind of a distinct role from programming. Sure, if you don't have any designers, then your frontend person is also your designer, so in that case, it makes sense that their job is distinct from backend.

The opinion I've adopted from my designer friends, though, is that once you have a designer in-house and the site's basic design has been established, what is more important is that the developers notice and care about details. That's not something I would consider a frontend vs backend developer trait, just more of a general engineering attitude. Do you notice that the padding here doesn't match up, do you question why this form is laid out differently from all the other ones, how does this flow from page to page work, do you go find a designer and work with them until it's right.

I would posit that the same person who cares that the UI is consistent and makes sense would also be pointing out why is our code formatting all over the place, why we use different libraries in different places to do the same thing, why our patterns and architecture is inconsistent. If you just copy/paste in random UI pieces and call it done, then you're probably also copy/pasting in random stackoverflow snippets on the backend and just recompiling until the tests pass.

OK but my understanding is that modern approaches to client side JS are based around the concept of web components. In which case, even though the JS code encompasses many areas of software engineering (data flow, dealing with asynchronous events, MVC-like architectures to achieve separation of concerns etc) there is no escaping the fact that part of your code is directly representing a DOM which is rendered as a UI. So I'm not sure I believe that client-side JS can really be divorced from the design of the UI. Sure, the CSS can be done by someone else, but the choice of components that exist in the (virtual) DOM is necessarily very much part of the UI design isn't it?

Right, that's why designers generally work with a component library, in an application like Sketch that is designed for building websites and mobile apps. Your component library might first start off with just all the basic HTML stuff, but that eventually becomes tailored to your company's own custom stuff. You're not just hiring abstract artists who then whip up a fever dream in photoshop.

Ok, so in the setup you describe can the js engineers focus on software engineering and not be involved in the choice of components and UI layout design? I.e. they can have all that handed to them by a designer? I didn’t know that, in my experience the JS engineers also design the UI layout (but have designers work on CSS styling )

So, if you start off with something new or large, your UI/UX designers would be the ones driving all the work. Then once you're working on something established, then your developers might suggest components based on common patterns they know, and then ask designers to validate it. And then once you're adding trivial things, like another field to a form, you wouldn't involve the designer at all.

The recurring theme in this whole discussion is "it depends", and that is the case here as well.

If you're building a relatively simple UI, using common features like buttons and text boxes and maybe some simple charts, you might well do what has been mentioned in this thread. You can identify reusable pieces that the designers can use to define layouts and specify styling and that the programmers can use to implement those things in code. This is an easy method of UI design and implementation, and often it is all you need.

If you're building something more challenging -- a rich document editor, a game, an interactive 3D visualisation of a complicated data set, basically anything that isn't just a combination of standard controls and UI patterns -- then the main part in your UI might not fit that component model very well at all. Now you're going to have to approach both the UI design and the programming from a different direction, just as you would in desktop, mobile or embedded software. This is harder, because you're moving away from patterns and tools that are well understood and readily available, and instead you're building something original. However, it's also much more flexible for the same reason, and sometimes that's what you need.

Even in the latter case, you will often need standard features in your UI that can be designed and built as individual components as well. There's no rule that says you can't have a hybrid with both reusable components for the simpler, recurring features and then one or more features that are more sophisticated.

Actually, programming is just a small part of the product development process. A huge amount of work is spend on communication, architecting, planning, gathering user requirements, maintenance... Then you need deep knowledge of the technical domain. In that regard, I would say FE and BE differ tremendously. The constraints are different, the people with whom you engage are different, the objectives are different. It won't be very obvious in small companies and young product teams where everyone does a bit of everything. As things scale up and gain maturity, people have to specialise, and it becomes very hard to be the best at both. You have to pick: making great UI components, or storing data optimally. You can be average and do a bit of both, but if you want to be an expert engineer, you'll need to specialise in one (which is what I think d--b was referring to).

Of course there are many other skills involved besides programming, but I don't make the big distinction you apparently do. For example, the part about storing data optimally is going to be handled by the database in most web applications, and using that tool well is a distinct skill set from both front- and back-end programming. Indeed the latter two have far more in common than either has with designing an efficient database or optimising queries that access it, or with designing a good UI for that matter.

At the very top of each field, sure, there will always be those specialists who live and breathe that subject and can do the things no-one else can, but most people will never achieve such proficiency in any field during their career and most businesses will never hire anyone on that level, so I'm not sure it is going to generate much insight to talk about extreme cases. For anything below elite levels, you certainly can have the same person with expert skills in both front- and back-end dev, or in back-end dev and DB admin, or in front-end dev and UI design, or just about any other combination of relevant skills.

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.

It is becoming clear to me that much of the perceived difference of opinion here is just because of terminology. I was thinking of "development" as meaning specifically the programming side of things. This is quite distinct from the other skills you mentioned like responsive design or database design.

Of course someone might have both front-end programming and user interface design responsibilities on the same project, but I would no more assume that than I would assume the same person would have both front- and back-end programming roles, and the skills for the latter combination are much more closely related. My point here is just that everyone has a different mix of skills and trying to pigeonhole people or restrict anything to only certain combinations is not necessarily either realistic or helpful.

>, I've never really understood it. It's just programming, like any other software project. [...] But the fundamentals of programming are still much the same whatever you're building.

It doesn't matter if the underlying programming fundamentals are the same because the human brain still has preferences on what it wants to work on. The mistake is applying some "umbrella term" (i.e. "programming") for an activity and thinking that will automatically make all sub categories attract the same interest level. It doesn't work that way.

This same phenomenon happens in other intellectual activities such as mathematics, writing, painting, etc:

One mathematician might prefer to study algebraic topology while another mathematician prefers to work on number theory. Thus, saying, "I don't get it -- it's all _math_ so why should one person have more interest in one branch vs another?!?" ... does not remove the preference.

One writer may prefer to write political analysis essays and never writes fiction -- but another writer prefers to write fiction and never opinion pieces on current events. Therefore, saying, "I don't get the fiction/non-fiction dichotomy because both activities are just the same task of manipulating _words_?!?" ... doesn't make a preferred interest disappear. Yes, some authors write both fiction and non-fiction but the existence of them still doesn't remove the preference of other authors who specialize in just one. Even within sub-category of fiction, you get sub-specialization of "mystery novels" instead of "romance novels".

Likewise, saying "painting is painting" does not change the fact that an artist might prefer to always paint landscapes and never horses or people.

>It is becoming clear to me that much of the perceived difference of opinion here is just because of terminology. I was thinking of "development" as meaning specifically the programming side of things. [...] and trying to pigeonhole people or restrict anything to only certain combinations is not necessarily either realistic or helpful.

Some people naturally just want to pigeonhole themselves. I've done frontend work on old DOS machines (text-based UI), raw Win32 API, VB/C# GUI forms, Javascript/HTML -- and I don't like any of it. I prefer to program the backend algorithms. Yes, coding a loop to "iterate through all window controls to enlarge them by 10% in the GUI" has something in common with "iterate through all nodes of a graph to optimize a path" ... because they're both "loops" ... but they have very different levels of intellectual satisfaction. I won't argue with you if you feel that they should feel exactly the same because they're both "programming" but I can't help it that I don't derive the same enjoyment.

If I was employed by Google, I'd enjoy working on the backend ranking algorithms. To a lesser degree, I'd be ok with working on the spider crawlers. But I'd quit if they assigned me to work on the web frontend where users type in queries. But I'm also glad there are developers who prefer to work on the frontend instead of the backend because it allows people like me to stay with my preference.

FWIW, I'm not trying to suggest that front-end and back-end dev are the same and that no-one will have any preference for one or the other. Of course they feel different and some people will enjoy one thing or another more.

My objection is to the common arguments that front-end and back-end dev are fundamentally different on a technical level and/or that they should be done by different people or that the same person can't be good at both. Compared to other programming fields, such as traditional desktop applications or embedded real time systems, front- and back-end on the web are quite similar in the skills and technologies they use, and I don't think drawing a clear line between them is very helpful (that is, I agree with the original article that started this discussion on this point).

front-end: webpack/parcel/etc. configs, plugins, css-, js- and asset-'transpilation'. arcane CSS knowledge, keeping up with HTML developments, learning about promises, no async, no web-workers, react hooks, etc.

back-end: perhaps less, uh, dynamic, but: db architecture, SQL, much more CLI/linuxy stuff, server security, API design, version control, deployment, containers, ansible, load-balancing, nginx config...

The difference not primarily being a sort of 'core' skillset, but rather purely learning and remembering the intricacies of all these things. That's too much for most people.

EDIT: I find that there's a definite sense of 'progress' or 'leveling-up' in all these areas put together. I get better at finding the right documentation, finding the best places to go for help, figuring out what the foot-guns are as well as distinguishing fads from truly worthwhile developments.

I get better at 'intuiting' where I might need to take a deep dive to truly understand things, or where I might need to consult an expert.

It gets easier to take lessons from one area and apply them to another.

But ultimately there's still so much 'domain knowledge', much of it shifting and changing, even if just because the client cares about it, that it's hard to keep up in both the front- and back-end world. And even if that shouldn't have to be necessary, in practice it often is.

For example, I've been doing more back-end stuff for the past few years. I keep an eye on what's happing in the js/React world as that is what I mostly did before. I struggle with setting up a new project because apparently Webpack changed, apparently we do CSS in js now, and apparently hooks are the hot new thing. I have a /lot/ of time to study all of this, but unless I actually work on a project that uses all this fancy new stuff, it doesn't really properly become part of my skillset.

The same goes for backend stuff. I can set up proper Linux servers 'in anger', but apparently now it's pretty useful to know how to use Amazon/Moft serverless stuff and I just never got to that. And I'm single and almost permanently reading up on all this fancy new stuff!

> It is becoming clear to me that much of the perceived difference of opinion here is just because of terminology. I was thinking of "development" as meaning specifically the programming side of things. This is quite distinct from the other skills you mentioned like responsive design or database design.

I don't think you can break things up like this. Good developers can work one, sometimes two layers in each direction. A back-end developer who can't design a database is a lousy back-end developer. A front-end developer who implements user interfaces handed over from a designer is a lousy front-end developer.

Pigeonholing people isn't helpful, but it is helpful to

(1) Recognize that there are distinct, deep skill sets

(2) Known when and how to organize teams and software. Some benefit from vertical splits, and some from horizontal. There aren't universals here.

I agree entirely that there are many different skill sets involved in building a web application, and I also very much agree that there are no universal rules for how to organise the team building a web application.

I'm just arguing, following the spirit of the article we're discussing here, that there is no inherent reason the same person can't have both front-end and back-end programming skills, and can't perform both of those functions proficiently.

Of course there are many non-programming skills involved as well, but I don't accept your premise that a back-end developer should necessarily know how to design a database or that a front-end developer should necessarily know how to do all the design work for a UI. Plenty of web applications aren't backed by a database at all, so the first claim is clearly not universally true. Plenty of organisations have people dedicated to their design and branding, and that might be shared across all media, so again it's clearly not always the case that someone doing front-end programming must also be able to handle those aspects in order to be competent or useful.

Given that front- and back-end programming are much closer in the skills required than either is to user interface design, graphic design, creating digital art, understanding accessibility and usability issues, designing and maintaining an efficient database or system administration, among other relevant skill sets, it seems entirely reasonable to me that a project might want to have the same team responsible for all programming, and have different people doing things like the UI design and the database and system administration. Another team might have people with different mixes of skills and might use them more along the lines you described. All projects and all project teams are different.

It's not requisite, but it's a big part of the difference between junior and senior. I'd phrase your text as:

"Of course there are many non-programming skills involved as well, but I don't accept your premise that a __junior__ back-end developer should necessarily know how to design a database or that a __junior__ front-end developer should necessarily know how to do all the design work for a UI."

I agree with this for a junior developer working on a simple project:

"Plenty of organisations have people dedicated to their design and branding, and that might be shared across all media, so again it's clearly not always the case that someone doing front-end programming must also be able to handle those aspects in order to be competent or useful."

But a senior developer working on a complex project should be able to work a couple of levels up and down wherever they are in the stack:

* If building a complex web app (e.g. Google Docs an online game, etc.), there isn't a clear separation here.

* On simpler projects, even just implementing corporate branding from a designer, little pieces of cross-cutting work come up.

* Even where there isn't cross-cutting work, being able to leverage synergies requires people to be familiar with both domains. If a designer comes with a design, and the engineer can modify it to be 90% as good (or sometimes 110% as good) for 50% of the effort, that's a conversation a senior front-end developer should be able to hold with the designer on relatively level ground (e.g. know the jargon, constraints, modes of thought, etc.).

There are jobs for full-stack engineers, and I agree with your current comment ("it seems entirely reasonable to me that a project might want to have the same team responsible for all programming"), but that's a few steps divorced from your original claim ("'ve seen this argument many times ... 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.") Since you said you never understood this argument, I thought I would elucidate.

I've worked with really good front-end people, and really good back-end people, and it's an entirely different skillsets. Beyond the (relatively junior) skill of being able to write code and understand a "for" loop, the more senior level stuff goes off in two deep and very different directions.

Again, I suspect we agree on most of this.

It's definitely different for junior positions, when someone hasn't had enough time to build up a breadth of experience yet and getting to a useful depth of understanding in at least one area is more important.

FWIW, I also think it's different at elite levels. If you actually are the person who had to, say, develop a data storage system for Facebook at a scale no-one had ever done before, you're probably a database specialist with skills and knowledge in that area far beyond any generalist's. But these positions are rare, as is the need to have someone with that level of specialist skills on your team.

For seniors at a high but not exceptional level -- that is, the most senior people you're likely to find in most organisations doing web development -- it's definitely normal for someone to develop both breadth and depth of skill and understanding throughout their career. No doubt many front-end developers (in the programming sense) do also have some level of ability with design work, and many back-end developers (ditto) do also have some level of ability with database design. There's certainly nothing wrong with that, and it's certainly helpful to have that level of understanding whether it's to use the skills directly or just to communicate more effectively with a colleague who has responsibility for that aspect of the work.

The only area where perhaps we would slightly disagree is in the idea that being a senior front-end or back-end developer necessarily requires advanced skills in specific related areas as well. The industry is huge and the number of related skills that are potentially useful is large, and which ones are useful for a particular person playing a particular role can vary widely.

For example, I've met someone who is very capable when it comes to writing server-side code yet who as far as I know has never touched a database in well over a decade. Their speciality is interfaces for network-connected devices. While a recent project for them might well have had a snazzy SPA on the front-end and a super-dooper GraphQL API running server-side, what is behind that API is probably nothing like a SQL or NoSQL database at all. On the other hand, they probably know a lot more about calling local C APIs from server-side languages like JS or Python than most. I would certainly call that person a senior level developer -- I doubt there are more than a few thousand people in the entire world with the combination of skills and experience they have, maybe not even that many -- but it seems they would not clear the bar for you because they lack significant database expertise?

I think we might just have difference for where we place the bar for 'senior.' This does vary by company too. A non-tech company, a tech outsourcing shop in India, Oracle, Google, and elite startups all have very different bars.

At least in companies I've been, someone who can code but cannot design a database, that's a junior backend position, no questions asked. Likewise, someone who can code, but can't do UI/UX design work, that's a junior design position, no questions asked.

I think one issue is that if someone has depth in algorithms, computer architectures, and similar, becoming a competent DBA isn't too much work. SQL isn't rocket science, and neither is how databases are organized. If you don't understand B-trees, have background in what sorts of operations to nanoseconds, microseconds, or milliseconds, cache hierarchies, and so on, that's a pretty generally-applicable back-end data set, and you can pick up databases in a few months. That's something I'd expect a senior back-end engineer to have done at some point in their career. If not, I'd hire them in a more junior role, and then advance them quickly. Coincidentally, with that skillset, you can also design something new, like that Facebook back-end. That's also what FAANG interviews try to screen for, although they've had the narrowing effect that people try to master FAANG interview questions, without necessarily that depth.

In line with that, I also don't think positions like the Facebook one you described are rare. A lot of positions I've seen require that level of background. I also think you underestimate the number of people at that level.

If you ask me, the problem seems to be setting up a team of juniors without training or supervision.

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.

Doing front-end well involves being able to do a lot reasoning about how human beings will interact with the system, graphic design, and similar sort of skills. It's not just the work of making something responsive or organizing SASS/CSS. You're trying to make a coherent experience for a user.

I'd expect senior folks to be able to not get confused by an HTML tag, of course, and to be able to build a good end-to-end system, but the really good front-end devs I've worked with think through really subtle details of interaction design -- how long a slider slides, subtle changes to colors during mouse-overs and other actions, and just thousands of details that make a world of difference in how the product feels.

Conversely, anyone who's coded for more than a few years should be able to do a database query. But a really senior back-end dev will be able to think through how to, for example, make an architecture capable of streaming through thousands of events per second with 100ms latency, how to shard a system to work in data centers around the world to maintain data coherence while minimizing user latency, or hundreds of similar complex algorithmic tasks.

There are plenty of full stack people who can make an app responsive, have a coherent SASS/CSS framework, and efficiently organize a typical database (I can do all of that too, for that matter), but doing either side well takes many years of experience on its own.

There are times to go with a generalist. And there are times to go with a specialist.

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

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.

> It's just programming...

Ah, yes. Quite.

Having started with frontend as well because of necessity, I've realized people actually appreciate people with backend background working in frontend. Especially on complex UIs it makes sense to have people who are comfortable building complex features even if all details aren't clear yet. On the other hand, backends profit also from people with frontend-only experience.

In complex UIs it makes much more sense to have product and design people who are able to simplify it without losing value for customer. Actually, ability to have the same outcome with less hussle is added value. It is manyfold more important with mobile-first experience.

> Similarly, if your team is backend first, you'll have a nice API

Or you have a horrid kludge, and regardless of how great your frontend team is, you are now stuck with a terrible mess.

I agree, my summary of the post: "Frontend is engineering too" which I 100% agree with, however the notion of not splitting up systems into functional goals is a mistake.

User-facing applications just have different goals from an application consumed via API. Practically when you split up a system into a client facing application and an API application, from my experience and reasoning, it's always been because it results in a far easier to manage development process.

The simpler you can make your system the less likely it will be to fail by any measure. So breaking systems up into smaller systems is just easier and simpler. One such division that is really easy is the backend and frontend.

Model View Controller type frameworks are a great practical example of why breaking systems up makes them much easier to construct.

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.

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.

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

Funny that you say they can’t be unified, just yesterday I wrote an article about how you can write backend JS within your front end project, without even thinking about the stuff going on behind the scenes.

I think things might get closer and closer together. At least in the JS community. Performance critical work will be done in Rust / wasm and we will always have people who specialize instead of generalize across all these technologies. But that doesn’t mean some projects can’t be unified more!

https://zach.codes/es6-import-nodejs-on-the-frontend/

> 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

I agree that frontend and backend development are deep enough on their own that they require specialization for complex projects. But lacking even basic knowledge of how other parts of the stack can by an issue IMO.

You mentioned CORS for example. One time I had to explain to a co-worker, who was a senior level backend dev, why the browser’s calls to his API were failing due to CORS. He couldn’t understand why the fix had to be on his end. When he tested the API with Postman the same requests were succeeding after all. It was shocking to me that someone at his level was not familiar with what was happening. Sure, it requires knowledge of browser behavior but it’s still relevant to the person writing the API.

Beyond that, I find that having a little full stack knowledge helps with inter-team communication.

While I agree that he should have some knowledge about the CORS issue, I disagree that it's a backend problem.

It's the engineering/architecture problem. There's no reason why you couldn't build a proxy on the same domain as your front end app and proxy the request to the backend.

It sounds like his interface (API) was built before you even started consuming it. Maybe adding such headers increased the scope of complexity for his API and tests. I don't know the circumstances, but I disagree the fix HAS to be on his end.

There should be a front and a back end team, but the back-end team should know how the front-tend works in interacting with the back-end, and even be able to write JS to this end. Having one team hitting just API endpoints is fine - until you need more nuance in your approach then you need to appreciate how end-to-end works.

example: what if you need to limit API calls, or stream data in a specific way? what if you need to work with the back-end to pre-fetch certain data and then cache it client-side?

I'd argue these things are back-end-interacting client-side code. and they should probably be written by someone with a strong appreciation of the back-end, whether than be someone actually on the BE team, or a knowledgeable FE team member.

Of course, you can always write a spec that covers all of it and bounce it between the two teams, but that doesn't always work out well, especially if FE/BE silos have developed.

The first thing I said was advocating cross functional teams with both frontend and backend engineers

But what does that mean?

One or two devs knows the other teams stuff? The whole team?

also, what does it mean in the context of "different skillsets"? It sounds like the FE devs has some comprehension of the BE, but weaker skills than the BE devs. Then cross-functional just means not strongly siloed, but what is the advantage is that? a little knowledge can be worse than none.

KT can be expensive, specialism exists for a reason, and you can end up limiting your hiring pool if your requirements are too strict.

I don't think a FE team needs every member to know every detail of the back-end, a suitable abstraction can simplify how much you need to focus on the back-end detail.

Instead I'd advocate having a few "specialists" that have a good knowledge of where FE meets BE. they needn't be the best BE or FE dev, but the best at integrating the two; I'd say this is usually a BE engineer who can write good JS and has a decent appreciation of the relevant protocols. They can architect the main touch points, and then abstract them (i.e. create relevant classes) for the FE, BE. These devs would be competent experts in integration, rather than the "jack of all trades, master of none" full-stack variant; a shallow but wide knowledge may be great for prototyping, but not for mature stacks.

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.

From my perspective, the reputation comes from its roots. Modern web apps that interact with a multitude of APIs and the user are a far cry from the ad-hoc scripts or static webpage authoring that it was a couple decades ago.

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.

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.

I'm going to be a bit contentious here but

> you're being told how something should look by a designer, [...] Being ordered around by a gasp artistic person

Neither are very relevant. UI interface design is about supporting workflow. Visual appearance is not unimportant but it's shallow.

> about having real, non technical people interact with your code

yeah, that's how you do it! Assuming your company actually does UI testing at all.

I somewhat disagree about the irrelevance of visual design. A good or exceptional visual designer can quite often have an enormous impact on the user experience, and also save the development team a lot of work.

I don't think it's shallow, it's actually taken for granted. Look at how vertical scrollbars work on both mobile and desktop, for example.

We don't give it a second thought, but imagine how many layouts would break on mobile, with a default 20px scrolling rail on mobile browsers. Or the way the URL bar hides when you start scrolling.

Those kind of ideas, from my experience, rarely come from product developers without some visual design experience.

I think if frontend didn't mean JavaScript and npm packages, that animosity wouldn't really exist.

While there is some use of JavaScript at the backend, IME it's much less that other languages, so backend developers are used to "better" languages with actually useful standard libraries (C#, F#, Elixir, Ruby, Python...).

Of course, JavaScript is evolving, albeit slowly, and recently TypeScript helps somewhat. Web assembly may eventually offer a real alternative, but I think we're still a long way front it becoming mainstream.

My impression is there are a segment of technically-minded backend engineers who look down on frontend work - who cares what the damn thing looks like as long as it works?

I think the truth is, most engineers just aren't comfortable with A) working with stakeholders and translating requirements to specs, aka soft skills, B) any sort of design (which is actually hard!) or C) learning the HTML/CSS/JS ecosystem. Also, I found learning how to write frontend applications to be just as challenging as writing CRUD apps.

Do back-end teams not have to deal with clients, requirements or software design?..

The HTML/CSS/JS ecosystem is hard, props for that, but then it's made harder by being reinvented every year by the latest fad.

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

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

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.

That's right, though I do see how my original formulation didn't make that terribly clear. Thanks for clarifying it.

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

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

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.

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

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.

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.

I doubt that they take different mindsets, many frontend engineers make extremely complex applications that need to maintain state and queue tasks.

That said when I say I'm full-stack I say there are parts of the stack I am more comfortable with than others.

I think I'm equally good at the frontend and middle layer, the data layer I am passable, the backend processes - meaning receiving data/pulling data from other sources for insertion in my data repositories, processing data, queuing data, optimizing processes for images, anonymizing data etc. I hack stuff together and it looks pretty ugly to me (unless processing XML where I am very good), but I can get it done. It's not a different mindset that makes me less competent in those areas, in my opinion, just inexperience.

on edit: and of course one will always be less than perfectly competent in every part of the stack, because the stacks cover a lot of ground. I think I'm pretty good at CSS, but really am weak in use of some parts, what I'm better at in CSS than most developers is understanding the cascade rules and when things will conflict.

I think I'm of a similar mindset. I started my career working on low-level things in C, and later moved towards being a sysadmin - largely as a result of working for a company who's sysadmin quit with zero notice.

These days I'm a devops-engineer, whatever that means, and I think my background of low-level understanding/coding has been very helpful.

Developers these days who can do amazing front-end things tend not to understand how computers work, how servers work, and how to debug problems under pressure. I'm sure they're entirely capable of doing the obvious/basic things, but their experience doesn't often qualify themselves to work from the bare metal upwards.

Right, similar experience here, and that's exactly what I mean. For example, I don't think a typical fullstack dev would know what it means to see a 'too many open files', how to debug, or how to fix. Hell, most don't understand the difference between a 'connection refused' and a 'unknown host.' In fairness, they don't have to. I started as a full Linux/C nerd who thought I'd conquer the world, and watched as tools like Docker attempt to make it irrelevant. I say attempt because I find it typically a huge waste of resources as an abstraction, but people love it, so I lost.

I don't feel defeated or obsolete, just the nature of an ever evolving curriculum I guess.

There are plenty of front end engineers that understand how computer works, how server works, and how to debug under pressure.

It's good enough to debug performance and compilation problems.

They exist, definitely.

But I think there are far more front-end developers who know (and are amazing at) CSS, Javascript, react, and all that stuff - and have no ability to diagnose, or resolve server-side problems (be they overheating CPUs, bad RAM, flaky DNS, or other problems).

I'm full stack. I see what you're saying and I think that in some (many?) cases your impression is correct.

In my last job, I entered as a frontend developer and moved into more backend work in addition to frontend work. There was strong engineering vigour, rigorous code reviews and careful coding standards to ensure consistency. I'd like to think I was competent across the field and at least equal to my peers but that's not for me to judge. My peers and those to whom I reported were very pleased. This suggests externally-verified competency.

I find it better to enter as either a frontend developer or backend developer and then demonstrate internally competency at both rather than trying to sell yourself as full stack from the outset.

It helps to have been developing web-related software for the past 25 years. Over time you learn new things because they fascinate and interest you.

Recognisable competency throughout the stack is achievable by anyone with enough curiosity to explore combined with enough experience to know how little you actually know.

I'm sort of from the middle but have recently been more frontend by dint of doing a lot of frontend. We are a design studio so getting design right is also pretty key. That said I built and maintain a large RoR ecom app with heavy customisation and a purpose built integration framework written in node.. and I enjoy it just as much, even if I might not be as expert tier as someone who does nothing else. All of one would be boring for me, do what makes you happy.

> I've never met a perfectly competent "full stack engineer". Most seem to learn just enough to hack both together.

I hear you that there are plenty of "full stack devs" whose competency is mostly in one area.

But (at risk of sounding cocky,) I would consider myself competent on both the front and back end. And I'd say I'm not alone.

"Absence of evidence isn't evidence of absence." You just haven't been around these people. Frankly, I think this is more a statement about the industry as a whole than "full stack". There are a lot of gainfully employed but mediocre developers.

I think having both skill sets affords me the perspective to see whenever e.g. the front end is doing things the back end should be doing.

Sometimes specializing in one area means "you have a hammer, so everything looks like a nail." I've seen _way_ overcomplicated front-ends that would be a much lower long-term maintenance burden if the developer wasn't looking through "everything should be solved with client side JavaScript" tinted glasses. ;-)

Sure, I believe you completely. People are perfectly capable of writing great code in both. I think when it gets to errata, domain knowledge, errors, etc is where it really starts to open up. I can hit some opaque error and a good frontend dev can tell me what it means, or that it only exists in X browser, etc.

Similarly, some know about every Linux error code, and how to tune systems around applications, which is a bit of a lost art.

So sure, fullstack exists in a way, but I still find it too broad a concept for any human to master on both ends.

So sure, fullstack exists in a way, but I still find it too broad a concept for any human to master on both ends.

Like almost anything, it's just a matter of time and experience. Plenty of people in the industry have been around since the Web was young, and have watched the technologies evolve over the years. We've built UIs rendering on the back end and we've built UIs rendering on the front end. We've built back ends that talk to databases and we've built front ends that talk to an API that looks like a lot like a thin wrapper around a database. So many of the skills and so much of the domain knowledge in web development is useful, or at least potentially useful, on both sides of the HTTP divide that it's hard to see the front and back end as significantly different from this perspective.

Once you've got your fundamentals sorted out, the important things don't change very fast in this business. Much of the "rapid development" is just hype and reinventing the wheel, and every time a new generation of young and enthusiastic developers thinks they've discovered a radical, game-changing idea, which in time they will discover the old fogeys had been using since the last millennium. Again like anything else, with enough experience you can easily see through most of that, but also learn to pay more attention to things that might actually matter. This is true in front-end development, back-end development, usability and accessibility issues, databases, visual design...

To put this in concrete terms, if we say (just to choose a number) that someone reasonably conscientious with 3-5 years of professional experience behind them could be proficient with the technical details of current front-end or back-end development, is it really so implausible that someone with 7 years of professional experience behind them could not have developed and maintained similar proficiency with both?

> To put this in concrete terms, if we say (just to choose a number) that someone reasonably conscientious with 3-5 years of professional experience behind them could be proficient with the technical details of current front-end or back-end development, is it really so implausible that someone with 7 years of professional experience behind them could not have developed and maintained similar proficiency with both?

Yes. The world doesn't stop spinning so you can learn both. In the time you're focused on one, the other changes. Computer science fundamentals are going to be consistent, but the problem domains of front-end vs. back-end are vast. You can have skills from either, but ultimately either one is complex and wide enough that an individual focused on just one won't master it but merely be more than competent.

Also, just keeping track of the tech either side is discarding is enough to fill one mind. Keeping a pulse on useful best practices from multiple domains while the world races forward is no small feat.

The world doesn't stop spinning so you can learn both.

That is true, but the world seems to spin a lot slower from the right perspective. Most of the "progress" in web development really isn't. Game-changers come along every now and then, but much more rarely than hype. Someone who is already proficient with both front-end and back-end work can easily keep on top of the developments that actually matter.

Also, just keeping track of the tech either side is discarding is enough to fill one mind. Keeping a pulse on useful best practices from multiple domains while the world races forward is no small feat.

Yes, professional development takes work, and keeping up with technology requires some of your time. But once again, the more you already know, the less any given development is likely to make a profound difference to you, and the more quickly you can scan what's happening and focus in on anything of real interest.

For example, on the front-end side, I probably find one or two articles or videos per month that offer some genuinely new insight or understanding. I might find one or even two front-end tools per year that are sufficiently interesting to be worth investigating in more detail and potentially adopting for future work. It's not that I don't read or watch more than that, but I filter ruthlessly and rarely waste time on anything that doesn't have either an immediate benefit or obvious potential. This also means I usually haven't wasted much time on tech that didn't stick around for long.

Statistically speaking, I'm probably a more experienced developer than most here, but I make no claim to being unique or superhuman. I imagine there are others reading this discussion whose experience is not so very far from mine.

Unrelated, but there are plenty of people having above average knowledge that's good for real world use. Say 80% (if you define mastery as above 95%)

Aside from being a software engineer. I also have various hobbies that I cultivate with above average level, graduated from 3 degrees in unrelated field, and know three languages.

And I know there are plenty of people who do more than me.

It isn't a stretch by any means. I believe plenty of people are very capable than what they think they can do. Human capabilities are more able than you think. Little by little knowledge compounds. i.e. if you can play guitar well most likely you can pickup bass quickly.

I think the attraction of "full-stack engineers" is exactly that they're a jack of all trades, mastery optional. They're incredibly useful for smaller companies that can't afford, or lack the workload, to separately hire serverside, front end, and devops engineers.

As you said, most full stack devs tend to have an area they're strongest in, and know enough to be able to hack things together for the rest. As a team, there should be someone with skills in each field that can be utilised to tackle harder problems and for guidance, while simpler tasks can be completed by any team member. You don't need 5 years of experience as a JS dev to add a loading spinner to the UI or 5 years as a Rails developer to add a CRUD endpoint.

I like to describe it as being analogous to an infantry squad, you have the machine-gunner, the grenadier, and the designated marksman, but everyone on the team is capable on some level of using a machine gun, a grenade launcher, or a sniper rifle.

The important part is to ensure that there are people with enough experience in each area to be able to provide technical leadership and mentoring. If you have a bunch of backend devs trying to hack away at JS and reviewing each others code, with no concept of best practice, you're going to get an amateur end result.

> As a team, there should be someone with skills in each field that can be utilised to tackle harder problems and for guidance, while simpler tasks can be completed by any team member. You don't need 5 years of experience as a JS dev to add a loading spinner to the UI or 5 years as a Rails developer to add a CRUD endpoint.

The challenge here is that, at least in the front-end (I'm a front-end engineer), it's not so much the case that there are certain problems that are hard and you need help with, but that there are things you should know you're doing wrong, or at least suboptimal.

For example, you can add a loading spinner, but you need to do some extra work to make sure people relying on screen readers, for example, know what is going on. After you've implemented a loading spinner, there is nothing that is really pointing out to you that you forgot that.

Though I guess the same holds true for the back-end: if I write a really inefficient database query, everything still appears to me as if it worked just fine. Only when it blows up later will it become clear that I lacked knowledge there - and let's hope that I did have enough knowledge to properly instrument the logs.

Of course, this isn't necessarily problematic. When you're a small team, getting something out the door that can load data even though the UX for some people sucks is better than not being able to do anything at all. But if you can afford specialists (at least in the sense that e.g. the front-end will typically only be touched by those who are strong on the front-end), you can get higher-quality products.

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.

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.

I share this mindset, but I don't love pigeonholing myself to software. If the problem is better solved with a mechanical machine, I'll build that instead. If the problem is best solved by baking bread, I'll do that. Software has its place, but is not the best solution to all problems.

I don't think it's a skills thing, it's a time thing.

Personally, I work as the architect/leadership level, but I'm still pretty handy at DevOps, SRE, RE, Back end, and have even delivered a few front-end projects in my time (mid 30s).

I'm not claiming to be the best, but I'm good enough that I mentor engineers that are senior and costing >$250,000, and I did not gain these skills simply from being a generalist.

What I simply cannot do is keep up with 10s of engineers changing a code base when I spend a lot of the day in meetings. My choice is to be the bottleneck the project and cause discontent, or let the team roll with it and pick up the pieces that fall through the cracks.

Does this means that I could never again be an IC which specialises in any part at a reasonable enough level? I doubt it. But pragmatically, there are few people who see the bigger picture who have enough technical chops to get disparate specialists working together, so rather than be the 10x engineer, I try to focus on amplification and making my team a 10x team.

That propped up 10x engineer always working overtime, is really a 10x*0.3 bus-factor engineer. Team members can each be 3x engineer with significantly improved bus factor (though not without investment and some coordination).

The funny thing is that 10x engineer drains mindshare from the teams, rest of the org, and will lack diversification, like architecture, testing and Ops.

Over the years I worked on native desktop apps, mobile apps, a Scala backend.

Now I work on a complex React app in TypeScript with a GraphQL backend in TypeScript. I can build a feature end-to-end. From domain modeling to an API to UI with animations. Optimising SQL queries.

There are people like this. Software engineers who have experience across the stack.

I don't do devops but I've met someone who can do full stack app development and devops pretty well too.

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

It's mostly due to the sheer amount of things you have to keep in mind at any given time. Not the core things like algorithms and such, but (Javascript + Typescript + React + Redux + GraphQL + Apollo + .... ) + (Java + Spring Boot + MySQL + BigQuery + PubSub + Datastore + ...). All the different libs, and the ways to communicate, and idiosyncrasies specific to different languages and different libs.

There's never time to get good at something, as you're pulled apart :)

What is the issue of figuring just enough NodeJS as long as they can solve the problem at hand ?

At the end of the day what we do is to solve problem.

Even if you specialized in let say just front end, that itself can be broad enough to master.

There are plenty of very competent fullstack engineers, one man army people around the world.

I think you just haven't seen them yet.

Is it not possible to be highly competent at playing the piano and also at carving wooden sculptures? Or not possible to be a master of C++ _and_ CSS? That just doesn't make any sense.

Perhaps your views are more a reflection on people getting pigeonholed at large companies, or otherwise choosing to specialise? Or something like that?

I personally think it's hard to be a _really_ good frontend dev without a chunk of more general development experience. What wider experience will you draw from to solve hard frontend problems otherwise? If your Angular/React app isn't performant enough because of the computations it needs to do or allocations it needs to make, how big is your mental toolbox to fix that if you haven't done more general backend dev work? It's all just software, ultimately.

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.

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?

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.

> Let's not get too carried away with the endianness here. There's complexity everywhere.

Hah! Much appreciated for the clever use of "endian" in this context.

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!

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.

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

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.

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.

I think communication overhead works against this, because it is a very big overhead for programming.

If one or two people can build a feature all the way through, getting help and advice from the experts in each area as necessary, then you can save a lot of time and are more likely to end up with a coherent design.

Also, how can you know what a good backend design looks like if you have no experience of consuming it on the front end?

I think if you're a web developer you should really build a web site all the way through at least once, even if you later forget the details about a lot of those stages.

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.

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.

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

I'd be surprised if none of the folks who built Kafka have built a decent JavaScript framework.

I'm not saying it's impossible I'm just saying it seems improbable to have a significant contribution to both projects. Also, there are other considerations, for example some people may just like working on the FE and some on BE.

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.

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 :\

> 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

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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!

I can't install the LinkedIn app because I can't trust they won't steal all my contacts (which they've done before). The web sandbox is a much stronger container.

Is that on Android, iOS, or both?

For me, iOS, but they were caught on both platforms.

The app stole your contacts after you granted the app permission to access them, right? Not saying it’s your fault, just wondering if they used some loophole.

> The app stole your contacts after you granted the app permission to access them, right?

That completely misses the point. With mobile applications you are only a dark pattern away from clicking on a button and letting a third-party spy on all your contacts, location, personal info, etc.

You don't get that with the web.

So they didn’t use a loophole? Cool, cause that was all I cared about.

Also, you will get all of that with the web. Just check google chrome to see what kind of permissions can be granted for any individual website. Contact sharing is right around the corner.

How long ago was this? I get the sense that their sandboxing is improving?

LinkedIn is why I won't ever again grant any app this permission ever.

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

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.

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.

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

Jobs was stalling because the native API wasn't polished for release and he needed a story for ATT to bite.

BS. I tried selling Gil Amelio on an App Store concept and he shot it down for channel reasons (still put me on WWDC speaker list). Jobs said the idea was “fucking stupid”. For Mac at the time.

Well, one could argue that an App Store anything like the one that we have now -- i.e., all driven by digital downloads -- was fucking stupid for the Mac at the time, given that the time you're talking about sounds like it's over two decades ago and the majority of users who were online were still using modems. Time may have proved your concept right, but that doesn't mean your timing was right. :)

I don't know whether Jobs really wanted the iPhone to be open all along and was just playing dumb with his "sweet solution" of anemic web apps. Some of what I've heard from others supports the idea that he really did think web apps would work, but it also seems to be common knowledge that they were working on what became the iPad before the iPhone, and it seems pretty unlikely that they were planning to shop that without support for third-party applications -- although, of course, they might not have been thinking of an app store.

Oh, my timing was definitely wrong. :/

I don’t think apps can be called more efficient. A good majority are just web wrappers anyway. I’ve tried the twitter app for example multiple times and it always causes iOS to lock up when changing apps. It’s the only app that does it and extended use causes the phone to heat up.

Websites can have ad blockers too which I’d argue make the web versions way more efficient.

SwiftUI is better than React and CSS... on iPhone. It’s not going to help you at all on Android. So at a bare minimum you’re replacing React and CSS with two totally different UI implementations. Maintaining two separate code bases (and hiring engineers to do so) is not simpler than React and CSS. And we haven’t even started talking about desktop.

And I’m not convinced about the “hacked” argument. How can anyone be hacked via any web browser on an iPhone? At least on Android they could download an APK without knowing what they’re doing but default security will stop them installing it. Meanwhile we’ve recently discovered that a ton of native apps constantly read the user’s clipboard, something web sites aren’t able to do. So it’s nuanced at best.

But IMO the biggest argument for the web is simply that you don’t have to install it. If I’m shopping I want to browse through a few different sites, I’m not going to download and install an app just to look at one product listing.

I’ve found the two codebases approach, one for iOS and one for Android, is simpler and cheaper because native development tools are just so better.

Then you’re doing web development wrong, frankly.

You will always keep separate code base for Android and iOS due to difference in the interaction paradigms between the platforms. Doesn't matter if the code is in Javascript/CSS or shared via Swift between Android and iOS. For native apps.

For web it's different but you see more and more webapps following the Android's Material Design which for me feels awkward on Windows or macOS.

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

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.

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

What does that have to do with the article, though?

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.

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.

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.

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?

I started coding web apps around 2012. Back then I didn't hear about backend/frontend and I've coded both backend and frontend JS scripts. But we did have specialists who created the static HTML & CSS templates. We just called them the CSS guys. I guess they were the pre-cursor to the front-end engineers. Then the JS frameworks started to rise and at first we used to spend a lot of time rewriting pure HTML to React, but gradually the CSS guys started to learn React/JSX and evolved into front-end engineers.

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.

Having both the frontend and backend in TypeScript helps.

Calling everything an antipattern is an antipattern.

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

This argument applies to all generalizations ever, doesn't it?

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.

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.

This.

Dividing by technology is often a bad idea.

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

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

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.

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.

Every backend is someone else’s frontend.

So Firebase is an antipattern?

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.

I agree probably 80% or more of your mundane enterprise back-end programming tasks are shuffling data to and fro to the database, batching transformations, system integration and on the wire data transformations. Sure there are the jobs out there where back-end developers are sequencing genomes or creating ML models but for the majority of them, if you need to use ML, you are just the guy pumping the data to some service to get the magic data results. Don't get me wrong, I do back-end dev and it is important, just highlighting that it can be pretty routine stuff.

In those environments front end work can actually be the more complicated system, where a developer is trying to take a complicated manual workflow and capture it into a flow of screens that make logical sense for the user.

What the author is seeing is a lack of team alignment not the division of labor, give that he is a full-stack developer I am sure he is keen to the division, but the problem is a people problem in nature. In the environments I have worked, we do not divide teams into front-end or back-end. Teams are comprised of a mix of skills that are aligned to supporting a business silo. In these team dynamics developers know the value of each of the roles, from the DB admin, to the back-end guy to the front-end guy and what we usually see is cross pollination where many of the *-end developers end up picking up skills from the other side and start working the full-stack.

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

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.

People with no legitimacy trying to make blanket statements like this is an anti-pattern. Frontend is massively different from the backend. It appeals to very different people. I care about scale and performance, not UI work. For me BE is much closer to infrastructure/ops/OS than the JS library of the week. This "full stack" mindset also shows the limited experience of the author. He has no idea of the depth of specialization that some of these tasks include. The fact that he can get away with basic knowledge in both of them just shows the level of the technical challenge in his work. If you are in that context, sure, I even wrote business plans when I had to (and that doesn't mean I think those roles should be merged for everyone), but there's more outside of your knowledge bubble.

I have worked in the past with AngularJS and Vue. The work I produced was similar in quality to the work produced by pure "front end" engineers. I am a generalist, and I haven't seen yet any "front end" engineer doing relational data modelling or learning other language that is not JS

Reply on news.ycombinator.com