6 ms·

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 alwa

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.
- ironmagma 6y ago
  You can always continue to write JS as a static piece of code in your HTML, use raw CSS, and use imperative, lifecycle-agnostic libraries like jQuery; there is nothing stopping you, and nothing about that has changed. It’s just that there are better options now.
  - ehnto 6y ago
    I do it for a living so that's not really an option. That's also where my perspective is written from, as an industry full stack dev turned contractor, commenting on the past. I wasn't trying to say one way is better than the other, it has just been a surprising outcome that's all. I think it's also worth remembering the context of old web tech. Computers were slow, javascript wasn't performant and backward compatability was still a huge issue. We did our best to use as little JS as possible. When phones came along, computers got faster, and flash et al were earmarked for deprecation, there was a void of opportunity for javascript powered frontend frameworks, and the web industry started to build and embrace UI tooling albeit with a new lexicon.
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.

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.
ironmagma 6y ago
You can always continue to write JS as a static piece of code in your HTML, use raw CSS, and use imperative, lifecycle-agnostic libraries like jQuery; there is nothing stopping you, and nothing about that has changed. It’s just that there are better options now.
- ehnto 6y ago
  I do it for a living so that's not really an option. That's also where my perspective is written from, as an industry full stack dev turned contractor, commenting on the past. I wasn't trying to say one way is better than the other, it has just been a surprising outcome that's all. I think it's also worth remembering the context of old web tech. Computers were slow, javascript wasn't performant and backward compatability was still a huge issue. We did our best to use as little JS as possible. When phones came along, computers got faster, and flash et al were earmarked for deprecation, there was a void of opportunity for javascript powered frontend frameworks, and the web industry started to build and embrace UI tooling albeit with a new lexicon.

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.