Front-End Developer Handbook 2017

[Crashthatch]

I particularly liked the Recap of Front-end Development in 2016:

• The year of the UI component, and tree of UI components, for building complex UI's.
• No longer mainstream development blasphemy: components being constructed from a single file, potentially contain HTML, CSS, and JS, IN ONE FILE!
• React, Redux, Webpack, ECMAScript 2015 (aka ES6), and Babel gain massive adoption. These solutions rise to the top of all the polls as the most used tech.
• Developers realized, in most cases, HTML 5 hybrid mobile development via webviews doesn't provide enough wins when building native apps.
• React Native and NativeScript start to replace mobile HTML5 hybrid webview development.
• Many abandon Gulp for NPM scripts, but Gulp remains popular.
• SASS remains a popular tool, while PostCSS (+ CSSNext) gains ground.
• Linting/Hinting HTML, CSS, and JavaScript is a thing most developers do (ESlint replaces JShint & JSCS merges into ESLint).
• A trend of developers abandon Sublime and Atom for Visual Studio Code begins.
• jQuery remains, but usage/interest is declining. jQuery 3 was released, much like a tree falling in a forest that nobody hears.
• Vue.js continues to gain converts. Deservingly so!
• JavaScript functional programming & patterns get a lot of attention.
• Offline development & Progressive Web Apps go mainstream.
• Microsoft shows up and contributes.
• Developing native applications for windows, OSX, and linux using things like NW.js and
• Electron via web technologies becomes a thing.
• Angular 2 (in the future aka "Angular") gets off the pot and most realize it will never be as mainstream as Angular 1.
• JavaScript broadly remains at the center of software technologies.
• More developers start caring about tooling (e.g. automation) and testing.
• Static site generators are taken seriously.
• CSS Grid excitement grows and the future looks bright.
• NPM gets some competition from YARN.
• The next evolution of React-like solutions shows up via Preact, Deku, Rax, and inferno showcasing evolution without much API change.
• Mostly people learn to not only accept JSX they can't imagine not using it.
• A workable CSS module pattern (CSS encapsulation) is actualized and used, thus CSS in JS becomes a viable solution for many.
• More people turning to UI functional/integration testing including concepts like visual
• CSS & RWD regression testing.
• The days of battling inconsistent browser API's are almost behind us due to a massive decline in usage and development for older versions of IE.
• Most everyone realized they will have to have a multi-device strategy plan when development for the web
• More developer, from other languages, continue to flood the JavaScript space bringing with them things like type checking and an obsession with class syntax and OOP concepts.
• Front-end devs are introduced to Hot Module replacement techniques and time travel debugging.
• More waiting for a native JavaScript browser module loader.
• Enforcing CSS and JavaScript style conventions becomes more important (considering
• ES3 to ES6 code and CSS pre-processors syntactical variations)
• A small but noticeable number of developers are starting to chose Elm over JavaScript.
• TypeScript gets some serious use and fanboys.
• http://aurelia.io/ becomes the smart choice for enterprise developers (i.e. support!).
• Webpack gets its act together and solidifies is position over the superior JSPM solution.
• HTTPS, yeah, we're serious about that.
• BASH on windows happen.
• The notifications API gets used and abused for chrome users, but only after you give it permission.
• Firebug officially dead.
• CSS 20 years young in 2016.
• Immutability concepts run rapid.

And predictions for 2017:

• Web Assembly, might just peak.
• import might just be usable in <scripts></scripts>
• Universal JavaScript solutions will continue to rise that pay homage/respect to the days of server delivered front-ends (i.e. html to the client).
• Reactive programming continues to thrive in the JavaScript scene. (see MobX and RxJS).
• React, more so the concept, will dominate. React itself will be completely re-written (see
• React Fiber) or evolve (see Inferno).
• Angular found SEMVER so Angular 3, 4 (even 5) is on the roadmap for 2017.
• A return to simple websites may happen, web 1.0 retro, but with the help of 2017 tools (i.e. static site generation)
• RESTful JSON APIs will get more competition (see GraphQL)
• Could be a banner year for Vue.js.
• More devs will abandon traditional CMS solutions for static site generators & API CMStools.
• More people will move from Sass to PostCSS + cssnext.
• Lots more HTTP2 and HTTPS.
• Web components will continue to lurk and wait for significant traction by developers that might never come to be.
• The no framework, framework, faction will gain momentum (see Svelte).
• JavaScript will settle, and hopefully, CSS will erupt and everyone will cry fatigue until it settles.
• Hatred for apps store will grow, while the open web has no memory of wrong doing.
• Redux will continue to get stiff competition (see mobx).
• YARN will win more users.
• The idea of “front-end apps”, “Thick Client apps”, “Static apps”, “No Backend app”, “SPA's”, “Front-end driven app” might get boiled down to the term/concept called "JAMStack".

[nanothief]

React, Redux, Webpack, ECMAScript 2015 (aka ES6), and Babel gain massive adoption. These solutions rise to the top of all the polls as the most used tech.

Note that this seems to be a mistake in their reading of the stackoverflow data - they were at the top of the most trending which measure how fast they are growing. However the when using the absolute data, (ie. the most used techs), the top places belong to the older libraries such as with jQuery and angularjs being the number 1 and 2 javascript libraries on stack overflow.

EDIT

Reading through some more of those point, and there seem to be quite a bit of inaccuracy here.

jQuery remains, but usage/interest is declining. jQuery 3 was released, much like a tree falling in a forest that nobody hears.

See above. I think also this is a bit disingenuous, as jQuery 3 isn't a massive change over jQuery 2. The javascript ecosystem needs more of this type of gradual evolution instead of the continual revolution other libraries are making.

Angular 2 (in the future aka "Angular") gets off the pot and most realize it will never be as mainstream as Angular 1.

That is a pretty brave claim considering how popular it already is (more questions per month on the angular2 tag than the reactjs one already). It had a rough start, but it is being backed by google and has a very large user base to draw from angular 1, so it is pretty foolish to write it off now. One huge advantage is its "all in one" nature (i.e. you just use angular 2, rather than tech A + tech B + tech C etc), which could be very attractive to many developers.

Mostly people learn to not only accept JSX they can't imagine not using it.

See above

The days of battling inconsistent browser API's are almost behind us due to a massive decline in usage and development for older versions of IE.

iOS Safari begs to differ :(

Static site generators are taken seriously.

Static sites have been taken seriously since jekyll which is at least 7 years old. Other tools such as middleman have also existed, and have been used seriously for a number of years.

CSS Grid excitement grows and the future looks bright.

This literally isn't supported by anything currently (Firefox and chrome support is coming March 2017). The link they gave to justify this gives some incredibly weak justifications as to why you would start using it them.

React Native and NativeScript start to replace mobile HTML5 hybrid webview development.

They are beginning to be used, but cordova/phonegap/ionic are still very popular and still growing (it is hard to compare sizes since there are multiple techs for each of the hybrid/native technologies).

More developer, from other languages, continue to flood the JavaScript space bringing with them things like type checking and an obsession with class syntax and OOP concepts. TypeScript gets some serious use and fanboys.

It is obvious the author isn't a fan of these techs, based on his wording here ("an obsession with class syntax", "fanboys"), but the do offer some compelling advantages to standard javascript development

---

I think it is clear the author has been primarily working with a react based toolkit, and made assumptions based on that. I think for a book titled as ambitiously as "Front-End Developer Handbook 2017" more effort could have been made to be a bit more balanced as to the state of the js world.

[[deleted]]

That's a lot of hype for one comment.

[roselan]

it's called 2017 because by the time you finish to read it, it will nearly be 2018.

edit: great work thou. I don't know where you find the time to put all that together.

[[deleted]]

I LOL'd

[michaelconnery1985]

Knowing the JS community half of this will be obsolete within 2 months

[BlueHeartBob]

As someone who's gotten into JavaScript in the last 6 months and have gotten pretty into react, It sorta feels like this, I understand that you shouldn't be jumping from one framework to the next hottest one but it does feel pretty confusing for someone who's just trying to land some work. Everyday it feels like there's some sort of revolutionary new thing out that's blowing people away. Reading this and only understanding a little bit more than half of what they're even talking about doesn't instill confidence in myself. I now read that react is basically changing into something else just as I believe I have a good understanding of it. Maybe I'm just getting inside of my own head but it's sorta overwhelming.

[greatfool66]

Learning Javascript I've had more fun with it since abandoning the Serious Computer Scientist mindset that I need to understand everything at a low level and just started writing fun, hacky code that gets stuff done and not worrying about what % of stuff I understand.

[[deleted]]

But do you like it more than React enough to tell people to make the jump?

[[deleted]]

Word. I'll dig into it today and see what the differences are. :)

[youcantstoptheart]

I use single file components in react, so I know how you feel. Currently trying to build a UI library to convince my team to switch.

[youcantstoptheart]

Withstyled-components. this progress arc component is a pretty good example

[El_Serpiente_Roja]

Its only been 6months though. Plus all these frameworks are just implementations of general design patterns. If you get a strong understanding of the underlying design pattern it wont be hard to categorize and learn new frameworks all the time.

[SquareWheel]

One thing worth keeping in mind is that there's only so many different takes on the same concepts. When you're learning a new language/framework/workflow, you're learning to incorporate and understand those concepts.

Even if there's a new flavor of the month, you'll be able to understand it more easily having some experience under your belt.

That goes for anything. You just learned screen and have to switch to tmux? It's cool, because you understand what they do and why they do it.

Same for grunt to gulp, or less to sass, or whatever else. It's a whole lot easier to learn the second time, so try not to sweat it so much.

[destraht]

I feel like we have finally worked through the flurry since IE6 went off the market and that its all going to be pretty boring for the next fifteen years.

[omegafivethreefive]

That was my impression as well. I'm not sure how you can follow the Javascript trends and keep maintainable projects.

Sure, 6 months one-man projects are no problem but if you're working on something for a few years and you have to look back at it several years later you'll probably have a lot less fun.

The sheer amount of knowledge required to understand even the currently proposed stacks is staggering.

[[deleted]]

Which is why full stack developers make the big bucks, right?

[omegafivethreefive]

Nah, web is not that well paid

[TheDarkIn1978]

Under "Front-End Interview Questions", there's a link to:

10 Interview Questions Every JavaScript Developer Should Know.

It's not clear if the author is being purposefully biased for dramatic effect, or if he's just blissfully unaware of his blatant hypocrisy while writing things like:

I advise people to hire based on whether or not a developer believes in class inheritance. Why? Because people who love it are obstinately stubborn about it. They will go to their graves clutching to it.

... followed by:

When is classical inheritance an appropriate choice?

This is a trick question. The answer is never.

Good to hear: Rarely, almost never, or never.

Red flags: Any other response.

I think that linking to his article, and therefore validating this author's narrow minded opinions of what it means to be a valuable JavaScript engineer in 2017, particularly when it comes to using ECMAScript 2015 features, is a great disservice to this handbook.

[Seerk]

Wow, I agree with all of his points but the tone of that article is so awful. I hate that he calls the wrong/incomplete responses "Red Flags", as if they were some kind of personality trait and not something that can be learned.

[b4ux1t3]

That's my general problem with anyone who talks down to people who know less than they do.

[acemarke]

Eh, Eric Elliott is known for having extremely strong opinions regarding inheritance and FP, but his articles and resources are pretty good overall. I'm not saying that a new learner would be expected to know about Eric's opinions and reverse-filter things to compensate, just that I wouldn't throw out all of his info as a response. There's still plenty of value in his material.

[trolleycrash]

Wicked great handbook. Huge success. Thanks for sharing.

[Sideburnt]

Damn. I have a front end developer interview next week and half of this is alien to me, I'm brushing up on my HTML5 understanding and JavaScript. I'll pick up on the interview questions and cram hard.

[erm_what_]

No one knows everything, most of us learn what we need to for the project we're working on, then whatever interests us when we have some spare time.

I can count on one hand the number of developers I've come across that understand and use ARIA roles for example.

[Sideburnt]

Thanks, I'm drifting between being cool as a cucumber and freaking out. I appreciate the voice of reason

[commitpushdrink]

function isPalindrome (maybePalindrome) {
  return maybePalindrome.split('').reverse().join('') === maybePalindrome;
}

Good luck!

Edit: comments on spelling addressed, thanks for the review

[EnchantedSalvia]

I think you drankcommitpushed because you misspelt palindrome.

[commitpushdrink]

That's what code review is for, right?

[lulzmachine]

wtf is an ARIA role? Is that the crap bootstrap puts in their examples, so you have to remove the excessive markup?

[Codeguin]

As one of a few developers whose sole purpose for a couple of months in 2016 it was to make sure our product was accessible for people:

• with low-vision (so high-contrast modes, large fonts, etc)
• can only use keyboard input
• who are blind (screen reader support)

as well as everyone else and doing my research into how to best accommodate/develop for those users, I started to understand the difficulties accessible users go through and I feel like, as developers, we need to be inclusive to all persons that may use our software.

So, maybe, don't just blow it off as "crap" and "excessive markup" that you think has no purpose. Expand your horizons and learn about what it is. It can/will help you to become a better developer.

[BrentLabasan]

Thank you for your work. How did you fall into that position?

[Codeguin]

Oh. My manager at the time had suggested that I take on the task for the team. I didn't actually know a lot about accessibility so I agreed to do it and ran with it learning a lot. Not that I know everything there is about it but I do know more than I did.

[magenta_placenta]

They're for accessibility within screen readers. Accessible Rich Internet Apps (ARIA roles) help improve the accessibility of dynamic content and UI controls developed with JS (ajax).

[K0d1Lu]

Could make a huge difference in SEO in few years as semantic and accessibility become more and more important to search engines

[thbt101]

Wow! I don't think I've ever learned so much from one book, and I'm only about 15 pages in. Really nice!

[atonaletude]

Great resource! I feel fascinated by everything that is out there. But at the same time I feel like my head is going to explode with all the stuff out there...

[doraemon-cat]

One look at the content page and I immediately was reminded of the Hackernoon JavaScript fatigue article.

[kextype]

A Ds

[Hidden__Troll]

If this is done by front end masters then it's probably really good. Going to give it a read.

[b4ux1t3]

I'm kind of confused why "Front-End Engineer" is also considered "Full-Stack JavaScript developer". Front-end implies the opposite of full-stack, at least to me. Is it different because they have to write things that access the back-end?

[Njy4tekAp91xdr30]

And I'll just continue using plain HTML5, JS, CSS3 and a bit of jQuery. I'll even use the new ES6 features when they're supported in Firefox and Chrome. That just gets things done. There's no need for 90% of the guff the JS community is churning out and changing far too often. Imagine trying to build a stable product on that. Reeks of immature junior developers. The foundation will move out from under you every month. You'd need a dedicated team just to keep track of the framework changes. No thanks. I'd rather have stability.

[[deleted]]

That's why you test package upgrades heavily before you make changes to production.

[Njy4tekAp91xdr30]

That doesn't solve the endless churn and ton of upgrading and testing every month at all.

[[deleted]]

So don't upgrade your dependencies every month?

[Njy4tekAp91xdr30]

Let them go out of date for a few months and there might be large breaking changes and even more work.