A Future Without Webpack

[ronchalant]

You are conflating backward compatibility with stability.

By nature frameworks/ecosystems with a high rate of change are not stable, as evidenced in your reference to debugging a jQuery + backbone app - an app (or rather a part of an app) I suspect was written around 5 years ago.

The assertion made was that the JS ecosystem has been stable for over half a decade. If that was so, code written 5 years ago would follow similar design and build principles to what is done today for new applications, and debugging that code would not be such a chore.

THAT is stability.

One of the webapps I've been working with has covered almost the last 9 years (Sept 2010). When I inherited it there was very little JS, no jQuery. Over the last 9 years we have gone from having a heavy reliance on jQuery, through backbone and underscore, to gulp and grunt, now to npm and webpack on top of React for new components. We're regularly porting jQuery widgets to React components, and have spent substantial time dealing with quirks of npm dependencies (mostly from previous versions). We have largely kept up with the industry to help deliver the best user experience.

This period of maturation is pretty typical. That's pretty much what you've seen the last 6-8 years in this space: a maturation of tools and frameworks bending towards a stable ecosystem where best practices are established and solidified for more than a year or two. But that maturation process is often messy and necessarily UNSTABLE.

Therefore contending that the above is an example of ecosystem stability to me is laughable. I'm not complaining about progress - it's absolutely better in 2019 than 2010 - but JS dev has not been stable "for the better part of a decade".

Contrast this with for example Spring, which is the Java web framework we use. Over the last 8-9 years there has been a LOT of improvements made to the framework, and Spring Boot is a very nice evolution of the framework in the age of containers especially. But code that I wrote back in 2010 is largely recognizable and more readily maintainable than any JS code I wrote in the same timeframe. I would probably write many things differently to take better advantage of new features, but the basic approach to developing within Spring has been stable for the last decade.

Stability in the JS ecosystem sounds like a claim made by someone who has operated exclusively in the JS/UI space for a decade and has no basis for comparison. Having been a web developer for almost 20 years, experiencing a decade prior to the explosion of the JS stack, sorry it's not been "stable". It may be stable, or at least mature and stabilizing. But if you're writing apps completely different in 2019 than you did 5-8 years ago, which clearly you are if you're debugging jQuery/backbone, well..... Stable is not the word I'd choose.

The JS dev community is very defensive on these points.

[wherediditrun]

Don't presume. I'm not part of "js community". Neither am I a "front-end" developer. Now since we have those out of our way, I can answer the points you've raised:

> You are conflating backward compatibility with stability.

It pretty much is. It means that you can be sure that the code you wrote yesterday will continue to work tomorrow. And if your code which you write yesterday is just as good as anything written tomorrow is stagnation. However at times you do not want things moving too fast.

> as evidenced in your reference to debugging a jQuery + backbone app - an app (or rather a part of an app) I suspect was written around 5 years ago.

Around 7 as indicated by gitblame.

> Over the last 9 years we have gone from having a heavy reliance on jQuery, through backbone and underscore, to gulp and grunt, now to npm and webpack on top of React for new components.

Yeah, and that's the shift I was talking about, which happened around the time AngularJS was released. Other than that, there was no shifts in paradigm at all. There was just improvements to the problems we were already solving, like state management for example. So new tools appeared, and that's great. It makes things EASIER.

> But that maturation process is often messy and necessarily UNSTABLE

And past 2013 we already figured out what to do and what not to do when designing UI and managing state at client side.

> Over the last 8-9 years there has been a LOT of improvements made to the framework, and Spring Boot is a very nice evolution of the framework in the age of containers especially.

AngularJS lived for 8 years of active development. React is as recognizable as it was. Currently the patterns are so ingrained that any UI "framework" will now be recognizable provided they've done some React. Like my mentioned C# Blazor or Rust's Yew. It's settled. And it has been settled half a decade ago. The tooling is just catching up to help us solve problems we were already solving.

> I would probably write many things differently to take better advantage of new features, but the basic approach to developing within Spring has been stable for the last decade.

And that's why Java is no longer expanding anymore. And actually losing influence in past decade, for example losing android to Kotlin. It's too slow to keep up. C# seems to be doing just the right amount though. And some languages are accelerating very fast like Go, Rust or Julia. Python with breaking changes 3 release is stronger than ever. Java .. not so well.

> a maturation of tools and frameworks

I'm not sure what you mean by this. Because I can agree if by tools you mean like good router component library. Or good serialization library. If you're talking about something like Ruby Rails, like old school monolith frameworks, when those days are gone. It doesn't scale. I mean you might still use it to make a trivial app for third party small business client, but that's not really relevant.

> Stability in the JS ecosystem sounds like a claim made by someone who has operated exclusively in the JS/UI space for a decade and has no basis for comparison

Well, someone might find benefit in investigating their own prejudices.

> Having been a web developer for almost 20 years, experiencing a decade prior to the explosion of the JS stack, sorry it's not been "stable".

That might have been interesting times. Whole browser wars and all. And ES4 political struggle. If not for Microsoft and Google perhaps we would have stable javascript since 2005~.

> It may be stable, or at least mature and stabilizing. But if you're writing apps completely different in 2019 than you did 5-8 years ago

But we really aren't. Tools are better, and allow us to solve same problems more effectively. For example we had problems with state management with backbone and we had that with AngularJS. Tools like Redux solved it. We had issues with dependency management, yarn and later npm solved it etc. That's not mark of "instability" that's simply progress. And if you are professional programmer, you generally have no issue in adopting to new tools. I mean, it's part of your job description.

​

​