
Is front-end development having an identity crisis? - fagnerbrack
https://dev.to/assaultoustudios/is-front-end-development-having-an-identitycrisis-2224
======
aalleavitch
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.

~~~
ehnto
I was in exactly your shoes, and they can be pretty big boots to fill. But
being able to take on so many parts of the process feels really good and you
get a greater feeling of ownership over the whole product. You can make
smarter decisions and understand the whys of more requirements rather than
just the whats and hows.

It also allowed me to develop a really strong pragmatism. With so much to
learn you have to be really lean and effective with your learning and cut
requirements where they don't make sense.

~~~
helij
Unfortunately as I am experiencing it right now while it's great to be able to
do lots of things and own the whole product, it is detrimental to your
knowledge and your CV. I am in the job market after 14 years and my skillset
is so specialised that it is hard to get a job. I got a few interviews but
fell hard on home assignment. We'll see what the future brings.

~~~
scarface74
I have the same fear with the road I’m taking now. I’ve changed jobs a lot in
the last 10 years after staying at one job for 10, and just being a really
good C# developer and then “architect” got me a long way. Along with barely
passable front end skills.

But now that I’m trying to fill out the gaps on both ends - back end with a
deep knowledge of AWS, Linux, Docker, devops, Node. and the front end along
with some more project management experience, I’m trying to qualify for
overpriced “implementation consultant” roles - since those are the only roles
that pay significantly more than I’m making now in my market without going
into management.

But the fear is that while having the broad expertise will qualify me for high
paying jobs, there are relatively few of them out there. I have to have a deep
understanding of at least part of the stack to get a job or contract gig
quickly.

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

~~~
root_axis
> _tools like PowerBuilder, Delphi, Oracle Forms, etc. Now it takes roughly 5x
> longer a_

I've seen no evidence to support the suggestion that building CRUD apps for
the web takes 5x as long as with something like PowerBuilder, Delphi, VB etc.
The web is very simple but extremely flexible and you can get as much or as
little out of it as you like. If it takes 5x as long it means the technical
management is inept. I also have personal experience with some huge internal
VB and Delphi projects during the 90s that were utter nightmares, and I know
_anyone_ else working in that era can attest to similar experiences.

> _JavaScript gizmos are always "breaking" when new browser versions come out.
> It makes DLL-Hell of the 90's look good in comparison._

This is just false. Standards compliant JS releases across the browsers have
been extremely stable for years, there are no "JS gizmos" breaking because of
browser releases. The DLL-Hell comparison is ridiculous, there is simply
nothing even remotely comparable to that on the web today.

> _Maybe we need one standard for "eye-candy" and games, and another for git-
> er-done GUI's._

This is an arbitrary distinction and not a technical one. The solution is to
understand which problems need solving and then to select the appropriate tool
(that you understand how to use) for the job.

~~~
meredydd
_> I've seen no evidence to support the suggestion that building CRUD apps for
the web takes 5x as long as with something like PowerBuilder, Delphi, VB etc_

Well, I have!

We actually did the test, with Anvil
([https://anvil.works](https://anvil.works)), which is explicitly a VB/Delphi-
like platform for the web.

We took a straightforward CRUD-y consulting project as a spec, and built it
with traditional tools and with Anvil. We did our best to keep it fair: We
raced an expert against an expert, and we kept the web tech simple: simple
templating, minimal JS, etc. And it was _still_ about 7 times faster with the
Delphi-like tool.

(It was actually 10x faster if you just count dev time, but we counted
overhead meetings too - again, in an effort to be fair. It was still "one
week" vs "one afternoon".)

~~~
root_axis
Huh? You don't see the irony in using a web toolkit as an example of how you
can be more productive NOT using the web? Anvil is a VB/Delphi-like platform
_for the web_ , it even transpiles python down to JS in order to run in the
browser. You're proving my own point for me. The web is so versatile that it
gives you the power to do whatever you want, including clone a Delphi form
builder in the browser. How is that an argument against the web?

~~~
tabtab
I'm skeptical such a tool can stand the test of time per browser changes. A
code base may work this year, but not in 5. A dedicated CRUD-friendly GUI
standard would likely be well-tested on CRUD because that's its main job, not
cat videos nor Amazon product lists.

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

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

~~~
crazygringo
> _and being able to translate it to the chosen medium (that is, HTML and
> CSS)._

Writing good, maintainable HTML and CSS is fundamentally an engineering role
-- how to deal with z-index, how to structure into components to avoid abuse
of !important, the performance implications of animating transform() vs other
properties, how to factor into variables for colors and distances, how to
avoid spaghetti classes because CSS is fundamentally global.

In my experience, good designers and good engineers generally come from quite
different mindsets, and I would never expect a designer to write well-
engineered and maintainable HTML/CSS, the same way I would never expect an
engineer to be versed in the intricacies of the rhythms of typography, color
theory, or the emotional associations of positive and negative space.

~~~
3pt14159
They exist. They're exceedingly rare, though. I know only a handful and they
tend to stick to one framework or way of doing things at a time to keep their
learning burden to the absolute minimum. They're also pretty picky about who
they work with.

(One of my friends that meets this description is looking for a new remote
Ember gig. If one of you out there at a cool company looking for a new
dev+designer send me an email and I'll intro you.)

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

~~~
lowercased
> I doubt the real answer is for the designer to code

I'm not saying they have to code 100% of everything, but I'm really fed up
with having to deal with that sort of "well gosh that's not our issue!" hands
off sort of 'design' folks.

Internal design teams that work in the same building as the
implementors/devs... maybe a different experience. I'm sometimes brought in
and given "mockups" from an external team, done in whatever tool of the day
they use, that have little bearing on real world web implementation.

it's apparently beneath some of these folks to learn css/html and use ... you
know... a _web browser_ to mock up a _web site_. i don't care how much
'freedom' some tool gives you, you're just punting the hard implementation to
someone else.

Came off a project recently like this - the original team had done 'weeks' of
'design' and 'planning' with an external design firm. "but plan on having some
iteration as you discover gaps in the design" sounds nice, but in their mind,
they'd already "thought a lot about it" 8 weeks earlier, so any implementation
issues I found were somehow... my fault? my problem? "these guys are a really
strong design firm..." who don't seem to have ever actually implemented
anything they design, from what I could tell.

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

~~~
ransom1538
I have been in the mobile space. Backend to me means: server side
(rails/go/python), javascript, sql, devops, react admin panels, aws, css.
Frontend to me means: Android or iOS. When someone says 'full stack' \-- that
to me means they know iOS or Android AND all of backend.

~~~
nickthemagicman
Front end traditionally has meant the browser.

~~~
h1d
Mobile apps have been around for over a decade.

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

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

~~~
bausshf
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-
compil...](https://www.quora.com/What-are-front-end-and-back-end-compilers)

~~~
alkonaut
"Frontend developer" is shorthand for "frontend web developer" or "web
frontend developer". There is rarely any ambiguity in that.

While a compiler has a front- and back end, I doubt there are many ads for
compiler frontend developers or compiler backend developers.

~~~
bausshf
There aren't many ads for any compiler related issues, but that doesn't mean
they aren't "real".

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

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

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

------
seymour333
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
I really like this term "3/4 stack developer". Is it used elsewhere or did you
make it up?

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

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

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

------
Stranger43
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
Things like squarespace and webflow probably contributed to this effect as
well.

------
commandlinefan
> 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
No, not really.

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

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

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

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

------
Agathos
"'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
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.

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

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

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

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

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

------
marcus_holmes
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
You need two people, sorry.

You just described a designer and a developer.

~~~
marcus_holmes
I only have budget for one, and have met great designers who are also very
good JS engineers. What do we call those people?

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

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

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

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

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

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

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

