[Niksko]

Advice please: I tried to wade into the weird and complicated world of web development a few months ago, but eventually I gave up.

At first I used a boilerplate (in fact I think it was a previous version of this one), but it felt like I was jumping in the deep end. I didn't know what anything was, I didn't understand the configuration or the setup, and nothing was making sense.

So instead I decided "I'll start from scratch, introduce dependencies as I need them, and I'll actually understand what's happening". But then as I started to try and introduce dependencies and pieces of the toolchain and stack (Babel, GraphQL/Relay etc.) and that was a whole different type of confusing. I found it really hard to follow tutorials unless they were written for EXACTLY the stack I was using, because small changes seemed to radically change how I had to go about things.

How do you start? Both situations seem perilous. Bottom up is really difficult unless you follow a tutorial that exactly matches your stack. Starting with boilerplate means that if anything breaks you have no idea how to fix it or how anything works.

[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?

[bshimmin]

It's a ghoulish nightmare, isn't it?

I think one possible approach - and I haven't tried this because I am in the fortunate position of having been working in web development for a long time and just about having kept pace with most of what's been happening (and also I've been happy enough to avoid the parts that weren't enticing or seemed actively unpleasant) - is to take something like this boilerplate project and prise apart its individual components to see if you can work out what each of them does and to get some experience with it in isolation. Perhaps you might start with a tiny project with React - just an HTML file and enough JavaScript to make React, well, react. Then maybe play about with ES6 and Babel. Then see what PostCSS does. Then add Redux in there to your React mini-project. Then... oh, I don't know, throw the whole thing away and use Elm, because that seems quite popular now.

[the_bear]

I ran into this recently myself. I've been doing web development my whole career, but I never got into the complicated toolchain side of it. I just used a vanilla html/javascript setup and I would build out my own tools or manually include existing libraries as I needed them (no webpack, etc.)

Then it came time to learn React and pretty much every tutorial out there requires a twisted combination of npm, webpack, babel, etc. just to get a simple page running. I just about gave up.

Then I realized that you can run React without any of that stuff by just copying the first section of sample code from this page: https://facebook.github.io/react/docs/getting-started.html

So I started with that and built out my own simple framework. As I became more familiar with React and how it interacted with my own homemade framework, I was able to understand where all of the other pieces fit in, and gradually I've been including some third party tools that previously seemed insanely complicated to me (note: the toolchains still seem needlessly complicated, but at least I can generally get things to work now).

[philihp]

Exactly this. If you're just starting out, just do a simple page with only React.

Very quickly you'll find there are problems with managing your page lifecycle, and you might imagine a good solution to it. That solution probably looks a lot like Redux.

Then you might want some unit testing of your React components. Woo, that too has also has a satisfactory answer with Enzyme.

Slowly, you will add more and more to your toolkit. Before you know it, you have scaled the frontend ivory tower.

There is a rationale for all of this, but you shouldn't feel obligated to use any of it. You can save yourself a lot of headache down the line by starting with a project like React Boilerplate. Maybe you don't need 70% of the things in it? That's cool. Just start with it, build up the bits that you need using just 30% of it. Then maybe later, you want another 10% of it... it's already there, configured, and ready for you to use.

[jfdk]

My advice would be don't use all the fancy stuff. You really don't need to. A basic HTML page with a few <script> tags will go a long way. And with browsers supporting most of ES6 (WebKit supports all of it) you can use all the new JS features in your dev environment no problem.

Don't introduce these dependencies if you're just learning. Just use what you need (React + Redux).

[bdavisx]

I think it was Dan Abramov (the creator of Redux and quite a few other things in the React ecosystem) said to start with React only; then, when your application gets complex enough to need other things (Router, Redux, etc.), you'll know it.

And you'll know it because by starting simple, you won't get overwhelmed - and you'll build up the knowledge you need to move to the next level.

As for where to start, either here for "text" only: https://facebook.github.io/react/docs/tutorial.html

OR

here for video: https://egghead.io/series/react-fundamentals (although I think it may require a subscription).

[dagw]

How do you start?

Me? I start by asking myself "do you really really need Babel, GraphQL/Relay etc"? Once I've answered "probably not, at least not right now" I decide to use PostgreSQL with python and flask (or node and restify/express if I'm that sort of mood). For the front end I start with a simple bootstrap setup. Once I get to the point where I actually really need GraphQL or whatever I have a good enough understanding of my needs that it becomes pretty obvious how I should integrate it.

[larksimian]

My suggestion is to go through some full-stack tutorials. Vary them up to learn how workflows with different library combinations/boilerplates feel for you.

For React my quick and dirty intro a few months ago involved: http://jamesknelson.com/learn-raw-react-no-jsx-flux-es6-webp... and then following along with http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial...

The first link is very light on dependencies and brief. The second link is basically a mini-ebook going from front-end to back-end but walks you through the choices very well.

What you want to do is build apps, so look for tutorials that make you build an app from start to finish. Do a number of those, semi-rotely, and you'll develop familiarity with the tools and methods they use. That's when you want to deep dive on specific libraries and stacks.

Imagine how complicated it would be to try to learn Rails by learning ActiveRecord and then ActiveSupport etc. The interesting work happens when all the dependencies are combined -- and the challenge/beauty of the framework is how it combines them -- not when they are taken as individual libraries. Boilerplates are shitty, immature frameworks but similar principles apply.

[htns]

That's a good suggestion. The teropa.info post was very helpful for reintroducing myself to web development after not touching it since 2008. I hope I'm not scaring anyone from getting started by adding I also consulted typescript tutorials ;D

[afarrell]

The Teropa one is particularly good because it uses Test-driven development, which is a good way to keep yourself from going too far down a rabbit hole.

[tunaoftheland]

Many have already added excellent comments, and here's mine, as someone who's recently worked on a project with React + Redux + ES6 (Babel5 -> 6) + WebPack, etc.:

Start simple and refactor the application as you add the other libraries gradually.

In your particular case, forget everything else except React and ES5. It won't take long to understand what props and states are in React and to get used to the idiosyncrasies of JSX. You might even want to start out by kicking around in JSFiddle or JS Bin.

The other tools are very useful, but they won't be so until you see the need for them, Make notes of which parts you find annoying with the simple setup and turn to see the tools you listed to see if/how they will help you.

Kinda changing gears into a diatribe about the crazy ecosystem in the JS-land: I feel that there are several subsets of it that have been rising above the rest to give developers the productivities that they need. It's not clear-cut and there are many valid options, plus even more subspecies within those options. Several of them could be well-suited for the task at hand, so I wouldn't worry too much about making the wrong choice and paying heavy price for it. The way I see it, frontend development scene is tough if you have not already been immersing yourself in it for a while. It is like that now and it will be for immediate future. The good news is, it is getting better, and I think we will see the community gradually converging toward several collections de facto standards. It will remain amorphous, but not as overwhelming, I think.

[vectorpush]

First you should think about what you actually want to build, then determine which features would benefit that type of application, from there you can consider the available tooling that facilitates the development of those features.

The fact that you are overwhelmed by the "start from scratch" approach makes me think you are falling into the common front-end pitfall of reaching for popular tools that you don't necessarily need (yet). These tools should be the answer to specific problems, instead of being problems that need an answer for why you should be using them.

If you find that you can't extract useful information from tutorials that don't match your exact stack, then its probably the case that you're taking on too much and don't really understand the context for why these tools were developed in the first place. You should learn to walk before you delve into the technical intricacies of augmenting your gait with a fusion powered exoskeleton.

[pbreit]

The current state of web development is a disaster, imo. All the Node, Angular, React stuff is pretty much unintelligible for mere mortals. Rails/Django much easier but a bit bloated.

The average app/website is glorified CRUD so I don't really see why it has gotten so complicated.

[jbob2000]

Work backwards. Start with tools that basically do all your work for you, and then try to understand the pieces as you work with them.

Try the angular-fullstack generator using yeoman: https://github.com/angular-fullstack/generator-angular-fulls...

This will generate you a fully functioning front end and server, with an authentication and user management service. It also has methods to push to heroku, so you don't really need to know how to deploy to a live server.

[jakub_g]

A pragmatic attitude of mine is: do not use anything that is less than a year old.

Applies to frameworks, tools, programming languages, operating systems etc.

You can break this rule if you really know what you're doing, and it's only one thing in the chain. But basing your whole product on a whole stack of work-in-progress stuff is madness, unless you like pain.

Ok, React et al. are more than one year old, but still the whole ecosystems is not the best one to just start your webdev career from, due to complexity, lots of moving parts, breaking changes, etc.

[dceddia]

I've been writing about this a lot recently -- particularly with React, where do you start?

I think your "start from scratch" approach is actually the right one, and the only caution I'd add is that you'll probably be tempted to "introduce dependencies" TOO EARLY.

Everything out there will guide you toward adding everything at once, or ramping up too quickly. Many tutorials are "full stack," and so you're tempted to make your stack match theirs just to make it easier to follow.

Add to that the groupthink around the idea that you really need React+Redux+Webpack+etc+etc+etc to build anything of any meaningful size, and you're stuck with a lot of pressure to add more than you need, before you need it. Oh, and nobody really says "wait until X happens before you add Redux," it's much fuzzier than that, more like "you'll know it when it happens." Great.

I wrote an article just the other day about this learning process: https://daveceddia.com/timeline-for-learning-react/

A key to the process is building a bunch of throwaway apps, I think. You don't want to dive in and try to build a full-stack app. Too many moving pieces, even if you're adding them one at a time.

They're all independent libraries, right? That's what everyone keeps saying anyway. So why not just learn "pure React" (no Redux, no backend) first: get it down rock-solid, and THEN add one more library to the mix. Build a few small apps, add another. Eventually you'll know the whole stack cold, but not if you start with a shaky foundation.

[RichH]

Just use clojurescript its simpler. By the time you have set up webpack you would already have a webapp in clojure.

[pritambarhate]

I think ES-6 requires a lot of tooling support (because you need to support older browsers too) so it can be very complicated to set up for a new comer. If "learning React" is not your goal then I think learning, Prototype Based Object Oriented JavaScript, jQuery and Backbone.js can help you make almost any type of web application.

I think learning core ES-5 JS is important, for anybody who wants to learn ES-6.

Once you have done couple of applications with this stack, I think gradually picking up Babel and Gulp like tools and React wouldn't be that hard.

[fauria]

I completely agree. One of the things I find more stressful is the lack of time to dive deep into new stacks while meeting deadlines and delivering on time.

Maybe a side project would be helpful. I personally have considered implementing an MVP for a personal project using a stack I already know, and then gradually reimplement different parts with newer technologies.

Having a solid set of integration / E2E tests would probably easy the transition and help overcoming the If it ain't broke, don't fix it feelings that might later show up.

[ianstormtaylor]

As someone who's been around frontend development for a while now, and who had a similar "wtf" moment when finally deciding to pick up React and all of its friends, I think it depends on what you want to learn...

1. If you want to learn frontend from scratch...

Then I'd recommend not going anywhere near React at all. Stick with plain HTML/CSS/Javascript injected with <script> tags on the page. Throw in jQuery if you need to. Although if you're just hacking on things that need to work in Chrome / Firefox, you don't even need it.

That should give you a good introduction to the fundamentals, and still be fairly easy to find tutorials and information about how to get things done. The key is to have a well-defined, but small project idea to be able to implement.

When I was first getting started one of my early projects was a domain name search using the Domainr API. Something at that scale, with just one or two pages and a small amount of Javascript is perfect.

2. If you want to learn React...

Then I'd recommend not trying to do add anything like Redux or Flux or Relay to begin with from the "state control" side. And don't worry about Webpack or Hot Module Replacement or anyting from the "build experience" side.

The only additional thing I'd add here is Babel. While it's not required to get going with React, you'll find that 90% of people using React also use Babel for JSX, and so 90% of the tutorials are written in JSX. It's totally possible to first learn how the translate between non-JSX and JSX, and to convert it in your mind, but it'll end up confusing you way more than just deciding to get Babel running.

Whatever you do, DO NOT start from a boilerplate. These things are actually completely counterproductive to learning how things work. You'll end up with a huge mess of things you don't understand! The only time a boilerplate is really ever useful is if you're having trouble configuring some tool, and you check out a few boilerplates to see how they work. If you ever actually generate a new project from one, god help you. Not recommended.

With that, again, build something simple with React and JSX by itself. Self-contained, one or two pages.

Be careful, because trying to throw in all of ES6 once you get Babel up might be alluring, but see if you can get by with just using straight ES5 to begin with. If you can do this for a little while, it'll be much clearer where React ends and ES6 begins. Trying to learn them at the same time is possible, but it makes it a much slower process.

As the project expands, add in React Router to handle routing. If it continues to get bigger, or once you feel comfortable, add in Browserify or Webpack with HMR and Live Reload to see how much it improves your development workflow.

3. If you want to learn Redux...

Here I can't really help you. I honestly am not convinced at all that Redux is a tool 90% of teams should be using. In my opinion, it's one of the primary reasons why tutorials these days are so damn complicated. If you can get away with not using it, always do that.

If you have to learn it, do it the same way, get all of the React fundamentals down first. And honestly, get a live reloading development environment down first too, because Redux generally involves creating tons of files and directories to stay organized.

If at all possible, I recommend looking into Relay (from Facebook) instead. It's an equally challenging amount of boilerplate and new concepts to learn, since the API isn't as clean as Redux's. But once you get it working, you can literally completely forget about data-handling logic and the app will function exactly as you expect it to. It's much, much simpler to reason about and develop around.

---

Hopefully something in there helps!

As confusing as it can be, once you get the hang of React, JSX, ES6, and live development it's incredibly productive and easy to reason about, and you'll want to be using it everywhere. (Redux is sadly the opposite.)

[TJSomething]

I am currently trying to get into the deep end by reading and watching enough tutorials that I can see the patterns emerge. It's tough. I miss Ember, but it's not really going to work on my current project, which is probably going use Webpack, Babel, React, Redux, GraphQL, Koa, Scala, Akka HTTP, and Sangria so far.

[ianstormtaylor]

If you're already going to be using GraphQL for your main API, I highly recommend looking at Relay. Slightly steeper learning curve than Redux, but it will more than make up for it once you get it configured, because you'll be able to completely ignore it and it will just work. You won't need to think about "how do I get this data" at all anymore.

[fiatjaf]

Whoa, so many names.

[andy9775]

To learn, I built it up little by little. Start with Babel, Webpack, express and react. Build something basic. Next add Redux then react router and finally server side rendering.

You have to use various tutorials, read lots of docs and try and fail. In the end I found I had a better understanding of what was going on.

[rdoherty]

I agree and I'm also curious how someone would integrate all the React ecosystem into an already exiting app (Rails specifically). Starting a new project is easy, rewriting one is a huge challenge.

[RobertKerans]

React Rails[1] works fine: you just get React, and it's difficult to integrate other shiny React-associated stuff like Redux, but it makes it incredibly easy to build out an app, or even just sprinkle components throughout an existing Rails app. It's dead simple to get started, and I've found it generally Just Works; the whole team I work on has been using it for the last 4-5 months without any issues. Just add to Gemfile -> it sets up a components folder + a file that imports the file tree -> then optionally set initializer options (like include React Addons, or use stage-0 stuff). All exposed globals though, which is a pain, but that's generally expected with the asset pipeline unless you're very disciplined.

There's a pretty complete tutorial, but it's a bit out of date + uses CoffeeScript rather than JSX - I made a copy of the original, with updates, for one of my colleagues, the gist is here (sorry, might be a little rough): https://gist.github.com/DanCouper/b6953544a34606617eb5

To get a bit deeper, there's React on Rails[2], which retains the same entry point, but moves all the JS to a separate folder at root, and uses Node to handle that side of things during development. The setup is batteries included, and pretty flexible, but I haven't used it a huge amount so can't give much detailed feedback.

1. https://github.com/reactjs/react-rails

2. https://github.com/shakacode/react_on_rails

[fiatjaf]

Really? GraphQL? You don't need that.

You don't even need React, there a ton of excellent frameworks based on the same React ideas (virtual dom, a single state, render everything from top to bottom) out there, and they don't come with all these fancy arrogant stuff (Webpack, Redux, Babel, ignore these).

[cloverich]

React doesn't come with those things either. React is just a view layer. If its confusing (to anyone) -- just use Facebook's getting started example and start building stuff. It'll all come together.

[fiatjaf]

I know, but the React community almost forces you to use all these, if you're following any tutorial or guide, or even just asking help on some specific issue.

[numbnuts]

Arrogant?