Front-End Developer Handbook 2017 | Hacker News Reader

Front-End Developer Handbook 2017

gitbook.com

459 pointsblueatlas137 comments

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.

People are less and less understanding of the fact that nobody lives in a vacuum and all our actions affect other people. They're stressing individual liberties, which you see in the mainstream political opinion of "if it doesn't directly affect me then why should I care?", and that same guiding principle is also pushing developers to make gigantic changes without any regard to the waves, splashes, or ripples they make.

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.

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

Vue.JS is great to use!

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™

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

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

:-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.

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

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.

Given that FP has been around longer than OO, I'm not sure it qualifies as a fad!

React seems like an overly complicated mess to me. We've worked for years to separate HTML, CSS and Javascript, and the reasons for doing that haven't changed.

Many think about separation of concerns when splitting up CSS, HTML and JS, but what they are doing is separation of technologies instead.

No, what we are doing is separation of concerns. CSS, HTML and Javascript aren't just separate technologies, they're completely separate and unrelated concepts.

HTML is content. CSS is style. Javascript is shit.

I am enjoying VueJS also and it is the 1st framework I've developed in since starting dev. I measure my skills on how comfortable I am doing whatever it is I am doing. I have to say that I've enjoyed Vue thus far, but I don't have any other framework to compare it to. I also have to say that the Front-End Developer Handbook 2017 looks pretty sweet for anyone in front-end dev right now. But again, I'm only an adolescent at this, what do I know?!?! :)

Me too, the first JS franework, I am writing an easy to ubderstand tutorial for VueJS, would you be interested?

Thanks for the offer, but my plate is full right now, sorry.

When I started looking at frontend frameworks a couple years ago, I ended up with Vue as well. Just enough functionality for the majority of tasks. Angular was waaaaaaay too complex for most needs. Simple two way data binding is where it's at.

Echoing the same here. I just found Vue a few days ago. Instead of starting with the documented way on their site, I'm going the Typescript with Components route, so I have classes, and typing. Now if I compare all of the frameworks I've been learning lately. Ang2 has a horrible module system that just gets in the way and confuses the crap out of everyone. Vue with Typescript is basically Ang2 without that horrible module system. React's flux model still bothers the crap out of me. Polymer's not on NPM and refuses to see that as the way to win.

Polymer's got the BEST router system however. It makes the URL choppable at the component level, not the app level. So you can literally throw in an external component and it can add it's OWN part of the overall URL. I don't know any other framework that can let an external component eat some of the URL if it needs to.

For the record, we do not refuse to see npm as the "best way to win", we just have work to do to get there without abandoning out current users. We are currently working on npm support, and have kept the github issue up-to-date with developments.

Honestly I had hoped Angular 2 (with iminent release of 4) would be the holy grail. It took soo long to come out, I dabbled in React and have not looked back. However I'm under no illusions that "this is it". Vue is definitely one I want to explore.

I think Cycle.js is a better Observable framework than Angular 2.

But I guess React will be big for the next years, because of FB.

As with any JS framework, much of what you want to achieve with it, has a lot to do with the number of developers building packages to make things easier. There is a lot going for React because a lot of effort is going into the world of React outside of FB.

Look into polymer, its like vue (vue was inspired by it a lot), and it is really small in size (polyfills IF needed weigh only 20kb). And everything is a component - imo this is what Angular 2.x should have been.

You just use pure javascript/web standards html to create your application. All the people that I worked with that used it were really happy with it.

I have the feeling Angular was fad.

The only client side JS library that doesn't seem to be a fad is jquery. Which now has backlash - maybe that's a sign of success in frontend dev land?

Well, jQuery is rather low level. So this abstraction level seems to be solved.

Current frameworks try to solve a higher level and most failed.

What is this "higher abstraction level"? The frameworks are trying to solve components, and they're doing it by introducing a needlessly complex API. All you need is a template library like Handlebars and you're mostly set. For an SPA, a routing library like PageJS (https://visionmedia.github.io/page.js/) should have you covered. If you prefer server-side rendering over SPA, just use jQuery-Pjax to get all the speed advantages of an SPA and all the SEO advantages of server-side rendering.

I think "just a template library" would re-render the complete DOM for every update, or require you to manually wire up all components. The "shadow DOM" at the root of React is quite central to its appeal, as it speeds up DOM changes by several orders of magnitude.

I am genuinely curious what percentage of web apps are demonstrably affected by "slow DOM updates" of several orders of magnitude.

You realize React solves a performance problem that it imposes on itself, due to immutability, right?

Pre-react web apps to do attempt to re-render the entire page root on every press of a key. They simply handle events and remove/add/update the specific DOM nodes that are appropriate.

remember appendChild() and removeChild() ? These are quite fast.

I am in total agreement with you. I am rarely updating more than a handful of DOM nodes in a pass. I don't need a diffing algorithm to tell me which ones are gonna change.

Usually I've experienced the performance issues with poor event handling (at the control level) on grid-like views...

That said, I like React's component structure... it works with me more than most. Though I tend to dev against react and build against preact-compat for reduced size. Which iirc uses real dom as point of truth.

The main take away from React is flux-like state management (ie Redux)... this is what helps with the real pain of larger apps (especially MVC) and that is cross-cutting concerns and state management. This is why Redux has been adopted, or roughly copied to all the up and coming options.

O.K., these organizational/structural concerns are fine, but are not what my point is addressing, which was OPs motivation of React on performance grounds.

Yes, grids seem to always be a problem. This is one of those 'sticky wickets' (for frameworks too!). Of course it can be solved, but i'm more interested in the general case here.

The problem with that is then you end up with the same horrible mess of event handlers all mutating global shared state. That's the same problem you have in most C# and Java UI programmes too.

not what my point is addressing

Yes it is. You said:

>They simply handle events and remove/add/update the specific DOM nodes that are appropriate.

Don't bloody pretend you didn't.

yes, "They simply handle events and remove/add/update the specific DOM nodes that are appropriate." is intended as a clarification as to why DOM updates in this style are FAST. I am not intending with that statement for it to serve any purposes about code clarity or structure. (Which i think is clear in the context of what I wrote in the same paragraph, and what I am responding to.)

I am specifically responding to this:

The "shadow DOM" at the root of React is quite central to its appeal, as it speeds up DOM changes by several orders of magnitude."

Of course you can take isolated sentences from me and purport alternate motivations (code clarity) to them so that you can make a new argument against that alternate motivation, but that is a different conversation.

There seems to be a downvote brigade on us React disparagers. Try not to worry too much about. We're releasing faster than them anyway ;)

That's if you use your template library to emulate React. What jQuery brings to the table is that you can sprinkle in a few selectors, event listeners and ajax calls, then you have no need for a shadow dom.

The minimal transform is usually trivial to implement by hand:

  var message = $('.widget__message'),
      title   = $('.widget__title'),
      button  = $('.widget__button');
  button.on('click', () => {
      $.get('/api/widget/1', response => {
          title.text(response.text);
          message.text(response.message);
      });
  });

Not only is this technique significantly more flexible than react, there's no magic about it so it's far easier to reason about when things aren't working.

My definition of "not a fad" is "now has native browser support". I'm thinking of jQuery influencing native querySelector as an example.

I worked with Ember at a YC company a year and a half ago. At the time at least, it was really hard to find good docs about it; I read Ember.js in Action, but it was already mostly outdated since ember-cli was just released. Lots of help ends up being found in random gists or people's blog on page 10 of Google Search. I haven't touched it since last winter though, so not sure how the situation has evolved, but I'm sure that was one of the big entry barriers for Ember.

True, but I had this feeling with many frameworks.

I'm not saying this is a good thing, but I started to read more in the frameworks repos after trying a few of them.

I think this is a barrier for most devs, but I think it made me better at coding.

The highest barrier is time. If people need to get things done, do they have time to look into the code?

When I hear the word "way", I reach for my gun.

Seriously though, if there has to be a certain "way" of using some technology I can't help but remember Code Complete, that you should always code into a language as opposed to coding in it.

Same here.

I did Ember while Angular was "a thing".

For those thinking about Angular2, I would recommend angular-cli[1] and then going through the tutorials in Angular documentation[2].

Angular-cli because it provides a scaffold for getting started with the project and getting something up and running. The documentation feels pretty good. I like the example app they are building and the documentation format (they provide the full source code for the files right there in the documentation, no need to navigate to somewhere else).

[1] https://github.com/angular/angular-cli [2] https://angular.io/docs/ts/latest/

There are multiple ways to look at that.

My previous job was on a product that used CoffeeScript and Backbone. As a stereotypical front end hipster, I was worried at first. I thought: "This is really old stuff in JS time. There are shiny new things out there". But I soon saw that while it would be more fun to use a new framework/language, the old ones are _totally fine_.

CoffeeScript was last updated a week ago. Backbone was updated several times last year and 1.4 is expected some time soon. There are online communities, there is documentation, there are answered questions on stackoverflow. Yeah, everything feels a bit old, but there won't be breaking changes to the API every few months and that blog post from 2015 that solves your exact problem is still useful!

Try looking at it like Angular is a language, not a framework. Sure, there are fancier ones coming out all the time, but that doesn't mean you have to switch every time that happens. The one you know has a bunch of apps built in it, you can still learn about its intricacies and there will be jobs for you for quite some time.

I am the sole front end developer at ReportDash, an online report and dashboard builder. We use backbone, backbone layout manager & coffee script and never ever once regretted the choice. The code is highly organised, thanks to the structure provided by backbone layout manager, and is pretty much readable and extensible. And not even once I felt limited by the framework.

The code has got quite complex over time, and I strongly suspect I would have gone mad if I had used a different framework. I used to wonder why the hype over react, vue, angular etc.

IMO, the hype over them is because Google, Facebook, et al are trying to gain developer mindshare. Their modus operandi is to hoard as much webdev talent as possible to limit the possibility of a startup usurping them. With front-end development being trendy, this buys them massive brand recognition.

The technology itself doesn't need to be new, exciting or practical. All you need is sufficient marketing $$$$$$ backing it.

I couldn't agree more with your comment. If you found your favorite framework, which is still maintained and gets the job done, then stick with it unless you have very good reasons not to (and "it's uncool to use this long established framework" isn't one of those reasons).

I saw so much flawed frontend code which wasn't written by bad coders but by people which try to use always the fanciest and newest thing out there. Even if the docs written in marketing language claim otherwise, there's always a learning curve and it doesn't make any sense to switch the framework as soon as the learning curve getting flat.

One reason that Angular feels more like a language than a framework to me is that it essentially has its own module/dependency system with all the dependency injection stuff.

It don't even use Angular's D.I. to test things. We don't have any tests in our app, what would you even test? It just displays data it gets from various sources.

But this:

    angular.module('...')
      .controller('BlahController', function(a, b, c) {
        'ngInject';
        ...
      });

is still clearly better than this:

    var a = require('a');
    var b = require('b');
    var c = require('c');

    exports.BlahController = function() {
      ...
    }

This is why I still use jQuery :)

I work for a company with a couple of heavy Angular-based apps. They are pretty easy to support/extend for anyone with a decent level of JS knowledge. The backend API they are talking to and some of the business logic in the apps is kinda tricky but that's not angular's fault per se.

The downside is for candidates looking to add a hot shot tech to their resume, Angular isn't all that sexy, but for anyone with JS knowledge willing to spend a couple of days getting up to speed with the app itself (the "tool stack" is minimal - npm, grunt, bower, browserify and since it's an existing app they are learning by example) - this is almost a no-brainer.

I'm 56 and have been programming for 40 years and counting. I'm paid extremely well for one reason...I've never stopped studying and learning.

If you want to base your future on something you already know, you're in the wrong profession.

Thank you... 42 here (at it about 20 years now), and I can't imagine where my career would be today if I stood still at any point. Even in the JS and front-end space alone there's a lot to learn. There's adjacent tech too (various db's, cloud providers, ci/cd, docker, etc). It hasn't stopped or stood still and never will.

I'm not sure having to learn how some kid decided to design a new package manager is what we should be re/learning. If anything it might kill your career as you keep learning basic libraries and never understand the underlyings.

Learning fundamentals and mastering every shiny, new frameworks that will be replaced in few months (years max) are totally different things.

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?

> 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).

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

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

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.

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.

Just to note this here: SSR support for styled-components is almost finished and will be released after some testing on real projects in a few weeks as v2.

You just hear more about React because it's the "hot new thing".

Initial release March 2013; 3 years ago

Hot, but not new on a JS timescale.

Wow, that's almost 4 years ago!

Although it seems like it started becoming popular 1-2 years ago: https://www.google.com/trends/explore?cat=31&q=react

Not sure why you think it's settled, just look at any recent js/react discussion here and search for the word "vue".

It's Vue.js everyone's raving about now. React is so 2016.

In early 2015 you might have said the same about angular.

The other moderately amusing parallel is that it used to be people said angular was for a full project and react you can use a lot or just a bit. Now people are saying react is for a full project and vue can use a lot or just a bit.

Not sure how you'd come to the conclusion that "large part of the JS community has started to settle on React", other than confirmation bias of reading Hacker News and a lot of recent discussion about what the new hotness is.

I'd rather use a gauge of number of people showing up at Meetups, number of jobs in job searches, etc.

At my current guess is that the AngularJS camp is at least 4x the size of the React, and even that number is likely low since Angular is a lot more stabilized in all the enterprise environments.

Toolsets change but the core principles are pretty stable. I've been around for all the paradigm shifts. When browsers first had DOM APIs and CSS. That was when FE dev first became a dedicated job. Since then we've just been layering more and more abstraction on the same stuff.

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.

This is what J2EE developers said back in the day.

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.

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/ 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.

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.

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.

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?

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.

I find this surprising because all I hear about are React/Angular/Vue.

At this point, I am likely to stick to React because of the support and community. But I could see myself using web components if it reaches critical mass.

This link will get you to the handbook content: https://github.com/FrontendMasters/front-end-handbook-2017/b...

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

Doesn't inspire confidence.

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?

I think he meant that gitbooks doesn't have a responsive layout when you hit the "read" button instead of downloading a PDF, ePub, or mobi. The book's content is unreadable and cut off in my mobile browser when I try to read it that way.

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).

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.

Looks fine to me. The TOC is hidden behind the hamburger menu, and the text layouts correctly.

Both on FF and Chrome (Android 6)

  'support' <> 'mention'

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.

"gem 'twitter-bootstrap-rails'" in the Gemfile.

"bundle install" in the command line.

That's my approach to dealing with frontend libraries but I tend to cheat by using Rails or RailsComposer to setup my project.

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

That's what you get by shoehorning XML. Here's how you do it:

  var someThing = document.createElement("button");
  someThing.onclick = handleClick;

HTML is a fun an powerful language, but it should only be used for static web pages or old school server rendering.

You can also use <SomeThing onClick={() => this.handleClick()} />

DHH recently posted a comment on Quora about why it's still valuable to learn Rails in 2017 [0]. I don't agree with everything he says, but he is right that the Rails ideology was a big thing for web development in the '00s. Yes both Rails and Ruby have their issues, but if you look at what was around before it was a breath of fresh air.

I keep hoping the JavaScript community will have the same epiphany, but so far I'm still dreaming. Yes there are boilerplates that give you something working out-of-the-box, but still you need to keep up with which boilerplate is the latest and greatest. I'd argue Rails being so opinionated was one of the reasons for it's success.

[0] - https://www.quora.com/What-makes-Rails-a-framework-worth-lea...

That was similar to my failed attempt to make an app with Meteor. Not having much free time I seem to have started at the wrong time so that halfway into learning the framework and applying it to my own project, Meteor got an update. Being still in the learning phase I updated to be working with the latest stable version, something which broke the app, so I spent time fixing that, then the free hosting tier was dropped and for a hobbyist who was making an app that was guaranteed to never generate revenue ever ever, it became too expensive to host in comparison to a traditional $10 host with a mySql DB. And what was I doing anyways? Meteor Blaze? Was that the correct choice? Or was Meteor & Angular a better choice? Or was Meteor React the way to go? Or if I'm using Angular or React why am I using Meteor? Ended up with so many questions about whether or not I was using the right stack for me, and as I said, not much time to work on it so looking for something that wasn't going to be abandoned in 6 months time, in the end I just gave up on that project.

It doesn't help either that these js communities are splintered around every tiny issue and forked every other week (mean.js! is where I started the whole process). The feeling that there is zero permanence one week into a project does not inspire confidence either in my own project or the tools I have chosen.

There should just be one tool, one command. "modernjs build". Done.

You seem to be building an argument based on the idea that there's "one true way" to write web applications. There isn't. People have very different ideas about what's best. While ostensibly different tools do the same job, they take quite different approaches. For example, take "gulp vs grunt vs make vs npm" for the build process. gulp uses "JS with a framework" for config. grunt uses json. make uses unix-y scripting. npm uses JS but plain node.js without a framework. Those are opinions, and there isn't a "right" one.

Suggesting there should be one tool for compiling web apps is a bit like suggesting there should be one C compiler for compiling C programmes. There can only really be one tool if there's only one way to do things, and that's simply not the case. With different approaches comes different tools.

But, all that said, it doesn't matter to an individual developer. Choose the tools that suit you, learn them, and be happy. Whatever approach you take to development is far less important than writing software that works for your users.

> You seem to be building an argument based on the idea that there's "one true way" to write web applications.

Nah, you misunderstand me. I'm saying webpack+babel should be a single program with a sensible default config. I didn't mean to imply anything grander than that.

> Choose the tools that suit you, learn them, and be happy.

If someone decides to use Webpack+Babel, I don't think they're going to be "happy" about having to memorize a list of at least 9 different npm packages and 35 lines of configuration. Not to mention re-memorizing the new sets of packages and configurations every six months when some maintainer decides that package X should be split into packages Z, Q, and R, or that the current configuration tree is "wrong" and needs to be tweaked in backwards incompatible ways.

It's OK for tools to be opinionated and for there to be advocates for modernjs build vs. newjs build vs. stdjs build. It is even OK for there to be configuration knobs to twiddle. But the GP is absolutely correct that not enough effort is put into choosing good defaults that most developers won't need to fiddle with just to make tools work well together.

Right now, FE JS development mostly has a terrible OOTB experience.

> 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.

If it hurts, don't do that then - put all your build stuff and devDependencies in a separate module and install it into your next project like any other development dependency, adding new capabilities as you need them and bumping the version number when you need to like any other tool. You can start doing it yourself [1] or use one someone else made earlier [2] - there are an increasing number of these toolkits about.

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

You can do exactly that if you're using React or one of the many libraries which use React-like conventions (Preact, Inferno, Mithril.js etc.), so just use one of them.

> 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.

You don't have to, and there are lots of tools which will take care of this for you (see [2] again). That's the exact same workflow I wanted, so I created it for the types of projects I'm working on [3] - it doesn't take much extra effort to turn your own preferred build setup into a command.

[1] https://github.com/insin/ad-hoc-reckons/blob/master/Creating...

[2] https://github.com/facebookincubator/create-react-app#altern...

[3] https://medium.com/@jbscript/quick-development-with-nwb-35f3...

> You can do exactly that if you're using React

No, you can't. This is broken:

   class Foo extends React.Component {
       render () {
           return (<SomeThing onClick={this.handleClick}/>);
       }
   
       handleclick () {
           this.setState (blah);
       }
   }

It _shouldn't_ be broken. I don't agree with any arguments about the semantics of Javascript, this, scope, binding, etc. It's a pain point; something every developer runs into. It should be fixed. Instead, we have about 10 ways of working around the problem. In all the revisions of the Javascript that have gone by, nobody fixed this _very_ common usage of the language. Instead they just added more workarounds.

> it doesn't take much extra effort to turn your own preferred build setup into a command.

Here's the thing. Let's say, instead of selling people cars, we only sold parts. You shop on various stores for all the parts you need, depending on the kind of car you want, order them all, and then put the car together. The great thing about this is that every person gets exactly the car they want for their specific needs! And the people making the parts get to focus on a specific part, so the individual parts are will end up well designed and polished.

For a car nut, that's probably great. But most people aren't car nuts. For everyone else, this system is terrible. They don't know how a car works. They go online, search around, get overwhelmed, and decide to just follow whatever random "Build a Car in 30 minutes!" guide they stumble on. They end up with a car at the end, and now they can do what they really want to do; drive from point A to point B and forget about building cars. Until one day the radio breaks. They look online for a replacement, only to discover they don't make that radio anymore. In fact, the new radios don't fit in their dash configuration. So after hours and hours scrounging through oiloverflow.com questions, they finally piece together how to replace their dash with a new dash, without having to replace their steering column configuration. Then they get their radio, and all is well. Except now they've missed the movie they were going to see with friends, so they just go to bed and don't even use the car.

And the promise about each individual part being well designed and polished? It didn't pan out in practice. Some parts ended up really nice (React). Most parts just kept getting revised or forgotten and were never really thought through (react-router).

Most developers just want to get from point A to point B. Go from idea to app. Fiddling with packages, compiler configurations, etc, is not productive for them. "it doesn't take much extra effort to turn your own preferred build setup into a command" is the equivalent of asking everyone to build their own car. Just give them a pre-made car! If they're the type of person to want to customize their build tools and environment, they'll do that. But don't foist that burden on every single developer.

> I don't agree with any arguments about the semantics of Javascript, this, scope, binding, etc. It's a pain point; something every developer runs into. It should be fixed. Instead, we have about 10 ways of working around the problem. In all the revisions of the Javascript that have gone by, nobody fixed this _very_ common usage of the language.

Maybe I'm not completely understanding you correctly, but es6 and es7 does fix many of these problems, doesn't it? In which case the problem is there is no way to make es6 or es7 code compatible with older browsers other than transpiling. I don't know how you fix that without a time machine.

> In all the revisions of the Javascript that have gone by, nobody fixed this _very_ common usage of the language.

It would break way too much of existing code.

Are you complaining that passing around a function reference doesn't maintain the `this` reference? That's... uh... just how Javascript works. That's how functions behave, that's how prototypal inheritance works, and the class syntax maintained that behavior for backwards compatibility. That has nothing to do with Webpack, Babel, React, or any other tool. That's part of the language syntax.

There's several strategies for ensuring that `this` in a function refers to a particular class instance, particularly in a React app. The basic approaches are re-binding the function every time you re-render; binding each function once in the constructor; using a decorator or utility method to bind each function once; and using the Stage 2 Class Properties syntax and writing the function using the arrow syntax. See http://reactkungfu.com/2015/07/why-and-how-to-bind-methods-i... for an overview of the approaches.

It's how it works, and it's wrong. It's incorrect. It's badly designed. It should be fixed.

Let me write `'use sanity;'` at the top of a function (like `'use strict';`) and then let me use sane lexically scoped semantics.

I completely agree with your frustration, but even inside the a "sane block" the are cases where you'll need the existing behavior, and backwards compatibility... Ugh.

Almost easier to make completely new keywords that allow you to designate where a special-scope begins and a "this"-like keyword that behaves a little differently.

Well ideally we'd all just use Perl-6-compiling-to-WASM on the web I suppose. Then we can have Perl 6 both in the backend and the frontend!

+1 If I could I would use the Perl programming language for everything!

Let's hope this becomes the reality soon!

> 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="…" />

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.

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?

It's not hip, but Dojo has similar markup.

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].

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.

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

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

Any recommendations on where to start with that? As someone who started with front-end because it was the easiest to jump into right away, and is now already sick of it, I'd appreciate the help transitioning to back-end. I have some PHP experience and a touch of SQL experience.

The bad thing is that it's much harder (IMO) to find freelance jobs for back-end development (especially for SQL-based stuff and not Node or Rails with Mongo or whatnot).

On the other hand, yes, the SQL coursework I did a decade ago is holding up really well :) .

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.

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

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

They probably are now that front end tech is churning so much. Being full stack used to be easy, now it's a mess of javascript.

No I think all devs has to be more or less full-stack today.. When I think about a "full-stack dev" I think about someone with T-shaped skills. Aka specialist in one area (web/backend/devops), but knows a little bit about everything. Not an expert but knows enough (or takes the time to learn) about e.g. data structures, time-complexity or even css quirks to make educated decisions and participate in engineering discussions.

> T-shaped skills

Ahh, the universal sign of someone who worked around IBM.

I was just asking myself what the T-shaped skills were...

No, it's a thing now. Everyone's talking T-shaped people (let alone 'comb-shaped' people)

An important step on the path towards the conjoined triangles of success.

Quality full stack developers are rare. People who understand nuances of React / Angular / Vue who also understand nuances of MongoDB / PostgreSQL who also understand nuances of AWS / Azure / Google Cloud are rare.

Generally they will be storng in one and weak in another.

I don't know many front-end devs who understand the nuances of React, Angular and Vue (especially Vue). I don't know anyone who understands the nuances of AWS, Azure and Google Cloud.

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 :)

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.

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

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

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 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.

Excellent history and good advice :)

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.

This comment makes so much more sense than their "Myth of the Full Stack Developer"

I've been getting into web2py recently. It's a backend framework for python that autogenerates crud forms for you. It'll autogenerate an entire admin backend just from your table definitions in the ORM. I use Pjax to make page loads a bit quicker. Don't miss my front-end SPA framework whatsoever. Especially since my sites are SEO ready out of the box.

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.

jQuery has had the reputation of being very antiquated for a while. The problem that it set out to solve no longer exists. The same will be true of what you mentioned above.

Now there are tools that solve problems that arise from other tools, it is getting very meta. An ecosystem like this cannot last indefinitely.

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

Those 2013 frameworks didn't get to the level of completion necessary to become popular until 2015, really.

Reply on news.ycombinator.com