I see this same, tired old meme in every thread about web technologies.

It's funny to me that certain people are so disdainful of the churn in web development on a forum dedicated to "hackers". Web application development is hard, and the reason why there's so much churn is because smart, inventive people are constantly finding better ways to do things. Things aren't just resetting from scratch every 18 months. The web apps I'm working on today are way more modular, composable, testable, and maintainable than the ones I was writing as little as two or three years ago. Just because Java systems development hasn't changed significantly in the last 5 years doesn't mean Java devs are any more or less reasonable developers than web folks.

> "... the reason why there's so much churn is because smart, inventive people are constantly finding better ways to do things."

It also follows that at some point, these smart, inventive people will come up with fairly stable frameworks that are sufficiently flexible and powerful to accommodate most of the problem space out there. It is reasonable to ask if such a point has been reached...

Depends on the space.. for example, Express has been pretty stable.. Angular 1.x has been as stable as anything else for the most part... Node's mostly been progressive additions, and features from engine updates since 0.10... npm has been pretty stable since node 0.10, though there's been significant advancements since npm 3 came out.

Browserify -> Webpack has been noisy. Babel 5 -> 6 equally noisy, but better for moving forward

Today, I think webpack, babel, react, redux and fetch cover a LOT of ground for client-side dev. There's a few other bits around that, and I think CSS tooling is starting the a similar shakeup to node's tooling options.

In the end, almost all the JS features I care about seem to be at stage-3 now, so who knows when they'll be in the major browsers.

JavaScript has been around since the 90's; a quick scan of this page reveals around 2 dozen JavaScript technologies. The only solution is to remove JavaScript from all browsers and replace it with Java.

Try GWT ;-)

> The web apps I'm working on today are way more modular, composable, testable, and maintainable than the ones I was writing as little as two or three years ago.

The better question is: are the apps someone with two or three fewer years of experience than you more modular, etc?

My experience is on the backend rather than the frontend, but in that domain, at least, system quality is still way more about developer maturity than ecosystem maturity. You can figure out a terrible, hard-to-maintain lazy way of solving today's immediate problems in any language.

I think the problem was the hard-to-maintain lazy way was usually the most obvious. There was so much momentum behind the quick-and-dirty imperative DOM approach that it was hard to do anything else. For example, you could totally use Backbone to construct modular, refactorable views -- but in practice everything would devolve into DOM-munging event-driven spaghetti.

I think one reason why React is so popular is that it forced you into an object oriented approach whereas before many developers used innerHTML everywhere. It is possible to write object oriented, structured "class" based vanilla JavaScript with imperative DOM manipulations though, witch is more performant then popular frameworks.

"I think one reason why React is so popular is that it forced you into an object oriented approach"

And yet React's claim to fame is that it popularized techniques other than OOP, which was plaguing the JS world up until recently.

Right, it's interesting react had a goal of eliminating xss vulnerabilities so common with the innerhtml approach.

I agree that a lot of the churn is each generation (a generation here seeming to be about a year) of tools learning from and building upon the former. Obviously the churn is continuing since developers realize that the tools are quite "there" yet. My hope is that some year we will finally reach "there" (not perfection, but highly good enough) and the churn will slow down to the point that perhaps the generation time period will stretch out to five years or so.

Well, most of the features I care about in JS are in stage 3 now. Webpack 2 will get the tree shaking, and babel seems ready to work with both. It think the CSS options are next in line to see some shakeup... I've been liking what I'm seeing from JSS, though I still use mostly sass at work.

What is your current recommended or dream stack?

Currently my go-to is: React, Redux, Typescript, CSS Modules (optionally with Less) built/managed via npm and Webpack. The real beauty is that everything is well-encapsulated. If I decide one component absolutely needs to use jQuery for some reason there's nothing stopping me as long as the top-level API is still React.

Nice! Why ts over flow?

Momentum, mostly. DT/typings/@types are surprisingly comprehensive and with 2.0 typescript supports strict null checks which was the biggest flaw in my opinion. I've also unfortunately become pretty familiar with some of the obtuse concepts in typescript (e.g. extending module definitions).

I'd love to give Flow a try -- just waiting for the right opportunity.

Awesome, glad to hear they are doing such great work. Thanks for sharing your valuable insight!

> Web application development is hard

Replace JavaScript with Java in all browsers and make it much easier, dependable, predictable and reliable.

Well yeah, that'd be great. But the unfortunate reality is Javascript is the lingua franca of the web and we have to make due until there's a reasonable alternative.

Furthmore, it's not even JS that's really the problem. It's the entire JS/DOM/CSS stack.

I like the DOM, basic CSS is fine. The twisted stuff some people do with CSS I'm not fine with but yeah I know. JS isn't going away, what irks me the most is the naivety around trying to push it to the backend. It doesn't belong in the backend when the frontend story is so messed up.

Backend JS is not perfect by any stretch of the imagination, but if you limit yourself to plain data and functions and write simple code, it can really work nicely for getting stuff done and iterating on an idea.

I don't think the churn has really settled down, what makes you think that? The idea that framework lifespan only lasts 6 months was always exaggerated.

Some forms of "churn" are also called "progress". Is the current crop somehow better than the previous?

It's not so much that churn has been greatly reduced, but that the worst churn has started to be centralised and hidden behind tools like `create-react-app`.

There will still be more churn as people come up with ways to be more productive, however it will be hopefully concentrated in areas other than build process tooling.

You're spinning this as a positive thing, but the fact that a UI library needs its own build tool does not speak well to the state of front-end development.

Specifically the fact that we still don't have modules or widely-deployed http2 is what makes the build tool complexity necessary.

I wouldn't say that was spin, I said that build complexity is likely going to be handled by fewer engineers. The underlying problem still exists but less people need to put their oar in: that's bittersweet.

You're pointing to create-react-app as a solution to JS churn when it was just created 2 and a half months ago.

The fact that people keep thinking that a 2 and a half month old project is the solution to all of their web development problems is exactly why there's so much churn.

Every new tool overtakes the previous generation by being superficially more simple, only to add complexity of its own over time until the next generation repeats the cycle. It turns out the complexity is there whether you acknowledge it or not, and over time your leaky abstractions will burst.

I don't think that will happen with create-react-app since its intention is zero customisation.

You can't generate more complexity with a tool that reduces opportunity for developer choice.

A basic example is that a starter app would normally require you to connect 10s of libraries together just to get started. It is difficult to argue that not having to do so is actually more complex.

Create-react-app is a great idea, but I found it really didn't cover enough use cases.

I remember building Windows ui apps 10-15 years ago, and that definitely needed a build tool. Http2 might be great for module loading, so things don't have to be bundled, but there's lots of unsupported use cases right? Css encapsulation, autoprefixing, hot reloading for dev, compiling features not yet in browsers into js versions supporters by browsers etc.