17 ms·

Is front-end development having an identity crisis?

134 points by fagnerbrack 8y ago

egeozcan 8y ago
The biggest problem is most companies hire by ticking boxes. On the other hand, a developer is a developer. Yes, it will take a while for them to adapt if you hire a "Ruby developer" to do, say, embedded systems, so yes, it makes sense to check for patterns, but trying to match a profile is a somewhat unreachable target and useless to begin with.
- Guthur 8y ago
  A developer is not just a developer. I've been in the industry for quite a while and life for quite a bit longer and I have just never found this sort of pluggability in developers or people in general. If you want someone to write an etl script from SAP to salesforce you could probably trip over one in the street. But if you want someone to define a well thought out data model in 3rd normal form with versioned entities, property based testing coverage and full CICD pipeline you will have to search hard.
  - aalleavitch 8y ago
    In my experience, a developer is a developer; given time and an internet connection you can fill in any knowledge gaps reasonably easily (even the kind you usually go to school for), but depending on specialization and experience you can have a project done in a week or you can have it done in half an hour.
    - shodan666 8y ago
      You are wrong. 99% of serious (enterprise) software is not available for free to use just like that, and you can't learn it just like that... Let's say advanced ETL software (Informatica in above than free version), Baseband/RRU management software and APIS, the commercial solutions built on TIBCO etc. etc.
  - siquick 8y ago
    There's a lot of software projects that don't need 'a well thought out data model in 3rd normal form with versioned entities, property-based testing coverage and full CICD pipeline' out there.
    - dempseye 8y ago
      I have never seen property-based testing in the wild, to be honest.
    - xamuel 8y ago
      9 times out of 10, the person applying 3rd normal form doesn't know what they're doing and ends up over-engineering the hell out of a project and making things much worse.
  - chilledheat 8y ago
    I know some of these words.
sebazzz 8y ago
Me and my collegues like to talk about the "back-end of the frontend". This includes all the client-side logic and scripting. You have a server-side application primarily consisting of validation and data storage concerns, and a back-end of the front-end implementing some business rules etc.
- Udik 8y ago
  This is fun, in my last job I used to call "back-end of the frontend" the nodejs server (of which, as a FE developer, I was in charge too) that talked to the "real" backend and aggregated data from various other sources. So in your schema that would have been "the backend of the frontend's backend" :)
  - tracker1 8y ago
    lol.. I really like having a Node server for the app to talk to... for the most part it removes a lot of barriers to basic data transformations for requests and merging results closer to other data sources. Not having to think in a different language helps a lot too.
d--b 8y ago
> Frameworks like Angular or libraries like React require developers to have a much deeper understanding of programming concepts; concepts that might have historically been associated only with the back-end. MVC, functional programming, high-order functions, hoisting... hard concepts to grasp if your background is in HTML, CSS and basic interactive JavaScript. Well that's the difference between a frontend developer and a designer... I don't think fronted dev has changed that much. frameworks have, but the core of the role is the same: understanding/organize ui states, understanding threading models, events, interact with backend apis, know some design, etc.
- sureaboutthis 8y ago
  These "articles" on that site always leave the taste of frustrated redditors trying to make a name for themselves. They rarely make sense or have any meat to them and, after a few days of following it, I thoroughly ignore everything published there.
Adamantcheese 8y ago
I think it's less of front-end having an identity crisis and more that every major programming language is trying to do the job of every other one, as opposed to languages being specialized for certain tasks, Javascript and it's variants especially. But everyone's now got their preferred language and they won't budge. So it's another thing you have to learn in order to do the job, even if you don't actively use it.
aalleavitch 8y ago
I work for an ecommerce company that’s just small enough that as a front end dev I wear a really big stack of hats. I regularly have to reach across .net MVC, React components, jquery, fairly complex scss and JavaScript written to what standards were 6 or 7 years ago in order to implement new features. On top of that, I regularly fill in UX and design work when a designer isn’t available, and I run the company’s entire A/B testing process, and even find myself working with AWS configuration and the build process occasionally. That said, I love it; getting to participate in so much of the process allows me to really get a feel for the entire structure of the site as a whole, and I feel like experience in one area often informs learning in others and helps me communicate with specialists from many different areas. I could see it being a bit overwhelming coming foremost from a design background, but in my experience you do not need a degree to do this work (Mine are in Biology and Psychology). It just requires you to put in the time to research, and I personally think it’s time well spent (and a good boss will account for the fact that you may be learning things on the fly in setting project deadlines). Getting into the nitty-gritty of JavaScript and really understanding how it works and modern best practices will save you so many headaches later. I will say sometimes I feel pretty amateurish when it comes to the design aspect, because it relies so heavily on cultivating good design intuition, but even then I appreciate those opportunities to flex a different mental muscle.
- asknthrow 8y ago
  So, a regular programmer then?
  - Raphmedia 8y ago
    Programmers that have front-end web development has their main area of expertise are still programmers. The difference is in the tasks. As this person said, they do CSS/JavaScript and even step in the UI/UX expert shoes. Then even do design work. I have a similar task description and my title is "full-stack web developer". I simply call myself "web developer" as I consider that being able to deliver a website from A to Z is a requirement of my job. From design to back-end to hosting to SEO.
- ehnto 8y ago
BjoernKW 8y ago
Front-end and back-end are pretty arbitrary labels. Labels like these first and foremost are designed to help those who try to commoditise development work (e.g. recruiters). Why should someone be able to become an expert in HTML but not, say, SQL? Only because one of these runs on a client and the other typically runs on a server? Software development should be about creating something useful. Usually, neither back-end nor front-end code is useful on its own. By nonetheless making that distinction chances are you're creating a culture where developers neither take responsibility for the end result nor have any agency in it.
- smt88 8y ago
  I totally disagree that they're arbitrary. Front-end is commonly used to mean writing code that runs on a client browser or native environment, like iOS. Back-end means writing code that runs on a server. Sometimes they're intermingled code bases. At my companies, they aren't. Browsers are sufficiently complex targets that it's reasonable to specialize.
  - austincheney 8y ago
    In the case of web these terms are still defined by non-technical people and heavily misused. In a typical web stack the front end is the UI and the back end is the database. You notice that precludes about 80% of the people writing code on modern web apps (such as Java people) who are somewhere in the middle. Its not backend just because Apache (or Tomcat) is somewhere in there.
    - smt88 8y ago
      You can still somewhat stratify people by their specialty. Front-end devs might be working on server-side code that's generating their HTML/CSS/JS, but that doesn't require them to deal with the business logic between the database and front-end.
  - bausshf 8y ago
    To your surprise code that runs on a server can have a frontend and backend too, this holds true for a lot of other things too like compilers. Frontend does not mean visual, not at all. See: https://www.quora.com/What-are-front-end-and-back-end-compilers https://www.quora.com/What-are-front-end-and-back-end-compil...
jon-wood 8y ago
Over the last year or so I’ve started splitting what was once the big “Frontend Developer” role into two distinct parts. The first is the traditionally thought of one - taking mockups or a style guide and using that to create the visual elements of an application. CSS, HTML, and some JavaScript sprinkles. The second is a much more development focused developer role, someone who can take the work done by the first variety of frontend person and then break it down into components and integrate that with a backend API in complex ways. The two are very different roles which can rarely be fulfilled by a single person. I think we should stop trying to bundle them into the same thing.
- klez 8y ago
  Then the first should IMHO be called a front-end designer. Developer to me is someone who develops logic, not some interaction with JavaScript. Think for example of developing a static website. I wouldn't ask a developer to do that, I would ask a web designer, which I expect to be versed both in "design for the web" (as opposed to, e.g., "design for print") and being able to translate it to the chosen medium (that is, HTML and CSS). Anything more (business logic etc) are the domain of a developer. So as soon as the site is not static anymore and becomes an actual web application, that's where designers are out of their area of expertise and developers kick in. This is how we are organized where I work, at least.
  - m_fayer 8y ago
    My 2 cents: One of the hats I wear is what I'd call a "frontend app developer," corresponding to the second role mentioned by OP. I work with vue/webpack/etc. I have a passable knowledge of HTML/CSS. Give me a CSS framework and I can give you a LOB crud app with minimal fuss. Occasionally I've had to work on visually cutting-edge projects. In those cases, I've found that having a traditional frontend dev (OP's first role) and a designer on the team to be indispensable. The frontend dev specializes in thinking/coding visually with the toolset specifically provided by the web. Sophisticated layouts need careful consideration, balancing new specs (grid, flexbox), performance, maintainability, backwards compatibility, and responsiveness. Dynamic/interactive graphics and animation present a large number of approaches and frameworks all with their own tradeoffs. Then there's font rendering/scaling, optimization for print, email, and the list goes on. I guess what I'm getting at is that the strictly visual part of frontend development is huge. Easily big enough to justify its own specialty. And for me, keeping up with the frontend app-development landscape, in addition to backend/distributed-systems, that all just doesn't leave enough bandwidth for me to become amazing with the visual side of frontend dev. And the idea that a designer could do this is, to me, really improbable. Most designers I work with spend their lives in Photoshop/Sketch. Some know the basics of HTML/CSS - the box model, selectors, margins and padding and box-shadows and font-sizes, maybe some basic layout. I haven't met a single one that knows what a polyfill is, or could come close to dealing with flexbox/grid layout, or scss, or webpack, or git, nor could they set up a good workflow that rebuilds and live-reloads 4 different views every time you hit save. The frontend is now an app distribution/fat-client system. And it's huge and requires more and more specialties, there's just no getting around that.
alkonaut 8y ago
I think trying to standardize roles and role names is a pretty meaningless activity. Recruit for skills, not for some form of arbitrary title. In some stacks and some organizations these roles are well defined and meaningful - so they can be used internally. But for external use (such as in a pay comparison or job posting) they are pretty meaningless. Just recruit a software developer and specify what skills the job requires. Html/css to me is a design activity and probably better described as "web designers" or "interaction designers" and not developers at all (even if some JS is sprinkled on top to make the html come alive).
marcus_holmes 8y ago
I'm trying to hire someone for this kind of role at the moment, and it's really confusing. I need someone who can build a decent UI using Vue. I can do the tricky bits with Vuex and communicating with the server, but I do need them to be get the visual design parts of the thing, and the quite complex and advanced JS coding needed to make it happen. Am I looking for a designer or a developer? I can understand how this blurs out to needing to understand MongoDB and functional programming. It's a tough line to draw.
- intothemild 8y ago
  You need two people, sorry. You just described a designer and a developer.
  - marcus_holmes 8y ago
    I only have budget for one, and have met great designers who are also very good JS engineers. What do we call those people?
- citeguised 8y ago
  You could search for a front-end-engineer with some design-experience for hiring. Then get the initial visual/interaction-design from a freelancer. The dev should be able to fill in blanks and continue the initial design-work.
- Double_a_92 8y ago
  Someone who designs how everything should look and feel, and someone that implements that in Vue and JS.
- paraditedc 8y ago
  The keywords you should use in filters are "UX engineer" and "JavaScript". You don't need two people if you have a small team. I know a few people who meet your requirements (one person doing both design and coding). For your reference: https://careers.google.com/jobs#!t=jo&jid=/company/ux-engineer-design-1600-amphitheatre-pkwy-mountain-view-ca-3762830150 https://careers.google.com/jobs#!t=jo&jid=/company/ux-engine...
codingdave 8y ago
I fully agree that the skill sets and demands of different roles sometimes all get labelled with the same title. But that is true of any developer role. Titles are not standardized to skill sets, and trying to do so for one type of developer while the rest of the industry is still varied makes little sense to me. Yes, you will look at job postings that aren't really what you do. So keep looking, just like the rest of us web devs do when an SW Engineer title ends up being an embedded C role on robotics, and not app development. If you are struggling to find work, then expanding your skill set is the answer, not restricting the meaning of a specific title down to your comfort zone.
abledon 8y ago
I saw a tweet the other day how react hooks are the controller of the MVC in react. Wtf
- mmartinson 8y ago
  Ya that kinda makes sense. They seem like a great feature that will help smooth over some of the less sane patterns that exist in React today. I think "hooks" is a somewhat misleading name though.
paraditedc 8y ago
As a full stack engineer, I'm expected to know all of frontend, all of backend, and some level of devops. but I am not paid twice, or even close to twice. I'm not complaining, just pointing that scope of frontend is still relatively small as compared to other roles.
- elcomet 8y ago
  You are not paid by the amount you know, but by the amount of work you produce. I guess if 2 full stack engineers provide equal work as 1 front-end and 1 back-end engineer, there are no reasons for full stack engineers to be paid more
  - paraditedc 8y ago
    I think we are in agreement? My point is that people should be less entitled in terms of what's expected from them.
  - beatgammit 8y ago
    I disagree. What happens if one frontend or backend developer isn't available (quits, vacation, etc)? One of your full stack developers can fill in. You're paying for flexibility as well. However,. I think that two good full stack developers should be able to outperform a frontend/backend pair because they reduce the need for communication. Many problems take as long to describe as to implement, so you'll iterate a lot faster with two full stack developers focused on one feature each than a frontend/backend pair sharing two features. The only time having two specialists is important is if you have plenty of talent and projects are well separated. That's rarely the case, so a full stack developer should be significantly more valuable.
- gameswithgo 8y ago
  You are not expected to know ALL of both. You don't know ALL of both. A pure SQL specialist of similar talent as you probably knows tons of stuff you don't. Man, I would love to have one at my side all day.
  - 8y ago
Mon29Oct 8y ago
A good front-end developer knows how to architecture code for creating user interfaces, has a sense of design, is aware of UX, is sympathetic to accessibility, understands how the browser interprets CSS, is knowledgeable about the browser's rendering pipeline, knows the typical performance of API calls anywhere in the front-end stack, gets the division of responsibility between front-end and back-end. Any job posting asking for proficiency in Yarn or SASS or React or whatnot is for expert monkeys who will produce web trash.
dpeck 8y ago
It’s amazing how little you can get done with a big team, and yet it’s trendy in development to push for specialized roles that lead to huge communication inefficiencies.
Stranger43 8y ago
Is’nt the real problem that the market for web designers have imploded as social media became the primary platform for web marketing and customer outreach for most small businesses, killing of the need for a bespoke semi static website. Whit that role gone most web designers now find they are more needed as traditional app developers creating crud interfaces to data backend which requires less design and more business logic.
- dwaltrip 8y ago
  Things like squarespace and webflow probably contributed to this effect as well.
deleted 8y ago
[deleted]
commandlinefan 8y ago
> MVC, functional programming, high-order functions, hoisting... hard concepts to grasp if your background is in HTML, CSS and basic interactive JavaScript. And, conversely, HTML, CSS & basic interactive Javascript (or at least the UX/artistic aspects thereof) can be hard to get a handle on if your background is functional programming, high-order functions and hoisting.
- itwy 8y ago
  No, not really.
yawboakye 8y ago
To be fair, we could say programming itself also has identity crisis. Job posts don't look the same as they did 30 years ago. But in this case we accept it as part of the progress we've made. Frontend development is in the spotlight now, and it's in a far better position that it was a couple of years ago. Even for the same apps, I like them now compared to what they were a few years ago. It's a good time to be a web developer. Even better to be a web user.
jerkstate 8y ago
Same thing happened to SysAdmins with the conversion to SRE. Industries change. Sink or swim.
- expertentipp 8y ago
  Looking at many startups and even larger companies anything sysadmin and devops is for them just couple of clicks away in the AWS web console. They fail usually.
013a 8y ago
There is a substantial amount of evidence that the most effective product teams are cross-functional, and in parallel, the most effective product engineers are cross-functional. This idea doesn't necessarily hold up when you get into very deep topics like data science, db admin, cloud administration, server admin, etc. But it absolutely holds up for product development, and nearly all frontend, backend, and "modern devops" should actually be called by its real name: full stack development, or my preferred term, Product Engineering. I view every single product-focused engineer we hire as "full stack with a focus". The job titles might say things like "frontend engineer" for SEO, but the descriptions are clear: you're going to mostly be working on frontend and we expect competency in that, but you might be asked to reach into other parts of the codebase, or at least have opinions on how things are designed there. You'll be asked to participate in product planning and design. Everyone is general, but you do have a focus which represents 80% of your work. I know coding schools would love to just teach someone React and then the bare minimum of a NodeJS backend to check a box then say they're competent. Bad news: I've worked with a dozen coding school grads over my career, as well as a dozen people who classified themselves as "backend engineers". None of them were even playing the same game as the people who took the extra time to expose themselves to the entire spectrum of technology a modern product might use. Mind you, many of these fullstack people were CS grads, many others were just people with no formal training. Formal training only matters if you limit yourself by how you've been trained, and then it matters in a negative sense.
- magicbuzz 8y ago
  I don’t inherently disagree with you but you’re not recognising that as tech evolves, you’re asking people to span an extraordinary amount of complexity. In fact, the premise of the article is that front end development is now essentially two different roles.
readitone 8y ago
Hi there. The reality is this was totally predictable. In the beginning things were simple. UI/UX is focused on creating the prototype and actual implementation was done by front-end programmers. But nobody likes to pay extra, so why not make designers code? Yes, i am one of those designers, old enough to remember frustration with tables and inline css. So if you asking your self why there are no more websites that are beautiful and usable? This is your answer: Is very rare someone with artistic abilities to have "programmers mind". Is enough frustration to deal with browser layout to expect someone to do full stack front-end dev. In the end you have mediocre designers (without basic understanding of color theory or typography) that are mediocre programmers (using all the cool JS tech, without CS basic understanding), so websites have interactive technology with design interaction from 2005:)
- lowercased 8y ago
  > so why not make designers code? Well... I don't want to force someone to do that, but I'd really really really prefer if design people actually did code sometimes, so they understood the reality of what they're 'designing' from an implementation standpoint. It may take you 6-8 hours to mockup something that is ... logically impossible, which someone 'signs off' on, then 40 hours for someone else to try to cobble together - pushing back is 'combative' and 'negative', etc. You know how designers don't like people who ask for stuff that "pops" and then want more "pop"? Designers 'designing' stuff that creates practical impossibilities or gaps in state, etc. - programming folks hate that just as much as you hate 'make it pop' requests. Hey - cool - you "designed" a form with 3 elements! The actual implementation options are 17 for that area. What should happen with 0 selected? Do we want notifications or help text? Nice - that design looks really slick with 3 checkboxes in a pulldown, but you've sort of just invented a widget that doesn't really exist, will create accessibility nightmares, and you didn't show how this should behave on mobile/tablets. The number of design people I've met who can actually reconcile clean design with real implementation, usability and accessibility issues addressed is very small.
  - pjungwir 8y ago
    I can sure relate to this. Or my favorite question: "What happens when I click that magnifying glass in the top nav?" and they say, "Oh, I didn't think about that!" I doubt the real answer is for the designer to code (though it's nice when you get to work with someone like that), but you sure have to ask a lot of questions, and you never manage to check everything up front. Especially anything that doesn't immediately open a new web page, at every step there are just so many input possibilities: the user clicks this button or that, clicks elsewhere, types a bit here then a bit there, presses Enter, presses Tab, presses Escape, has a screenreader, is on a phone, is on an iPad, gets an error, gets 1000 results, changes the dropdown that enabled this other control. . . . I guess you do the best you can imagining flows up front, but plan on having some iteration as you discover gaps in the design.
Agathos 8y ago
"'It secures HTTP requests and responses' wasn't deemed a sufficient answer when asked what an SSL certificate was in a technical interview for a front-end role." I think I have to take the inteviewer's side there. Or I would at least ask a follow-up question.
- Klonoar 8y ago
  Errrr no, that's a perfectly sufficient answer for someone who's primary concern is UI layer. Is it a secure connection or not? It is? Then we're done here.
geebee 8y ago
I'm glad to see this post, and I'm glad front-end developers are starting to rebel against the nuttiness of what has happened in their corner of the web. I declared myself out a while ago. It took some digging in of the heels and a bit of a short term career hit, but I no longer do much web development. I do data work, I guess they call it "data engineering" now, lots of pipeline stuff. My background was in math and operations research, and I do calculation as well as data pipelines, so it works out nicely. I really had to start refusing to do javascript, though. I'd still do full stack (which means I handle simple frontend stuff but pass it onto someone more talented if it needs to be more elaborate) if we used Rails or something like it. That, I don't mind, and if I had to do it all myself due to it being a personal project, I'd happily keep things relatively simple in rails. If I needed something more specialized for data analysis, I'd probably write it as a service in python. Til then, I love that ostensibly Polish expression "Not my circus, not my monkey". Front end developers are going through framework churn unseen since the MVC days of 2005. You do what you do, folks, have at it, knock yourselves out. One thing, though - no, I'm not going to start writing data analysis code in Javascript so we can keep things consistent with the front end.
tabtab 8y ago
Something has gone very wrong in our industry. Typical in-house CRUD used to be relatively straightforward and a handful of developer/analyst hybrids could handle the vast majority of projects using tools like PowerBuilder, Delphi, Oracle Forms, etc. Now it takes roughly 5x longer and has to be divided into specialists, including a front-end specialist. JavaScript gizmos are always "breaking" when new browser versions come out. It makes DLL-Hell of the 90's look good in comparison. Sure, the tools mentioned were more difficult to deploy to users, but we jacked up programming costs to gain deployability. We need better standards: HTML/JS/CSS/DOM is okay for some things, but one-size-fits-all has dragged down a lot of specialities, including in-house CRUD. Maybe we need one standard for "eye-candy" and games, and another for git-er-done GUI's. I had hoped "The Web" would mature and solve the bottlenecks, but it didn't. Are we really stuck with 5x the programming resources? Accountants, wake up and bop IT on the head.
- holtalanm 8y ago
  My experience seems to be a polar opposite of this.
  - tabtab 8y ago
    A well-tuned web-stack can indeed lead to decent productivity. The problem is that the average shop either doesn't know how to tune the stack, or has no incentive to. A shop or domain settles on conventions, and one can potentially use these conventions to clean and tune a stack to fit an org like a glove. A handful of shops get it right. Web stacks have to be "managed", and if they have to managed, then the result depends on how well they are managed. The thing is, the tools I mentioned didn't need frameworks; they were frameworks. This reduced the urge and ability for "local creativity" to run amok with fads and experiments. Fear of keeping-up-with-the-IT-Jones often creates chaos in my observation. Devs have to stick the latest and greatest into the stack to placate the fear of being obsoleted.
    - sibeliuss 8y ago
      > Web stacks have to be "managed", and if they have to managed, then the result depends on how well they are managed Exactly! Without an engineer (or a team) to manage this then some serious problems can arise, including loss of productivity. If there _is_ someone managing this then productivity gains can be enormous.
seymour333 8y ago
The way this works out at the shop I'm currently at is that you get a bunch of devs who are, for lack of a better description, 3/4 stack developers (back-end, database, anything on the front-end that isn't CSS), and a few other devs who are strictly involved in the design/HTML/CSS portion of projects. This system seems to work out pretty well on most projects. There is a significant body if knowledge required to get the styling and markup in an application built properly, with a high degree of cross-browser compatibility, and in a reasonable amount of time. When I think of a front-end dev I tend to lean towards this definition. Which leaves me at somewhat of a loss to describe my role as a "back-end" developer, as I spend a generous portion of my time coding with Angular.
- brlewis 8y ago
  I really like this term "3/4 stack developer". Is it used elsewhere or did you make it up?
  - seymour333 8y ago
    As far as I know I made it up. It's the term I typically use to give potential employers (and other devs) a general sense of where my competencies are.
- h1d 8y ago
  Why would someone drop CSS as their skill when they know other frontend bits? Designers don't need to know HTML/CSS when frontends can just build it up from images. It's a weird place to draw a line that designers need to pass the result as HTML/CSS instead of just the image file.
taeric 8y ago
The irony in this is that much of the complexity in these newer frameworks is supposed to make it easier to separate the concerns. This is an area where flash actually did a good job. What was the deliverable from someone building a flash site to the web? The flash binary. There was little reason to try and blend the tooling of what the flash author built with the rest of the site. It was typically the point of the visit. Instead, we try and do a ton of stuff to setup the developer to more easily incorporate a designer's work. We do basically nothing to allow a literal handoff of a deliverable. Until that changes, I don't see it getting any more straight forward for designers/developers any time soon.
casper345 8y ago
We have shifted a focus on the developer comfortability than on the user's. All these new implementations (or libraries fundamentally) biggest selling point is making the developer life easier. Although it may make them more productive, we lose sight on the user needs.
magicbuzz 8y ago
Technology evolves. As it evolves, it becomes more sophisticated and the roles themselves become more specialised. Twenty years ago you could have a designer writing simple HTML/CSS pages and then a Java developer filling in the functionality with JSP pages. Today, the advent of sophisticated frameworks like React, and the browser becoming a highly capable development platform, it makes perfect sense to identify a separation of design-oriented UI/UX developer roles who are presentation experts and more engineering-oriented devs who focus on immutable state stores, app architecture, API design, implementation performance, testing, etc. We really need good names for these two roles.
tracker1 8y ago
imho, if all you know are HTML and CSS, you are NOT a front end developer. Knowing JS and some additional information can get you a lot farther, and to where I might consider you one... I happen to reach for node first in most cases on the server, so would say that a basic understanding of JS, node and build tooling would be sufficient. Personally, I HATE getting cast into the "front end" box when I have a lot of experience across the stack, but am simple far more experienced than most on the front end.
voycey 8y ago
Honestly - I would actually require front-end developers to have some backend coding experience in our case, we have a very large monolithic app that we are attempting to break down to a more MSA type app but it still needs upgrading. This means they will need to wade through code templated HTML / CSS / Javascript in order to re-skin the app. I think this is in part why you see these skills mixed in on job descriptions. There often cannot be a complete separation of concerns.
nanaewusi 8y ago
These titles are pretty meaningless in my opinion. Plus, what front-end developer means depends on who's looking anyways. Where I work, for example, my official job title is Senior Frontend Associate. What does this means exactly? I haven't got a fucking clue. But what boils down to on the day to day is this: I'll spend some time, turning mockups into static pages using HTML, CSS (and the occasional sprinkle of JS), but the bulk of my time is spent on implementation -- everything required to go from static site to a functional web application. Together with the other "Associates" on the team, we'll do everything from cutting the UI up into components, implementing business logic to handle behaviour and user interaction in these components, talking to the backend, and managing application state. So what we decide to call these roles isn't important. Rather, i think, we should focus on hiring for skills. This means that we should do a better job of describing the skill sets, that we are hiring for. If you are struggling to find work, you should invest time expanding your skill. Trying to restrict some arbitrary title to suit your comfort zone doesn't help either.

134 points by fagnerbrack 8y ago

The biggest problem is most companies hire by ticking boxes. On the other hand, a developer is a developer. Yes, it will take a while for them to adapt if you hire a "Ruby developer" to do, say, embedded systems, so yes, it makes sense to check for patterns, but trying to match a profile is a somewhat unreachable target and useless to begin with.

Guthur 8y ago
A developer is not just a developer. I've been in the industry for quite a while and life for quite a bit longer and I have just never found this sort of pluggability in developers or people in general. If you want someone to write an etl script from SAP to salesforce you could probably trip over one in the street. But if you want someone to define a well thought out data model in 3rd normal form with versioned entities, property based testing coverage and full CICD pipeline you will have to search hard.
- aalleavitch 8y ago
  In my experience, a developer is a developer; given time and an internet connection you can fill in any knowledge gaps reasonably easily (even the kind you usually go to school for), but depending on specialization and experience you can have a project done in a week or you can have it done in half an hour.
  - shodan666 8y ago
    You are wrong. 99% of serious (enterprise) software is not available for free to use just like that, and you can't learn it just like that... Let's say advanced ETL software (Informatica in above than free version), Baseband/RRU management software and APIS, the commercial solutions built on TIBCO etc. etc.
- siquick 8y ago
  There's a lot of software projects that don't need 'a well thought out data model in 3rd normal form with versioned entities, property-based testing coverage and full CICD pipeline' out there.
  - dempseye 8y ago
    I have never seen property-based testing in the wild, to be honest.
  - xamuel 8y ago
    9 times out of 10, the person applying 3rd normal form doesn't know what they're doing and ends up over-engineering the hell out of a project and making things much worse.
- chilledheat 8y ago
  I know some of these words.

sebazzz 8y ago

Me and my collegues like to talk about the "back-end of the frontend". This includes all the client-side logic and scripting. You have a server-side application primarily consisting of validation and data storage concerns, and a back-end of the front-end implementing some business rules etc.

Udik 8y ago
This is fun, in my last job I used to call "back-end of the frontend" the nodejs server (of which, as a FE developer, I was in charge too) that talked to the "real" backend and aggregated data from various other sources. So in your schema that would have been "the backend of the frontend's backend" :)
- tracker1 8y ago
  lol.. I really like having a Node server for the app to talk to... for the most part it removes a lot of barriers to basic data transformations for requests and merging results closer to other data sources. Not having to think in a different language helps a lot too.

d--b 8y ago

> Frameworks like Angular or libraries like React require developers to have a much deeper understanding of programming concepts; concepts that might have historically been associated only with the back-end. MVC, functional programming, high-order functions, hoisting... hard concepts to grasp if your background is in HTML, CSS and basic interactive JavaScript. Well that's the difference between a frontend developer and a designer... I don't think fronted dev has changed that much. frameworks have, but the core of the role is the same: understanding/organize ui states, understanding threading models, events, interact with backend apis, know some design, etc.

sureaboutthis 8y ago
These "articles" on that site always leave the taste of frustrated redditors trying to make a name for themselves. They rarely make sense or have any meat to them and, after a few days of following it, I thoroughly ignore everything published there.

Adamantcheese 8y ago

I think it's less of front-end having an identity crisis and more that every major programming language is trying to do the job of every other one, as opposed to languages being specialized for certain tasks, Javascript and it's variants especially. But everyone's now got their preferred language and they won't budge. So it's another thing you have to learn in order to do the job, even if you don't actively use it.

aalleavitch 8y ago

I work for an ecommerce company that’s just small enough that as a front end dev I wear a really big stack of hats. I regularly have to reach across .net MVC, React components, jquery, fairly complex scss and JavaScript written to what standards were 6 or 7 years ago in order to implement new features. On top of that, I regularly fill in UX and design work when a designer isn’t available, and I run the company’s entire A/B testing process, and even find myself working with AWS configuration and the build process occasionally. That said, I love it; getting to participate in so much of the process allows me to really get a feel for the entire structure of the site as a whole, and I feel like experience in one area often informs learning in others and helps me communicate with specialists from many different areas. I could see it being a bit overwhelming coming foremost from a design background, but in my experience you do not need a degree to do this work (Mine are in Biology and Psychology). It just requires you to put in the time to research, and I personally think it’s time well spent (and a good boss will account for the fact that you may be learning things on the fly in setting project deadlines). Getting into the nitty-gritty of JavaScript and really understanding how it works and modern best practices will save you so many headaches later. I will say sometimes I feel pretty amateurish when it comes to the design aspect, because it relies so heavily on cultivating good design intuition, but even then I appreciate those opportunities to flex a different mental muscle.

asknthrow 8y ago
So, a regular programmer then?
- Raphmedia 8y ago
  Programmers that have front-end web development has their main area of expertise are still programmers. The difference is in the tasks. As this person said, they do CSS/JavaScript and even step in the UI/UX expert shoes. Then even do design work. I have a similar task description and my title is "full-stack web developer". I simply call myself "web developer" as I consider that being able to deliver a website from A to Z is a requirement of my job. From design to back-end to hosting to SEO.
ehnto 8y ago

BjoernKW 8y ago

Front-end and back-end are pretty arbitrary labels. Labels like these first and foremost are designed to help those who try to commoditise development work (e.g. recruiters). Why should someone be able to become an expert in HTML but not, say, SQL? Only because one of these runs on a client and the other typically runs on a server? Software development should be about creating something useful. Usually, neither back-end nor front-end code is useful on its own. By nonetheless making that distinction chances are you're creating a culture where developers neither take responsibility for the end result nor have any agency in it.

smt88 8y ago
I totally disagree that they're arbitrary. Front-end is commonly used to mean writing code that runs on a client browser or native environment, like iOS. Back-end means writing code that runs on a server. Sometimes they're intermingled code bases. At my companies, they aren't. Browsers are sufficiently complex targets that it's reasonable to specialize.
- austincheney 8y ago
  In the case of web these terms are still defined by non-technical people and heavily misused. In a typical web stack the front end is the UI and the back end is the database. You notice that precludes about 80% of the people writing code on modern web apps (such as Java people) who are somewhere in the middle. Its not backend just because Apache (or Tomcat) is somewhere in there.
  - smt88 8y ago
    You can still somewhat stratify people by their specialty. Front-end devs might be working on server-side code that's generating their HTML/CSS/JS, but that doesn't require them to deal with the business logic between the database and front-end.
- bausshf 8y ago
  To your surprise code that runs on a server can have a frontend and backend too, this holds true for a lot of other things too like compilers. Frontend does not mean visual, not at all. See: https://www.quora.com/What-are-front-end-and-back-end-compilers https://www.quora.com/What-are-front-end-and-back-end-compil...

jon-wood 8y ago

Over the last year or so I’ve started splitting what was once the big “Frontend Developer” role into two distinct parts. The first is the traditionally thought of one - taking mockups or a style guide and using that to create the visual elements of an application. CSS, HTML, and some JavaScript sprinkles. The second is a much more development focused developer role, someone who can take the work done by the first variety of frontend person and then break it down into components and integrate that with a backend API in complex ways. The two are very different roles which can rarely be fulfilled by a single person. I think we should stop trying to bundle them into the same thing.

klez 8y ago
Then the first should IMHO be called a front-end designer. Developer to me is someone who develops logic, not some interaction with JavaScript. Think for example of developing a static website. I wouldn't ask a developer to do that, I would ask a web designer, which I expect to be versed both in "design for the web" (as opposed to, e.g., "design for print") and being able to translate it to the chosen medium (that is, HTML and CSS). Anything more (business logic etc) are the domain of a developer. So as soon as the site is not static anymore and becomes an actual web application, that's where designers are out of their area of expertise and developers kick in. This is how we are organized where I work, at least.
- m_fayer 8y ago
  My 2 cents: One of the hats I wear is what I'd call a "frontend app developer," corresponding to the second role mentioned by OP. I work with vue/webpack/etc. I have a passable knowledge of HTML/CSS. Give me a CSS framework and I can give you a LOB crud app with minimal fuss. Occasionally I've had to work on visually cutting-edge projects. In those cases, I've found that having a traditional frontend dev (OP's first role) and a designer on the team to be indispensable. The frontend dev specializes in thinking/coding visually with the toolset specifically provided by the web. Sophisticated layouts need careful consideration, balancing new specs (grid, flexbox), performance, maintainability, backwards compatibility, and responsiveness. Dynamic/interactive graphics and animation present a large number of approaches and frameworks all with their own tradeoffs. Then there's font rendering/scaling, optimization for print, email, and the list goes on. I guess what I'm getting at is that the strictly visual part of frontend development is huge. Easily big enough to justify its own specialty. And for me, keeping up with the frontend app-development landscape, in addition to backend/distributed-systems, that all just doesn't leave enough bandwidth for me to become amazing with the visual side of frontend dev. And the idea that a designer could do this is, to me, really improbable. Most designers I work with spend their lives in Photoshop/Sketch. Some know the basics of HTML/CSS - the box model, selectors, margins and padding and box-shadows and font-sizes, maybe some basic layout. I haven't met a single one that knows what a polyfill is, or could come close to dealing with flexbox/grid layout, or scss, or webpack, or git, nor could they set up a good workflow that rebuilds and live-reloads 4 different views every time you hit save. The frontend is now an app distribution/fat-client system. And it's huge and requires more and more specialties, there's just no getting around that.

alkonaut 8y ago

I think trying to standardize roles and role names is a pretty meaningless activity. Recruit for skills, not for some form of arbitrary title. In some stacks and some organizations these roles are well defined and meaningful - so they can be used internally. But for external use (such as in a pay comparison or job posting) they are pretty meaningless. Just recruit a software developer and specify what skills the job requires. Html/css to me is a design activity and probably better described as "web designers" or "interaction designers" and not developers at all (even if some JS is sprinkled on top to make the html come alive).

marcus_holmes 8y ago

I'm trying to hire someone for this kind of role at the moment, and it's really confusing. I need someone who can build a decent UI using Vue. I can do the tricky bits with Vuex and communicating with the server, but I do need them to be get the visual design parts of the thing, and the quite complex and advanced JS coding needed to make it happen. Am I looking for a designer or a developer? I can understand how this blurs out to needing to understand MongoDB and functional programming. It's a tough line to draw.

intothemild 8y ago
You need two people, sorry. You just described a designer and a developer.
- marcus_holmes 8y ago
  I only have budget for one, and have met great designers who are also very good JS engineers. What do we call those people?
citeguised 8y ago
You could search for a front-end-engineer with some design-experience for hiring. Then get the initial visual/interaction-design from a freelancer. The dev should be able to fill in blanks and continue the initial design-work.
Double_a_92 8y ago
Someone who designs how everything should look and feel, and someone that implements that in Vue and JS.
paraditedc 8y ago
The keywords you should use in filters are "UX engineer" and "JavaScript". You don't need two people if you have a small team. I know a few people who meet your requirements (one person doing both design and coding). For your reference: https://careers.google.com/jobs#!t=jo&jid=/company/ux-engineer-design-1600-amphitheatre-pkwy-mountain-view-ca-3762830150 https://careers.google.com/jobs#!t=jo&jid=/company/ux-engine...

codingdave 8y ago

I fully agree that the skill sets and demands of different roles sometimes all get labelled with the same title. But that is true of any developer role. Titles are not standardized to skill sets, and trying to do so for one type of developer while the rest of the industry is still varied makes little sense to me. Yes, you will look at job postings that aren't really what you do. So keep looking, just like the rest of us web devs do when an SW Engineer title ends up being an embedded C role on robotics, and not app development. If you are struggling to find work, then expanding your skill set is the answer, not restricting the meaning of a specific title down to your comfort zone.

abledon 8y ago

I saw a tweet the other day how react hooks are the controller of the MVC in react. Wtf

mmartinson 8y ago
Ya that kinda makes sense. They seem like a great feature that will help smooth over some of the less sane patterns that exist in React today. I think "hooks" is a somewhat misleading name though.

paraditedc 8y ago

As a full stack engineer, I'm expected to know all of frontend, all of backend, and some level of devops. but I am not paid twice, or even close to twice. I'm not complaining, just pointing that scope of frontend is still relatively small as compared to other roles.

elcomet 8y ago
You are not paid by the amount you know, but by the amount of work you produce. I guess if 2 full stack engineers provide equal work as 1 front-end and 1 back-end engineer, there are no reasons for full stack engineers to be paid more
- paraditedc 8y ago
  I think we are in agreement? My point is that people should be less entitled in terms of what's expected from them.
- beatgammit 8y ago
  I disagree. What happens if one frontend or backend developer isn't available (quits, vacation, etc)? One of your full stack developers can fill in. You're paying for flexibility as well. However,. I think that two good full stack developers should be able to outperform a frontend/backend pair because they reduce the need for communication. Many problems take as long to describe as to implement, so you'll iterate a lot faster with two full stack developers focused on one feature each than a frontend/backend pair sharing two features. The only time having two specialists is important is if you have plenty of talent and projects are well separated. That's rarely the case, so a full stack developer should be significantly more valuable.
gameswithgo 8y ago
You are not expected to know ALL of both. You don't know ALL of both. A pure SQL specialist of similar talent as you probably knows tons of stuff you don't. Man, I would love to have one at my side all day.
- 8y ago

Mon29Oct 8y ago

A good front-end developer knows how to architecture code for creating user interfaces, has a sense of design, is aware of UX, is sympathetic to accessibility, understands how the browser interprets CSS, is knowledgeable about the browser's rendering pipeline, knows the typical performance of API calls anywhere in the front-end stack, gets the division of responsibility between front-end and back-end. Any job posting asking for proficiency in Yarn or SASS or React or whatnot is for expert monkeys who will produce web trash.

dpeck 8y ago

It’s amazing how little you can get done with a big team, and yet it’s trendy in development to push for specialized roles that lead to huge communication inefficiencies.

Stranger43 8y ago

Is’nt the real problem that the market for web designers have imploded as social media became the primary platform for web marketing and customer outreach for most small businesses, killing of the need for a bespoke semi static website. Whit that role gone most web designers now find they are more needed as traditional app developers creating crud interfaces to data backend which requires less design and more business logic.

dwaltrip 8y ago
Things like squarespace and webflow probably contributed to this effect as well.

deleted 8y ago

[deleted]

commandlinefan 8y ago

> MVC, functional programming, high-order functions, hoisting... hard concepts to grasp if your background is in HTML, CSS and basic interactive JavaScript. And, conversely, HTML, CSS & basic interactive Javascript (or at least the UX/artistic aspects thereof) can be hard to get a handle on if your background is functional programming, high-order functions and hoisting.

itwy 8y ago
No, not really.

yawboakye 8y ago

To be fair, we could say programming itself also has identity crisis. Job posts don't look the same as they did 30 years ago. But in this case we accept it as part of the progress we've made. Frontend development is in the spotlight now, and it's in a far better position that it was a couple of years ago. Even for the same apps, I like them now compared to what they were a few years ago. It's a good time to be a web developer. Even better to be a web user.

jerkstate 8y ago

Same thing happened to SysAdmins with the conversion to SRE. Industries change. Sink or swim.

expertentipp 8y ago
Looking at many startups and even larger companies anything sysadmin and devops is for them just couple of clicks away in the AWS web console. They fail usually.

013a 8y ago

There is a substantial amount of evidence that the most effective product teams are cross-functional, and in parallel, the most effective product engineers are cross-functional. This idea doesn't necessarily hold up when you get into very deep topics like data science, db admin, cloud administration, server admin, etc. But it absolutely holds up for product development, and nearly all frontend, backend, and "modern devops" should actually be called by its real name: full stack development, or my preferred term, Product Engineering. I view every single product-focused engineer we hire as "full stack with a focus". The job titles might say things like "frontend engineer" for SEO, but the descriptions are clear: you're going to mostly be working on frontend and we expect competency in that, but you might be asked to reach into other parts of the codebase, or at least have opinions on how things are designed there. You'll be asked to participate in product planning and design. Everyone is general, but you do have a focus which represents 80% of your work. I know coding schools would love to just teach someone React and then the bare minimum of a NodeJS backend to check a box then say they're competent. Bad news: I've worked with a dozen coding school grads over my career, as well as a dozen people who classified themselves as "backend engineers". None of them were even playing the same game as the people who took the extra time to expose themselves to the entire spectrum of technology a modern product might use. Mind you, many of these fullstack people were CS grads, many others were just people with no formal training. Formal training only matters if you limit yourself by how you've been trained, and then it matters in a negative sense.

magicbuzz 8y ago
I don’t inherently disagree with you but you’re not recognising that as tech evolves, you’re asking people to span an extraordinary amount of complexity. In fact, the premise of the article is that front end development is now essentially two different roles.

readitone 8y ago

Hi there. The reality is this was totally predictable. In the beginning things were simple. UI/UX is focused on creating the prototype and actual implementation was done by front-end programmers. But nobody likes to pay extra, so why not make designers code? Yes, i am one of those designers, old enough to remember frustration with tables and inline css. So if you asking your self why there are no more websites that are beautiful and usable? This is your answer: Is very rare someone with artistic abilities to have "programmers mind". Is enough frustration to deal with browser layout to expect someone to do full stack front-end dev. In the end you have mediocre designers (without basic understanding of color theory or typography) that are mediocre programmers (using all the cool JS tech, without CS basic understanding), so websites have interactive technology with design interaction from 2005:)

lowercased 8y ago
> so why not make designers code? Well... I don't want to force someone to do that, but I'd really really really prefer if design people actually did code sometimes, so they understood the reality of what they're 'designing' from an implementation standpoint. It may take you 6-8 hours to mockup something that is ... logically impossible, which someone 'signs off' on, then 40 hours for someone else to try to cobble together - pushing back is 'combative' and 'negative', etc. You know how designers don't like people who ask for stuff that "pops" and then want more "pop"? Designers 'designing' stuff that creates practical impossibilities or gaps in state, etc. - programming folks hate that just as much as you hate 'make it pop' requests. Hey - cool - you "designed" a form with 3 elements! The actual implementation options are 17 for that area. What should happen with 0 selected? Do we want notifications or help text? Nice - that design looks really slick with 3 checkboxes in a pulldown, but you've sort of just invented a widget that doesn't really exist, will create accessibility nightmares, and you didn't show how this should behave on mobile/tablets. The number of design people I've met who can actually reconcile clean design with real implementation, usability and accessibility issues addressed is very small.
- pjungwir 8y ago
  I can sure relate to this. Or my favorite question: "What happens when I click that magnifying glass in the top nav?" and they say, "Oh, I didn't think about that!" I doubt the real answer is for the designer to code (though it's nice when you get to work with someone like that), but you sure have to ask a lot of questions, and you never manage to check everything up front. Especially anything that doesn't immediately open a new web page, at every step there are just so many input possibilities: the user clicks this button or that, clicks elsewhere, types a bit here then a bit there, presses Enter, presses Tab, presses Escape, has a screenreader, is on a phone, is on an iPad, gets an error, gets 1000 results, changes the dropdown that enabled this other control. . . . I guess you do the best you can imagining flows up front, but plan on having some iteration as you discover gaps in the design.

Agathos 8y ago

"'It secures HTTP requests and responses' wasn't deemed a sufficient answer when asked what an SSL certificate was in a technical interview for a front-end role." I think I have to take the inteviewer's side there. Or I would at least ask a follow-up question.

Klonoar 8y ago
Errrr no, that's a perfectly sufficient answer for someone who's primary concern is UI layer. Is it a secure connection or not? It is? Then we're done here.

geebee 8y ago

I'm glad to see this post, and I'm glad front-end developers are starting to rebel against the nuttiness of what has happened in their corner of the web. I declared myself out a while ago. It took some digging in of the heels and a bit of a short term career hit, but I no longer do much web development. I do data work, I guess they call it "data engineering" now, lots of pipeline stuff. My background was in math and operations research, and I do calculation as well as data pipelines, so it works out nicely. I really had to start refusing to do javascript, though. I'd still do full stack (which means I handle simple frontend stuff but pass it onto someone more talented if it needs to be more elaborate) if we used Rails or something like it. That, I don't mind, and if I had to do it all myself due to it being a personal project, I'd happily keep things relatively simple in rails. If I needed something more specialized for data analysis, I'd probably write it as a service in python. Til then, I love that ostensibly Polish expression "Not my circus, not my monkey". Front end developers are going through framework churn unseen since the MVC days of 2005. You do what you do, folks, have at it, knock yourselves out. One thing, though - no, I'm not going to start writing data analysis code in Javascript so we can keep things consistent with the front end.

tabtab 8y ago

Something has gone very wrong in our industry. Typical in-house CRUD used to be relatively straightforward and a handful of developer/analyst hybrids could handle the vast majority of projects using tools like PowerBuilder, Delphi, Oracle Forms, etc. Now it takes roughly 5x longer and has to be divided into specialists, including a front-end specialist. JavaScript gizmos are always "breaking" when new browser versions come out. It makes DLL-Hell of the 90's look good in comparison. Sure, the tools mentioned were more difficult to deploy to users, but we jacked up programming costs to gain deployability. We need better standards: HTML/JS/CSS/DOM is okay for some things, but one-size-fits-all has dragged down a lot of specialities, including in-house CRUD. Maybe we need one standard for "eye-candy" and games, and another for git-er-done GUI's. I had hoped "The Web" would mature and solve the bottlenecks, but it didn't. Are we really stuck with 5x the programming resources? Accountants, wake up and bop IT on the head.

holtalanm 8y ago
My experience seems to be a polar opposite of this.
- tabtab 8y ago
  A well-tuned web-stack can indeed lead to decent productivity. The problem is that the average shop either doesn't know how to tune the stack, or has no incentive to. A shop or domain settles on conventions, and one can potentially use these conventions to clean and tune a stack to fit an org like a glove. A handful of shops get it right. Web stacks have to be "managed", and if they have to managed, then the result depends on how well they are managed. The thing is, the tools I mentioned didn't need frameworks; they were frameworks. This reduced the urge and ability for "local creativity" to run amok with fads and experiments. Fear of keeping-up-with-the-IT-Jones often creates chaos in my observation. Devs have to stick the latest and greatest into the stack to placate the fear of being obsoleted.
  - sibeliuss 8y ago
    > Web stacks have to be "managed", and if they have to managed, then the result depends on how well they are managed Exactly! Without an engineer (or a team) to manage this then some serious problems can arise, including loss of productivity. If there _is_ someone managing this then productivity gains can be enormous.

seymour333 8y ago

The way this works out at the shop I'm currently at is that you get a bunch of devs who are, for lack of a better description, 3/4 stack developers (back-end, database, anything on the front-end that isn't CSS), and a few other devs who are strictly involved in the design/HTML/CSS portion of projects. This system seems to work out pretty well on most projects. There is a significant body if knowledge required to get the styling and markup in an application built properly, with a high degree of cross-browser compatibility, and in a reasonable amount of time. When I think of a front-end dev I tend to lean towards this definition. Which leaves me at somewhat of a loss to describe my role as a "back-end" developer, as I spend a generous portion of my time coding with Angular.

brlewis 8y ago
I really like this term "3/4 stack developer". Is it used elsewhere or did you make it up?
- seymour333 8y ago
  As far as I know I made it up. It's the term I typically use to give potential employers (and other devs) a general sense of where my competencies are.
h1d 8y ago
Why would someone drop CSS as their skill when they know other frontend bits? Designers don't need to know HTML/CSS when frontends can just build it up from images. It's a weird place to draw a line that designers need to pass the result as HTML/CSS instead of just the image file.

taeric 8y ago

The irony in this is that much of the complexity in these newer frameworks is supposed to make it easier to separate the concerns. This is an area where flash actually did a good job. What was the deliverable from someone building a flash site to the web? The flash binary. There was little reason to try and blend the tooling of what the flash author built with the rest of the site. It was typically the point of the visit. Instead, we try and do a ton of stuff to setup the developer to more easily incorporate a designer's work. We do basically nothing to allow a literal handoff of a deliverable. Until that changes, I don't see it getting any more straight forward for designers/developers any time soon.

casper345 8y ago

We have shifted a focus on the developer comfortability than on the user's. All these new implementations (or libraries fundamentally) biggest selling point is making the developer life easier. Although it may make them more productive, we lose sight on the user needs.

magicbuzz 8y ago

Technology evolves. As it evolves, it becomes more sophisticated and the roles themselves become more specialised. Twenty years ago you could have a designer writing simple HTML/CSS pages and then a Java developer filling in the functionality with JSP pages. Today, the advent of sophisticated frameworks like React, and the browser becoming a highly capable development platform, it makes perfect sense to identify a separation of design-oriented UI/UX developer roles who are presentation experts and more engineering-oriented devs who focus on immutable state stores, app architecture, API design, implementation performance, testing, etc. We really need good names for these two roles.

tracker1 8y ago

imho, if all you know are HTML and CSS, you are NOT a front end developer. Knowing JS and some additional information can get you a lot farther, and to where I might consider you one... I happen to reach for node first in most cases on the server, so would say that a basic understanding of JS, node and build tooling would be sufficient. Personally, I HATE getting cast into the "front end" box when I have a lot of experience across the stack, but am simple far more experienced than most on the front end.

voycey 8y ago

Honestly - I would actually require front-end developers to have some backend coding experience in our case, we have a very large monolithic app that we are attempting to break down to a more MSA type app but it still needs upgrading. This means they will need to wade through code templated HTML / CSS / Javascript in order to re-skin the app. I think this is in part why you see these skills mixed in on job descriptions. There often cannot be a complete separation of concerns.

nanaewusi 8y ago

These titles are pretty meaningless in my opinion. Plus, what front-end developer means depends on who's looking anyways. Where I work, for example, my official job title is Senior Frontend Associate. What does this means exactly? I haven't got a fucking clue. But what boils down to on the day to day is this: I'll spend some time, turning mockups into static pages using HTML, CSS (and the occasional sprinkle of JS), but the bulk of my time is spent on implementation -- everything required to go from static site to a functional web application. Together with the other "Associates" on the team, we'll do everything from cutting the UI up into components, implementing business logic to handle behaviour and user interaction in these components, talking to the backend, and managing application state. So what we decide to call these roles isn't important. Rather, i think, we should focus on hiring for skills. This means that we should do a better job of describing the skill sets, that we are hiring for. If you are struggling to find work, you should invest time expanding your skill. Trying to restrict some arbitrary title to suit your comfort zone doesn't help either.