
Front-End Handbook - AllThingsSmitty
https://frontendmasters.gitbooks.io/front-end-handbook/content/practice/types-of-front-end-dev.html
======
ksikka
A word of caution from a worried developer -

Implicit in this laundry-list of technologies is that learning the
technologies implies you will be good at frontend dev.

This is simply not true and encourages the incorrect philosophy that knowing
technologies makes you a good developer.

Aspiring frontend devs should just practice building and maintaining stuff,
not worry too much about the technology, and that itself would put them on the
fast track to becoming better developers. Along the way they will encounter
problems and evaluate the pros and cons of various solutions to solve those
problems. That's the valuable experience you need to be a successful frontend
developer - not simply knowing what gulp or angular is.

~~~
49531
If you want to be a successful front end developer you need to learn
JavaScript. The more JavaScript you know, the more valuable you will be. If
you know JavaScript then you can pick up Angular / React / Gulp / Node /
Backbone / whatever web tech someone needs.

Having experience with a specific technology might help you, but I'd hire a
JavaScript expert with no experience in my tech stack more than an someone who
has become an expert in a specific framework / library.

~~~
falcolas
I agree. If you can come to grok CSS, HTML, and Javascript, there's no limit
on the abstractions around those three concepts that you can pick up.

As an anecdote, I am not a front end developer. I try and shy away from it as
much as possible; I don't have the design chops to make my own designs, and I
dislike the chains of following someone else's design to the pixel. That said,
I was able to pick up an abandoned sass/React/Flux/gulp/bower/lodash/...
project built up by an intern and make it work in under a day.

Because I knew the basics, I could follow the execution path, consulting
documentation where necessary, and figure out why things didn't work.

Learn the basics; it makes understanding the abstractions easier.

------
buro9
This basically says: Learn all the things!

But the best front-end people I ever saw did _not_ learn all the things. They
learned a few things, mastered even fewer of those things, but ultimately
understood how to make what they had learned work for them to do whatever they
needed to do.

If anyone is reading the handbook and thinking this is too much, you'll never
get through it... you're right, it is and you won't. Just learn HTML really
well, CSS fairly well (and pick a tool to help manage the CSS) and learn raw
JS and one of the helper systems (JQuery). That's it... get the core skills
right, get those mastered, and the rest will come easily and you'll understand
when and why to use them.

~~~
aklemm
This is great advice. Especially in a time where people from varied
backgrounds are scrambling to learn software development, it is critical to
stay focused on what matters to avoid getting bogged down. So, for anyone
getting bogged down, just get back to handling your CSS and learning your
JavaScript fundamentals along with one framework.

------
teh_klev
Perhaps should link to here:

[https://www.gitbook.com/book/frontendmasters/front-end-
handb...](https://www.gitbook.com/book/frontendmasters/front-end-
handbook/details)

or here:

[https://frontendmasters.gitbooks.io/front-end-
handbook/conte...](https://frontendmasters.gitbooks.io/front-end-
handbook/content/index.html)

Current link points to a list a front end developer job titles which had me
wondering what the context was for a minute.

------
thomasjonas
I was just going through the list of possible interview questions
([http://www.frontendhandbook.com/practice/interview-q.html](http://www.frontendhandbook.com/practice/interview-q.html))...
Am I the only (mediocre) Front-end dev that has problems answering these
questions? I always start doubting myself when I don't know the answer to
basic questions like "Are there any problems with serving pages as
application/xhtml+xml?". All these questions ring a bell somewhere, but I have
no idea how to turn that into a good answer at an interview... Whenever I run
into problems I just try to fix them... I'd like to think that's more
important than this factual knowledge.

~~~
callahad
> "Are there any problems with serving pages as application/xhtml+xml?"

That was more relevant when XHTML was still vying to be the future of markup
on the web. The issue was that the XHTML content type mandated a strict XML
parser that hard failed if your markup wasn't well-formed, whereas HTML is
more lenient. With XHTML, it was easy for a single stray closing tag to kill
your entire site. This was an especially common concern if you allowed markup
in, say, comments.

~~~
atom-morgan
> That was more relevant when XHTML was still vying to be the future of markup
> on the web.

Unfortunately many interviewers still ask these types of questions even if
it's no longer relevant.

------
jfaucett
Who can look at this list and actually want to start getting into frontend
development? 30 learn X entries not to mention 30x lists of tools for each
area. Front end development seems to have gotten beyond ridiculuously
complicated - especially when you consider half these entries will probably be
outdated in 6 months time and almost certainly in 2 years time.

------
domrdy
The best frontend developers I know are those that actually stick to frontend
development. Imho its one of the most frustrating job in the field yet
underappreciated and looked down upon.

------
gozo
Seriously, how is this on the front page and why do I get down voted for
pointing out that it is less than excellent? If you want to be a better
developer, especially as a front-end developer, you need to learn how to write
and value good documentation. Let's take a look at the first paragraph:

> Below is a list and description of various front-end job titles

Completely redundant, just makes reading and editing it harder.

> The common, or most used (i.e. generic), title for a front-end developer is,
> "front-end developer" or "front-end engineer".

Common/most used/generic? There's no need for this clarification and developer
versus engineer is already covered by that subsection.

> Note that any job that contains the word "front-end", "client-side", "web
> UI", "HTML", "CSS", or "JavaScript" typically infers that a person has some
> degree of HTML, CSS, DOM, and JavaScript professional know how.

So HTML, CSS and JavaScript means HTML, CSS and JavaScript? Even if you want
to keep this line it's an easy rewrite to 'Jobs that contain "front-end",
"client-side" or "web UI" imply work experience with HTML, CSS and
JavaScript'.

I could go on and on, like the use of "when the word" everywhere. Half of
every description is fluff that is already obvious by the context. It's not
properly written for it's audience. If you don't know what testing is you're
not going to be enlightened by a list of tests, you need to describe what
someone in testing does and what purpose it has.

> When the word "Acessibility" is included in the job title, this will denote
> that the developer has extensive experience crafting front-end technologies
> that support accessibility requirements and standards.

Again, seriously?

~~~
underwater
Your comment was almost as long as the page you're complaining about. Maybe
channel your time into writing something useful instead of just complaining
that what others do isn't good enough.

Your complaints were all about on the first page. There are a lot more pages,
and decent enough content on subsequent pages.

~~~
gozo
And what does your own condescending remarks add exactly? This was the page
that was linked and frankly it wasn't good enough for HN nor did it reflect
particularly good on front-end developers. Maybe something you yourself should
think about when posting comments with a claimed employer in your profile.

~~~
underwater
I may have been a little condescending in my response, but I stand behind my
point. You listed a bunch of surface level complaints about the structure of
the text which had little to do with the content. They weren't constructive at
all.

And it's worth pointing out that though HN doesn't have many guidelines,
complaining about downvotes and that a submission isn't appropriate are two of
the things that they ask people not to do
([https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)).

~~~
gozo
At least my comments add something to the discussion, yours is just meta
complaints that helps no one. My comment was constructive, I even offered
suggestion how to rewrite things to make it better. It wasn't more surface
level then any other comment and I did "complain" about the content if you
read the last two lines. My main complaint wasn't about the structure at all,
it was about signal to noise level and not providing value. The part about
accessibility is a perfect example, it has structure but says nothing to
someone who doesn't already know what it is.

I wonder is this how you treat code at Facebook? You let glaring faults just
sit because criticism are seen as complaining? Just because it's text and not
code doesn't make it less important. In fact is often more important since the
value is in the text itself, while code can be "good enough" if it produces
the right output.

You have now made two comment, but still haven't actually disagreed with
content of my comment. It's comments like yours that ruin HN by making it into
lowest common denominator meta discussions where everyone just states opinions
without having to present any form of argument.

Since you are so concerned about my time I can inform you that I was going to
write another comment about something that I had researched which five other
people were cluelessly speculating about, but now I wrote this one instead.

------
jordache
a successful frontend developer is more than just the sum of the tools he/she
knows. the individual needs to have an interest (dare I say passion) in art &
design. Needs to continuously evolve his design vision, and have enough of
interest of the subject to peruse work of his peers to get inspiration.

------
supergetting
Very cool! Does anyone know of anything like this for back-end development?

------
pbreit
Is this useful? It looks like a ton of links with very modest curation.

~~~
hliyan
Perhaps not for someone of your (or my) level of experience with the subject
matter. But when I was a beginner, this was exactly the level of curation I
needed (and could not find at the time). If the links provide all the details,
there's no need to pad the book with redundant content. I'm familiar with
almost everything mentioned here, but I still appreciate what the author has
done. I just shared this with my entire team.

------
gozo
I'm sorry but that page is a big mess. There's no structure, too much
redundant information and confusion of terms.

------
f0rgot
How do you save on hacker news?

~~~
icebraining
Upvote it.

