16 ms·

Dividing front end from back end is an antipattern

177 points by Kinrany 6y ago

contrarianmop 6y ago
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.
- kls 6y ago
  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.
- Kinrany 6y ago
  "At ThoughtWorks, we think of our roles as fluid and non-exclusive areas of championship. [...] To be clear, I’m not saying that we all need to be experts in everything. That would be impossible. Today’s technology stack goes down a long way, so being a genuinely balanced full-stack dev is probably not the most realistic of goals — but staying open-minded is."
  - dakiol 6y ago
    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.
  - andresp 6y ago
    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.
- dakiol 6y ago
  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
  - deleted 6y ago
    [deleted]
maxharris 6y ago
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!
- jnwatson 6y ago
  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.
  - maxharris 6y ago
    Is that on Android, iOS, or both?
    - jnwatson 6y ago
      For me, iOS, but they were caught on both platforms.
      - heyoni 6y ago
        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.
        rumanator 6y ago
        > 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.
camgunz 6y ago
This post is Javascript Rodney Dangerfield. I'm sure there are backend engineers who think FE isn't real engineering, just like I'm sure there are frontend engineers who think BE oughta be a $15/mo. service you pay for and that's it. Let's not get too carried away with the endianness here. There's complexity everywhere.
- imheretolearn 6y ago
  To add to that, I think the challenges faced by FE engineers are different from challenges faced by BE engineers or at least I think so. The article incorrectly conflates the two.I'd like to know on a scale of 1 to 10 how correct I am?
  - sixstringtheory 6y ago
    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.
- webmaven 6y ago
  > 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.
macca321 6y ago
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
kutorio 6y ago
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.
m0llusk 6y ago
Specialization is a critical element of our modern economy. It doesn't make sense to expect that SQL and CSS experts should overlap and trade places now and then, and there are more divisions than that in any deployed application.
- humanfromearth 6y ago
  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.
- GlennS 6y ago
  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.
emersonrsantos 6y ago
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.
monkeycantype 6y ago
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.
awesome_dude 6y ago
Yick, as a user I refuse to install apps now, I don't need 8 zillion apps, I just need a browser. It's not a security thing, it's a plain and simple, I only want one thing to launch, that I can use for anything. The only apps I install that aren't a web browser are ... an ssh client, because then I can ssh to .. my VPS, work, whatever, and look at things, or IRC, or, again, it's the whole single app multiple uses thing, and the damned "smart" watch app, because it needs something on the phone to manage it :\
- Shared404 6y ago
  > 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
enahs-sf 6y ago
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.
christiansakai 6y ago
As a fullstack dev, this article resonates with me. I was worried that being Fullstack dev is a career killer (what I heard), but I found out its not true. In my current company (one of the tech giants/unicorns), there are many small independent teams that maintain stuffs themselves. In my team we maintain everything, from frontend to backend to devops. Python, JS/TS, Go. Not impossible to achieve, since frameworks/methodologies are transferable. I.e., I use React, but I learned Angular2 in just a day or two and was able to be productive right away for maintaining/building feature in some apps that use Angular2. Backend we use Express, Flask, plain Go. ES, SQL, MongoDB, DynamoDB. Doesn't matter. Granted, everyone in my team are senior devs, more than 5+ years exp. Besides, after a while doing just frontend or doing just backend you'll get tired and sick of it and want some change. It is nice to just flip back and forth, do database today, do css tomorrow, do API the day after tomorrow, do buttons and forms next week. We don't do Kubernetes etc though, too complex. Just plain old Ansible Jenkins on real machines. And when we can, just use managed services.
- axaxs 6y ago
  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.
  - toomanybeersies 6y ago
    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.
imheretolearn 6y ago
You can be a Full Stack Engineer if you want to hack together an application that works. However, if you really want to do the interesting work, in both FE and BE, you need to choose one domain and dive deeper. There is a difference between building the next Kafka and the next React and it would be challenging if not impossible for one person to be an expert in both domains.
- nlh 6y ago
  I beg to differ with your assertion that "building the next Kafka and the next React" is the interesting work. I, and I'm sure many, would prefer to build (hack?) an end-to-end application that actually solves a business problem vs. spend all my time building infrastructure tools. I guess my point is: to each his or her own. Everyone finds different engineering tasks interesting.
  - imheretolearn 6y ago
    I stand corrected. I agree to each his/her own.
- ownagefool 6y ago
  I'd be surprised if none of the folks who built Kafka have built a decent JavaScript framework.
  - imheretolearn 6y ago
    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.
sroussey 6y ago
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.
torgian 6y ago
Ehh I’m not sure if this is necessarily true. You can, in fact, completely separate front end from back end... but that distinction is very Blurred nowadays due to front end frameworks requiring hundreds of Megs of code just to work. It’s still possible to keep things simple, serve data from the server to the front end, and keep the front end purely visual. Unfortunately this isn’t the case anymore; I think the current trend is making things harder to maintain overall and lowers the user experience.
- toomanybeersies 6y ago
  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).
- filleduchaos 6y ago
  What does that have to do with the article, though?
hardwaregeek 6y ago
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.
- jhanschoo 6y ago
  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.
- clintonb 6y 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.
toomanybeersies 6y ago
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.
baron816 6y ago
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.
d--b 6y ago
No, it's not the division that's the problem, it's having one driving the other. The thing is front end dev is actually very different from back end dev. Having done a lot of both, I can say that they require very different skillsets and different knowledge, so it is quite normal that they're not done by the same people. Now, if your team is frontend first, you'll likely screw up your backend design in the sense that you won't be able to define a nice API for it. Similarly, if your team is backend first, you'll have a nice API, but probably won't think about all the frontend needs, and will have to patch things nastily down the road. Truth is, coordinating people with different skills is hard. Now this kind of articles take aim at teams that don't manage to make it work. So yeah, not being great at managing teams is an antipattern...
- Silhouette 6y ago
  The thing is front end dev is actually very different from back end dev. Having done a lot of both, I can say that they require very different skillsets and different knowledge, so it is quite normal that they're not done by the same people. I've seen this argument many times, but as someone else who has done a lot of both, I've never really understood it. It's just programming, like any other software project. Sure, you might use different languages and each might have its own tool chain, but unless you're using radically different languages or tools in the two cases, those are probably superficial differences. Most experienced professional developers can probably work in several languages, and you pick up a new tool chain in days if you need to. But the fundamentals of programming are still much the same whatever you're building. Certainly different applications also have different knowledge and skills -- writing a business automation tool is likely to be quite a different experience to writing a control system for ABS in a car, say -- but for a typical web app, the front and back ends are usually going to overlap a lot in this respect. As I mentioned in another comment, the huge exception to this is junior roles, because at that stage in someone's career they probably haven't gained much diversity of experience yet and you probably should start by focussing on one particular aspect. So if your project team consists of many relatively junior people and not so many seniors with broader experience, sure, you're going to put most people specifically on front-end or back-end, at least to start with.
Vinnl 6y ago
> What does a frontend dev actually do that’s so different from a backender? Deal with and pre-empt cross-browser compatibility issues, ensure accessibility, iterate on the UX, deal with stateful-but-not-persisted applications, optimise for constrained devices whose hardware you do not control... And keep up with whatever technologies exist to help with those challenges. The article even mentions some of these. Yes, you could just say back-enders should know about all that, but... There's a limit to how far a single human can vertically integrate their knowledge. For example, the same argument could be used to claim that 'developers' should be able to handle all the challenges of the back-end, of database adminstration, of operations, and why not, let's throw in business development, design and content strategy as well. In the end, it mostly depends on what you can afford. If you're a small, bootstrapped startup, you have a couple of people doing everything. But as you grow, specialisation can become more efficient.
- dragonwriter 6y ago
  > deal with stateful-but-not-persisted applications No, they don't. The application is persisted. The store is one or more external resources, but that's usually the case with persistence, even on the backend.
  - allover 6y ago
    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.
    - Vinnl 6y ago
      That's right, though I do see how my original formulation didn't make that terribly clear. Thanks for clarifying it.
    - dragonwriter 6y ago
      > 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.
Silhouette 6y ago
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.
gamma3 6y ago
Having both the frontend and backend in TypeScript helps.
swyx 6y ago
calling anything an antipattern is an antipattern - focus on the reasons and situation instead of blindly applying labels.
- Kinrany 6y ago
  This argument applies to all generalizations ever, doesn't it?
- politelemon 6y ago
  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.
lewisjoe 6y ago
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.
mouzogu 6y ago
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!
vertis 6y ago
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).
nodefortytwo 6y ago
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.
deleted 6y ago
[deleted]
k__ 6y ago
This. Dividing by technology is often a bad idea. Divide by purpose and then group tech that suites that purpose.
- musingsole 6y ago
  ...isn't the front-end back-end split about dividing by purpose? Front-end is user interactions; back-end is about data retrieval and storage (some which might be the user interactions supplied by the front-end). Ultimately either can do analysis of data, though tradeoffs generally push that to one side of the API or the other.
  - k__ 6y ago
    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.
bob1029 6y ago
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.
have_faith 6y ago
> 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.
cryptica 6y ago
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.
philipov 6y ago
Calling everything an antipattern is an antipattern.
notsag-hn 6y ago
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
beowulfey 6y ago
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?
- black3r 6y ago
  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.
- GordonS 6y ago
  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.
tedk-42 6y ago
Our cross-functional teams have both frontend and backend engineers working on business goals for their team. The skillsets of definitely different though and they both compliment each other. I'm really not a fan of having 'full stack' engineers which do everything. The truth is they are often stronger in frontend or backend, with a few unicorns that excel at both. Frontend engineers know frameworks well - angular, vue or react with other frontend concepts like cookies and frontend security. Backend engineers don't need to know about cross-site scripting, CORS and a bunch of other things that have been standardised and built into browser security. Backend engineers have used more languages outside of javascript and work with a much larger set of technologies day-to-day (databases, queues, file systems, other APIS, RPC etc). They see the client (frontend) like any other consumer hitting their system. They can't be unified because tech stacks and the web is so big and there are so many ideas and new things coming out. I'm not sure if a browser could ever do something like reading a message from a Kafka topic. A frontend dev should never have to worry about that, so why on earth would they ever need to know anything about Kafka? A backend dev might have to play with it though.
- lolinder 6y ago
  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.
  - nedoka 6y ago
    There's a golden balance between front-end and back-end. This article seems a bit like a he said she said, venting some kind of dispute with management on the internet.
  - tedk-42 6y ago
    Yes and I agree with the writer on that. But I dislike his view that dividing frontend and backend expertise is problematic
jiofih 6y ago
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.
amelius 6y ago
So Firebase is an antipattern?
snarfy 6y ago
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.
kissgyorgy 6y ago
I agree that everybody should be open-minded. I disagree these roles can be unified somehow. It is literally impossible to learn everything. I believe there is no such thing as "full stack developer", because it would be such an enormous area to learn, so many things would be required that only very few people are capable to learn it.
- cameronfraser 6y ago
  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.
rrdharan 6y ago
Every backend is someone else’s frontend.
nicolashahn 6y ago
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.
djmetzle 6y ago
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.
nilkn 6y ago
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.
ulisesrmzroche 6y ago
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.
hannasm 6y ago
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

177 points by Kinrany 6y ago

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.

kls 6y ago
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.
Kinrany 6y ago
"At ThoughtWorks, we think of our roles as fluid and non-exclusive areas of championship. [...] To be clear, I’m not saying that we all need to be experts in everything. That would be impossible. Today’s technology stack goes down a long way, so being a genuinely balanced full-stack dev is probably not the most realistic of goals — but staying open-minded is."
- dakiol 6y ago
  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.
- andresp 6y ago
  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.
dakiol 6y ago
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
- deleted 6y ago
  [deleted]

maxharris 6y ago

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!

jnwatson 6y ago
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.
- maxharris 6y ago
  Is that on Android, iOS, or both?
  - jnwatson 6y ago
    For me, iOS, but they were caught on both platforms.
    - heyoni 6y ago
      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.
      - rumanator 6y ago
        > 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.

camgunz 6y ago

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

imheretolearn 6y ago
To add to that, I think the challenges faced by FE engineers are different from challenges faced by BE engineers or at least I think so. The article incorrectly conflates the two.I'd like to know on a scale of 1 to 10 how correct I am?
- sixstringtheory 6y ago
  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.
webmaven 6y ago
> 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.

macca321 6y ago

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

kutorio 6y ago

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.

m0llusk 6y ago

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

humanfromearth 6y ago
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.
GlennS 6y ago
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.

emersonrsantos 6y ago

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.

monkeycantype 6y ago

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.

awesome_dude 6y ago

Yick, as a user I refuse to install apps now, I don't need 8 zillion apps, I just need a browser. It's not a security thing, it's a plain and simple, I only want one thing to launch, that I can use for anything. The only apps I install that aren't a web browser are ... an ssh client, because then I can ssh to .. my VPS, work, whatever, and look at things, or IRC, or, again, it's the whole single app multiple uses thing, and the damned "smart" watch app, because it needs something on the phone to manage it :\

Shared404 6y ago
> 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

enahs-sf 6y ago

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.

christiansakai 6y ago

As a fullstack dev, this article resonates with me. I was worried that being Fullstack dev is a career killer (what I heard), but I found out its not true. In my current company (one of the tech giants/unicorns), there are many small independent teams that maintain stuffs themselves. In my team we maintain everything, from frontend to backend to devops. Python, JS/TS, Go. Not impossible to achieve, since frameworks/methodologies are transferable. I.e., I use React, but I learned Angular2 in just a day or two and was able to be productive right away for maintaining/building feature in some apps that use Angular2. Backend we use Express, Flask, plain Go. ES, SQL, MongoDB, DynamoDB. Doesn't matter. Granted, everyone in my team are senior devs, more than 5+ years exp. Besides, after a while doing just frontend or doing just backend you'll get tired and sick of it and want some change. It is nice to just flip back and forth, do database today, do css tomorrow, do API the day after tomorrow, do buttons and forms next week. We don't do Kubernetes etc though, too complex. Just plain old Ansible Jenkins on real machines. And when we can, just use managed services.

axaxs 6y ago
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.
- toomanybeersies 6y ago
  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.

imheretolearn 6y ago

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

nlh 6y ago
I beg to differ with your assertion that "building the next Kafka and the next React" is the interesting work. I, and I'm sure many, would prefer to build (hack?) an end-to-end application that actually solves a business problem vs. spend all my time building infrastructure tools. I guess my point is: to each his or her own. Everyone finds different engineering tasks interesting.
- imheretolearn 6y ago
  I stand corrected. I agree to each his/her own.
ownagefool 6y ago
I'd be surprised if none of the folks who built Kafka have built a decent JavaScript framework.
- imheretolearn 6y ago
  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.

sroussey 6y ago

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.

torgian 6y ago

Ehh I’m not sure if this is necessarily true. You can, in fact, completely separate front end from back end... but that distinction is very Blurred nowadays due to front end frameworks requiring hundreds of Megs of code just to work. It’s still possible to keep things simple, serve data from the server to the front end, and keep the front end purely visual. Unfortunately this isn’t the case anymore; I think the current trend is making things harder to maintain overall and lowers the user experience.

toomanybeersies 6y ago
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).
filleduchaos 6y ago
What does that have to do with the article, though?

hardwaregeek 6y ago

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.

jhanschoo 6y ago
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.
clintonb 6y 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.

toomanybeersies 6y ago

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.

baron816 6y ago

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.

d--b 6y ago

No, it's not the division that's the problem, it's having one driving the other. The thing is front end dev is actually very different from back end dev. Having done a lot of both, I can say that they require very different skillsets and different knowledge, so it is quite normal that they're not done by the same people. Now, if your team is frontend first, you'll likely screw up your backend design in the sense that you won't be able to define a nice API for it. Similarly, if your team is backend first, you'll have a nice API, but probably won't think about all the frontend needs, and will have to patch things nastily down the road. Truth is, coordinating people with different skills is hard. Now this kind of articles take aim at teams that don't manage to make it work. So yeah, not being great at managing teams is an antipattern...

Silhouette 6y ago
The thing is front end dev is actually very different from back end dev. Having done a lot of both, I can say that they require very different skillsets and different knowledge, so it is quite normal that they're not done by the same people. I've seen this argument many times, but as someone else who has done a lot of both, I've never really understood it. It's just programming, like any other software project. Sure, you might use different languages and each might have its own tool chain, but unless you're using radically different languages or tools in the two cases, those are probably superficial differences. Most experienced professional developers can probably work in several languages, and you pick up a new tool chain in days if you need to. But the fundamentals of programming are still much the same whatever you're building. Certainly different applications also have different knowledge and skills -- writing a business automation tool is likely to be quite a different experience to writing a control system for ABS in a car, say -- but for a typical web app, the front and back ends are usually going to overlap a lot in this respect. As I mentioned in another comment, the huge exception to this is junior roles, because at that stage in someone's career they probably haven't gained much diversity of experience yet and you probably should start by focussing on one particular aspect. So if your project team consists of many relatively junior people and not so many seniors with broader experience, sure, you're going to put most people specifically on front-end or back-end, at least to start with.

Vinnl 6y ago

> What does a frontend dev actually do that’s so different from a backender? Deal with and pre-empt cross-browser compatibility issues, ensure accessibility, iterate on the UX, deal with stateful-but-not-persisted applications, optimise for constrained devices whose hardware you do not control... And keep up with whatever technologies exist to help with those challenges. The article even mentions some of these. Yes, you could just say back-enders should know about all that, but... There's a limit to how far a single human can vertically integrate their knowledge. For example, the same argument could be used to claim that 'developers' should be able to handle all the challenges of the back-end, of database adminstration, of operations, and why not, let's throw in business development, design and content strategy as well. In the end, it mostly depends on what you can afford. If you're a small, bootstrapped startup, you have a couple of people doing everything. But as you grow, specialisation can become more efficient.

dragonwriter 6y ago
> deal with stateful-but-not-persisted applications No, they don't. The application is persisted. The store is one or more external resources, but that's usually the case with persistence, even on the backend.
- allover 6y ago
  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.
  - Vinnl 6y ago
    That's right, though I do see how my original formulation didn't make that terribly clear. Thanks for clarifying it.
  - dragonwriter 6y ago
    > 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.

Silhouette 6y ago

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.

gamma3 6y ago

Having both the frontend and backend in TypeScript helps.

swyx 6y ago

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

Kinrany 6y ago
This argument applies to all generalizations ever, doesn't it?
politelemon 6y ago
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.

lewisjoe 6y ago

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.

mouzogu 6y ago

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!

vertis 6y ago

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

nodefortytwo 6y ago

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.

deleted 6y ago

[deleted]

k__ 6y ago

This. Dividing by technology is often a bad idea. Divide by purpose and then group tech that suites that purpose.

musingsole 6y ago
...isn't the front-end back-end split about dividing by purpose? Front-end is user interactions; back-end is about data retrieval and storage (some which might be the user interactions supplied by the front-end). Ultimately either can do analysis of data, though tradeoffs generally push that to one side of the API or the other.
- k__ 6y ago
  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.

bob1029 6y ago

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.

have_faith 6y ago

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

cryptica 6y ago

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.

philipov 6y ago

Calling everything an antipattern is an antipattern.

notsag-hn 6y ago

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

beowulfey 6y ago

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?

black3r 6y ago
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.
GordonS 6y ago
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.

tedk-42 6y ago

Our cross-functional teams have both frontend and backend engineers working on business goals for their team. The skillsets of definitely different though and they both compliment each other. I'm really not a fan of having 'full stack' engineers which do everything. The truth is they are often stronger in frontend or backend, with a few unicorns that excel at both. Frontend engineers know frameworks well - angular, vue or react with other frontend concepts like cookies and frontend security. Backend engineers don't need to know about cross-site scripting, CORS and a bunch of other things that have been standardised and built into browser security. Backend engineers have used more languages outside of javascript and work with a much larger set of technologies day-to-day (databases, queues, file systems, other APIS, RPC etc). They see the client (frontend) like any other consumer hitting their system. They can't be unified because tech stacks and the web is so big and there are so many ideas and new things coming out. I'm not sure if a browser could ever do something like reading a message from a Kafka topic. A frontend dev should never have to worry about that, so why on earth would they ever need to know anything about Kafka? A backend dev might have to play with it though.

lolinder 6y ago
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.
- nedoka 6y ago
  There's a golden balance between front-end and back-end. This article seems a bit like a he said she said, venting some kind of dispute with management on the internet.
- tedk-42 6y ago
  Yes and I agree with the writer on that. But I dislike his view that dividing frontend and backend expertise is problematic

jiofih 6y ago

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.

amelius 6y ago

So Firebase is an antipattern?

snarfy 6y ago

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.

kissgyorgy 6y ago

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

cameronfraser 6y ago
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.

rrdharan 6y ago

Every backend is someone else’s frontend.

nicolashahn 6y ago

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.

djmetzle 6y ago

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.

nilkn 6y ago

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.

ulisesrmzroche 6y ago

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.

hannasm 6y ago

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