[_uhtu]

That's simply not true. I'm kind of tired of hearing about this kind of stuff said about JS. This comment adds absolutely nothing to the discussion about this article.

Did you even read the article before making this comment? It would appear you didn't since this is just a classic, low effort javascript bashing comment that mentions no evidence from the article.

Every single thing he marks as important to learn is either

1. a mature library that has been around for years and is used in production at hundreds of companies (React is 3 years old and Angular is 6 years old, Lodash is 4 years old, Node is almost a decade old)

or

2. is a fully specced and largely implemented feature of the Javascript language.

How is Ajax gong to be obselete before you finish reading? How is Node, a nearly decade old, battle hardened runtime going to go out of style in 2017? By literally any definition JS builtins, functions, closures, callbacks, Chrome Dev Tools, React, Angular, Tern, ESLint, npm, git, Redux and Promises are all "mature robust solutions". They've all been around for years and are thoroughly tested and used. Many of them are used maturely in other languages as well, for example Futures in C# are basically the same thing as Promises.

The author does mention some newer things like async/await, generators, and ES6, but all these are now official parts of javascript. They simply can't "go obselete", and all of these share ideas with other languages which are also, by any definition, mature and robust.

The author does mention some libraries which are new and less proven, like RXJS, Angular2, MobX, Vue, Yarn, Typescript, and Flow, but did you notice how every single one of these has an asterisk? Which he specifically states means "strictly optional": Cool things to try out that may be useful tools, but not essential. Even most of these are several years old and perfectly mature anyway.

Yes the javascript community moves quickly. Yes JS programmers enjoy trying out flavor of the month frameworks, but it seems I'm one of the only people who sees this as a great thing. People try out lots of new things and learn lots of new strategies, and in the end the ideas of these get incorporated into existing mature frameworks, making them better and more robust.

[bkovacev]

From my personal experience what the parent comment stated is actually very true.

As someone who is actively trying to get into the JS world coming from the back-end side it is extremely hard to find best practices that do not change every other week. In the beginning of the year, tutorials were made with grunt, yarn, yeoman and the likes, then they were written to use gulp, bower and now it's webpack and what not. I can't even catch up on what the tutorials have used. To be extremely fair, every other week there seems to be a new tool I need to know and I can't even catch up on why I should learn or stop learning/using the previous. Every tutorial/documentation does something differently - there is no unique set of tools and instructions that do not change over time. I cannot find the best practices docs, because everyone has their own opinion of something and bashes the other guy for having an opinion in the first place.

I know it might be a bad analogy - but I usually compare the state of the principles of RESTful APIs to the state of principles of the front-end stack. They are design principles and you have set of instructions/best practices you should follow regardless of the language, framework etc. Thus I can make RESTful APIs in Python, Go, Ruby etc. On the other hand, Javascript is very opinionated framework. I cant seem to find the principles wrapped in a talk, book or docs. Offer me a choice, let me make it, do not make it for me. Let me make a mistake, let me learn how it does not add up to the whole picture.

Every JS documentation assumes something or fast forwards through an important part of the process - the set up. Why the heck do I need to use something, and why is it good with another tool you have in this stack. Why shouldn't I use something? Don't just copy the gulpfile or any other js file I need, explain it.

You said it is a good thing to try a new thing every month - how do you have enough time to observe it and test it properly in production or wherever? I don't see a new framework every month as a good thing, the frameworks don't mature in your environment and neither does my deep understanding of the framework. That makes for constant struggle to optimize a way. People in the JS world, at least to me seem like, hmm, this does not sound cool anymore let's change it up with this.

I hope I don't come of as a hater, I'm just speaking as a front-end newbie.

[Can_Not]

I followed a gulp tutorial, continued using it. When webpack came out, the gulp community seemed like it's was just as alive as before. When webpack came out I didn't rewrite all my gulp code to webpack. I'm not sure how you got different results.

[_uhtu]

These are better points that actually have something to do with the article. I may have seen harsh in reply to the parent comment, but that's because that comment didn't address the article whatsoever, nor did it add anything to the discussion like you did.

I don't have a perfect answer for you, but this article is a great place to start. Focus on the fundamentals of the language first, then the tools he provides here will let you build apps. The reason things are this complicated is because JS basically comes with basically no standard library and the need for javascript escalated extremely quickly before tooling could catch up. Now there's been a tooling explosion so it can be hard to find out what's best and how to learn it.

Get started with simple scripts, learn the Javascript basics he talks about, the built-in functions and classes, ES6, etc. Then move on to basic DOM manipulation, then the frameworks like React to let you build more complicated features without worrying about the DOM nodes themselves.

"how do you have enough time to observe it and test it properly in production or wherever?"

I certainly don't have time to use them in production, but with most I just look at the documentation and see what I think of the philosophies they use. Once you know the fundamentals of the language, simply reading their examples usually gives a pretty good idea. Then if I want to try it I'll download example code, mess around with it, and see what does what.

"I don't see a new framework every month as a good thing, the frameworks don't mature in your environment and neither does my deep understanding of the framework"

I'll give an example of why I think this is a good thing. React has been around for about 3 years ago and at this point it's probably the thing most people are going to go for when they are starting a new app. It's mature, robust, well tested, and well proven. It's a rock in the JS world that brings new features occasionally but doesn't break past features and remains strong and consistent. There has also been an explosion of frameworks that use the same philosophy as React, declartive UI that is expressed as a function of state, and resolved using a virtual DOM. These can't really compete with React yet, but they have helped improve React. For example, Inferno, which has almost the exact same API as React, has some great tricks for extremely fast rendering, and the people who work on React have expressed interest in using those ideas.

In the end, yes there's a new framework every month, but the tools that people are really using in production aren't really changing too quickly. Focus on the things that are mature, and there isn't much fatigue to wrry about.

"People in the JS world, at least to me seem like, hmm, this does not sound cool anymore let's change it up with this."

Guilty as charged. Part of the reason for this is that it's so easy since every computer has a browser and trying something can be as simple as adding a script tag. I love trying new things, though in the end in production I've been writing in React with Webpack, Babel, and some of my own self-built libraries for a while now without much changing since not much about that needs to change. I remember trying out Redux when it got big and loved the ideas so much that I wrote a similar state management tool that fits my needs better, and I've added that to my app but haven't changed much in the grand scheme of things to do it. I basically just learned some principals and applied them.

[jdd]

This! Lodash turns 5 in 4 months :)