
Front-End Developer Handbook - wyclif
https://frontendmasters.com/books/front-end-handbook/2018/
======
jpd-
"A developer who can code the front-end, back-end, API, and database isn't as
absurd as it once was (excluding visual design, interaction design, and CSS).
Still mythical in my opinion, but not as uncommon as it once was."

I see this attitude expressed a lot among people who identify as "front end"
developers and it seems like psychological projection to me. I would count
myself and a number of close friends and associates as these mythical "full
stack" developers so (in my circle) I don't think it is uncommon at all.

One thing I have noticed (again, in my circle) is that "front end" developers
tend to start learning with front end development and are commonly self
taught, while "back end" guys are more likely to have a degree and start with
something enterprisey like .NET or Java. From what I've seen, back end guys
have a much easier time moving to front end than vice versa.

~~~
nickthemagicman
Are you able to fully configure webpack? Do you know how to animate with CSS?
Do you know Greensock? Three.js? Babel? The differences between ES5,6,7?
Co.js? ES generators? Webassembly?

Being able to hack out a little Js and css to make an Enterprise dashboard imo
does not a front end or full stack developer make.

I have one of those 'college degree' thingys and I'll tell you
something....imo CORRECT front end development is way more challenging than
back end development.

~~~
manigandham
That's a nice set of buzzwords but nothing complicated. Babel is just a
transpiler. ES versions are like any other programming language with versions,
use Babel to solve. ES generators are just yield functions that have been
around for decades and finally getting to JS. What about webassembly? It's
just a compilation target for other languages and delivery format for the
browser.

And why is configuring webpack always mentioned as a complicated thing? If you
can code all the above then why cant you make a simple javascript app return
an object following a schema with an input, output and list of loaders?

~~~
nickthemagicman
Of course! Databases are just more complicated spreadsheets! And puppet is
just scripts that configure servers. And encryption is just a few math
equations that mask data.

Man when you put it that way I just realized how trivial all technology is!

Really anyone can do it without years of experience and training!

Who knows why the salaries are so high!

~~~
manigandham
I'm not sure what the point of your comment is, but the large number of 3
month bootcamps that create frontend devs does seem to show that anyone can do
it.

I'm calling out the fact that the things you mentioned and the concepts behind
them are not unique to frontend and certainly not even that complex. All it
means is that the frontend landscape is finally catching up to traditional
backend languages and dev practices. We've had compilers, multiple language
versions, and environment targets for a long time. We've had functional
programming, event sourcing, actor systems, immutable data, and materialized
views for a long time. We've used DSLs and full programming languages to
create config objects and execution paths for a long time. We've had async and
multithreaded programming for a long time.

None of this is new or suddenly challenging, which goes to the original point
of this thread that backend skills tend to move much easier to current
frontend dev than the opposite direction because of what's involved. I'm not
sure how much backend experience you have, if any, but naming assorted
buzzwords and claiming that configuring webpack is complex only seems to
reinforce my comments.

~~~
nickthemagicman
Actually making things happen with the technologies is alot different than
being able to spout general principles on how they work on the internet.

Your trivialization of these technologies makes me think you're possibly a
first/second year computer science student who's never actually worked with
any of them and mainly read a modern javascript overview page on the web or a
rundown in a textbook. Or just a troll!

~~~
manigandham
Ok... but again, what does that have to do with frontend vs backend which is
what this thread is about?

The concepts define the complexity, and my point is that they are nothing new
so why would frontend be harder when it's only catching up to backend
environments? No amount of buzzwords changes that.

------
poof131
"A whole lot of developers adopt static type checking for mostly subjective
reasons or band wagon emotions. Some sell out completely to Typescript and the
Microsoft way of doing things while others take on a slower approach with
Flow. One thing is for sure, most developers don't need types, they are simply
complicating already complex problems and solutions. Like most things, most of
this trend is subjective dogma not objective value."

Wow, biased much. I love JavaScript and ES6. But anything that I work with a
team on or expect to live beyond a month or so, I love types for. Making a
large refactor without types is the wild west. Types help provide
structure/understanding about the data flowing through your system. And if you
need to eject you can with Any. I used to prefer pure JS (or Python),
certainly quicker to prototype, but also more difficult to grow and maintain.
Tradeoffs in both directions. Such an amateur statement makes me question the
rest of the document.

~~~
baron816
> Making a large refactor without types is the wild west. Types help provide
> structure/understanding about the data flowing through your system.

If you’re working on a large, unstructured project that you’re trying to
refactor, you’re problem probably isn’t with the types. It’s that the people
working on it used types as a crutch so that they thought it was okay to write
classes that were thousands of lines long with giant methods that are
impossible to make sense of.

The interview question I’ve been asking lately is about object design. I tell
them not to put things into one big method—that it needs to be readable for
junior devs. They always ignore me. The ones who struggle the most are the
ones who try to do it in a staticly types language (which I’m sure you agree
is crazy to use in an interview for a tiny problem). Their mental model forces
them to think about types first, and they then can’t think about anything
other than that and just making the thing work.

If you aim to keep your objects and you methods small enough that anyone can
read them and make sense of them, then you don’t need static types and
refactoring becomes easy. There are plenty of developers of mediocre talent
who never use types and are able to build huge features and projects quickly
and with high maintainability and flexibility because they write code that
sticks to good object oriented design principles.

A class I work on regularly has become so big that everyone, especially the
more senior, more talented engineers at my company are too afraid to touch,
let alone try to refactor. It’s stayically typed.

~~~
swirepe
I don't know why you're conflating using a type system with writing large
classes.

~~~
baron816
At question is whether the benefits of static typing outweigh their costs.
From my experience (purely anecdotal) static typing provides a false sense of
security that encourages bad practices, thus turning the benefits of types
into costs themselves.

~~~
Can_Not
To me, that sense of security is not false (even 90% reliable is better than
0%). And to suggest that type systems are a contributory factor to developers
writing functions/classes that are too large is completely unsubstantiated.

------
pjmlp
The title should be Web Front-End Developer Handbook.

Native desktop, mobile, TV and infotainment systems are also front-end.

~~~
anon1094
I don't understand why you're getting down voted, but this is absolutely
correct and more specification is needed when it comes to "front-end".

I come from a traditional front-end background (for web) and I send many
front-end jobs for my company RemoteLeads as well. Front-end is the most
fragmented programming job category and I'm sure it's the one that gets the
most applicants.

Companies will say they're looking for a front-end developer with JavaScript
experience. In reality, they need an engineer. They need someone who
understands Computer Science principles and can express that in JavaScript.
But, because "JavaScript experience" can mean anything they'll get a lot of
applications from Front-end Designers who are more on the HTML / CSS end of
the spectrum.

And now with things like React Native it's getting even more complicated.

Ultimately, it's because knowing HTML, CSS, and JavaScript makes you such a
powerful developer and you can do a lot.

To combat this the title has to be more specific. What do you need
accomplished? Engineering? Design? It's not just front-end, be more specific.

Jerry Low put it best in his article titled The Death of Front-end Developers
([https://medium.com/@jerrylowm/the-death-of-front-end-
develop...](https://medium.com/@jerrylowm/the-death-of-front-end-
developers-803a95e0f411))

~~~
Blackstone4
I read the Jerry Low article and comments.

On the front-end, I feel like you can group people into two categories:

\- Front-end/UI designer - UI specialist with HTML, CSS, wireframing and some
JS skills

\- Front-end developer - JS engineer typically leveraging JS frameworks and
Bootstrap

In the comments section of Jerry's article, it feels like there are a bunch of
HTML + CSS specialist who need to re-position themselves as UI designers. They
are being displaced by front-end devs who can leverage Bootstrap to do the
bulk of the UI. They can work with a UI designer to put together the workflow
and tweak the UI.

Jerry also states: "Even without the divide on the front-end I still hear lots
of people claiming they’re full stack developers — I guarantee they’re not."

I don't understand his perspective here. If you work on the front and backend
then you are a full-stack developer. If on the other hand, a full-stack
developer claimed to be an expert on both the front and backend...then I would
be wary.

~~~
mrisoli
Definitions are complicated, it feels like they should be static when the
definition of what a front-end developer does is always changing as technology
comes up with different mediums like smartphones, watches, VR, etc.

I've thought about this a lot and I would say something like this:

A front-end/UI designer is concerned about the _user_ interface with the
application, that is, how a user interacts and utilizes an application.

A front-end developer is concerned about the _client_ interface with the
application, such as what browsers support what and how you can work with
that, screen sizes and how to best utilize them(can't have a full word
processor and keyboard in a smartwatch), how do you flow data through the
client in a way that it doesn't hog the system's memory or makes everything
slow, tradeoffs between server-side and client-side rendering, caching,
optimization, optimistic UI, unstable connections, progressive enhancement and
graceful degradation, and much more.

Of course, this doesn't mean a front-end developer/designer won't have to
dabble in both roles eventually.

------
tannhaeuser
Congrats to putting this together; I like it.

At the risk of preaching to the choir here, however, I feel like these days
Web dev publications don't sufficiently focus on foundations (HTML, CSS) and
jump to JavaScript-heavy solutions a little bit too early for my taste.

As a consequence, I frequently see Web dev newcomers ask questions such as
"What framework should I use for (basic website)" when of course for the
requirements at hand a simple static site will do, and thus is preferable. See
[1] for an example.

It might be all very clear to older devs (like me) who have seen the Web
evolve during the last (almost) 25 years. But I'd imagine for 20-somethings or
younger the "trifecta" of HTML/CSS/JS as they are today will be a giant puzzle
when presented as a whole, having aggregated many features and workarounds
that can only be understood in the discourse of the time. In particular,
JavaScript is IMHO a terrible beginner language, the design rationales and
compromises only apparent to someone with a little bit of compiler writing
background, and in the context of its original purpose.

[1]:
[https://www.reddit.com/r/webdev/comments/8bi1bc/creating_my_...](https://www.reddit.com/r/webdev/comments/8bi1bc/creating_my_first_site_which_framework_should_i/)

~~~
iandanforth
[http://bettermotherfuckingwebsite.com/](http://bettermotherfuckingwebsite.com/)

------
slindsey
It looks like a book at first glance but is really an outline with a list of
references to other locations to read more about each of the topics. Useful
but no new or interesting content on its own.

------
xhrpost
Do other devs tend to agree with the idea of full stack being a myth? "A
developer who can code the front-end, back-end, API, and database isn't as
absurd as it once was (excluding visual design, interaction design, and CSS).
Still mythical in my opinion, but not as uncommon as it once was."

I've been FS for most of my career, mostly the result of working in smaller
dev teams where you had to own product from top to bottom. I'm willing to
admit not being an expert in all the areas and perhaps that's the catch. I
also have to disagree with the timing idea, if anything, I feel I was more an
expert in the past (despite JS being my top skill) before the exponential
increase in JS tooling and framework complexity hit the scene. So, 10+ years
ago, I was writing FS application. VBS on the back-end in ASP classic, build
out the schema in T-SQL(Sybase), build out our own psuedo-mvc in VBS to server
JSON for XHR requests from the client that we then wrote with the help of
PrototypeJS. I knew ES3 like the back of my hand and often had to contribute
to SQL queries a couple hundred lines long. VBS wasn't that hard (just
annoying) and ASP classic pretty straight forward. Now even though JS is
everywhere, things are much more config and library dependent and the shift
has been a challenge for me.

~~~
JamesBarney
I'm with you, what do you call someone who can build and ship the back and
front end of a working application, if not a full stack developer?

Because its pretty obvious a bunch of these people exist,

~~~
ggregoire
Most small/middle companies hire people with a CS degree who can create a data
model, some APIs in any language and then build a JS web app calling those
APIs. Well, at least that’s how companies work in France. Not sure what’s
mythical about these profiles, they are the most commons from my experience.

------
frou_dh
Not sure I'd call this a book. It's a colossal link dump.

There could be a sibling publication containing links to 1000 MOOC courses
calling itself "The Renaissance Man Handbook".

------
lioeters
Noticed that "Learn Node.js" is a single short page. These days, I think
frontend devs are increasingly working with complex build and test flows that
require deeper familiarity with Node.js, for example, npm, Webpack, etc.

------
daviddahl
"Here's a guide for you to make 75K a year, learning all of this will take 10
years." LOL

~~~
seattle_spring
Can you show me where this was said or inferred in the article? I'm a front
end engineer and I make, well, a _LOT_ more than 75k.

~~~
JamesBarney
The picture inserted from payscale or salary.com

