I appreciate the effort, certainly do. But, and this a big but: the amount of tooling, libraries, complexity and systems needed for a "modern" web app is almost comical at this point.
https://facebook.github.io/react/blog/2016/07/22/create-apps...
It's surprisingly full featured. Testing, ES6, CSS, live reload dev server, building for production ... everything you need for the majority of React based web app builds. Literally up and running in minutes. Also you can just offload all of the cognitive burden of selecting tools to people much more qualified.
Judge the whole scene by one GitHub project if you will, but the "boo hoo web development is too complicated" meme is getting a bit old now. It's mainly coming from a place of ignorance. Yes it's been a journey for web development over the past few years, but there are powerful and simple tools available now that other platforms and communities could learn from, rather than just disparage.
The entire WPF ecosystem for example was developed and refined in a fraction of this period. Heck even .NET itself is only 14 years old.
That said, treehau5 has a point. This shouldn't inherently be an issue in devDependencies, unless there are individual problems. The end product is what's important.
It gets a project up-and-running fast and contains basically all you need. It's not a "boilerplate" that dictates which libraries you use (in terms of Redux, Router, HTTP, etc.).
So here's the interesting part: it basically turns your build into a dependency, with all the pros and cons that entails.
CRA is regularly updated so if you choose to, you can keep your project in sync with the latest fads/features in builds -- snapshot testing, minified production build, hot module reloading (coming soon), etc. Of course, like any dependency, there's the risk of breaking changes.
It's a tradeoff, but a pretty good one in my opinion. Having been part of a couple projects that started in Grunt, then moved to Gulp as the Grunt build was getting slower... it's painful to have to retool the build system, basically ever. "Set it and forget it" works great for a few months, but there always seems to be some new trick to make things faster/better/etc that your tool can't do.
I really like the "build as dependency" idea.
https://github.com/facebookincubator/create-react-app#conver...
Angular (1.x) might not be "cool" anymore, but it can be pretty darn "minimal" to set up: https://github.com/roboprog/ang-prog-enh
(above not quite done, it's for a presentation I'm going to do in December, but it's pretty close)
React works better for many things - server side rendering for SEO; endless scrawling wall of chunks of more-of-the-same (social media...) - but it's not "simple".
BUT, the author might want to address the "elephant in the room" that there is a certain amount of necessary complexity if you want to meet certain goals.
E.g. - I (only) want to read some hidden link data in the original page DOM, then load some page fragments that are taking longer to generate.
Yeah, there's a lot of evil lurking in Java-land, but that doesn't stop people from having to use all those things, either.
> You might pick Ant, Ivy, Docker, Dropwizard, Guice, Jersey, Jackson, Mockito, JUnit, etc.
With javascript, I need: webpack.conf, package.json, .babelrc and god knows what else. Seems like every piece of technology around javascript (transpilers, packers, dependency managers) requires another layer of configuration, another set of CLI commands, and another waste of time trying to figure out why it doesn't work.
But there are other tools that are much simpler. One example is the Dart programming language. I know it's not very popular here in HN land, but the experience is really really nice. You have a fast, powerful, concise, sane and optionally static typed language with awesome tooling (debugging, introspection, profiling, package management) and great support from Google. All this comes in a single easy to use installer. The only extra thing that you might need to download is a plugin for your favorite editor or IDE. Dart, of course, doesn't enjoy all the hype that the JS ecosystem has, but the barrier of entry is really low, and the tools are extremely polished, stable and very production ready. I recommend anyone who is not scared of leaving the hype train to give it a try.
And I think that's the point many are trying to make. It's not overly complicated, it's just that people are trying to use every tool they read about without understanding it or why it was created.
If you are making a website for your restaurant, you don't need react, webpack, babel, sass, etc... You need a few hundred lines of html and like 20 of javascript and you are good to go. But if you are building a video streaming platform, then the extra complexity will most likely pay off.
If I replace "Java" with "javascript" I get:
> Javascript really shines better in the backend long-lived services realm.
If you treat JS like a toy, it's gonna act like a toy.
Tons of companies are very successfully using javascript for long-running processes on the server side. And it's not exactly showing any signs of slowing down.
Then they rewrote everything from scratch because as it turns out, javascript on the server side is still pretty damn awful performance wise.
Like most things in life, use it in moderation, and you'll end up much happier. But if you take absolute stances on things, you are only hurting yourself.
For the benefit of folks unfamiliar with Java, Docker is not necessary nor tied in any way to Java. The majority of Java is not deployed on Docker, and Docker is written in Go. In fact, the Java mantra "write once, run anywhere" is accomplished by the JVM, so you don't need Docker. You would need it for other languages not on the JVM.
Also, Dropwizard is just a bundle of libraries (most of those you mentioned), so you don't need to include both Dropwizard and a list of libraries that it includes.
Maven, Dropwizard, Guava, Guice, JUnit, Mockito.
(Jersey and Jackson too, but those are included in Dropwizard so ideally you don't need to care about them) Also, ideally, installing dropwizard, guava, guice, junit and mockito consist of just adding 5 lines of XML to the pom.xml file for each - no configuration needed.
Of course if you fall out of the ideal world, things can get ugly. The horrors if two dependencies insist of using incompatible versions of Jackson but Maven insists that you can only use one version of it in your project at a time...
It is no surprise that businesses don't want to spend an extra 20% development time supporting 0.5% of web users. At some point, it becomes a problem for the user - you cannot support everyone.