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.
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.
React.
Redux.
Reflux.
Flux.
Relay.
Does anyone else see the madness in this ?
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.
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).
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.
Don't introduce these dependencies if you're just learning. Just use what you need (React + Redux).
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).
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.
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.
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.
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.
The average app/website is glorified CRUD so I don't really see why it has gotten so complicated.
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.
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.
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.
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.
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.
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.)
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.
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.
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).
We've been working on this complete overhaul of react-boilerplate for several months. Based on the combined experiences of tons of collaborators, we've created the strongest foundation to build your next React.js application with.
The biggest changes are:
- Revamped architecture: Following a bunch of incredible discussions (thanks everybody for sharing your thoughts!), we now have a weapons-grade, domain-driven application architecture.
- Scaffolding: Generate components, routes and more parts of your application directly from the command line, skipping all the boilerplate writing!
- Performance: We've got the best code splitting setup currently available, giving you the leanest, meanest payload. (The fastest code is the one you don't load!)
- JS utilities: We now include redux-saga, ImmutableJS, reselect and react-router-redux to make sure your application scales to the size it needs.
- CSS improvements: We use CSS modules for truly modular and reusable styles, code split your styling based on the page the user is on and make sure your code style is in order automatically!
I think this is by far the best boilerplate currently available, both for starting your next project and for simply getting inspiration into what's possible.
Let me know what you think everybody, I'm beyond excited to finally share this with the world!
Ember has demonstrated singular organisational maturity - stable and consistent release process, standardised build tools, high quality documentation, excellent deprecation warnings & clear upgrade paths. It allows teams to focus on delivering value without prevaricating about build pipelines and trust that the whims of the maintainers won't result in months of rewriting at arbitrary intervals.
Equally it's been pressure and progress from React on render speed that's helped push along Ember's Glimmer engine, long may the ecosystem and healthy competition drive innovation!
I mean, how does updating work? If you improve the scaffolding, people need to merge in their changes? Why is this not a CLI tool that would be effortless to update?
Although I must say it's impressive work made on this, and that it's cool to be able to generate many things, I fail to see any big value in using these kind of boilerplates.
I don't want to spend days figuring out my asset pipeline, build scripts, and implementation of flux/gulp/grunt/webpack/broccoli blah blah.
It's good those choices exist, but I don't care about the differences enough anymore, I just want to build my app. Plus, you lose the sense of common solutions when there's this much variance.
angular has adopted ember-cli into angular-cli – any plans by the react community to do this?
First, you would need to define what a React framework looks like, which libraries it needs and which conventions it should use while wiring them together, then build tools around that.
Version 3 of React Boilerplate takes steps towards that by deciding on a set of tools, libraries and conventions and providing code generators for adding to them in a compatible way, but the initial wiring is still done as boilerplate (like it says on the tin).
react-project [1] was heading towards something more like managing this wiring behind the scenes as a dependency rather than a boilerplate, but it's not being actively developed any more at the time of writing.
---
I think React and view libraries like it also necessitate a slightly different approach in that there's no overarching thing to hook into behind the scenes - you just write a bunch of JavaScript and what it returns (plus side effects) is exactly what you get.
For example, to use Font Awesome icons with Ember via ember-cli, you install ember-font-awesome and the next time you run ember-cli it does... something... such that an fa-icon component is now magically available in your templates. [2]
In React, you install react-fa, import it into module scope where you need it and use it as part of what a render() function returns - your build tools handle it the same as any other JavaScript and CSS you've imported. [3]
[1] https://github.com/ryanflorence/react-project
[2] https://github.com/wycats/github-issues-demo/commit/a3358026...
[3] https://github.com/insin/react-nwb-github-issues/commit/cad3...
Ugh. I just don't get it. Am I just old and curmudgeonly? And what's with the 200+ line package.json. That's a helluva lot of tooling for a simple web app. GET OFF MY LAWN!
For people coming to this area fresh it's really daunting. There's a new library for every little thing you can think of and it's almost impossible to know where to start. Fortunately Redux itself is such a simple model that it's easy to build on your understanding of it (vs, say, Angular that has a huge surface area - I know, they're different things, but people are probably going to start with one or the other).
Will try this out now to see how I get on. Great timing, thanks!
[1]: https://openmic.io, a MediaRecorderAPI experiment
As a note, Gluestick has been iterating and this project is obviously a few months old, but it does show the basic structure of a Gluestick built application.
Disclaimer: I work for TrueCar.
I think people have hard times pronouncing framework these days, because it sounds offending in terms of learning curve. Why would you spend X amount of days to learn a framework, when you can spend that time learning about the core technologies and make yourself no-dead-code code base? That's why I dislike frameworks.
With React-boilerplate, having a CLI tool that helps you modify the "boilerplate" I think we are getting more or less to the framework definition.
In any case I've never used a boilerplate without having to use `rm` command after installing it. That's why I dislike boilerplates and avoid them.
Right, that's exactly what I mean.
v2 to v3 is like stone age to modern times. :)
Quick question - what does the HMR work with? If I change a component it seems ok, if I change a reducer it blows up in my face.
EDIT is there a walkthrough of getting set up with this anywhere? After about 30 minutes playing I think I'm going to put this down until there's an obvious way of building a simple app with it.
if (process.env.NODE_ENV !== 'production' && module.hot) {
module.hot.accept('./reducer', () => {
store.replaceReducer(require('./reducer'));
});
We've actively been working towards it, we realise it's a really important one too, so it won't be long.
Chime into the discussion here if you have thoughts about it: https://github.com/mxstbr/react-boilerplate/issues/174
Boilerplates exist because, quite honestly, modern web/JS development is a hot mess. First, setting up a new project is the definition of analysis paralysis -- too many options and microdecisions. Second, there's a new library or a new, breaking update to your existing framework every other week. When you're busy actually working on a project, it's hard (and useless) to keep up with all the changes. So if you work on something for, say, 2 months, the next time you need to start something new, it's likely you'll have to spend some time updating your own project base and making sure dependencies work the way they're supposed to. Things will probably have changed in unclear ways.
Unless you're reusing a stack that might be out of date/not maintained anymore, the time from "start project" to "start actually coding" when starting a new web project is terrible.
Having a boilerplate to start from relieves you of all that stress, since you know it's more or less maintained and guaranteed to work out of the box.
A few years ago I'd never have started from boilerplates. I'd look up examples for certain patterns, but always start from scratch, many times reusing some of my own stuff. Nowadays, my approach is the opposite: I take a boilerplate with the combination of things I need, and change it a bit, adding or removing things here and there.
We've added tons of removal guides for each major feature, so people can take the parts they want from react-boilerplate and discard the ones they don't want! I see it more as a reference implementation that gets many small details right, a thing you clone and the cut to your liking to keep all those small details intact.
Does that make sense?
- so you can postpone learning some of the more esoteric stuff until you actually need it, rather than guessing at the beginning
- Spending a day setting up boilerplate at the beginning of a 6 month project doesn't seem like a big deal vs spending a day tweaking the boilerplate throughout the project, but early time on a project is important, it let's you get feedback earlier.
This is the main appeal for me. I want to get something off the ground quickly and start learning the core concepts - not get sidetracked into understanding a peripheral tool.
If you don't actually need it then why are you deploying it into production? IMO, while these boilerplates are an excellent way to get familiar with some popular tooling, I think it's a terrible idea for people to be deploying code into production that they don't need or even understand.
You hit the nail on the head! This is a huge problem. We had a scaffold that included isomorphic rendering. At one point we discovered a potential XSS vulnerability in how we were serializing the initial state. Updating was trivial but we had to manually patch multiple apps.
We wanted the same thing and it didn't exist so we created it. https://github.com/TrueCar/gluestick
I see Redux+React as becoming the next Ruby on Rails due to the set of conventions it promotes. These conventions will have the same benefit to companies and developers switching between projects/developers and getting up to speed very quickly due to the same structures ( actions / reducers / etc ) being used by multiple projects.
Typically I just need react + router + bootstrap, and if I can choose, I prefer gulp. The whole ecosystem evolves too quickly, so every 2-3 months I need a fresh boilerplate.
This said, most of the changes I to from boilerplate to app are pretty much confined, and it's not hard to update the boilerplate below... problem is that often time people release a boilerplate, then abandon the project.
Even if I don't want to do it anymore, there's a good 20 people that know the project just as well as I do, if not better!
As for your biological linter- you will be surprised at how quickly you are able to get used to it. The key for me was to stop thinking of it as HTML or markup- because it isn't. It's really just a different way to call functions and create objects.
It's far better than handlebars or other template languages because it's an actual regular syntax that you can use a linter with so you know it's going to work as you intended.
I will say that I initially disliked the inline markup as well, but it honestly just makes practical sense. When we used Handlebars still, I always had the template open in a split when I was editing a view anyway, why not just keep it all as one contained unit?
I have been told that .NET works in a similar way, but with a key difference of that diffing happening on the server, so it isn't as fast. This is just hearsay, please don't take my word for it, I don't claim to know how .NET works.
What's with that 200+ line package.json? That's like a makefile, with everything already configured for you. Sure, it's a lot of tooling, but you could say the same about most software development tooling. Why is XCode 4 gigs? That's a lot of libraries just to create simple mobile apps. Back in my day, all we needed was a tiny WML XML 200 byte file to display to a cell phone. And yet, here we are, in the future.
Perhaps you're thinking of components (or "controls" as they're known) in WebForms for .NET? They had a component style architecture but everything about them was difficult to understand and hard to use. Compared that to React where components are cheap and easy to build/compose, to such an extent that almost everything even things which don't actually render their own UI) ends up as components in React.
At the risk of getting long-winded, I like React, not because it is the best among its peers of JS view-layer libraries, but because it has an effective ecosystem that can give you a fairly consistent development experience in a somewhat narrow set of use cases.
To put it in more concrete terms, I see efforts like React Native as something that can give a single developer or a small team some reach into several different platforms with some reusability of the code base + tools + dev workflow, though none of the implementation will be the best-of-breed for any of the platforms (maybe with the exception of desktop web browser).
I could see many people disagreeing with it, and I could see myself being convinced by them, too. But really, it's something I've had easy enough time learning to use in production and made some parts of development work easier than the ball-of-mud feeling I had in the past using others, so I've found that to be a plus.
But I truly empathize with the red squiggly lines in the editors! :)
Yes
For those of us who have been coding since before there was even JS, it's hard to let go of the Html / JS split but honestly, it's so much nicer when you just grab the React approach and run with it.
Yes for me too.
While making web applications with JEE and PHP for a decade, every best practice article on creating maintainable web apps told me to keep markup and logic different. That too in different files preferably in different folders like Controllers, Views, etc. Same for not mixing JS and CSS with HTML. And in practice it worked very well for me. So when I saw React's approach of putting JSX straight in JS code, I was thrown off a bit.
Even Angular 1.x felt wrong with adding nonstandard directives in plain HTML. Common wisdom before Angular was only to use standard HTML/XHTML that passes W3 Validator, then use JavaScript to enhance the page.
But then I just made peace with Angular and React way of doing things. If I want to get the benefits of the Angular/React eco system, then I need to use their approach, and still make sure that I produce maintainable code.
I've decided to skip on boilerplate for the moment. I found that it wasn't very clear as to how to manage the code and I didn't find any obvious walkthroughs. Maybe for people with a little more experience it's useful but I found that it made everything a little murky for me.
Since yesterday I've made good progress on my own app and I have have a much better understanding of how everything fits together. It might well be that boilerplate has the answers to some of my questions on how to manage the codebase but I just need to go through the process of figuring it all out for myself.
I find that this generally is the best approach.
Of course, the mistake I usually end up making, and one I made in this case, is that I try to learn too many things at once. For the current project: Redux, React (+ router stuff), Flowtype, Typescript, hot reloading, and something else I forget. Certainly didn't make things easier or more efficient, but it was hella fun!
(Flowtype in particular is going to stick around for future projects where I don't want to go all-in on types. Typescript seems like a better long-term bet though, FWIW).
(Possibly someone who knows a lot about drills is going to tell me I'm an idiot in a second...)
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.
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?).
> 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".