[Kequc]

I feel like knowing which tools are useful, which ones are currently dominating, and which ones are going to continue being supported in the future is the best place to start learning JavaScript. This is difficult because the ecosystem is so wildly fragmented and insane. You'll get a lot of different opinions if you go searching for them, so here are mine.

ES2015 is the place to start, it is a finished stable release of the latest version of JavaScript. It represents the single largest update to the language in a long time and includes many features that make development easier. It is being phased into web browsers natively and is the future of the language.

For maximum browser support you need a transpiler, this would be a matter of preference because it isn't for you, it's for the computer. TypeScript however is a very very clean transpiler and it offers optional features which are for you, should you choose to use them.

Once you have that setup, you really don't need anything else. You don't need jQuery unless you're trying to support IE8, which is a tiny proportion of the browser market and that will gum up your code significantly.

Speaking of gumming up your code, nearly every single library out there is bloat and can or should be avoided. React is very popular but it suits one very specific use case, it should be used almost nowhere else. Particularly since it is still new and evolving, it is going to cause more headaches than it will resolve. Webpack is an enormous bloated nightmare for example, it messes with even static html for little or no perceivable benefit and honestly just avoid all of it if you're trying to learn JavaScript.

If you want the full-stack experience, Node.js is rapidly becoming the largest JavaScript community on the net. You'll have your questions answered quickly and there are modules for everything you want to do. Choose a markup tool for html and css, such as pug and less.

There you go. State of the art front end JavaScript with two tools. Full stack with five. If it wasn't for the whirlwind massive chaos of the JavaScript community currently, fewer new developers would feel discouraged from becoming involved.

[lucb1e]

> React is very popular but it suits one very specific use case, it should be used almost nowhere else.

Which use case?

I've never worked with React but from yesterday's stateofjs.com I got the impression it's currently the go-to framework for everything.

[Kequc]

It gives you components. If your webpage is loaded and significantly complex with a need for different things all over the place then it's for you. It was built for Facebook, which has stuff everywhere on every page.

If all you want is a normal webpage, like a blog, like all of the websites out there I'd say you do not need components. Just build your own object. That is a lot of stuff just to do something that has been done for decades without it, battle tested so to say. Another one of the problems with the JavaScript community currently is the number of people who treat their favourite tool like a religious experience.

React is a large hammer being used quite often to close a twist tie. The ecosystem of tools which have sprung up around it is far worse than React itself. Each one a larger amount of overkill than the last.

[Ambroos]

I'm sorry, but once you feel comfortable using React there are very few things that React would not be a good fit for, however small the task.

I started coding in JavaScript two years ago, right at the point React was gaining popularity. I made a gamble going for it 100%, and since then both the company I was working at back then and the one I started working at recently have fully switched to React for all new front-end development after seeing how much easier it is than anything they'd ever used before (jQuery, self-rolled prototype-based things, Backbone, Angular 1, Ember).

Yes, sure, you have to get the basics set up every time, and yes, sure you have to package React on every page. But as a gigantic win, you get a uniform way of dealing with the DOM every single time. React has well-defined best practices by now. When every Javascript coder in your workplace is familiar with React, it's usually best for you and for them to simply continue coding in React.

[Kequc]

I feel that you are marginalising the amount of complexity you are adding to projects which might not need it. There are multiple routes toward completing the same task in development. My concerns surrounding additional complexity I feel are well founded, there are costs associated with such a thing.

If all you are doing is DOM manipulation, without doing a huge amount of it, that isn't such a complex task that it should require an entire framework. If you're doing more than that it outscopes what React can do.

[Ambroos]

That's just it. If all your developers are familiar with at least the basics of React and Webpack, you aren't adding any complexity. Once you know how things work, a simple Webpack configuration with Babel and 2 presets isn't complex anymore.

What would be complex, however, is introducing DOM logic in yet another way. We're all used how you just define the desired state in React and letting it figure out the transitions. When you suddenly ask your developers to write code that manually manipulates the DOM and has to take care of all the transitions between states, you end up with complex, unclear code that takes everyone a long time to understand.

[Kequc]

Webpack alone requires hundreds of dependencies. You are populating your node_modules directory with megabytes of code, any of which could stop working. If you plan to maintain your code for years into infinity then it's no problem. Otherwise the shop down the street doing the same thing without it will be much better off.

[FrancoDiaz]

React in itself is simple, but familiar with and comfortable with the complexity of Webpack is another story ;)

Ok, I guess Webpack isn't too complex, but its weird syntax (the whole right to left chaining) and poor documentation can be a barrier.

[callumlocke]

> the amount of complexity you are adding to projects which might not need it

If 80% of your projects are written in X, it's probably simpler to just use X for everything, even things that don't need it

[ryanSrich]

> Which use case?

If you're building Facebook.

[enraged_camel]

Come on, your response is pretty shallow, don't you think? Or do you genuinely believe a Facebook-like application is the only one that could benefit from organizing into modular, reusable components?

[sAuronas]

This is a very good reply. Someone trying to grab a foothold in front end development should keep it simple and add tools as they require them (if applicable). I used to develop for the web until I found iOS development to be more enjoyable because of the feeling of stability of the SDK. When I did do it, I got to the point where I said, fuck all this noise and just give me Nodejs/npm, MongoDB and raw JavaScript...

Right or wrong it felt like enough at the time. Just adding Angular felt dirty. Damn, I feel for you guys.