Ask HN: Why is Front-End development looked down upon? - FrontEnder
======
chungleong
I've been pondering this conundrum lately. Building an effective UI is very
hard and having one probably has a greater bearing on whether your product is
successful in the market place. Yet front-end development is looked down upon.
Why is that? Here're some of the explanations I came up with:

1\. Back-end code runs on expensive software whereas front-end code runs on
free software. People associate cost with importance.

2\. Activities of back-end code are often not directly observable. People are
conditioned to regard the mysterious with the sacred.

3\. Front-end code operates in an uncontrolled environment. That makes
development more difficult. In human society, however, control implies power
and those with power sit higher in the hierarchy.

4\. Front-end programmers often find themselves deferring to the opinion of UX
designers. A variation of reason 3: Not being a decider is associated with
lower social standings.

5\. Front-end technologies change more rapidly than back-end ones. Again, that
raises the difficulty of front-end development. Yet it means investment into
front-end code wouldn't hold its value as well as investment back-end code.
People are loss-adverse. It's an uncomfortable thought losing a critical part
of a project to obsolescence.

6\. Back-end programming is less exciting than front-end programming. People's
sense of justice lead them to reward--rightly or wrongly--back-end programmers
with greater regard.

------
acconrad
Here's a good summary from Reddit:
[https://old.reddit.com/r/cscareerquestions/comments/b4jp0k/w...](https://old.reddit.com/r/cscareerquestions/comments/b4jp0k/what_are_some_worthy_job_specializations_to_get/ej7cfuw/)

As someone who has a CS background who wanted to work in front-end, I think a
big portion of the "looked down upon" piece comes from an older era where
front-end just meant HTML and CSS. Since there isn't much logic to HTML or
CSS, it was looked down upon as easy from people with a CS background who
generally gravitate towards the backend.

Now that the front-end is more robust with arguably just as much logic on the
front-end, the thought is shifting. In addition, some people just don't like
handling the GUI layer. For the back-end, dealing with the GUI layer is their
least favorite part. So if you have a CS degree and you want to tackle the
front-end, you could be one of the rare few who has the technical chops to
handle this new world of front-end complexity.

~~~
andrei_says_
> there isn’t much logic to css and html

well structured css and html are extremely important to project
maintainability long term. Css is a declarative programming language and not
at all trivial.

As for JS based front ends, yes, they approach the complexity of game
development and totally deserve due respect.

As someone who has worked on both front end and back end code, I have a lot of
respect for both. That being said, when I delegate work, I feel a bit more
nervous about the front end because of the brittleness and potential
compatibility issues.

------
karmakaze
My personal take on this is that front-end developers move fast, really fast.
This is a good thing for business, get the feature working, move on. This
usually means doing things inefficiently. Not a problem, each user gets an
octa-core on their 3GB (to 6GB) phone. Hit a hurdle, google, stack overflow,
try, try another, working, move on. Why didn't it work, why does it work now?
Not deeply important. If it comes up a few more times, maybe find out.

Now there's nothing wrong with this flow. In fact it's pretty good as long as
tech debts are kept in check. (Don't use unvetted node modules for trivial
things.) Why do back-end devs think this isn't so great? We like knowing.
Everything down to where the software interacts with the hardware and how the
hardware behaves. Also, the 10K concurrent users are all using 10's of servers
so best not to waste memory, CPU, or network. This feels like engineering.

There is a third category of front-end devs that do truly amazing things with
very little. Elm is one such example. I also prefer Vue to React or Angular as
it is meant to be the best of these two worlds. Nuxt/Next are also awesome.
Front-end devs made these. After developing apps decided to do it better. Some
single-page applications are really well written but they are the exception.
Usually it's copy-paste, hit the deadline.

TBH, I often think front-end devs are more aligned with business. Doesn't
change the fact I still like to do clean, efficient, well-factored back-end
work.

------
thedevindevops
Can some front-enders and UX devs answer these questions (this isn't a
criticism - genuine datamining here):

1\. How are your javascript test suits organised? Do you measure code coverage
the same way?

2\. Are there any standardised terms that you can use to convey stylistic
concepts to other (front end)devs (excluding framework specific terms and html
elements)? i.e. Software Design Patterns for code

3\. Do you personally feel your field is more artistic or rigorous?

4\. Do you personally think it should be artistic or rigorous?

5\. (For reference) What is your job title?

6\. Would you say you work more closely with the Tech Lead (or organisational
equivalent) or Artistic Director (or organisational equivalent)?

7\. What is your direct report's job title?

8\. Are you able to suggest/implement global style changes on the basis of
your own authority?

9\. Do you maintain/contribute to any (front-end dev) documentation?

~~~
otras
I'm a software engineer working mostly on the front end at a large tech
company. For context, we have a separate UX team that works on design. Happy
to give these my best.

1\. Tests are organized around their component. This includes unit tests for
any logic (though often we prefer to keep as much logic out of FE as possible)
and screenshot tests for components. We also have larger-scale integration
tests.

2\. You mean like MVC (model-view-controller)? That's a pretty common one.

3\. I'm not sure artistic is the antonym of rigorous. For example, math proofs
are often both. I think it's better to characterize it as a craft. It's like
being an electrician; sometimes your wires line up nicely, but sometimes you
have to find a way (aka a hack) to be up to code while still having the
microwave's fan button turn on a fan on the building's roof.

4\. I think it should be as rigorous as possible, but as another user
mentioned, it's not realistic to own the environment in which your code runs.
I would love to have a small set of environments/browsers/screen sizes to
develop for, but that's not an option in 2019 at scale.

5\. Software Engineer

6\. Definitely tech lead

7\. Senior software engineer

8\. I can definitely suggest them, and everyone is open to ideas and
discussion. Design and software is a team effort.

9\. I write a lot of documentation. This includes writing/updating comments,
writing design documents for new FE features, updating wikis etc.

------
hacknat
I am a "back-end" engineer that could be said to "look down" on front-end
development, but the truth is more nuanced than that.

I actually think really great front-end development, when necessary, is hard
to do and the folks who are interested in it and good at it are great
Engineers. I also think that good User Experience is what makes money, though
this doesn't always mean lots of bells and whistles or even, what is
traditionally thought to be, "front-end" development.

Unfortunately the barrier to entry is probably lowest in front-end development
and so there are a lot of folks, when seeking a career change into software
development, naturally gravitate to front-end, when their natural aptitude
would probably be better suited to something else in tech, like product
manage, devops, or even "back-end" engineering (though I will admit that
"back-end" engineers tend to be biased against folks with non-technical
degrees/backgrounds).

The way I see it this creates a chain of negative causal effects. First,
"front-end" is chalk-full of people who don't know what they're doing or
talking about. Second, naturally being biased to think that the work they do
is valuable and important, "front-end" engineers often advocate for lots of
front-end rewrites and Rube-Goldberg-esque front-ends that aren't actually
necessary to the success of the product or business. The front-end is the most
visible part of the product even though it is _often_ the smallest piece of
the product so business leaders, who have little technical experience, will
often put the front-end team in a position of de-facto authority over the
product or at least give them out-sized input. The stereotype that emerges is
that front-end teams often get more resources then they need, get to rewrite
the front-end once a year using the front-end framework du jour, when it is
often not necessary to do so and a static website with few interfaces would
actually not only be fine, but better. This is a trope that you will commonly
find complained about on HN, and my own personal anecdotal experience
confirms. I once worked at a company that had a massive back-end; not that VM
count is always an indicator, but we had over 1000 large servers running our
stack. Our front-end team was half the size of the back-end team and wrote
their own CMS at one point. Two thirds of our users interactions (as evidenced
by our server logs) were through the CLI that the back-end team maintained and
wrote. Users often had no idea how to do something on the front-end, because
there was so much feature clutter.

My personal opinion is that a lot of products actually don't need as much
front-end as they think and that hiring a design firm to come in at the
beginning (and then once every two years) and hand off the front-end to a team
of back-end engineers to keep up to date with features would probably be fine.
Of course, of course, of course there are lots of exceptions to this, and I'm
not suggesting a ratio of when this is true, but even if it's 50/50 that does
not seem to justify the proliferation and front-end bloat that a lot of us
have come to loathe.

My two cents.

~~~
axaxs
Fellow back end engineer, these are exactly my thoughts. In short, it's where
most new people with no experience enter, and as a result a ton of
questionable code.

A great frontend engineer is worth their weight in gold... it's just that so
many bad ones exist, the default thought when hearing 'front end engineer' is
not a good one.

