I'm curious -- what does a "front end developer" actually do?

[futureDevelopment]

I know they develop the outward look and functionality of websites.

..But with drag & drop development tools out there, CMSs, etc., how valuable could "front end development" actually be?

The coding isn't hard. HTML, CSS and javascript are actually pretty damn easy. I learned them on my own, and I'm thinking damn near anybody can learn enough to develop a website (including the billions of people in "low overhead" countries like India).

...So what makes "front end developers" so valuable in the US job marketplace?

What do they do all day? Please describe one task in detail.

 

[Sonny Bonds]

You're forgetting all the libraries and frameworks in Javascript.

 

[Tr0yTV]

Post this question in the programmers thread. You can also check reddit, quora, or stack exchange. I'm sure they have the in depth answers you're looking for.

 

[desjardins]

The JS ecosystem changes rapidly. There is a running joke about the "state of javascript in 20xx" every year because every year there are changes in frameworks and tooling it seems
Front end Devs are in demand from what I can see

 

[PikaDaDon]

I know they develop the outward look and functionality of websites.

..But with drag & drop development tools out there, CMSs, etc., how valuable could "front end development" actually be?

The coding isn't hard. HTML, CSS and javascript are actually pretty damn easy. I learned them on my own, and I'm thinking damn near anybody can learn enough to develop a website (including the billions of people in "low overhead" countries like India).

...So what makes "front end developers" so valuable in the US job marketplace?

What do they do all day? Please describe one task in detail.

Have you ever made a website? Following tutorials and knowing the basic syntax of HTML/CSS/Javascript maybe easy but actually finishing a project is a whole other thing.

 

[Matt504]

The drag and drop sites you're referring to are inherently limited in what they can achieve and many of them don't really care about things that are important to user experience. They are for building out relatively simple websites that don't need complex functionality.

 

[dora_da_destroyer]

It’s not just for web, any software you use has a front end, the pieces you see and interact with, lots of money to be made as a front end developer for b2b software as that’s what drives the experience, customer satisfaction and thus sales.

 

[futureDevelopment]

Have you ever made a website? Following tutorials and knowing the basic syntax of HTML/CSS/Javascript maybe easy but actually finishing a project is a whole other thing.

I’ve built a few websites — “child themes” out of wordpress, using my own css and javascript.

 

[futureDevelopment]

The drag and drop sites you're referring to are inherently limited in what they can achieve and many of them don't really care about things that are important to user experience. They are for building out relatively simple websites that don't need complex functionality.

One example of this “complex functionality” please?

To me, “front end development” doesn’t connote “complex functionality”... I’ve always looked at databases & such as complex functionality, but that’s not front end...,

 

[Pete Wrigley]

With Front End development, at least in my experience, it's more design oriented in that you also have a knack for UI/UX. That said, it also helps to be well versed in Photoshop and Illustrator (or similar programs).

Also, sprinkle some marketing in there too because more than likely, you're going to be working with the marketing, sales, and social media staff.

So yeah, anybody can code but can you code AND design? Can you also create a brand identity that flows well across different platforms and applications?

Last thing, if you're working with WordPress, it wouldn't hurt to learn PHP and possibly React.js with this whole Gutenberg fiasco that just dropped.

 

[TrebleMan]

To me front end and server side are both easy when you're doing your own projects.

However, enterprise front end code that has tens of thousands of lines of code written over the years? What the jobs are really paying for is not so much knowing the tech, but making sure you can adapt to changing environments both in house and the whole Javascript ecosystem.

Large codebases are going to need to be maintained, modified, refactored and add additional features to - and that's not easy. There's a reason why so many companies have a lot of bugs on the front end. Multiple teams can all be working on the same front end projects, sometimes they'll modify other teams' code to make sure it'll fit in with their's.

Everything changes when you step into big feature heavy projects with teams. The scalability problem is very real whether you're on the front end, native or server side.

Again, as a software engineer no matter what part of the app you're working on, the most vital skill will be reading code, not writing it.



Ah, not to mention when they want to convert that entire codebase from one framework to the next to keep up to date. There are probably some companies right now that have a major React codebase that they want to switch over to Vue. Maybe they want to implement React styled components and get rid of their CSS files, which is another major overhaul. React Hooks are a big new feature in alpha, so people are going to have to re-write all those render prop and higher order component patterns, then get rid of the connection to Redux. Then it's going to be something else or a new pattern somebody else finds out, and people will have to rewrite the codebase again to keep up. So they hire some new engineers to assist and they don’t like dynamically-types codebases, so now integrate typescript. But typescript isn’t as nice as Elm according to some opinions, so now time to port everything over again. Now some engineers start to get tired of this, so they get other jobs and you have new hires that need to be onboarded. Of course this needs to be done while writing new features and fixing bugs. These new features add new state to the application that now your existing components must watch. Sometimes they don’t play well with the current architecture either, so back to refactoring again. But now the next new shiny Javascript pattern emerges.

If you want to see the hassle first hand: Take whatever project you have right now, write it in React. Use Flux for state management. Focus on making it scalable and readable. Then write it with React styled components to get rid of the css files. Then remove Flux and use Redux instead. The remove Redux and use the Context API. Then rewrite the whole thing with Vue and Vuex with additional functionality/feature. Now imagine all of this, but with more people writing on top of your code while keeping in mind the company is looking at the next major framework and/or library to use instead. Are you keeping up with the new ECMAscript standards as well?

Meanwhile on the server side, that team is using Go, which depends very little on external libraries so their environment is much more stable and predictable. Must be nice.

Funny thing is, according to the new Javascript survey the front end end on average makes more salary wise than serverside Javascript now, primarily for the reasons mentioned.

 

[futureDevelopment]

T
Everything changes when you step into big feature heavy projects with teams.

Thanks for the detailed response.

Just out of curiosity -- what are a few front-end "features" on enterprise sites that you wouldn't find on normal sites?

Forgive my ignorance -- I know they're out there. I'm just having a hard time picturing what a site might do on the front end that would require thousands of lines of code. Stuff like "cookies" maybe?

 

[TrebleMan]

Thanks for the detailed response.

Just out of curiosity -- what are a few front-end "features" on enterprise sites that you wouldn't find on normal sites?

Forgive my ignorance -- I know they're out there. I'm just having a hard time picturing what a site might do on the front end that would require thousands of lines of code. Stuff like "cookies" maybe?

No problem breh.

I've worked on both server side and front end for different applications, and some of the front end tasks I've had were to write the basic CRUD on the server. So some front end developers are expected to know some back end as well.

In terms of code, taking Redux for instance, the state of a front end application can have numerous states: which modals are modals on/off, which animations to show based on where the user is scrolling like perhaps some parallax effects, the logic being handled to send http requests to the server and based on the responses will have to dispatch actions based on whether a user is signed in/out, the error handling for failed requests which brings up a whole new set of conditions. Remember, this being about the user experience, most enterprise apps elegantly handle the user experience compared to most personal projects. General performance for websites utilizes modern algorithms to keep space and time complexity down.

Cookies is another thing, but also handling "HTTP only" cookies and jwts, tracking session data as well.

For single page applications, the conditional rendering of components/routing can be complex based on application state: what if the user is inactive and tries to click somewhere they can't access unless they have privileges - do you want the same action to take place when they try to access their profile page as you do them trying to submit a reply. Speaking of that: the different routes for a site. A lot of profile pages don't look like other places on the site, the navbar changes according to whether a guest or user is signed on. Same goes for languages: enterprise apps must take into account several different locales and some characters need different fonts and styles to accommodate for the less/extra space taken. If you want realtime feedback, then websockets must be added to a user gets updates as soon as they occur. Switching themes and allowing user's to customize their own viewing experience.

Tensorflow just got a Javascript SDK so now we can run that in our browser as well, only a matter of time until people want that in their apps.

Take a look at these websites:
Awwwards - Website Awards - Best Web Design Trends

Google Cloud Infrastructure

As I said, me personally I have experience with both serverside and front end, and I'll be honest, I have more experience with the server stuff and I think the serverside stuff is easier. I'd much rather write SQL queries than try to reason about css's frustrating behavior.