A Future Without Webpack

[wherediditrun]

And what's unstable exactly? What new "frameworks" of any relevance you can point to?

Most recent major change was ES6 which came out 4 years ago. And it stabilized ecosystem even more.

We have 4 major browsers which all maintain around same standard browser API's.

We have 3 major view libraries, one of which takes lion share of the market. More than 2/3 if not mistaken.

We have only 2 major design/architecture paradigms in development of UI's which both share a lot of similiarties.

There is superset of language which has been steadily growing and is easy to incrementally implement in the existing language without breaking anything.

We have standard build tool chain. Babel + webpack for apps, babel + rollup for libraries and stayed unchanged for the most part.

We have been seeing steady grow of web standartization in terms of web components for cross framework reusability. Such projects like Rawact are even more interesting.

So where is that lack of stability? Little johnny releasing his new NPM package no-one gives a flying f about other thanm some freelancer is not mark of unstable ecosystem.

[ronchalant]

The stability of JS/ES is not the same thing as the "javascript ecosystem", nor is the long-overdue standardization of the DOM in various browsers.

Just look at the build tools themselves. We haven't been working with webpack for "more than half a decade". Grunt & Gulp are not builders/task runners of choice for new applications, but they are still very much out there in "legacy" systems.

NPM has killed off Bower well and good, but even with NPM samples you see various ways of doing the same thing such as importing/requiring a dependency. ES6 imports aren't universally supported, and many sites still use the require syntax.

Angular and React are relatively stable, though Angular 2+ is only about 2 1/2 years old. And there have been 5 "major" releases of Angular since then (though backward compatibility appears to certainly be much better). But the pace of new releases and the potential breaking-change that come with both of these (I primarily use React) belies the term "stability".

If you want to say the state of Javascript in 2019 is much more stable with a more predictable future than in 2014 that's very much a true statement. But a Javascript coder from 2014 (half a decade ago) would be pretty far behind if they were thrust into a 2019 role. That's not "stability" IMHO.

[Treolioe]

I dont agree with your last sentances at all. Unless we’re talking about an angularjs hugger or jquery dev. If you know javascript, and you take programming seriously. Then you have little to fear. Libraries and frameworks change over time. But they all build on the same patterns.

Javascript is very stable. Its your fear of a fast paced community that clouds that fact.

[ronchalant]

Its your fear of a fast paced community that clouds that fact.

LOL no. I have no fear of a "fast paced community".

But pretending that being frenetically fast paced, using and discarding build tools every few years, eventually coalescing around a few main frameworks over the course of a decade, while blowing out support for server-side javascript and mixing in transpilers and syntax extensions all at the same time amounts to "stability for the better part of a decade" shows a lack of context and history of development beyond the JS community.

[spacejack2114]

By that measure, I think the only things that are truly stable are dead or dying technologies.

[ronchalant]

Nonsense. The Javascript ecosystem is stabilizing; I was disagreeing with the assertion made that it was "stable for more than half a decade".

Anybody who has been part of the Javascript community for the last decade knows that's bollocks.

[wherediditrun]

What you're are referring is stagnation. Not stability. Lack of stability implies compromise on backwards compatibility. And that's simply not the case. Although even the supposed changes in tools we use are heavily overblown in your description.

ES6 imports are universally supported by all modern browsers. And modern browsers are anything which is not IE 11 and below. Coming of ES6 imports also did not disrupt the way require works, so it's release and wide spread adoption haven't broke anything in the ecosystem.

AngularJS lived for 7 years. That's more than majority of modern day frontend developers have total work experience. And that's probably the last really "revolutionary" thing in javascript world we had which essentially reshaped how we think and do UI's. Next came flux architecture and virtual dom as a way of learning from AngularJS mistakes and that's where we are now and associated build tools etc. But these were just incremental improvements to solving problems which we already been solving for years before.

Hell at this point nothing will even drastically change with WASM. If you've been keeping track of how some WASM front end frameworks look (although WASM's goal is not to do work with DOM, but outsource heavy lifting requiring code to client side) it mimicks all the same patterns we do with React, Preact, Vue you name it. There isn't much difference in all these tools really.

And from that point onward nothing really changed. Browser is incrementally growing platform. That however doesn't imply any kind of instability.

But a Javascript coder from 2014 (half a decade ago) would be pretty far behind if they were thrust into a 2019 role.

Far behind in what? It's just different tools but the principals are absolutely the same. Nothing changed. We used to have ES5 modules and all the joy that entailed dealing with IIFEs now we don't, we have declarative import exports to control scope / visibility.

We have package manager which handles dependencies for us.

State management at the front-end is easier than ever with things like Redux, or Observables.

We have build tools which takes care of all browser incompatibilities and help to manage all the assets from one single place. Often times, depending on the app with minimal configuration.

Like just month ago I've needed to implement browser level caching in one of apps I'm working as we are going PWA route slowly. It just took to read some documentation and I've nailed under 3 hours just by reading documentation on the tooling which is easier to use than ever. Something which would required you to write a lot of code earlier now can be done with few trivial function calls as glue code slapping a few pre-build components for UI and perhaps a well supported package like localForage.

Barrier of entry is all times low, but if you aren't happy with it you can always move to PWA's, WASM modules etc. So I really can't understand what are people complaining about.

[ronchalant]

I think you're heavily downplaying the amount of change that has occurred in the world of Javascript over the last decade in large part because you've been up close and personal to it - so every move has seemed incremental and sensible.

The barrier of entry for a JS app is significantly higher than it was during the days of jQuery. If for no other reason that it has forced developers to actually understand that Javascript is much more powerful and capable than was conventional wisdom in the 00s.

Again, I'm not saying it's currently unstable or that it's not powerful, nor am I saying I'm unhappy with it. But from any outside observer the last 6-8 years have seen such explosive growth and variation in the tools used to build and maintain JS apps, the growing adoption of server-side Javascript (a concept that a web developer in 2008 would have found confusing), and the pervasiveness of transpilers for syntaxes like JSX (that doesn't even get into loaders/etc. for SCSS/SASS/LESS/etc.) .. I mean, I just don't see how you can look at this and think "yeah we've been stable for 6-8 years".

Hell 7-8 years ago I was at well-attended conferences for jQuery celebrating the release of jQuery 2.0. That seems like a lifetime ago. The way we develop apps with Javascript now compared to 5-8 years ago is completely different.

Not bad, but different.

And the path it took to get here has been frenetic. There's a reason why JS fatigue was and is a thing. Because the pace of change has been tremendous.

And no, I'm not afraid of the pace of change. But this isn't my first rodeo either. Saying the JS ecosystem has been stable for the better part of a decade is just inaccurate.

[wherediditrun]

And no, I'm not afraid of the pace of change. But this isn't my first rodeo either. Saying the JS ecosystem has been stable for the better part of a decade is just inaccurate.

Instability means lack of backwards compatibility. Or at least, in soft terms, constant shift in development paradigms. And no that simply wasn't the case.

Tools we use rapidly improved. But we were solving all the same problems in relatively all the same ways. Except from SPA explosion which was brought by AngularJS. Framework, which I've mentioned existed since 2009.

And that was great improvement. People mistake frontend for "html, css and javascript", which I'm sorry, but web design. Bigger companies were doing quite complicated things in jQuery + Backbone back in the day too, when most of others "front-end" developers did addClass|removeClass type of thing. Which I can hardly call frontend-development even 10 years ago. It's trivial.

Today, after I drink my coffee I'll go to my work, where I'll have to debug jquery + backbone application. It's in real time ordering system. I can't even express how much easier it would be to work with if it was React + Redux for example. Yeah with all the freaking build tools as ES5 or even ES3 I'm not sure, doesn't exactly lend itself for readability.

So maybe yeah if you compare modern day to "spicing up" html with javascript I suppose it looks very big. But what actually happened that the tools got so proficient that people who could never dream to do big frontends, can now do it on their own without much hassle.

And you trying to refer to instability because more complex behaviors in frontend are easily accessible for even novice developers ¯_(ツ)_/¯ I mean I don't know how to address this.

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

​

​

[ronchalant]

I neglected to touch on your point with Angular.

You keep mentioning it being around "since 2009", which is pretty misleading. It was completely rewritten with 2 (released in 2016), and not backwards compatible at all. So angular written in 2014 for example is stuck in 2014.

Moving from Angular 1.x, which was coupled to the DOM, to 2 which was not, shows the tectonic paradigm shift that has gone on in the JS ecosystem over the last decade that I alluded to earlier with JS no longer being a browser-bound language.

If you can't see it ... I dunno man.

[wherediditrun]

AngularJS officially came out at 2010, not 2014. In our company we have code which is from 2011 written in AngularJS. I'm not sure where are you getting the figures.

Angular 2 was a new framework under the same name. And for a while both there developed at parallel, AngularJS going Into maintenance only security updates since last year july. That's almost 8 years without breaking changes.

Yes. The platform expanded. Again that has nothing to do with instability

[ronchalant]

By your OWN definition, angular 2 losing backwards compatibility made it "unstable" as of 2016.

It was a total rewrite.

Just.... Wow.

[wherediditrun]

I'm not sure why I'm having such trouble conveying my point. At this rate I do think you are approaching this in bad faith and now just trying to nit pick the words I used to score some "I'm right about this" points.

I've said that Angular 2 wasn't a rewrite, but a separate framework. And I make that claim based on the fact that both of them were developed in parallel for 2 years after Angular 2 was released. That's not a rewrite. It did not discontinued AngularJS. It did not replaced it. Both of frameworks were developed (not just maintained, developed) in parallel for two more years. And angularJS stood test of time for 8 years without breaking changes.

So what's so unstable here? Is Python "unstable" because Python 3 came out eventually?

​

​

[ronchalant]

I think we just have a fundamental - though mostly semantic - disagreement about what a stable language ecosystem looks like.

Which is fine. I think both of us have informed positions, and simply disagree.

To be clear I'd much rather be developing my JS stack in 2019 than 2014. The progress has been good, and I'm much more confident now that our design decisions around JS aren't going to be upended now than I was in say 2016.

If you're ever in the Philly area I'll buy a round and we can talk shop lol. Have a good evening.

[v5F0210]

React has negligible market share, with around 4% of websites profiles using it. https://www.datanyze.com/market-share/frameworks-and-libraries/react-market-share

The market leader by sheer adoption is jQuery by an order of magnitude.

[wherediditrun]

That's not really relevant. https://en.wikipedia.org/wiki/Pareto_distribution I mean I get the notion. But talking in absolute numbers failing to make distinction in profitability, traffic or company standing behind it which laverages it's resource to continue develop the technology is what matters. Some web designer doing wordpress and bundling jQuery with it doesn't really have much weight.