[freyr]

Modern web development is a bit of a mess. My advice is to start small, and introduce new technology gradually. You should be familiar the foundation (HTML, CSS, and vanilla JavaScript) first, if you're not already. Be able to manipulate elements of a webpage using vanilla JavaScript.

At this point, you might want to get up and running with Babel and the new language features introduced in ES2015, since more and more tutorials are written assuming you're using ES2015.

Then pick one library or framework (e.g., React) and get comfortable with it. Think of a simple project to build, then try building one even simpler than that. Don't introduce a second technology (e.g., Reflux, Relay, etc.) until you have a handle on the first. And even then, try to introduce just one new technology at a time.

You might be thinking that this will be a slow, involved process. That is correct.

[sixo]

I'd love to see a list of web frameworks with one-paragraph blurbs describing the problem they solve and what they work with. To an outsider (which I am) they all seem the same.

[wrong_variable]

As a web developer who is not a 'web bro'

React.

Redux.

Reflux.

Flux.

Relay.

Does anyone else see the madness in this ?

[vectorpush]

All these tools exist for a reason, it's not "madness", it's individuals who wrote some code and open sourced it for the benefit of those who might find some use in it. Just because a tool hits the front page of HN doesn't mean you need to use it. I find it ridiculous when people complain about the js tooling ecosystem (especially beginners), "too many tools" is only a problem for someone who doesn't have a real problem to solve. If you were tasked with the job of hanging a window curtain, would you walk into Home Depot and exclaim "omg, hardware is a mess, why are there like 40 different types of drills, why can't they just make this simple??". It is simple, you are the one making it complicated by obsessing over the options instead of focusing on getting the job done. "but I want to pick the best tool for the job", well if you don't know what that is, hire an actual professional, it's their job to know.

[bshimmin]

I'm not sure this analogy works. My brother-in-law is a builder and I would certainly ask him what drill to buy if I needed a new drill, and I'm sure he'd have an answer. (If I didn't have him to ask, I'd probably be able to differentiate by "brands I've heard of" and price, with a sprinkling of research on Amazon.) But if those 40 different drills all had slightly-to-greatly different characteristics and then had a fundamental paradigm shift every six to twelve months, rendering previous drills potentially obsolete, would the professional builder really be able to answer definitively? Can anyone in web development really answer definitively as to whether you should use npm by itself, grunt, gulp, or even make?

(Possibly someone who knows a lot about drills is going to tell me I'm an idiot in a second...)

[vectorpush]

> rendering previous drills potentially obsolete

This is the flaw in your reasoning. A better drill does not make the older one incapable of doing the same thing it has always done to meet your needs. For something to be made obsolete, the alternative must be definitively superior by definition, so the reason for picking the superior option is clear in such cases, but even then, you don't have to use the superior tool. If a traditional drill can meet your needs, you are the one creating a problem by using a tool that doesn't provide you with clear benefits.

> My brother-in-law is a builder and I would certainly ask him what drill to buy if I needed a new drill, and I'm sure he'd have an answer.

If you told your brother-in-law you needed a new drill, he'd likely ask "what are you going to be using it for", and then you'd explain your requirements and he'd give you an answer based on that. If you said "I really want to get into building stuff, but I'm not sure which magnetic drill press is the best option for a beginner", he'd probably say "whoa whoa whoa, that's a specialized tool for a specific kind of job, just stick with a regular drill and if that doesn't do what you need come back and ask me again".

> Can anyone in web development really answer definitively as to whether you should use npm by itself, grunt, gulp, or even make?

The crux of my point is that this isn't a useful question to ask. The question should be more along the lines of

Q. "I need a way to run some custodial tasks related to the operation of my application, what should I use to accomplish this?"

A. "Well, you could write some shell scripts and run those directly or with npm's script running capabilities, or if you prefer to use JavaScript to define these tasks since you're already using that for your application you can try gulp or grunt; grunt takes a more declarative 'config file' approach while gulp takes a more imperative 'streams' approach but they basically do the same thing, though, you've been a C programmer for 10 years so you might already feel comfortable with make, so you could use that I suppose, but you won't be able to easily import js code from your application into make so if that's something you want to do then you probably want gulp or grunt...." etc.

These tools didn't just emerge from the ether, they were created in response to specific issues. The existence of some arbitrary library or framework has absolutely zero impact on whether or not your existing solutions are adequate for the problem at hand.

[bshimmin]

Thank you for your thoughtful and considered response. I'll just leave out the bit about drills, because debating analogies is always unwise, especially if the analogous subject is outside of one's area of expertise!

> The crux of my point is that this isn't a useful question to ask. The question should be more along the lines of Q. "I need a way to run some custodial tasks related to the operation of my application, what should I use to accomplish this?"

I think you've just rephrased the question, no? We all know that "run[ning] some custodial tasks" is what a task runner does; but many wise people have expended many words telling you which of these increasingly fancy task runners you absolutely must use, ecosystems have built up around them, and the waxing of one and the waning of another does have a significant impact on the decision-making process.

> These tools didn't just emerge from the ether, they were created in response to specific issues.

I'm not sure people were really desperate to move from "configuration to code" or thought they really needed streams in their task runner before they were told they did, so for me I struggle a little to see what the "specific issue" was that gulp solved over grunt. The movement away from grunt and gulp to npm scripts and even crusty old make(1) is, of course, at least partly in reaction to the added complexity of these task runners - so in a way that's almost like unsolving a "specific issue".

[mikeryan]

I think we see the early growing pains of a new ecosystem.

React is great and a fantastic tool but by making it "just the 'V'" it opened up a lot of options and complexity in the ecosystem and Redux/Reflux/Flux/Relay each are trying to fill in the missing pieces. And yes it's hard to figure out and painful even for seasoned vets. But its getting better, the community seems to be settling on Redux for the most part over Flux/Reflux (Relay tries to solve a different problem).

NodeJS web development is kind of in the same boat. There's still no clear "winner" in the framework wars there like Django/Rails. I don't know why these trends seem to be magnified in the JavaScript ecosystem but it's similar to the early days of Java web development in the late 90s early 00s (Struts anyone?).

[evan_]

Are you objecting to the names, or that they all exist?