I feel like the people complaining about how many libraries there are in this stack don't know what these tools do. Most are small tools that do one thing very well.
Yarn installs packages, much like Gem, NuGet, whatever. Pretty standard.
React is a frontend framework. Not surprising that you'd use one. I suppose you could opt to write a giant pile of vanilla JavaScript instead (I'm assuming you're not using this kit for a simple webpage, which would be silly. We're building a web app, right?)
I'd dare to compare Gulp + Webpack + Babel to your "compiler" in a way. I'm a little lost at why we're using both Webpack and Gulp though. Babel is a necessary evil to ensure we're "cross-platform" in a manner of speaking. These are probably your most "unnecessarily complicated" tools.
ESLint and Flow check your code for obvious mistakes. Reminds me of IntelliSense and compiler warnings. Again, pretty standard stuff.
Mocha is a test runner and Chai is an "assertion library". Chai isn't a big deal: expect(foo).to.equal('bar'); Simple stuff.
Feel free to scoff at Redux and Immutable if you'd like. Probably unnecessary.
Am I the only one that likes this ecosystem? I feel like it follows the Unix philosophy of "Make each program do one thing well". You need almost all these tools in other environments -- they're just typically chosen for you in advanced.
I think the reason most of us dislike the ecosystem isn't because therre are many libraries and tools in the stack. In the C-world, every time you type 'make' I am probably executing two dozen different programs, so we are very comfortable with "Make each program do one thing well".
The problem that most of us dislike the javascript/web ecosystem is that those set of libraries and tools keep changing every couple years. As someone who doesn't do this as a full time job but once in a while has to poke his head out to the other side, it's really hard to keep up with even the acronyms. For example, I know that we are using npm, but now you say we should use yarn?!
I don't buy that either. The youngest thing on that list is yarn, but aside from that everything is a few years old at least.
And nobody is saying you need to use anything. Npm works fine, bower still works fine, hell pulling down tarballs still works fine. You don't need to use the newest thing if you don't have the problems it's trying to solve.
Yeah, from the outside I can understand the "everything keeps changing!!" complaint, but having been involved in JS for a few years, every single tool that got replaced was replaced for completely valid reasons, that couldn't have been solved incrementally by improving what was already there.
Because that's what leads to monumentally difficult to use tools.
Instead of choosing between gulp or grunt, you'd need to choose which config flags you want for this hypothetical "gunt". So instead of having simple to use tools (but a bunch of them), you have a few tools which take weeks of learning before you can even scratch the surface on them. And it leads to tools that have settings that nobody knows about because nobody uses them, and weird security holes and issues because of legacy support for an option that was added 3 years ago which when combined with a new flag causes everything to break...
Gulp is very simple, it's like 4 functions, and like 3 or 4 "conventions" you need to learn. There is no config, there are no settings, and there isn't any baggage. And that's the theme with JS tools. Rather than bloating current tools, you make a new one. Switching between them is easy, as they are all very trivial in nature. The power comes from combining those trivial tools.
Even if that were the case I would think learning powerful tools over the span of a few weeks would be worth the effort if you had the reliability that these tools would exist for years to come.
It seems like the rapid change and throw-away-ability of the tool ecosystem reflects the final product as well -- and maybe that's the large difference which is emergent from web technology? What is the average lifespan of a web application?
I don't think the past few years will be representative of web development in the future. The community has had a lot of churn because basic questions (How do I ensure my code has what it needs to run? How do I include dependencies? How do I efficiently deliver my code?) weren't answered, but now those questions have robust, widely used solutions, we don't have everyone figuring that out for themselves (and writing throwaway tools).
I think most of the current crop of tools that are in vogue will stick around for a while. There have been a few challengers to Webpack offering feature improvements (Rollup, Broccoli), but the ideas they introduced were added to Webpack, rather than replacing it.
I use maybe 3 main tools for my build system. Gulp, webpack, and babel. And I only use gulp because it is a bit easier to read than just putting stuff in a makefile (which is replacing one tool with another), or just using bash scripts.
If we were going with the "add options instead of adding tools" way of doing things, I might have one tool, but 100 flags and settings that I would need to manage and change, and you can't ignore the flags and settings just because you want defaults, because the defaults would work in a way that's out of date, or there might no be defaults at all.
Just because there are tools out there, doesn't mean you need to use them all. You can ignore everything you don't need in your project. And that includes ignoring the downsides, bugs, security issues, breaking changes, and baggage that comes along with them.
In half the cases parent presented, there were no "existing tools" to update(manual polyfills -> modernizr/6to5, script tags -> package managers like bower/npm, nothing -> eslint/type checkers, writing ad-hoc scripts for your own os -> grunt/gulp).
The rest of the examples are cases of merging two large ecosystems(web development and nodejs) together - that spawned browserify/webpack for bundling, npm for package management.
Many of these tools did try to update and adopt the new schemes. The grunt developers spent a lot of time optimizing their architecture in order to achieve the same speeds that gulp had. NPM has not stopped evolving - major version 3 tries to address a lot of the problems that yarn tackles. Babel evolves to adopt new javascript features.
I see the churn in development tools as a very natural progression, but that might be because I've been following it for a while and have seen and felt the pain points that each of these tools try to solve. I see a lot of effort within the javascript community to remain "compatible" wherever possible - for example, there are tons of guides how to migrate from grunt to gulp, there are matching tasks to ease your migration, etc. Library developers often release both on npm and bower, and craft elaborate "UMD loaders" for their libraries to allow for commonjs/AMD to exist side by side.
All in all, I find living with "javascript fatigue" to not be very exhausting. In our company, we have a wide variety of projects - some use literally no tooling, some use just bower, some use grunt, some use gulp, and our latest ones use the "modern stack" with webpack, etc. All of these projects are still actively maintained and their respective tooling stacks work and provide the benefit they were added for.
The problems the "newer" tools try to solve may not even be problems your development process has. If you've never really suffered performance problems working with grunt, then perhaps you've never felt an urge to migrate to gulp. Maybe you've never been bitten by npm's non-deterministic installations and poor download performance(I really haven't, so I haven't migrated to yarn, for example).
The magnitude of web development projects has ballooned in the last couple of years, and the tools are racing to handle it. It's not surprising that tools that are fit for a large web application with tons of code and a large team aren't really fit for a few javascript files to decorate a mostly static site built by a single developer. The churn is there, if you need it, but you don't have to use any of the newer libraries or tools.
The thing is, in other languages, frameworks and libraries can evolve without being replaced. It's called version 2. I can't help but think that in the JS world, you are more likely to ditch the old project because JS code is more difficult to read and maintain than languages that have more static typing, a somewhat higher entry bar, and a culture that values stability.
In other words, this is the consequence of optimizing for new entrants and writability versus readability and maintainability. It also becomes much harder to funnel talented people into being contributors to existing projects rather than starting their own.
In other languages there are very large projects that are heavily refactored and improved to support new patterns and use cases with regularity. Just yesterday I was using Antlr 4, which has been around for 25 years. But it's been updated many times. Maven was started in 2002, and maven 3 in 2008. It's stable and production quality. The openssl library goes back to 1998. Vim goes back to 1988 -- also rock solid and reliable. We're using a networking stack that is pretty damn old. But in the JS world, I can't help but think they would never be able produce anything that reliable because 6 years later they would be on their 6th re-write of Vim. And no, it's not (IMO) because other languages have corporate sponsors.
Javascript came out of the webspace which (was) primarily throwaway code. It was a bad thing to have an old website. They prioritized rapid prototyping, which was appropriate for that business case. However as Javascript is maturing and branching out to server-side programming and at the same time the client side becomes more complex, you can't keep re-writing all your tools every couple of years, or even every 5 years. You need tools that last decades, even as they are incrementally improved. If you don't have that, you are going to be subject to increasing exponential costs that are going to weigh very heavily on the language. Soon, you'll need to spend almost all your resources just re-writing stuff. It's no different than the developer that builds non-sustainable housing that has to be torn down every 10 years but is really cheap to build. Long term, a city built that way will necessarily be smaller in size and more expensive to maintain than a city built with housing that is more expensive to build up front but lasts a lot longer. Exponential decay is going to catch up to languages that like to keep re-writing all their libraries.
More importantly, I don't see an awareness on the part of the JS community that this is a serious problem that they need to tackle. They look at all the new libraries and the fact that they have the most code on github as a good thing, instead of as a warning side that they are already spending way too much time re-writing stuff.
So when there is announcement -- here is your standard webstack and it contains a tool less than a year old, a lot of people are gonna say "WTF", and explaining to them that Yarn has some new feature that NPM doesn't kinda misses the point. Of course it has some new features -- but still -- "WTF"?
> However as Javascript is maturing and branching out to server-side programming and at the same time the client side becomes more complex, you can't keep re-writing all your tools every couple of years, or even every 5 years.
The client side becoming more complex is the reason why new tools keep being developed.
> If you don't have that, you are going to be subject to increasing exponential costs that are going to weigh very heavily on the language. Soon, you'll need to spend almost all your resources just re-writing stuff.
No one is forced to rewrite their code when a new tool is released.
> They look at all the new libraries and the fact that they have the most code on github as a good thing, instead of as a warning side that they are already spending way too much time re-writing stuff.
There is a post, somewhere around here, that characterizes the JS culture as being one where shipping is the win condition. And I think this reflects what you describe better than the idea that other cultures merely value stability; JavaScript seems to value Github stars. And, as you say, that leads to a desire to rip out, rewrite, and own things, even if it doesn't necessarily make sense.
Just google "yarn vs npm" and you'll know the answer...
the tools change because the technology is evolving, despite node the front end is still the driver, and mobile phones / browsers / etc are constantly being improved and evolved, and the ecosystem keeps up with it. Would you rather it all stayed static like in the C world and then you program a 2016 smartphone with a 2006 stack?
The answer to your question is yes. I would rather the stack, or at least most of it, stayed stable for 10 years. The problem seems to be that the JS community keeps re-discovering the wheel at every step, instead of actually looking at other ecosystems and learning from them.
How log did it take for a sane build system to show up? Or a sane package manager (with dependency resolution, upgrades, checksums, signature verification, etc.)? Why is Grunt/Gulp a thing when we have thinks like make/CMake?
The technology is not changing, in the sense that the state of the art is not really changing. In the past 15 years the biggest paradigm shift has really been towards single page apps, ES6-7, and TDD. The rest has existed as state of the art in many other ecosystems, but the JS community is notorious for having a bad case of NIH syndrome, so it's taking forever to get to the state of the art.
The good news is that it will slow down at some point. The bad news is that it probably won't be for a few years.
> Why is Grunt/Gulp a thing when we have thinks like make/CMake?
What a ridiculous statement. It's like asking why .NET doesn't use the JVM or why Haskell doesn't use the C compiler. Grunt/Gulp solve web dev specific problems, make is a different kettle of fish.
No, the problem is never improving the existing software but rewriting a new solution from scratch every 3 months [1][2], that, while it solves the shortcomings of the previous tool, now introduces a complete set of new problems. And people that actually have stuff to deliver are always playing catch up and fighting the bugs of alpha quality software.
I feel strongly about this, especially when reading a step-by-step tutorial, that's most probably intended at frontend "newbies", that for example is pushing Yarn: I played with it the other day on a working VueJS application, and got hit by a bug, causing yarn to delete important files in node_modules. My code wouldn't work anymore. Really sorry that I can't find the bug report anymore to prove my point. The workaround was going back to npm.
Teaching people alpha quality software is irresponsible. If you want to teach, or have stuff to deliver, use the battle tested tech. Experiment when you know how the pieces work together and have lots of free time.
2: EDIT: this is a big problem of our industry, it happens in all environments, but the JS community is the worst IMO. Desktop Linux is the second worst offender.
The problem with continuously changing technologies is that it doesn't allow you to become a master of that stack, so your constantly relearning how to accomplish the same thing. It's inefficient. If I build my applications with well established technologies, then I can do it quickly and accurately. Sure, I might miss out on some cutting edge benefits, but my shit works, always.
However, if i switch to JS, I feel like I will have to not only relearn how to do things I already know how to do, but I will be stuck in a cycle of continuing education and won't ever be able to expand my skillset beyond those things.
That's the state of the computing industry. 80% of the continuing education is about learning to do what you already knew how to do in a newer, hotter stack (but not necessarily better). 20% is about learning new paradigms. And I'm being too generous. It's probably about 5%.
Suddenly being a medical doctor sounds much less stressful. I really feel some of us chose the wrong career path. Imagine having high social status, having almost always some meaningful work, all for debugging meat machines that have lots of failure modes, but most of them well understood?
Having experience in both worlds, I can assure you medicine isn't what you seem to think it is. Social status, and income aren't so grand these days, and working conditions are bad for a lot of practitioners. And "debugging meat machines" is anything but well-understood in the majority of serious cases.
I know working with Javascript can be an annoying proposition. I'm maintaining a web app I wrote a couple of years ago in vanilla JS and gotten to be kind of a hairy beast. Probably would be better to rewrite it, but it works and for all the warts at least I know where they are. Maybe I'm just too lazy to take the time and effort to recreate from scratch. I figure by the time I got it working, I'd always be lagging the newer, "better" stuff anyway.
Interestingly, your comments about education have a parallel in CME (continuing medical education). There are real paradigm switches that appear from time to time, but not as much as you'd think. Most changes have to do with small refinements like new medicines that are variations on the current ones, theoretical or research findings, administrative or procedural issues.
So yeah, the really important information approximates the 5% figure you cite, and a significant amount of "updated" info is only marginally different or new, more or less equivalent to the "newer, hotter stack" idea you mention. Sure seems all that greener grass still needs to be mowed about the same way.
I like it too. People vastly over-estimate the complexity of these tools.
As a freelancer, I start a new project every other week or so. It's really not hard to get up and running with these tools. They're also incrementally adoptable: since most of them are loosely coupled, you can get started with a new one without rewriting your whole stack (for example, I first used React with Gulp+Browserify, not I've switched to Webpack).
It's the fact that the entire Javascript community seems to suffer from ADHD and is constantly inventing a new tool that is marginally better than the last.
So for those us who don't do front end development we come back and suddenly have to learn 20 new tools.
> It's the fact that the entire Javascript community seems to suffer from ADHD and is constantly inventing a new tool that is marginally better than the last.
If you assume that the entire Javascript community was one person or one coherent group, then yes. But it is not like that at all. You state this as if a single organization made grunt, then made gulp, then made webpack. This is nearly as absurd as saying "The entire programming community seems to suffer from ADHD and is constantly inventing new languages". People who are using grunt didn't pack-up their bags and move to gulp, then pack up their bags and move to webpack. Rewriting your front-end in a new webframework every 6 weeks isn't a thing that actually happens. That's as absurd as suggesting that after leaving ruby for node, your team left node for golang, then left golang for rust, then finally rewrote their application in elixir.
All these different tools solve different problems, or solve them under different constraints, or solve them in ways that better match their backend languages. There isn't some magical tool that everyone needs to jump to.
Probably a better term than inventing is "standardizing". The community as a single general entity, is constantly changing what they accept is the "standard stack". I don't get to have my safe goto stack of LAMP for twenty years, and then swap out alternatives after research and my needs; the goto stack is radically different every year.
And ofc there's a big push for frameworks and languages over libraries, and libraries get coupled to frameworks, so anytime you do want to "upgrade" to the new thing, _everything_ goes with it.
> The community as a single general entity, is constantly changing what they accept is the "standard stack".
You're operating on a false premise, the community is not a single entity. You don't oversimplify Javascript and pick the "standard stack", you have to do some basic research first. Maybe you need jQuery, maybe you need React. It would be pretty stupid to assume that all web development problems are nails then also assume the latest popular bleeding edge tool is a hammer.
> And ofc there's a big push for frameworks and languages over libraries, and libraries get coupled to frameworks
I don't see any evidence of this. If anything, the source of most people's complaints is that the JavaScript community heavily prefers libraries over frameworks, which means you need to pick several libraries to build a project instead of
Are you sure you have any clue what you're talking about? I regularly "upgrade" parts of my stack without changing "everything." It's a huge part of why libraries like React are awesome.
Rewriting your front-end in a new webframework every 6 weeks isn't a thing that actually happens
I don't think any sane person would rewrite their apps everytime a new flavor of the month tool came out, but all this technical churn must make maintenance a nightmare.
Maybe that's part of the problem. Most people don't start a new project every week, so we get to know the same tools pretty well for a year or two or longer.
"As a freelancer, I start a new project every other week or so."
Yeah - I'm not sure if this is representative.
Moroever, if you're staring a project every other week, you may not be working at the scale/resiliency that most entities need, not even considering legacy etc..
The toolchain churn in JS is too much, especially relative to other platforms.
I like it as well. I have yet to see tech stack that has comparable potential but is less complicated and can be stripped down as low as the web stack if your requirements permit it.
I mean yeah, if you have a big app, complex requirements, there is a bunch of stuff you need to take care of.
However, I would like to see the tech stack that allows you to do the same with less complexity.
It's not like Android (gradle?!, java 6?!, the android api!?) or iOS development is a walk in the park if you want to do anything with production quality.
I'm usually one of those "JS frontend ecosystem is too complex" guys, but I found this tutorial to be quite approachable. Maybe the format of introducing one thing in each section helps?
There was a similar but much more complicated tutorial on HN a while back that I didn't get at all. Most of the explanation was handwavy - "just do this, trust me" - and the entire tutorial was dumped on a single page. Just looking at the scrollbar discouraged me!
I'm kind of surprised to see Yarn in a tutorial already. Welcome to the fast-moving world of JS, I guess?
Many people feel "JS frontend ecosystem is too complex". All of this is usually because of the horizontal complexity than the vertical horizontal complexity. There are just so many tools one should know. As nulagrithom said, all these do their job best ! And if you want to have a good project, you will be better with these tools :) And once you know what they do, they are pretty easy to work with.
Unix philosophy is "Make each program do one thing well", but they've made them once, many decades ago and haven't change them much since. The problem here IMHO is the speed at which it all evolves, and even more the speed at which the old tools become obsolete. You start a new project with the current 'cutting-edge' stack, and within the 6 months everyone switched to something else. It's become a full-time job just to stay up to date with everything that's going on, and that means making architecture decisions is a lot harder. Also, I personally dislike the fact that it forces one to pick a niche. For decades you could say "I'm good in front-end dev" and really mean it, and now it's not possible anymore to be truly proficient in all that's going on, you just have to specialize.
It took my 2 minutes to find a laptop under $500 with 8GB of RAM. My 2011 asus laptop has 8GB RAM. I'm not going to build software with my 2005 Inspiron in mind. Don't expect people to cater to 10 year old machines.
Not everyone has $500 of disposable income, either. Not to mention that very few phones and netbooks (like Chromebooks) have more than 4GB of RAM (in fact, I'm not aware of any in either category except for the Chromebook Pixel line). Lots of people in the real world are stuck with hardware with 2GB of RAM (or less!).
I develop with those users in mind. I don't expect the average HN-reading programmer to do the same (I've long given up on that), but that doesn't mean it ain't a problem.
I also develop with users in mind, which is why I don't care how large my development environment is as long as it brings benefit to them. My original comment was a response to a person who rhetorically asked how big the node_modules folder was after installing a list of dev tools. I don't install my IDE on your phone/netbook, nor do I install my JS dev tools. Who cares how much disk space it eats up on my developer computer? I couldn't fill my disk space unless I spent a week downloading porn. My laptop cost comment was one about developer contributions, based on the belief that we were still talking about dev tools. I won't design my dev environment so that a developer with a 10 year old computer can work with me. Everything in here has been about developer workflow. The user isn't impacted by any of it. In fact, all it does is improve their experience. For an example, I have a hobby app I'm working on in node/angular2, which is an image editing platform.
$ du -sh my_app/
483MB my_app/
$ cd my_app && npm run build
$ du -sh my_app.tar.gz
3.7MB my_app.tar.gz
It unzips to 24MB, 20MB of which are the few node modules that don't play nice with my build system. Spinning it up, it takes ups 62 MB of RAM. I'd hardly consider that earth shattering to a user (the user doesn't download it anyway, it's an api deployed on a server). When I run it in dev mode, it takes up 400MB of RAM. I don't care, because that's what this computer exists for.
Memory is still the number 1 limit I have to deal with, every day. Both on my laptop, and on the server side. It remains highyl relevant exactly because of that kind of attitude.
The issue isn't a single tool. It is when you have a lot of them, and it all starts adding up.
> These are dev dependencies. If they are making it to your server, memory isn't the issue.
Yet you above suggested deploying them somewhere else. Which is exactly what I do because otherwise my laptop is constrained by the heap of bloated tools I depend on.
Not just memory footprint (which is still at least somewhat relevant, and if you've never tried to delete a node_modules folder from Windows explorer you're in for a treat. More Microsoft's fault, but still annoying), but the sheer amount of trust required for all the dependencies. Only one of those tons of dependencies needs to be subverted to do something awful to you. The attack surface is much larger than it is in other environments.
This is 2016 and devices have more memory, that's true. But ignoring memory efficiency is ignoring the basic principle of engineering and I see younger folks tend to ignore that more than olders. Having more memory available does not mean that reduced footprints are not better.
Sure, but I'm also not going to optimize dev dependencies. I care about the prod environment, but when one window of my IDE takes up 4x the memory of the app I'm actually developing, I just fail to find a reason to care about my local environment.
I love the fact that tons of great engineers are coming up with new ideas everyday to make my life as a developer easier.
I love hearing a developer at a daily stand-up meeting saying he's been up all night trying out a new shiny thing and concluding by saying it also solves a big issue we had in our product and here's the pull request (timestamp 4am).
The hype is here for a reason. Hype is nothing bad, being excited about your tools makes your days happier.
I love the fact that JS people are never going to take "No" for an answer, constantly pushing the boundaries of what's possible, and making the web standards improve. I love the rise of functional programming. JS is a playground where mathematical theory and all of its beauty meets practice and the real world. It attracts talented people who bring a new perspective to our field. I love the fact that now I have theorems that ensure my login button will work.
> I'm a little lost at why we're using both Webpack and Gulp though.
Same here. I think one of the huge benefits of webpack is that it actually kills a lot of complexity by allowing you to skip gulp/grunt in most cases.
I think most people do not realize that the JS ecosystem is actually removing complexity.
Most people think the JS ecosystem is overly complicated, when in fact, it's just that in JS the complexity is exposed. This allows us to focus on reducing it. In order to address an issue, you must first make it visible.
Nowadays the trend in JS is to use multiple small tools that solve specific issues very well. We have a complexity in setup in exchange for less complexity in development. I argue this is a good thing, because setup is easy to document and only happens once in a project. Whereas you face development complexity every day.
This part from the tutorial is very significant to me:
> I recommend writing everything from scratch yourself
Yes! Yes! Yes! That's the heart of the JS philosophy: the ecosystem is trying very hard to make you understand what you are doing and why. It's giving you the keys to question what you're told and improve it. It's also why there's so much trolling. It's a good thing, question what seems too complex so that people can tackle the issue.
Please, do keep saying JS sucks, it's exactly what makes it so strong.
Do not use a framework, wire-up things yourself so that tomorrow you can repair it or upgrade it easily.
Do not write your router from scratch. But do connect the standard-issue router to your business logic yourself. Don't let someone else plug it in for you. It'll fit, but it won't look as good as if it were custom-made by a great tailor.
Finally, I love the config files. I hear a lot of trolling about all the config files, but I love the fact that I don't need to tell both webpack and mocha how to transpile JS and can just let the .babelrc tell them and everyone else. It's amazing that you can just git clone something and have all your environment setup as the author intended: language variant, linting... with .eslintrc developers using IntelliJ and atom both see the same messages.
Long live JS, or whatever comes next as we improve it!
"I love hearing a developer at a daily stand-up meeting saying he's been up all night..."
A phrase I heard from a much older, wiser developer: "heroism doesn't scale." If you encourage workaholic behavior don't be surprised if the team starts falling apart, or worse if their families suffer.
So, i'm someone that uses gulp and webpack together. But probably not in the way you think.
Webpack is great as a compiler, but it's not great at being "make". It still needs something to kick it off. And something to setup the environment correctly, run the tests, do the commit for the deploy, run the db migrations, clean the build directory, etc...
So a little bit ago I wrote a tool called `gulp-run-command`[0] that basically turns gulp into a command-line task runner, and it works great.
Gulp sets up the task dependency list for me, most things are command-line tools, and every now and then I use a gulp-plugin (like with mocha) rather than the CLI because it adds some feature over using the tool standalone.
If you have worked in JS for some time, and have an idea what all these tools do, This comment is probably the best tl;dr of what you are going to learn ! Pretty balanced, Just to the point.
I havn't read the tutorial, but looks promising !. Will sure checkout this weekend :)
I think what sets many people off -- including myself -- is that the "recommended" libraries change so often. It's like a joke: "You're still using npm for installing packages? That's SO 2015! Of course you should be using Yarn."
After 21 years of JavaScript, one would expect a little more stability, so that the web app you build in 2016 with cutting-edge technology wouldn't be scoffed at in 2017 and obsolete by 2018.
"You need almost all these tools in other environments -- they're just typically chosen for you in advanced."
+ I don't think anyone is complaining about what the tools do, or necessarily their quality.
The fundamental complain is 'churn'. The stack you see today may be replaced in a year - moreover - it's really hard to tell where the community is going. There are few resources (or rather too many) that can tell you what 'works and what doesn't' etc..
Also - many of these problems should not exist in the first place, and kind of illustrate the underlying failures of the web-browser platform in the first place.
Again - great stack. But it won't last long, and it's very expensive to churn.
Recent comment at a JS meetup form some guy: "I just left a startup where I was the key Angular guy, it was all in Angular 1 - I have no idea who's going to support that now that I'm going considering everything is Angular 2 now".
Reasonable assertion.
Also - I'm not so sure the 'do one thing and do it well' theory is always an advantage. There are many solid platforms where things are really well curated by company ABC. I'd suggest that if they do their jobs well, it's better than a community approach.
Obviously - community vs. monolith is not black and white, and there are advantages to each side, but it would be unwise I think to ignore the problems of constant churn.
Another example - just at MS HQ in Montreal for a preso on React. 100 devs in the room were not particularly excited. They seemed more resigned to it than anything. The consensus was 'yet another thing'? I think there is really a big gap between those pro-shops on the cutting edge - and 'everyone else'. And React is by no means trivial.
Yarn installs packages, much like Gem, NuGet, whatever. Pretty standard.
React is a frontend framework. Not surprising that you'd use one. I suppose you could opt to write a giant pile of vanilla JavaScript instead (I'm assuming you're not using this kit for a simple webpage, which would be silly. We're building a web app, right?)
I'd dare to compare Gulp + Webpack + Babel to your "compiler" in a way. I'm a little lost at why we're using both Webpack and Gulp though. Babel is a necessary evil to ensure we're "cross-platform" in a manner of speaking. These are probably your most "unnecessarily complicated" tools.
ESLint and Flow check your code for obvious mistakes. Reminds me of IntelliSense and compiler warnings. Again, pretty standard stuff.
Mocha is a test runner and Chai is an "assertion library". Chai isn't a big deal: expect(foo).to.equal('bar'); Simple stuff.
Feel free to scoff at Redux and Immutable if you'd like. Probably unnecessary.
Am I the only one that likes this ecosystem? I feel like it follows the Unix philosophy of "Make each program do one thing well". You need almost all these tools in other environments -- they're just typically chosen for you in advanced.