
Front-End Developer Handbook 2017 - blueatlas
https://www.gitbook.com/book/frontendmasters/front-end-handbook-2017/details
======
mrits
I made a pretty sophisticated Angular app a few years ago which is still
selling and being maintained by other devs on my team. I started helping my
friend with a new app and realized I'm already obsolete. Screw frontend
development, I'll come back when things settle down.

~~~
k__
I have the feeling Angular was fad.

I met many people who bet on it, but most of them, even the 'fanboys' didn't
seem to be 100% convinced of it.

"We panicked multiple times, bit it always turned out we were wrong and just
didn't do things the Angular-Way"

Ember, for example, is kicking it for a much longer time, even with fewer ppl
using it.

~~~
thewhitetulip
I am using Vue, which is much simpler than Angular. With Angular2, I spent a
few weeks and still wasn't able to understand how things are working, contrast
that with Vue, I was up and running within one week, migrated my html only app
to use AJAX in a matter of a week!

[https://github.com/thewhitetulip/Tasks-
vue](https://github.com/thewhitetulip/Tasks-vue)

Vue.JS is great to use!

~~~
k__
Same with React. Tiny API, not much concepts.

Even Cycle.js just has a few concepts and is even more flexible than React or
Vue.

Angular 1&2 feels like someone let loose a Java or C# dev onto JavaScript, who
tried to apply all the design patterns™

~~~
thewhitetulip
I feel Vue is simpler and faster as far as programming is concerned as
compared with React.

~~~
k__
yes, it's more OOP like the others. which is probably easier to understand for
most devs.

But I'm currently buying into the FP fad, haha

~~~
thewhitetulip
:-D I am not in any fad as such, but for some reason I find writing functions
better than writing classes, it is faster and more intuitive to write vue-js
code than react code. Simple architecture and small API.

~~~
arvinsim
Funny you should say that since the other person was implying that React apps
are usually functional(largely when paired with Redux).

~~~
thewhitetulip
I was under the impression that functional programming and programming by
writing functions are two different things.

Also, I might have said it incorrectly, the thing is, Vue has a clean API, you
have to hook up lifecycle functions, so all I have to write is a Vue element
with six lifecycle functions and one function each for distinct AJAX call.

Sorry for the confusion.

------
iagooar
It should be called Front-End Developer Handbook Early 2017. Or even early Feb
2017 ;)

Now seriously, how's the front-end progressing currently? Has the pace become
a bit more humane?

~~~
hakanito
> JavaScript will settle, and hopefully, CSS will erupt and everyone will cry
> fatigue until it settles.

Sounds pretty accurate. My perception is that a large part of the JS community
has started to settle on React with Redux/MobX for state management.. Facebook
also really lowered the barrier to entry for React with create-react-app. CSS
is still up in the air a little bit, with many different solutions still being
used. Sass, CSS-in-JS, CSS Modules+PostCSS and most lately styled-components
(which is very promising, but lacks features like universal rendering out of
the box).

~~~
ktRolster
I think WebAssembly is really going to shake things up here in the next few
years.

~~~
flukus
Why? Besides easy deployment (sometimes), what does it offer over desktop
applications?

~~~
ktRolster
Over desktop applications? Ease of deployment, cloud based, etc. Most things
have already moved to the web anyway, so it's not really a competitor against
desktop applications, it's a competitor to everything that is already in the
web.

~~~
k__
As far as I know it's not suited as target for many mainstream languages.

It's more like the NDK in Android. So ppl can write high performance libs in
non-gc languages like C or Rust.

------
rpcorb
I'd argue that front end development tools are complex and varied because the
craft itself is complex and varied. Try to strike the optimal balance between
usability and fine control. It's not easy. How to welcome newbie developers
with intuitive tools while not frustrating experienced ones with blunt
instruments. Imagine all the schools of thought for how to best achieve this
delicate balance. Not to mention beauty and elegance in design.

~~~
kbart
Front-end is not fundamentally complex at all, the only complexity comes from
ever changing tools and techniques. I occasionally create websites (approx.
one or two per year) for my own or family/friends use and _every_ time I have
to learn everything anew, because the tools I used a year or even several
months back are no longer around or have changed beyond recognition.

------
ergo14
Just take information there with a grain of salt. The what to expect in 2017
section says that web components will never gain traction where in fact one of
the biggest enterprises in their industries adopted them already: Github,
Slack, Comcast, USAToday (Ganett), ING, Coca-Cola, Electronic Arts, General
Electric, Google, Youtube and others.

Just [https://www.webcomponents.org/](https://www.webcomponents.org/) reached
over 500 reusable elements, just polymer slack channel is now 6,5k users.

The current growth and adoption looks very bright, chrome, opera and safari
already shipped 1.0 versions of most of the spec (so no polyfills are needed),
firefox is close behind and edge is implementing right now.

If this is not traction then I'm not sure what is. I'm not even accounting for
other libraries/frameworks like x-tags, bosonic, svelte and others.

~~~
GeneralMaximus
Have you used Web Components as part of a large project? What has your
experience been?

I'd love to start pushing them to my clients, especially non-tech companies
who can't afford to rewrite all their code every time a new framework becomes
the fad, but I'm still kinda unconvinced. I'd love to read some real-world
case studies.

~~~
ergo14
Well if you want "big" cases you have Google Play Music, Youtube (gaming site,
+ the main one is being rewritten right now - you can force beta with some
cookies), electronic arts sites like battlefield1 and others. Watch polymer
summit streams they show some really high profile sites that use
webcomponents.

Personally I've introduced web components using polymer library in two ways -
upgrading legacy jquery based application and when starting a fresh CMS system
with admin panel that is 100% SPA built with polymer (kind of like weebly
interface - its not public yet).

It worked well for both of my cases, It felt quite similar to my previous
angular 1.5+ component based approach (so I suppose it would be comparable to
react/vue development).

Right now you can use polymer-redux or polymer-uniflow if you want to
structure big application data flows.

I haven't encountered bigger obstacles or problems compared to other solutions
I've used in the past.

I've integrated 3rd party libs like crossroads-router or quill editor just
fine.

I looked a bit at Angular 2.x but for me Polymer look way more natural in
terms in how applications should be build on the web.

What I did miss was a routing element like angular's ui-router (I didn't like
`app-route` element)- but this is currently being worked on and there is a POC
ui-router port for Polymer already.

~~~
GeneralMaximus
Thank you so much for your response. I had no idea all those properties were
built with Web Components/Polymer! Maybe I'm living in a React/Vue bubble,
because this stuff has never shown up on my radar.

> I looked a bit at Angular 2.x but for me Polymer look way more natural in
> terms in how applications should be build on the web.

Completely agree. In the long term, I'd love to see most reusable UI
components on the web built with Web Components, with optional wrappers for
people who still want to use frameworks.

One more question: is there currently a way to do server-side rendering for an
SPA built with Web Components? I'm assuming something like jsdom will work?

~~~
ergo14
No as far as I can tell this is not possible - because web components with
shadow dom do not leak implementation details.

For example you have <video> tag - it has its own internal controls that are
not part of the markup - same with web components - <my-custom-elem> is what
the browser sees - not what is inside - for it it is just a DOM element.

Then again I haven't explored the subject too deeply since I do Python server
side so js rendering is not an option here. I suppose it would be possible if
you would drop the shadow dom from your elements.

------
sjcrank
This link will get you to the handbook content:
[https://github.com/FrontendMasters/front-end-
handbook-2017/b...](https://github.com/FrontendMasters/front-end-
handbook-2017/blob/master/SUMMARY.md)

------
Nimsical
It's rather ironic that the front-end developer handbook doesn't support
mobile devices.

Doesn't inspire confidence.

~~~
kagamine
There is mention of mobile devices as early as page 8. There are 31 uses of
the word "mobile" in the document. The document does not tell you how to build
a website, it tells you about the tools you can use to do so reading as a
series of lists linking to those technologies and a series of graphs. If you
want to know about media queries for example, you have to follow the links.
It's not meant as a PDF version MDN or W3schools.

edit: not usually one to complain about downvotes, but the document is
literally what I described it to be. So, why?

~~~
tmnvix
I think you have been downvoted because you missed the point of the parent
comment. The HTML version of the handbook is not readable on mobile (the table
of contents leaves no room for the content).

~~~
kagamine
Well thanks for telling me at least. I reread OP's comment and I see what was
meant now, it wasn't clear to me at the time I commented though.

------
fpgaminer
I did LAMP+HTML+JS+CSS stuff back in the day, but most of my work and hobbies
over the past six years has not involved front-end. I only recently got back
into the scene. I've dabbled with React and crew in quite a few hobby projects
now and, at this point, I just find the whole modern front-end development
stack completely wacky.

I always liked Javascript as a language, but like everyone else had the scars
to show for its thorny bits. Looking at the modern stack from afar left me
fantasizing about all the painful points in Javascript being fixed. ES20XX,
Babel, webpack, npm. Wow!

To be honest, a lot of the modern stack _is_ nice. But for every step forward
these tools take, they take two steps back.

We have a nice package manager, npm, yay, but what happens when I `npm install
-S bootstrap`? Nothing. Oh sure, it installs it, but how do I _use_ it? It's
tossed in node_modules, where there's no sane way to reference it. I ran into
this problem immediately, on my very first hobby project. It's now two years
later, 2017, and it's still a problem that requires googling around, sifting
through old answers, and finding the hack that I find least painful.

Breaking up libraries into manageable sub-packages. Sounds great. It's
fundamental to strong development. But usually you have a master
application/library that references all the pieces, if the pieces were meant
to be part of a coherent whole. But front-end devs? _shrugs_ You just have to
include everything by hand. Has seriously no one looked at their package.json
in a simple TODO app and said "Something is wrong here"? How is a 20-30 line
list of dependencies normal for the most basic of applications? It isn't. It's
isn't maintainable. No one is going to remember all the packages they need to
include each time they start a new project. They're doing what I'm doing; copy
paste from the last project, like some holy script scrawled by ancient masters
from long ago.

Fancy new JS language features are nice. `for of`, `for in`, filter, map, etc.
But seriously I can't use `<SomeThing onClick={this.handleClick}/>`? I have to
use binding magic, special function definitions, etc? Because _nobody_ has to
register event handlers, right? Geez. And why did they spec a standard for
classes, finally, but not static methods and types!? That had to come in
another version later, leaving yet another legacy of out-dated documentation?

Webpack, like everything else, is an improvement by the numbers. Writing
modular javascript and getting it packed into a bundle is nice. Almost like a
real programming language! But why do I have to write a cryptic
webpack.config.js for every project? Why do I have to install Babel and
webpack separately? Why do I need to install 3 other babel related packages?
Why do I need a .babelrc? It's just insane. There should just be one tool, one
command. "modernjs build". Done. Break that one tool into sub-libraries/sub-
tools underneath, I don't care, but when I'm building fancy Uber-for-
breastmilk Web 2.0 SPA, I'd rather focus on UX than spending my evening
configuring compilers to what should be their defaults.

The most frustrating thing, and a common theme, is the amount of times I need
to Google things while developing with the modern stack. "Oh, ummm ... how do
I export/import?" "How did I configure webpack last time?" "Errr ... how do
you include a bootstrap theme?" "Was it `in` or `of` to iterate over
values...?" "How do you filter in place? Oh, you can't ... okay..." A lot of
that sounds like basic stuff, like "How do I export/import", but ya know what?
The way it's implemented in modern JS is just not intuitive. Call me dumb if
you want, but I've dealt with a _lot_ of languages in my time, and JS is the
one where I cannot possibly remember the exact magical incantations for
specific kinds of exporting and importing. And really, that's how everything
is. It's just cryptic and non-intuitive. The underlying concepts of any of
these major tools or systems is sound. The implementations are gibberish.

As much as I'd like to say "sorry for the rant", I'm not. Something is
horribly wrong with developer culture if this abomination is what we've
created. There's no excuse for it. I've heard people argue that all of this is
just a result of front-end being in-between stages of its life, and that
things will eventually settle down and be stable and usable in a few years.
But you know what? Rust, a completely new and modern programming language,
went from nothing to a thriving ecosystem in just a matter of years. It was
driven by Mozilla, hardly the largest company. Meanwhile MASSIVE companies
like Facebook, Google, Amazon, etc have given us the "modern front-end".
There's no excuse for the ecosystem to be in this state.

"But you don't have to use all those libraries and tools!" Of course not. I
could just LAMP+HTML+JS+CSS it up like the good ole days. It worked then, it
works now. But it frustrates me that there exists tools that _should_ be
better. npm _should_ make life easier. ES2017 _should_ make Javascript a
better language. I tried out these tools for a reason. Old school development
was painful. Javascript with modules and packages, reactive UI, state
management, etc. It's all awesome! I'm not messing about with the tools for no
reason.

Imagine if I sold you an automated potato peeler. "It'll peel the potatoes for
you in seconds!" And it does! But turns out you spend more time cleaning it
than you spent just peeling potatoes the old fashioned way. That's what the
modern front-end tools are like. They take the painful parts of old-school
front-end and make them easier, but they add tons of busy-work elsewhere that
ends up making things a net negative.

~~~
StreakyCobra
> But seriously I can't use `<SomeThing onClick={this.handleClick}/>`?

Give a try to Vue.js, you can do exactly this. This framework reconciled me
with frontend development after I discovered it on HN. Let's say you want to
build a custom button with a special functionality and reuse it, like a button
that logs when it has been clicked. Simply create a component like this (it's
almost self-explanatory):

    
    
        <template>
            <div class="colored-box">
                <p @click="logClick">{{ text }}</p>
            </div>
        </template>
    
        <script>
        export default {
            name: 'LogButton',
            props: [
                'text'
            ],
            methods: {
                logClick: function () {
                    console.log('The button "' + this.text + '" has been pressed"')
                    this.$emit('click')
                }
            }
        }
        </script>
    
        <style scoped>
        .colored-box {
            background-color: red;
            border: solid 1px black;
        }
        </style>
    

There are 3 sections in the file, one for the HTML template, one for
Javascript code, one for CSS style. All this belongs to the same components,
so the methods you defined in the javascript code can be called directly from
the html template as you wanted.

Once your component is ready, you can use it in other files, and in a damn
simple way:

    
    
        <LogButton text="Delete" @click="…" />

~~~
CharlesW
I _really_ like Vue, and I _love_ single file components.

React folks: Is there no way to do this with React? I may need to use React
soon, and if it can't do this I'm going to be pretty sad.

~~~
acemarke
You can write components however you want. For components and styles, there's
numerous approaches, and it's up to you which one you use. You can write your
CSS totally separately, you can import CSS into a JS file and have it auto-
generate unique class names, you can define styles completely inline in a
component, and so on.

Can you maybe clarify what you think you can't do with React?

------
carlmungz
As a junior dev, that list almost makes me want to run to the hills...where I
will presumably stumble upon another similarly monster-like list telling me
all the things I need to learn to become [insert job role here].

~~~
douche
Hint: Move to the backend. Building the APIs that crunch SQL into JSON for the
react/angular/fad of the week folks to consume is much easier, and the half-
life of your framework and language knowledge can be measured in years, not
months.

~~~
NTripleOne
Alternatively, find somewhere to work that doesn't insist on using the latest
'greatest' new fangled bollocks technology simply because it exists.

~~~
fpig
This is a double-edged sword, though, as it may hurt you once you try to
switch jobs again.

------
Shinchy
It's a nice little book. Normally these things can be a bit hit and miss with
the way the authors opinion of code structure seeps into them. You often end
up with a bit of a 'this is wrong' mentality when in fact there is nothing
wrong at all - thankfully they seem to of avoided that with this one.

------
prav
I wish there was something similar on Backend development, or better, full-
stack development.

------
ktRolster
Are full-stack developers really as rare as the book says?

~~~
k__
Back in the JSP/ASP/PHP days, everyone was basically a full-stack dev. Because
of server side rendering and direct DB access etc. I'd guess people who have
more than 5 years of experience come from that direction.

So they aren't that rare.

But doing just one thing is easier.

When I do back end stuff, I have to think about scalability and API design,
which is hard enough in it self.

When I do front end stuff, I have to think about information architecture and
perceived performance.

I can do both, but I don't have infinite time, so I focus on the things I like
the most, which is the front end :)

~~~
bshimmin
A lot of the people I knew doing "full-stack" (which just wasn't a phrase back
then) 5-10 years ago basically were still much stronger on one side than the
other. I knew a whole bunch of guys who could build you a beautiful - for the
time! - Flash site _and_ they could store data via PHP into a MySQL database
_and_ they could deploy it on a server ( _and_ then they could send you an
invoice! Seriously, totally full-stack)... but my goodness would you not want
to look too hard at the PHP, because little Bobby Tables would have cried.

~~~
k__
This is true, but doesn't help in the discussion.

There are always people who are good at something and bad at something
different.

------
thinkxl
I see people everywhere complaining about how frontend development is moving
too fast, and stories like mrits.

In 2011 I was sales manager in Mexico, doing WordPress sites for free on the
side just for fun. In 2012 I migrated to the US with my family (legally). Then
I worked in maintenance for 6 months until they fired me because I couldn't
talk English.

After that I decided to try to live from building websites. I started to learn
JavaScript and CSS, because already knew some HTML.

So I landed some clients as freelancer doing fixes on old sites, updating
WordPress. When I landed my first WordPress site from scratch I didn't know
how to do it, so I bought a book on the topic and used the gig as practice
while reading the book.

I was able to maintain my family doing responsive WordPress sites. Then I
started to get issues with all the grid frameworks and stuff, it was too
complicated to make a simple website responsive.

So I started to do what everyone tells you not to do: "don't reinvent the
wheel". I got myself to build my own grid, I did it, and I still use it Today.
The process was painful because I didn't knew any real CSS so forced myself to
learn it, when I got it done I was very confident I could do any layout in
CSS.

One freelance gig I got was a SEO tool to count the amount of words,
paragraphs, syllables, etc. of a given text, it was really exiting, because I
knew I had to learn JavaScript to do it. At that time Backbone was really
complicated for me, so I did it but really mostly copy/pasting stuff, I was
happy with the result but not with the methodology. One thing I really learned
from this project, is how to setup my development environment with Grunt.

So at this point I knew enough CSS and how to setup task runners.

From 2013 to 2015 I did only freelance work, then I got a full-time job at a
small advertising agency, doing WordPress sites.

I was able to get my paycheck doing stuff that wasn't complicated for me, get
a PSD, make it a responsive WordPress site (with the grid I did) and done. So
I was able to learn JavaScript on my free time, so I did what worked for me in
CSS again, go a reinvent the wheel.

I did my own "Backbone"-like framework, and was able to learn about Object-
oriented programming and how to do it in JavaScript using prototype
inheritance. Then I found out about React, and started using it too, learned
about functional programming, pure functions, immutable data, declarative
syntax.

At this point I was using Gulp, Sass, Babel, NPM, learned how to use the
command line too, Vim, Tmux, was using Linux as my primary OS, and other very
cool tools.

So in 2016 I landed an interview for a company where the job title was
frontend developer, so for me was like no more "make my logo bigger" website
clients. I got the job, Today I do only JavaScript using React/Redux/React-
Router, I learned Vue.js on the side and learned Python too, so now I can do
my own backend using Bottle/Flask on my freetime, learned about MongoDB,
Postres, SQLite.

And these days I'm building my own virtual dom implementation to understand
better how it works. And yes, a new JavaScript framework gets released
everyday, and yet I try to use as many as I can, spend a couple hours building
a todo app, reading the source code to see what I can learn from it, etc.

Right now I'm loving preact, and couple days ago found out
[https://github.com/hyperapp/hyperapp](https://github.com/hyperapp/hyperapp)
which is really cool.

The point of my boring story is:

\- frontend development moves fast, get with it. Don't expect to learn
something and keep using the same shit for ever.

\- learn JavaScript, not frameworks. If you understand the language you are
going to be able to understand any framework better

\- if you want to learn, reinvent the wheel

\- avoid the hype

\- if you are freelance and need to make a simple app and you are comfortable
with jQuery, go fucking do it in jQuery and don't mind about the new cool
stuff yet.

\- Backbone, Angular, Ember, React, Vue, or Preact? Whatever, when I open the
source code of a project built on any of those frameworks I only see
JavaScript patterns, that's it.

If you get a job and they are using something you don't like or something you
don't know, read the documentation, learn the basic idioms and try it. Again,
at the end, it's just JavaScript.

I mean, I was 29 when I started my journey, no English, no CSS, no JavaScript,
no knowledge about software development good practices. Now I'm 33 and very
happy with my job as frontend lead developer.

~~~
wts200
Excellent history and good advice :)

------
sapeien
The current front-end web stack today is not the answer, I think that is not
so controversial except to the most die-hard fanboys. Most of the contents in
this handbook are going to be worthless in a year.

Most front-end work is repetitive, with some minor variations. Rather than a
framework, I think that perhaps an expert system for making web apps that is
basically an interface for metaprogramming, would be a vast improvement over
the current tech.

~~~
shaki-dora
Let's see, going by the index, which technologies are younger than a year (the
logic being "would your statement have made sense a year ago" because I
obviously can't prove if a technology will still be relevant a year from now):

Internet/web: no

Web browsers: no

DNS: no

HTTP: no

Web Hosting: no

UI Design: no

HTML: no

CSS: no

SEO: no

JavaScript: no

DOM, BOM, JQuery: no

Web Fonts: no

Accessibility: no

... and so on. But maybe you meant just Javascript libraries, which seem to
make up just a small part of the content, but ok... Let's use "Module/Package
Loading Tools" as a sample, because this thing is really to big to go through
everything:

Browserify: Started in 2012. So... nope

Rollup: Started in 2015. No (but close!)

SystemJS: 2013. Nope, sorry

Webpack: 2013. Nope

And let's arbitrarily add the behemoth:

React: 2013. Nope

It appears there was an awful lot of new frameworks in 2013 and that let to
the impression of framework churn. To perpetuate that narrative four years
later seems to be more groupthink than reality.

~~~
ravenstine
What people are feeling as "framework churn" is probably more like framework
uncertainty.

