11 ms·

Front-of-the-Front-End and Back-of-the-Front-End Web Development

86 points by Cederfjard 6y ago

edgyquant 6y ago
This honestly seems needlessly arbitrary. If you’re the person whose job it is to write the component for a button making that button “work” (which almost always making a call to the backend and/or loading up an additional component or making changes to the current one) is not anymore complex nor is it really a different skill set. Front and backend makes sense as the two don’t even have to be the same language and front end is GUI work while backend is more number crunching, etc. “back of the front end” and “front of the front end” doesn’t have anything close to the same kind of compartmentalization. At least not in my experience.
- rlayton2 6y ago
  For static pages, the "front-of-front-end" developer is broadly the "web designer" and does CSS most of the time. As JS sites get more complicated, those buttons need behaviour which is generally also that person's job, so now they do JS. I'm a small operation, but I'll spend entire days on the "frontend" where I don't actually open a web browser. I'm writing the code that does all the client-side computation from the data it gets from an API. I definitely see the distinction in my own projects and as teams grown, specialization becomes more important. So I can definitely see the distinction.
- ehnto 6y ago
  It used to not be so, a front end developer at a typical web agency would just write HTML and CSS, maybe a sprinkle of jQuery, and any programming/logic would be done in the backend templates by someome else. Now frontend development is so complicated that you need to be a programmer as well as a frontend developer to get anything done. The first hint of deviation was when people started being called frontend engineers, we never needed that term before. It is also my guess that this is why frontend developers went from entry level roles to the highest paid roles in most agencies I have worked at. A twist I never saw coming!
  - jariel 6y ago
    "It used to not be so," UI's 'used to be' thinks you installed not web pages! That's what a lot of people are missing. With complex UIs, which people see to have forgotten even exist (!) there's a big difference between front-of-the-frontend and back-of-the-frontend. This is not new, it's 20 years old at least.
    - runawaybottle 6y ago
      I mentioned this in another comment, and it’s odd that this macro outcome is not more obvious. The ‘application’ industry didn’t disappear, it just packed up and moved into the browser. It’s like saying Talk radio is dead. No, it’s more alive than ever in the form of Podcasts. There’s nothing niche about GUI application development, and has always been one of the staple exports of the tech industry. Yeah, it’s all JavaScript and CSS, annoying I know, but could be worse (Java, .net).
  - CaptArmchair 6y ago
    The assumption here is that the Web equates hypertext: hyperlinked static text documents sprinkled with images and a bit of Javascript. Ever since the inception of the Web by TBL, there was a drive to use the Web as a jumping board for "Rich Web Applications". Flash, Java Web Applets, Silverlight,... were all attempts to bring the functionality of native applications to the browser. They filled a space where browsers natively lacked API's. They were also a threat to proprietary OS makers like Microsoft who sought to dominate the desktop space and what you could do with your computer in the late 90's early 00's. It was the arrival of mobile devices around 2010 that upended the status quo. It created massive new billion dollar markets for new players like Google. It also introduced an entirely new technological paradigm which spawned competition between native mobile applications and web based applications. All of that gradually coalesced around browser engines. These have evolved into incredibly complex beasts over the past 15 years with a cornucopia of API's and support for protocols. Just think about WebGL (look at the members of the Chronos consortium! https://en.wikipedia.org/wiki/WebGL https://en.wikipedia.org/wiki/WebGL)! Or how Microsoft decided to adopt Chromium for it's browser (https://www.theverge.com/2020/1/15/21066767/microsoft-edge-chromium-new-browser-windows-mac-download-os https://www.theverge.com/2020/1/15/21066767/microsoft-edge-c...) The end game here is much the same as it was back in the 90's: being able to control the sandbox in which both developers and users are playing. The difference being that you don't need third party plugins or whatever. Front-end engineering is just an expression of this evolution. It's a specialist role who's goal is to build fully-fledged applications and UI's in the browser. And that's totally valid. > highest paid roles in most agencies Early agencies in the early 00's started out as "we build and maintain your website". They were forced to pivot away from that pitch in a few short years. Either they moved towards integrated 360 communication, or they moved towards a specific niche e.g. mobile development, content strategy, UI/UX design, etc. This includes moving from building simple websites towards complex user interfaces to manage all kinds of data, content, and so on fluidly. Sure, it's still possible to start a company that does "traditional" websites through frontend/backend development based on some CMS solution. There's still plenty of outfits who do just that. It's just that this type of engineering never did encompass the entirety of how the Web evolves. I worked in a "traditional" agency around 2010. My former boss asserted back then that he doubted we would be doing the same thing, using the same technology, let alone we would still be around a decade from then. He was absolutely correct.
- deleted 6y ago
  [deleted]
- jhanschoo 6y ago
  > If you’re the person whose job it is to write the component for a button making that button “work” (which almost always making a call to the backend and/or loading up an additional component or making changes to the current one) is not anymore complex nor is it really a different skill set. This is untrue. Do you have cached data to show the next page while still retrieving it from your backend? When you retrieve data how do you cache them so you don't fetch redundant data? When the user is offline or on a spotty connection, how do you persist and reconcile whatever the user does?
- neonological 6y ago
  It's more efficient to do number crunching on the front end whenever possible. The only reason you would do number crunching on the back end is if the information is private OR sending the low entropy information over IO is too costly OR the algorithm is to costly to run on the client side. In most apps only the first issue applies. The later two issues arise when you try to integrate your app with analytics or data science. So essentially for the most basic web app, most of the "number crunching" should live on the client side and the server is just storage.
  - edgyquant 6y ago
    Sure but I was merely saying that the backend is more data focused (and should have worded that better) while the front end is more about displaying and interacting with that data.
  - IneffablePigeon 6y ago
    I don't really agree those are the only reasons. We keep as much of our logic on the server as possible - partly for the reasons you state, but also because - as a team, we generally prefer working in C# to JS - there's benefit to having all your business logic in one place. It's easier to concentrate it in the back end than in the front end - minor: we can roll back our server instantly, rolling back our client requires a user page refresh
  - jamil7 6y ago
    Not sure I agree, supporting multiple platform clients or having the ambition to support multiple clients usually means for me it's easier to do as much server side as possible.
    - neonological 6y ago
      Easier to develop for but in terms of raw computation costs and speed, client side wins. If you want the maximum tradeoff for ease of development then having all of the UI rendered on the server is the ultimate solution in terms of ease of development.
- pdamoc 6y ago
  There is a comparable divide between web-designers and web-developers. People can have both sets of skills and, obviously, there is an overlap BUT, in my experience, very few web-developers have good enough design skills to produce a professional looking UI. Most resort to pre-made frameworks like Material Design or Bootstrap in order to produce decent looking UI.
cccc4alll 6y ago
I've also noticed the trend that "Full Stack" now really means back end in job descriptions. Front End has to be explicitly called out for developers that will be responsible for developing rich UX features. Front End is gaining more prominence, as more companies are moving to Cloud services and want to leverage Front End for custom business logic, which in a way is moving the stack to Front End. In near future, there will be a job description for Front End Full Stack engineer. I'm all about it.
- news_to_me 6y ago
  But... why? Doesn’t all this seem needlessly complex? How are users better served by adding complexity to the front end? Certainly there are complex UIs that require sophisticated front ends, but you probably aren’t building one, even though you’ve convinced yourself it’s necessary.
  - ervine 6y ago
    Agreed that it's complex, but I think the "needlessly" part is up for debate. Considering we're all here on hacker news, we're all used to and just fine with the idea that if you want fresh data, you refresh the page. I agree with you that for 99% of websites, this is just fine. But if the requirements are for less page refreshes and high interactivity with always-fresh data, then client side rendering with a client side cache and cache management become important. Like Apollo Client, or what have you. Does it add unbelievable amounts of complexity? Definitely. Is it needless? Depends on the goal. I would argue it's easier than manually polling for new data, managing the cache by hand and ensuring that everywhere the data is needed has been updated, and updating the DOM as a response to that new data. So to answer your question: when done right, the user is served by having the most up to date information displayed for them at all times, with the number of network requests for said data kept to a minimum. Is it worth it? I don't personally think so in the big picture, but in my day to day having this complexity live on the client side gives us so much more control over the UX that it's necessary to build what is expected.
    - hootbootscoot 6y ago
rev12 6y ago
For me, and the places I've worked, "Front-of-the-Front-End" is usually described as "UI Engineer". However, I am fully aware that can and does mean something different to other people.
hootbootscoot 6y ago
Yeah, we used to call them "Web Designers" and "Web Developers". If you met someone at a free cracker and dip event and they self-identified as one or the other, you could potentially network and collaborate and not step on each others toes. Even in Flash. One made art and masks and timelines and tweens, and one wrote actionscript...I think you get the picture. The issue is more that the front and back end have divorced. As we all actually know, the backend receives a request and responds to it, some of which can be contextually appropriate to the particular source of a request, if you know what I mean, nudge is as good as a wink. Such a response, that probably has a "bundle.js" shoved up it's nether regions, actually constitutes a sort of tennis "serve" or volley, that may unleash a programmatic payload, via said javascript (no need for bundle.js. You can hard-code js and css right into server-rendered templates, voila scoped css lol) the interactions between this initial page rendering and the activation and machinations of said javascript are an implicit set of dirty activities folks often allude to in discussions of SSR and hydration and other such silliness encountered by running your entire webserver application on the dynamic single-threaded event-loop runtime known as "the web-browsers programmatic API, brought to you by javascript", and having the largest spyware erm browser makers scripting engine blessed with more money than most countries raise in annual GD whatever annually dedicated to the impossible task of making it map to how computers actually work, which it wasn't built to do, am I digressing here? I was trying to say that isomorphic code is not anything remotely desirable to most people for most things, as the real implicit goal on this tangent is that the server wants more intimate knowledge of what a client is doing in order to better provide the illusion of the user manipulating the data, etc, etc. RPC gui is different than remote folder browsing in a vast open scientific institutions network in which index pages provide valuable insight as to the sort of files/documents/data/research-papers/cat-pix available at said resource endpoint...ah such trust...was I digressing again? We used to say "Web Designer" and "Web Developer" Does anyone have time to discuss our good lord HTTP?
aCofD 6y ago
What is the back end (not back of the front end, but just “back end”) in this framework?
- ervine 6y ago
  I consider it anything that doesn't take place in the user's browser. Writing the APIs, interacting with the DB, defining the backend data models, dreaming up the microservice architecture, whatever your workplace is doing. If it's not responsible for generating HTML, CSS, or JS, I don't really consider it front end.
deleted 6y ago
[deleted]
mruniverse 6y ago
It seems that larger companies can afford the divide. But medium to smaller companies will want full stack. Good front-end devs are usually stronger with browser-side code. I usually see smaller html/css files, flex and grid being used and a11y reader and keyboard-nav issues taken care of. And the javascript is small and generalized (not much hard-coding). With full-stack devs I normally see a mess because they are just java programmers.
jypepin 6y ago
To me it seems like OP simply refuses to evolve and wants to keep writing HTML and CSS like 10 years ago while frontend today is more complex.
luthfur 6y ago
I am sorry but...Front-of-the-side-of-the-up-of-the-what? This is division of labor gone out of control. Complexity doesn't get simplified by merely renaming things. Bloated javascript frameworks and associated "infrastructure" keeps requiring more and more people to manage them.
- jariel 6y ago
  This is not crazy, it's been this way in any app of scale for a very long time. You can put a good backend guy on the 'back of the front end' no problem, it's sometimes similar work and it can feel like 'regular coding' - sometimes it helps to have the same team working both sides of the endpoint. But the 'view' components usually require very specific knowledge of the component system and also the ability to work well with the design team, which is a different thing. It's not really a stretch.
  - thecupisblue 6y ago
    >But the 'view' components usually require very specific knowledge of the component system and also the ability to work well with the design team, which is a different thing. They require an understading of UI basics and reading the documentation. That knowledge is rarely specific, it's mostly the same pattern applied in a different manner. If a "good backend guy" can't read that (usually super simple) documentation of the frontend framework and understand how to apply it, I would not call him a "good backend". Just like a frontend dev should be able to read and understand what a node server does, a backend dev should be able to understand basics of UI frameworks, otherwise, it's not a developer we're talking about, it's a glorified typewriter.
    - cameronh90 6y ago
      My experience is that fundamentally, usually good backend developers are not good UI developers. They don't know or care about how to write nice-to-use interfaces. It's not a technical ability issue in general, though there are a whole bunch of quirks such as browser compatibility that it can seem a little unfair to expect someone who mostly deals with optimising database queries and algorithms to also have to learn. There is always a gap between what the designer produces and what needs to be created to make a fully functioning application. A good frontend-of-the-frontend developer has the passion, experience and user empathy to fill in this gap and make a site that is pleasant to use. I say all this as a backend/platform developer.
eric4smith 6y ago
Sigh. Phoenix LiveView gets rid of most of this madness.
- ketzo 6y ago
  Phoenix LiveView is built by people who live inside this madness every day :D
mouzogu 6y ago
Well it used to be that you would learn HTML and CSS, then some JavaScript for basic UI, dom interactions then later Ajax. However now it seems people are learning React, Vue etc first and so to a man with a hammer every problem looks like a nail. I truly believe we have lost sight of progressive enhancement in modern web dev. Especially with the business-oriented drive towards hiring full-stack, two for the price of one mentality but 9 times out of 10 you end up with someone who doesn't appreciate the subtleties of each layer of the UI and how they interact. And now with browser vendors pushing out new features faster than we can learn them, it really is becoming overwhelming, even if day to day things are still manageable. When you have a million ways to do the same thing, each with its own trade-offs you can start to feel some career anxieties. I fully agree with the sentiments in this article and hope it will be heeded.
hyko 6y ago
Every developer is a potential full stack developer, even if they don’t realise it. The user interface is just another interface, with its own set of rules.
Borlands 6y ago
It seems to me front end developer and backend developer still works, although front end developer role evolved, can’t see a need for this extra long names. Yes front end developers do more, than when the web was just html and tables, but that’s just evolution. You want to focus on the UI only, UI developer fits. With complexity increasing, web developer title doesn’t make sense as it is too generic. But backend, being it in java or node is a backend. I don’t see the need for this new categorisations. I think the question arises from Fullstack term usage? fullstack front end and fullstack backend has been thrown around in job interviews, so fullstack alone without context doesn’t make sense: I don’t think it ever did.
- bryanrasmussen 6y ago
  As someone who is generally described as fullstack the problem with the term is what stack is that? When you say you're fullstack there are so many variables that come into play that it is unlikely you are going to be able to just be dropped in and work with any company's stack. Your full stack is not theirs.
  - tomlagier 6y ago
    Eh, beg to differ. There is certainly domain knowledge to be had, but the underlying principles behind any particular layer of the stack tend to be more similar than different across languages and frameworks. Everyone needs a database, authN & authZ, network requests, state management, pretty forms, error handling, optimized images, etc etc. Knowing how these layers work as concepts is a lot more important than deep expertise with a particular implementation. From the perspective of a new hire, you'll spend easily as much time learning their idioms, mutations of the platforms, unique glue code and business logic as you will learning the platform.
    - bryanrasmussen 6y ago
      this is true, but >you'll spend easily as much time learning their idioms, mutations of the platforms, unique glue code and business logic as you will learning the platform. unless that is a trivial amount of time, which it generally isn't (and obviously can't be if you are expected to learn a new platform in the same amount of time to a level of reasonable proficiency), then the amount of time that you would devote to the learning it is probably not that worthwhile for the company to let you lose on the platform you don't know. Of course my perspective is as a consultant, so if I'm brought in for 6 months and I do not know part of their stack it is just not worthwhile for me to learn that part of their stack, they generally want me to be productive on the parts of the stack I do know. If I was going to be at a place for some years maybe the motivations would change, but bigger places tend to optimize and specialize their developers and not want people to be "full-stack".
d--b 6y ago
Am I the only one to think that makes sense? This divide has always existed between those who were making the UI libraries (WinForms, Qt, Telerik and what not), and those using those libraries (app developers). Because the browser allows for a lot more customization than WinForms or Qt, app devs get sucked into pixel alignment problems or crap of that nature.
- mantap 6y ago
  It makes sense if you call that person a designer. Writing CSS is not programming. It's design with a text based UI.
mattlondon 6y ago
I've noticed in more and more projects a trend for the front-end team to build a legit backend server as a facade interface for multiple other backends. So I guess this is the front-end-of-the-back-end-of-the-front-end? The rationale is that it is often easier for the JavaScript to talk to one backend facade layer, and have that backend facade handle talking to the "real" backend servers. So think sequencing and/or parallelism of API calls, serialisation, transformation etc all happening on the backend server before sending only the final result as simplified JSON to the browser. So now your front-end dev also needs to know java/go/c++ as well as html/CSS/JavaScript/typescript :)... We just call them frontend engineers and be done with it. The best engineers tend to have broadly applicable skills and can rapidly learn something all with a smile and good attitude. A sneering/condescending/moaning/complaining/whinging aversion or outright refusal for writing CSS/c++ (it cuts both ways) is usually a red flag IME.
runawaybottle 6y ago
This type of bifurcation limits the growth of developers, and makes evolving inorganic. So how does one get better at either side of that coin? Talk to your boss and say ‘I need to do more front of the front work’, or ‘I need to do more of the back of the front work’? It’s no good, and oddly it has been the go-to divide and conquer tactic I have seen in at least two of my previous companies. In fact, a very long time ago I had a company straight up tell me and other frontend developers that all JavaScript work was too advanced and will be handled by their ‘real’ developers (the backend people). It was just Jquery work at best, zero app architecture. This happened again at another place where there would be people that would do the CSS and pass it off to people that hooked up the JavaScript. I’ve been on both sides of the coin, and in both cases I either felt like it was complete bullshit for myself to be limited, and if I was on the more ‘favored’ side, I would feel absolutely sorry for the front-of-front people being limited. Companies that have strict lenses to view developers in this way will always have a limited view on an employees potential. They also generally consider certain types of work lower class. So for example, they may think someone from QA can move up to front of the frontend, but the frontend person could never seriously move over to the backend. Both the QA and Frontend person are basically maligned to their caste with their potential capped. I am speaking very specifically of companies that have clear castes (there are many still), and not speaking of the new fullstack trend. You’ve been warned, you’re up against an insidious bias. With all that said. One of the things that makes me semi decent at frontend work is that I know css and js well enough where I can find a solution that can use css in a way that minimizes JS. I couldn’t get there if stingy idiots force fed me one class of work all day, every day. This is a massive opportunity cost issue if you are facing this. The prime directive for determining who is dope at one particular thing has only one use case - time sensitive delivery. If there’s a short timeline to get to prod, or a time sensitive bug, or critical deliverable, or critical architecture (you need the really good css people setting up your layouts for example, not the sql guy that knows some css), yeah, go ahead and discriminately delegate. Otherwise, let the fucking developers grow.
K0nserv 6y ago
I think it's really interesting to compare the web to apps in this regard. In fact I wrote a blog post about this as a response to "The Great Divide"[0] a few years ago. The core thesis of mine is that on the app side of things we've always had fairly thick clients where a lot of the "backend" complexity lives in the client. This has always worked, i.e. iOS developers are responsbile for and comfortable with both the UI/UX aspect of their job and the backend aspects. I don't really understand why the web would be different from iOS and Android in this regard. I suppose one stark difference is that both iOS and Android always had a turing complete programming language at the core of development, it simply isn't possible to learn "only" layout with iOS and Android. Although, storyboard and XML views are somewhat similar to CSS + HTML I guess. 0: https://hugotunius.se/2019/06/26/on-being-a-front-end-engineer.html https://hugotunius.se/2019/06/26/on-being-a-front-end-engine...
- dustingetz 6y ago
  client server web apps are a distributed system
- chenglou 6y ago
  You're right; the medium definitely shaped the message here. I've worked with and near many native and web teams, and have observed the engineering conversations of the folks from entry level to senior level. The difference in perspective and execution is notable each time. More interestingly, a transition transition from one side to another also changes perspective and conversation. The community culture obviously also influences these discourse, but a surprisingly large chunk of the regard or disregard for UI/UX comes from using the tools you're provided by the platform, so much that unfortunately (or fortunately, if you've chosen the right platform), these factors influence one's learning and result much more so than even hard work and talent. A change of perspective is worth 80 IQ points, like Alan Kay said.
- ricardobeat 6y ago
  Wouldn't the main difference be that iOS and Android come with a very complete and high quality default UI toolkit? It's easy to build a decent app using just the system libraries, whereas on the web you're pushed to reinvent the wheel from the very start (how do I load my CSS?). Technology churn is also minimal in comparison. Anecdotally, my impression is that mobile-focused designers are much more attuned to interaction design than their web counterparts; much easier to build nice UIs when they have been fully thought out.
ricardobeat 6y ago
Time for the 'UI developer' title to shine?

86 points by Cederfjard 6y ago

This honestly seems needlessly arbitrary. If you’re the person whose job it is to write the component for a button making that button “work” (which almost always making a call to the backend and/or loading up an additional component or making changes to the current one) is not anymore complex nor is it really a different skill set. Front and backend makes sense as the two don’t even have to be the same language and front end is GUI work while backend is more number crunching, etc. “back of the front end” and “front of the front end” doesn’t have anything close to the same kind of compartmentalization. At least not in my experience.

rlayton2 6y ago
For static pages, the "front-of-front-end" developer is broadly the "web designer" and does CSS most of the time. As JS sites get more complicated, those buttons need behaviour which is generally also that person's job, so now they do JS. I'm a small operation, but I'll spend entire days on the "frontend" where I don't actually open a web browser. I'm writing the code that does all the client-side computation from the data it gets from an API. I definitely see the distinction in my own projects and as teams grown, specialization becomes more important. So I can definitely see the distinction.
ehnto 6y ago
It used to not be so, a front end developer at a typical web agency would just write HTML and CSS, maybe a sprinkle of jQuery, and any programming/logic would be done in the backend templates by someome else. Now frontend development is so complicated that you need to be a programmer as well as a frontend developer to get anything done. The first hint of deviation was when people started being called frontend engineers, we never needed that term before. It is also my guess that this is why frontend developers went from entry level roles to the highest paid roles in most agencies I have worked at. A twist I never saw coming!
- jariel 6y ago
  "It used to not be so," UI's 'used to be' thinks you installed not web pages! That's what a lot of people are missing. With complex UIs, which people see to have forgotten even exist (!) there's a big difference between front-of-the-frontend and back-of-the-frontend. This is not new, it's 20 years old at least.
  - runawaybottle 6y ago
    I mentioned this in another comment, and it’s odd that this macro outcome is not more obvious. The ‘application’ industry didn’t disappear, it just packed up and moved into the browser. It’s like saying Talk radio is dead. No, it’s more alive than ever in the form of Podcasts. There’s nothing niche about GUI application development, and has always been one of the staple exports of the tech industry. Yeah, it’s all JavaScript and CSS, annoying I know, but could be worse (Java, .net).
- CaptArmchair 6y ago
  The assumption here is that the Web equates hypertext: hyperlinked static text documents sprinkled with images and a bit of Javascript. Ever since the inception of the Web by TBL, there was a drive to use the Web as a jumping board for "Rich Web Applications". Flash, Java Web Applets, Silverlight,... were all attempts to bring the functionality of native applications to the browser. They filled a space where browsers natively lacked API's. They were also a threat to proprietary OS makers like Microsoft who sought to dominate the desktop space and what you could do with your computer in the late 90's early 00's. It was the arrival of mobile devices around 2010 that upended the status quo. It created massive new billion dollar markets for new players like Google. It also introduced an entirely new technological paradigm which spawned competition between native mobile applications and web based applications. All of that gradually coalesced around browser engines. These have evolved into incredibly complex beasts over the past 15 years with a cornucopia of API's and support for protocols. Just think about WebGL (look at the members of the Chronos consortium! https://en.wikipedia.org/wiki/WebGL https://en.wikipedia.org/wiki/WebGL)! Or how Microsoft decided to adopt Chromium for it's browser (https://www.theverge.com/2020/1/15/21066767/microsoft-edge-chromium-new-browser-windows-mac-download-os https://www.theverge.com/2020/1/15/21066767/microsoft-edge-c...) The end game here is much the same as it was back in the 90's: being able to control the sandbox in which both developers and users are playing. The difference being that you don't need third party plugins or whatever. Front-end engineering is just an expression of this evolution. It's a specialist role who's goal is to build fully-fledged applications and UI's in the browser. And that's totally valid. > highest paid roles in most agencies Early agencies in the early 00's started out as "we build and maintain your website". They were forced to pivot away from that pitch in a few short years. Either they moved towards integrated 360 communication, or they moved towards a specific niche e.g. mobile development, content strategy, UI/UX design, etc. This includes moving from building simple websites towards complex user interfaces to manage all kinds of data, content, and so on fluidly. Sure, it's still possible to start a company that does "traditional" websites through frontend/backend development based on some CMS solution. There's still plenty of outfits who do just that. It's just that this type of engineering never did encompass the entirety of how the Web evolves. I worked in a "traditional" agency around 2010. My former boss asserted back then that he doubted we would be doing the same thing, using the same technology, let alone we would still be around a decade from then. He was absolutely correct.
deleted 6y ago
[deleted]
jhanschoo 6y ago
> If you’re the person whose job it is to write the component for a button making that button “work” (which almost always making a call to the backend and/or loading up an additional component or making changes to the current one) is not anymore complex nor is it really a different skill set. This is untrue. Do you have cached data to show the next page while still retrieving it from your backend? When you retrieve data how do you cache them so you don't fetch redundant data? When the user is offline or on a spotty connection, how do you persist and reconcile whatever the user does?
neonological 6y ago
It's more efficient to do number crunching on the front end whenever possible. The only reason you would do number crunching on the back end is if the information is private OR sending the low entropy information over IO is too costly OR the algorithm is to costly to run on the client side. In most apps only the first issue applies. The later two issues arise when you try to integrate your app with analytics or data science. So essentially for the most basic web app, most of the "number crunching" should live on the client side and the server is just storage.
- edgyquant 6y ago
  Sure but I was merely saying that the backend is more data focused (and should have worded that better) while the front end is more about displaying and interacting with that data.
- IneffablePigeon 6y ago
  I don't really agree those are the only reasons. We keep as much of our logic on the server as possible - partly for the reasons you state, but also because - as a team, we generally prefer working in C# to JS - there's benefit to having all your business logic in one place. It's easier to concentrate it in the back end than in the front end - minor: we can roll back our server instantly, rolling back our client requires a user page refresh
- jamil7 6y ago
  Not sure I agree, supporting multiple platform clients or having the ambition to support multiple clients usually means for me it's easier to do as much server side as possible.
  - neonological 6y ago
    Easier to develop for but in terms of raw computation costs and speed, client side wins. If you want the maximum tradeoff for ease of development then having all of the UI rendered on the server is the ultimate solution in terms of ease of development.
pdamoc 6y ago
There is a comparable divide between web-designers and web-developers. People can have both sets of skills and, obviously, there is an overlap BUT, in my experience, very few web-developers have good enough design skills to produce a professional looking UI. Most resort to pre-made frameworks like Material Design or Bootstrap in order to produce decent looking UI.

cccc4alll 6y ago

I've also noticed the trend that "Full Stack" now really means back end in job descriptions. Front End has to be explicitly called out for developers that will be responsible for developing rich UX features. Front End is gaining more prominence, as more companies are moving to Cloud services and want to leverage Front End for custom business logic, which in a way is moving the stack to Front End. In near future, there will be a job description for Front End Full Stack engineer. I'm all about it.

news_to_me 6y ago
But... why? Doesn’t all this seem needlessly complex? How are users better served by adding complexity to the front end? Certainly there are complex UIs that require sophisticated front ends, but you probably aren’t building one, even though you’ve convinced yourself it’s necessary.
- ervine 6y ago
  Agreed that it's complex, but I think the "needlessly" part is up for debate. Considering we're all here on hacker news, we're all used to and just fine with the idea that if you want fresh data, you refresh the page. I agree with you that for 99% of websites, this is just fine. But if the requirements are for less page refreshes and high interactivity with always-fresh data, then client side rendering with a client side cache and cache management become important. Like Apollo Client, or what have you. Does it add unbelievable amounts of complexity? Definitely. Is it needless? Depends on the goal. I would argue it's easier than manually polling for new data, managing the cache by hand and ensuring that everywhere the data is needed has been updated, and updating the DOM as a response to that new data. So to answer your question: when done right, the user is served by having the most up to date information displayed for them at all times, with the number of network requests for said data kept to a minimum. Is it worth it? I don't personally think so in the big picture, but in my day to day having this complexity live on the client side gives us so much more control over the UX that it's necessary to build what is expected.
  - hootbootscoot 6y ago

rev12 6y ago

For me, and the places I've worked, "Front-of-the-Front-End" is usually described as "UI Engineer". However, I am fully aware that can and does mean something different to other people.

hootbootscoot 6y ago

Yeah, we used to call them "Web Designers" and "Web Developers". If you met someone at a free cracker and dip event and they self-identified as one or the other, you could potentially network and collaborate and not step on each others toes. Even in Flash. One made art and masks and timelines and tweens, and one wrote actionscript...I think you get the picture. The issue is more that the front and back end have divorced. As we all actually know, the backend receives a request and responds to it, some of which can be contextually appropriate to the particular source of a request, if you know what I mean, nudge is as good as a wink. Such a response, that probably has a "bundle.js" shoved up it's nether regions, actually constitutes a sort of tennis "serve" or volley, that may unleash a programmatic payload, via said javascript (no need for bundle.js. You can hard-code js and css right into server-rendered templates, voila scoped css lol) the interactions between this initial page rendering and the activation and machinations of said javascript are an implicit set of dirty activities folks often allude to in discussions of SSR and hydration and other such silliness encountered by running your entire webserver application on the dynamic single-threaded event-loop runtime known as "the web-browsers programmatic API, brought to you by javascript", and having the largest spyware erm browser makers scripting engine blessed with more money than most countries raise in annual GD whatever annually dedicated to the impossible task of making it map to how computers actually work, which it wasn't built to do, am I digressing here? I was trying to say that isomorphic code is not anything remotely desirable to most people for most things, as the real implicit goal on this tangent is that the server wants more intimate knowledge of what a client is doing in order to better provide the illusion of the user manipulating the data, etc, etc. RPC gui is different than remote folder browsing in a vast open scientific institutions network in which index pages provide valuable insight as to the sort of files/documents/data/research-papers/cat-pix available at said resource endpoint...ah such trust...was I digressing again? We used to say "Web Designer" and "Web Developer" Does anyone have time to discuss our good lord HTTP?

aCofD 6y ago

What is the back end (not back of the front end, but just “back end”) in this framework?

ervine 6y ago
I consider it anything that doesn't take place in the user's browser. Writing the APIs, interacting with the DB, defining the backend data models, dreaming up the microservice architecture, whatever your workplace is doing. If it's not responsible for generating HTML, CSS, or JS, I don't really consider it front end.

deleted 6y ago

[deleted]

mruniverse 6y ago

It seems that larger companies can afford the divide. But medium to smaller companies will want full stack. Good front-end devs are usually stronger with browser-side code. I usually see smaller html/css files, flex and grid being used and a11y reader and keyboard-nav issues taken care of. And the javascript is small and generalized (not much hard-coding). With full-stack devs I normally see a mess because they are just java programmers.

jypepin 6y ago

To me it seems like OP simply refuses to evolve and wants to keep writing HTML and CSS like 10 years ago while frontend today is more complex.

luthfur 6y ago

I am sorry but...Front-of-the-side-of-the-up-of-the-what? This is division of labor gone out of control. Complexity doesn't get simplified by merely renaming things. Bloated javascript frameworks and associated "infrastructure" keeps requiring more and more people to manage them.

jariel 6y ago
This is not crazy, it's been this way in any app of scale for a very long time. You can put a good backend guy on the 'back of the front end' no problem, it's sometimes similar work and it can feel like 'regular coding' - sometimes it helps to have the same team working both sides of the endpoint. But the 'view' components usually require very specific knowledge of the component system and also the ability to work well with the design team, which is a different thing. It's not really a stretch.
- thecupisblue 6y ago
  >But the 'view' components usually require very specific knowledge of the component system and also the ability to work well with the design team, which is a different thing. They require an understading of UI basics and reading the documentation. That knowledge is rarely specific, it's mostly the same pattern applied in a different manner. If a "good backend guy" can't read that (usually super simple) documentation of the frontend framework and understand how to apply it, I would not call him a "good backend". Just like a frontend dev should be able to read and understand what a node server does, a backend dev should be able to understand basics of UI frameworks, otherwise, it's not a developer we're talking about, it's a glorified typewriter.
  - cameronh90 6y ago
    My experience is that fundamentally, usually good backend developers are not good UI developers. They don't know or care about how to write nice-to-use interfaces. It's not a technical ability issue in general, though there are a whole bunch of quirks such as browser compatibility that it can seem a little unfair to expect someone who mostly deals with optimising database queries and algorithms to also have to learn. There is always a gap between what the designer produces and what needs to be created to make a fully functioning application. A good frontend-of-the-frontend developer has the passion, experience and user empathy to fill in this gap and make a site that is pleasant to use. I say all this as a backend/platform developer.

eric4smith 6y ago

Sigh. Phoenix LiveView gets rid of most of this madness.

ketzo 6y ago
Phoenix LiveView is built by people who live inside this madness every day :D

mouzogu 6y ago

Well it used to be that you would learn HTML and CSS, then some JavaScript for basic UI, dom interactions then later Ajax. However now it seems people are learning React, Vue etc first and so to a man with a hammer every problem looks like a nail. I truly believe we have lost sight of progressive enhancement in modern web dev. Especially with the business-oriented drive towards hiring full-stack, two for the price of one mentality but 9 times out of 10 you end up with someone who doesn't appreciate the subtleties of each layer of the UI and how they interact. And now with browser vendors pushing out new features faster than we can learn them, it really is becoming overwhelming, even if day to day things are still manageable. When you have a million ways to do the same thing, each with its own trade-offs you can start to feel some career anxieties. I fully agree with the sentiments in this article and hope it will be heeded.

hyko 6y ago

Every developer is a potential full stack developer, even if they don’t realise it. The user interface is just another interface, with its own set of rules.

Borlands 6y ago

It seems to me front end developer and backend developer still works, although front end developer role evolved, can’t see a need for this extra long names. Yes front end developers do more, than when the web was just html and tables, but that’s just evolution. You want to focus on the UI only, UI developer fits. With complexity increasing, web developer title doesn’t make sense as it is too generic. But backend, being it in java or node is a backend. I don’t see the need for this new categorisations. I think the question arises from Fullstack term usage? fullstack front end and fullstack backend has been thrown around in job interviews, so fullstack alone without context doesn’t make sense: I don’t think it ever did.

bryanrasmussen 6y ago
As someone who is generally described as fullstack the problem with the term is what stack is that? When you say you're fullstack there are so many variables that come into play that it is unlikely you are going to be able to just be dropped in and work with any company's stack. Your full stack is not theirs.
- tomlagier 6y ago
  Eh, beg to differ. There is certainly domain knowledge to be had, but the underlying principles behind any particular layer of the stack tend to be more similar than different across languages and frameworks. Everyone needs a database, authN & authZ, network requests, state management, pretty forms, error handling, optimized images, etc etc. Knowing how these layers work as concepts is a lot more important than deep expertise with a particular implementation. From the perspective of a new hire, you'll spend easily as much time learning their idioms, mutations of the platforms, unique glue code and business logic as you will learning the platform.
  - bryanrasmussen 6y ago
    this is true, but >you'll spend easily as much time learning their idioms, mutations of the platforms, unique glue code and business logic as you will learning the platform. unless that is a trivial amount of time, which it generally isn't (and obviously can't be if you are expected to learn a new platform in the same amount of time to a level of reasonable proficiency), then the amount of time that you would devote to the learning it is probably not that worthwhile for the company to let you lose on the platform you don't know. Of course my perspective is as a consultant, so if I'm brought in for 6 months and I do not know part of their stack it is just not worthwhile for me to learn that part of their stack, they generally want me to be productive on the parts of the stack I do know. If I was going to be at a place for some years maybe the motivations would change, but bigger places tend to optimize and specialize their developers and not want people to be "full-stack".

d--b 6y ago

Am I the only one to think that makes sense? This divide has always existed between those who were making the UI libraries (WinForms, Qt, Telerik and what not), and those using those libraries (app developers). Because the browser allows for a lot more customization than WinForms or Qt, app devs get sucked into pixel alignment problems or crap of that nature.

mantap 6y ago
It makes sense if you call that person a designer. Writing CSS is not programming. It's design with a text based UI.

mattlondon 6y ago

I've noticed in more and more projects a trend for the front-end team to build a legit backend server as a facade interface for multiple other backends. So I guess this is the front-end-of-the-back-end-of-the-front-end? The rationale is that it is often easier for the JavaScript to talk to one backend facade layer, and have that backend facade handle talking to the "real" backend servers. So think sequencing and/or parallelism of API calls, serialisation, transformation etc all happening on the backend server before sending only the final result as simplified JSON to the browser. So now your front-end dev also needs to know java/go/c++ as well as html/CSS/JavaScript/typescript :)... We just call them frontend engineers and be done with it. The best engineers tend to have broadly applicable skills and can rapidly learn something all with a smile and good attitude. A sneering/condescending/moaning/complaining/whinging aversion or outright refusal for writing CSS/c++ (it cuts both ways) is usually a red flag IME.

runawaybottle 6y ago

This type of bifurcation limits the growth of developers, and makes evolving inorganic. So how does one get better at either side of that coin? Talk to your boss and say ‘I need to do more front of the front work’, or ‘I need to do more of the back of the front work’? It’s no good, and oddly it has been the go-to divide and conquer tactic I have seen in at least two of my previous companies. In fact, a very long time ago I had a company straight up tell me and other frontend developers that all JavaScript work was too advanced and will be handled by their ‘real’ developers (the backend people). It was just Jquery work at best, zero app architecture. This happened again at another place where there would be people that would do the CSS and pass it off to people that hooked up the JavaScript. I’ve been on both sides of the coin, and in both cases I either felt like it was complete bullshit for myself to be limited, and if I was on the more ‘favored’ side, I would feel absolutely sorry for the front-of-front people being limited. Companies that have strict lenses to view developers in this way will always have a limited view on an employees potential. They also generally consider certain types of work lower class. So for example, they may think someone from QA can move up to front of the frontend, but the frontend person could never seriously move over to the backend. Both the QA and Frontend person are basically maligned to their caste with their potential capped. I am speaking very specifically of companies that have clear castes (there are many still), and not speaking of the new fullstack trend. You’ve been warned, you’re up against an insidious bias. With all that said. One of the things that makes me semi decent at frontend work is that I know css and js well enough where I can find a solution that can use css in a way that minimizes JS. I couldn’t get there if stingy idiots force fed me one class of work all day, every day. This is a massive opportunity cost issue if you are facing this. The prime directive for determining who is dope at one particular thing has only one use case - time sensitive delivery. If there’s a short timeline to get to prod, or a time sensitive bug, or critical deliverable, or critical architecture (you need the really good css people setting up your layouts for example, not the sql guy that knows some css), yeah, go ahead and discriminately delegate. Otherwise, let the fucking developers grow.

K0nserv 6y ago

I think it's really interesting to compare the web to apps in this regard. In fact I wrote a blog post about this as a response to "The Great Divide"[0] a few years ago. The core thesis of mine is that on the app side of things we've always had fairly thick clients where a lot of the "backend" complexity lives in the client. This has always worked, i.e. iOS developers are responsbile for and comfortable with both the UI/UX aspect of their job and the backend aspects. I don't really understand why the web would be different from iOS and Android in this regard. I suppose one stark difference is that both iOS and Android always had a turing complete programming language at the core of development, it simply isn't possible to learn "only" layout with iOS and Android. Although, storyboard and XML views are somewhat similar to CSS + HTML I guess. 0: https://hugotunius.se/2019/06/26/on-being-a-front-end-engineer.html https://hugotunius.se/2019/06/26/on-being-a-front-end-engine...

dustingetz 6y ago
client server web apps are a distributed system
chenglou 6y ago
You're right; the medium definitely shaped the message here. I've worked with and near many native and web teams, and have observed the engineering conversations of the folks from entry level to senior level. The difference in perspective and execution is notable each time. More interestingly, a transition transition from one side to another also changes perspective and conversation. The community culture obviously also influences these discourse, but a surprisingly large chunk of the regard or disregard for UI/UX comes from using the tools you're provided by the platform, so much that unfortunately (or fortunately, if you've chosen the right platform), these factors influence one's learning and result much more so than even hard work and talent. A change of perspective is worth 80 IQ points, like Alan Kay said.
ricardobeat 6y ago
Wouldn't the main difference be that iOS and Android come with a very complete and high quality default UI toolkit? It's easy to build a decent app using just the system libraries, whereas on the web you're pushed to reinvent the wheel from the very start (how do I load my CSS?). Technology churn is also minimal in comparison. Anecdotally, my impression is that mobile-focused designers are much more attuned to interaction design than their web counterparts; much easier to build nice UIs when they have been fully thought out.

ricardobeat 6y ago

Time for the 'UI developer' title to shine?