The create-react-app tool from Facebook lets you create a "modern" (air quotes yours) web app with one development dependency and zero configuration.

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.

I'll add a second vote for create-react-app; it's a great tool.

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.

Say create-react-app stops being updated / maintained in a year or so, how hard would it be to "untangle" my project from it? With Javascript communities moving so fast, I worry about being left behind, or not being able to update when I need to (or the inverse, not being able to stay on a stable version)

Just one command to decouple your project: "eject"

https://github.com/facebookincubator/create-react-app#conver...

It's funny, but if some of these people griping about web development tried to unpack their favorite enterprise framework, like Spring MVC or whatever J2EE/.NET architecture they are running, there would be way more packages and bundles wrapped up together. It's just the web is finally getting to a good place.

Yeah, difference is between a "standard library" with a million components, and a million independently distributed components. With the usual tradeoffs between centralization and competition.

How do you think you get to a standard library? How do you package the best tools when you don't know what the best tools are?

How long do you think something like that should take? It's already been 25 years... I think it says something about the browser ecosystem and the language itself.

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.

I don't think that's really a fair comparison. I would argue that you should start counting from the adoption of UMD modules and npm for package management, since a universal package format and dependency management are requisite for an ecosystem to get of the ground.

Languages with one single corporate implementor obviously will centralize and standardize their library. Languages with a bunch of competing implementors stay fragmented. JavaScript is a lot like C++ in this regard.

Javascript development as you see it today started budding with Mootools, Prototype, jQuery, YUI, etc. Wasn't until the early 2000s that the concept of unobtrusive javascript was even a thing. Then bundling assets came, asset pipeline concept from the rails world got popular in javascript land, then you had all the grunt, gulps, webpacks come into the picture -- Point being .NET came out in what, 01? So Javascript has a few more years, I think we will be in a good place in a couple of years. Besides that point, how much work behind the scenes before .NET was even ever released to us was going on? How many man hours of development was put before that first public release? My guess is a lot more than we think.

The "one dependency" quoted is "react-scripts"[0], which just acts as an effective meta-package for auto-including 45 other dependencies.

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.

[0] https://www.npmjs.com/package/react-scripts

Of course it's coming from a place of ignorance - that's where all new devs start, right? This one is perpetuated by the fact that whenever a dev pokes his head into the web dev world, the tools are different than the last time they checked.

Not that I'm not using JavaScript to do things, it was never meant to do, but I don't know, using "modern" or "comprehensible" in same sentence with "JavaScript" always makes me giggle.

There's nothing modern about a website that does nothing without JavaScript

Describing that collection of tools as "minimalistic" was indeed a touch of irony.

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".

...and I'm just sitting here, using jQuery..

And that works well for some use-cases, as well.

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.

I guess I should have said it is helpful that somebody is putting together a tutorial for what they feel is a useful path to a certain destination.

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.

Yeah that's awesome! I still reference the Angular seed project whenever doing a quick front-end for a prototype.

Are you sure it doesn't seem that way to you because you're less familiar with the ecosystem? Compare it to a Java backend. You might pick Ant, Ivy, Docker, Dropwizard, Guice, Jersey, Jackson, Mockito, JUnit, etc. I don't consider that to be radically less complex than the front-end stack proposed here -- but it just seems that way because a lot of those are "de facto" tools.

  > You might pick Ant, Ivy, Docker, Dropwizard, Guice, Jersey, Jackson, Mockito, JUnit, etc.

I would pick maven, and add the rest as dependencies inside the pom.xml file (the only configuration file I need to worry about). It would take me about 5 minutes and then I could import the project into IntelliJ IDEA and hack away. I can write a tutorial about it in a single blog post, together with the necessary commands to build, test and deploy the artifact.

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.

Java is no less complex indeed. I'm just starting to use its ecosystem and I definitely think it has a lot of complexity.

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.

> Compare it to a Java backend. You might pick Ant, Ivy, Docker, Dropwizard, Guice, Jersey, Jackson, Mockito, JUnit, etc. I don't consider that to be radically less complex than the front-end stack proposed here -- but it just seems that way because a lot of those are "de facto" tools.

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.

Oh sure, let's pick on the fat kid :-)

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.

A more realistic list would be:

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...

The thing is - other platforms have a 'happy path' that covers a lot of use cases and is straightforward to setup and use. JS, similar to C++, does not have this.

It depends on what you're building. I think Java really shines better in the backend long-lived services realm. If you're just writing something that doesn't need any fancy "web" layers plain Java in a plain Eclipse project is all you need to get going. Nothing more. You just need to know how to type and what you're trying to do and most things you want to do are very easy to accomplish.

You can replace java with javascript and your sentence is still 100% true.

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.

Javascript is a scripting language for the browsers. Its original purpose was to make dynamic webpages by allowing browsers to modify their content according to some basic scripts.

If I replace "Java" with "javascript" I get:

  > Javascript really shines better in the backend long-lived services realm.

You realize how ironic that sounds, right? No matter how many language improvements, transpilers, builders, etc. you throw at it, javascript will always remain, at its core, a dumb scripting language for browsers.

Well I can't say I agree in the slightest.

If you treat JS like a toy, it's gonna act like a toy.

Treating it as something else won't make it something else. It will just require a "minimal" stack of 10 other technologies.

Again, you don't need to believe me, but shoving your head in the sand and pretending it's not useful isn't going to do you any good.

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.

Mhm, they have been.

Then they rewrote everything from scratch because as it turns out, javascript on the server side is still pretty damn awful performance wise.

Beats the hell out of Python or Ruby in that department. But regardless, absolute speed isn't the bottleneck in most situations, and in those cases trying to force JS will end you in a world of hurt.

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.

I've never been a front-end guy, and now the barrier grows with all these frameworks to make amazing applications still holding me back. Plus the fact that if I have NoScript installed, all my work is now pointless. I hate going to websites that literally don't work @ all if I have no JavaScript enabled, with the exception of HN and those rare sites that have minimal JavaScript in use.

> I hate going to websites that literally don't work @ all if I have no JavaScript enabled

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.

Progressive enhancement isn't about people with JS turned off. It's about resiliency to failures. That might be network congestion, it might be a mistake in your code, or something else.

Except they could spare 200% development time with only HTML+CSS. Many times the real motivation is monetization. Simple sites like HN that don't get revenue from readership don't need Javascript.

Agreed. Why spend more effort making sites less usable for everyone? If you keep things small and simple, you spend less time developing and they are more resilient

In fairness you definitely do not need everything listed here to have a perfectly fine web app. I think it's more beneficial to add in things when you find a use case for it. You probably don't need 3 unit testing libraries, you don't need Redux to use React, nor do you need Immutable to use Redux.

What's comical (or sad, really) that things built with this often are not even web apps.

I agree, all you really need is webpack and vuejs

Once you get an application set up for the first time you don't really have to change it much, unless you want to take advantage of new features in the browser or Node.