My previous job was on a product that used CoffeeScript and Backbone. As a stereotypical front end hipster, I was worried at first. I thought: "This is really old stuff in JS time. There are shiny new things out there". But I soon saw that while it would be more fun to use a new framework/language, the old ones are _totally fine_.

CoffeeScript was last updated a week ago. Backbone was updated several times last year and 1.4 is expected some time soon. There are online communities, there is documentation, there are answered questions on stackoverflow. Yeah, everything feels a bit old, but there won't be breaking changes to the API every few months and that blog post from 2015 that solves your exact problem is still useful!

Try looking at it like Angular is a language, not a framework. Sure, there are fancier ones coming out all the time, but that doesn't mean you have to switch every time that happens. The one you know has a bunch of apps built in it, you can still learn about its intricacies and there will be jobs for you for quite some time.

The code has got quite complex over time, and I strongly suspect I would have gone mad if I had used a different framework. I used to wonder why the hype over react, vue, angular etc.

The technology itself doesn't need to be new, exciting or practical. All you need is sufficient marketing $$$$$$ backing it.

I saw so much flawed frontend code which wasn't written by bad coders but by people which try to use always the fanciest and newest thing out there. Even if the docs written in marketing language claim otherwise, there's always a learning curve and it doesn't make any sense to switch the framework as soon as the learning curve getting flat.

It don't even use Angular's D.I. to test things. We don't have any tests in our app, what would you even test? It just displays data it gets from various sources.

But this:

    angular.module('...')
      .controller('BlahController', function(a, b, c) {
        'ngInject';
        ...
      });

    var a = require('a');
    var b = require('b');
    var c = require('c');

    exports.BlahController = function() {
      ...
    }

If you want to base your future on something you already know, you're in the wrong profession.

I met many people who bet on it, but most of them, even the 'fanboys' didn't seem to be 100% convinced of it.

"We panicked multiple times, bit it always turned out we were wrong and just didn't do things the Angular-Way"

Ember, for example, is kicking it for a much longer time, even with fewer ppl using it.

https://github.com/thewhitetulip/Tasks-vue

Vue.JS is great to use!

Polymer's got the BEST router system however. It makes the URL choppable at the component level, not the app level. So you can literally throw in an external component and it can add it's OWN part of the overall URL. I don't know any other framework that can let an external component eat some of the URL if it needs to.

Even Cycle.js just has a few concepts and is even more flexible than React or Vue.

Angular 1&2 feels like someone let loose a Java or C# dev onto JavaScript, who tried to apply all the design patterns™

But I'm currently buying into the FP fad, haha

HTML is content. CSS is style. Javascript is shit.

Angular-cli because it provides a scaffold for getting started with the project and getting something up and running. The documentation feels pretty good. I like the example app they are building and the documentation format (they provide the full source code for the files right there in the documentation, no need to navigate to somewhere else).

[1] https://github.com/angular/angular-cli [2] https://angular.io/docs/ts/latest/

I'm not saying this is a good thing, but I started to read more in the frameworks repos after trying a few of them.

I think this is a barrier for most devs, but I think it made me better at coding.

The only client side JS library that doesn't seem to be a fad is jquery. Which now has backlash - maybe that's a sign of success in frontend dev land?

Current frameworks try to solve a higher level and most failed.

The minimal transform is usually trivial to implement by hand:

  var message = $('.widget__message'),
      title   = $('.widget__title'),
      button  = $('.widget__button');
  button.on('click', () => {
      $.get('/api/widget/1', response => {
          title.text(response.text);
          message.text(response.message);
      });
  });

You realize React solves a performance problem that it imposes on itself, due to immutability, right?

Pre-react web apps to do attempt to re-render the entire page root on every press of a key. They simply handle events and remove/add/update the specific DOM nodes that are appropriate.

remember appendChild() and removeChild() ? These are quite fast.

That said, I like React's component structure... it works with me more than most. Though I tend to dev against react and build against preact-compat for reduced size. Which iirc uses real dom as point of truth.

The main take away from React is flux-like state management (ie Redux)... this is what helps with the real pain of larger apps (especially MVC) and that is cross-cutting concerns and state management. This is why Redux has been adopted, or roughly copied to all the up and coming options.

Yes, grids seem to always be a problem. This is one of those 'sticky wickets' (for frameworks too!). Of course it can be solved, but i'm more interested in the general case here.

>They simply handle events and remove/add/update the specific DOM nodes that are appropriate.

Don't bloody pretend you didn't.

I am specifically responding to this:

The "shadow DOM" at the root of React is quite central to its appeal, as it speeds up DOM changes by several orders of magnitude."

Of course you can take isolated sentences from me and purport alternate motivations (code clarity) to them so that you can make a new argument against that alternate motivation, but that is a different conversation.

You just use pure javascript/web standards html to create your application. All the people that I worked with that used it were really happy with it.

But I guess React will be big for the next years, because of FB.

Seriously though, if there has to be a certain "way" of using some technology I can't help but remember Code Complete, that you should always code into a language as opposed to coding in it.

I did Ember while Angular was "a thing".

The downside is for candidates looking to add a hot shot tech to their resume, Angular isn't all that sexy, but for anyone with JS knowledge willing to spend a couple of days getting up to speed with the app itself (the "tool stack" is minimal - npm, grunt, bower, browserify and since it's an existing app they are learning by example) - this is almost a no-brainer.

Now seriously, how's the front-end progressing currently? Has the pace become a bit more humane?

Sounds pretty accurate. My perception is that a large part of the JS community has started to settle on React with Redux/MobX for state management.. Facebook also really lowered the barrier to entry for React with create-react-app. CSS is still up in the air a little bit, with many different solutions still being used. Sass, CSS-in-JS, CSS Modules+PostCSS and most lately styled-components (which is very promising, but lacks features like universal rendering out of the box).

It's Vue.js everyone's raving about now. React is so 2016.

In early 2015 you might have said the same about angular.

The other moderately amusing parallel is that it used to be people said angular was for a full project and react you can use a lot or just a bit. Now people are saying react is for a full project and vue can use a lot or just a bit.

It's more like the NDK in Android. So ppl can write high performance libs in non-gc languages like C or Rust.

I'd rather use a gauge of number of people showing up at Meetups, number of jobs in job searches, etc.

At my current guess is that the AngularJS camp is at least 4x the size of the React, and even that number is likely low since Angular is a lot more stabilized in all the enterprise environments.

Hot, but not new on a JS timescale.

Although it seems like it started becoming popular 1-2 years ago: https://www.google.com/trends/explore?cat=31&q=react

Just https://www.webcomponents.org/ reached over 500 reusable elements, just polymer slack channel is now 6,5k users.

The current growth and adoption looks very bright, chrome, opera and safari already shipped 1.0 versions of most of the spec (so no polyfills are needed), firefox is close behind and edge is implementing right now.

If this is not traction then I'm not sure what is. I'm not even accounting for other libraries/frameworks like x-tags, bosonic, svelte and others.

I'd love to start pushing them to my clients, especially non-tech companies who can't afford to rewrite all their code every time a new framework becomes the fad, but I'm still kinda unconvinced. I'd love to read some real-world case studies.

Personally I've introduced web components using polymer library in two ways - upgrading legacy jquery based application and when starting a fresh CMS system with admin panel that is 100% SPA built with polymer (kind of like weebly interface - its not public yet).

It worked well for both of my cases, It felt quite similar to my previous angular 1.5+ component based approach (so I suppose it would be comparable to react/vue development).

Right now you can use polymer-redux or polymer-uniflow if you want to structure big application data flows.

I haven't encountered bigger obstacles or problems compared to other solutions I've used in the past.

I've integrated 3rd party libs like crossroads-router or quill editor just fine.

I looked a bit at Angular 2.x but for me Polymer look way more natural in terms in how applications should be build on the web.

What I did miss was a routing element like angular's ui-router (I didn't like `app-route` element)- but this is currently being worked on and there is a POC ui-router port for Polymer already.

> I looked a bit at Angular 2.x but for me Polymer look way more natural in terms in how applications should be build on the web.

Completely agree. In the long term, I'd love to see most reusable UI components on the web built with Web Components, with optional wrappers for people who still want to use frameworks.

One more question: is there currently a way to do server-side rendering for an SPA built with Web Components? I'm assuming something like jsdom will work?

For example you have <video> tag - it has its own internal controls that are not part of the markup - same with web components - <my-custom-elem> is what the browser sees - not what is inside - for it it is just a DOM element.

Then again I haven't explored the subject too deeply since I do Python server side so js rendering is not an option here. I suppose it would be possible if you would drop the shadow dom from your elements.

At this point, I am likely to stick to React because of the support and community. But I could see myself using web components if it reaches critical mass.

Doesn't inspire confidence.

edit: not usually one to complain about downvotes, but the document is literally what I described it to be. So, why?

Both on FF and Chrome (Android 6)

  'support' <> 'mention'

I always liked Javascript as a language, but like everyone else had the scars to show for its thorny bits. Looking at the modern stack from afar left me fantasizing about all the painful points in Javascript being fixed. ES20XX, Babel, webpack, npm. Wow!

To be honest, a lot of the modern stack _is_ nice. But for every step forward these tools take, they take two steps back.

We have a nice package manager, npm, yay, but what happens when I `npm install -S bootstrap`? Nothing. Oh sure, it installs it, but how do I _use_ it? It's tossed in node_modules, where there's no sane way to reference it. I ran into this problem immediately, on my very first hobby project. It's now two years later, 2017, and it's still a problem that requires googling around, sifting through old answers, and finding the hack that I find least painful.

Breaking up libraries into manageable sub-packages. Sounds great. It's fundamental to strong development. But usually you have a master application/library that references all the pieces, if the pieces were meant to be part of a coherent whole. But front-end devs? shrugs You just have to include everything by hand. Has seriously no one looked at their package.json in a simple TODO app and said "Something is wrong here"? How is a 20-30 line list of dependencies normal for the most basic of applications? It isn't. It's isn't maintainable. No one is going to remember all the packages they need to include each time they start a new project. They're doing what I'm doing; copy paste from the last project, like some holy script scrawled by ancient masters from long ago.

Fancy new JS language features are nice. `for of`, `for in`, filter, map, etc. But seriously I can't use `<SomeThing onClick={this.handleClick}/>`? I have to use binding magic, special function definitions, etc? Because _nobody_ has to register event handlers, right? Geez. And why did they spec a standard for classes, finally, but not static methods and types!? That had to come in another version later, leaving yet another legacy of out-dated documentation?

Webpack, like everything else, is an improvement by the numbers. Writing modular javascript and getting it packed into a bundle is nice. Almost like a real programming language! But why do I have to write a cryptic webpack.config.js for every project? Why do I have to install Babel and webpack separately? Why do I need to install 3 other babel related packages? Why do I need a .babelrc? It's just insane. There should just be one tool, one command. "modernjs build". Done. Break that one tool into sub-libraries/sub-tools underneath, I don't care, but when I'm building fancy Uber-for-breastmilk Web 2.0 SPA, I'd rather focus on UX than spending my evening configuring compilers to what should be their defaults.

The most frustrating thing, and a common theme, is the amount of times I need to Google things while developing with the modern stack. "Oh, ummm ... how do I export/import?" "How did I configure webpack last time?" "Errr ... how do you include a bootstrap theme?" "Was it `in` or `of` to iterate over values...?" "How do you filter in place? Oh, you can't ... okay..." A lot of that sounds like basic stuff, like "How do I export/import", but ya know what? The way it's implemented in modern JS is just not intuitive. Call me dumb if you want, but I've dealt with a _lot_ of languages in my time, and JS is the one where I cannot possibly remember the exact magical incantations for specific kinds of exporting and importing. And really, that's how everything is. It's just cryptic and non-intuitive. The underlying concepts of any of these major tools or systems is sound. The implementations are gibberish.

As much as I'd like to say "sorry for the rant", I'm not. Something is horribly wrong with developer culture if this abomination is what we've created. There's no excuse for it. I've heard people argue that all of this is just a result of front-end being in-between stages of its life, and that things will eventually settle down and be stable and usable in a few years. But you know what? Rust, a completely new and modern programming language, went from nothing to a thriving ecosystem in just a matter of years. It was driven by Mozilla, hardly the largest company. Meanwhile MASSIVE companies like Facebook, Google, Amazon, etc have given us the "modern front-end". There's no excuse for the ecosystem to be in this state.

"But you don't have to use all those libraries and tools!" Of course not. I could just LAMP+HTML+JS+CSS it up like the good ole days. It worked then, it works now. But it frustrates me that there exists tools that _should_ be better. npm _should_ make life easier. ES2017 _should_ make Javascript a better language. I tried out these tools for a reason. Old school development was painful. Javascript with modules and packages, reactive UI, state management, etc. It's all awesome! I'm not messing about with the tools for no reason.

Imagine if I sold you an automated potato peeler. "It'll peel the potatoes for you in seconds!" And it does! But turns out you spend more time cleaning it than you spent just peeling potatoes the old fashioned way. That's what the modern front-end tools are like. They take the painful parts of old-school front-end and make them easier, but they add tons of busy-work elsewhere that ends up making things a net negative.

Give a try to Vue.js, you can do exactly this. This framework reconciled me with frontend development after I discovered it on HN. Let's say you want to build a custom button with a special functionality and reuse it, like a button that logs when it has been clicked. Simply create a component like this (it's almost self-explanatory):

    <template>
        <div class="colored-box">
            <p @click="logClick">{{ text }}</p>
        </div>
    </template>

    <script>
    export default {
        name: 'LogButton',
        props: [
            'text'
        ],
        methods: {
            logClick: function () {
                console.log('The button "' + this.text + '" has been pressed"')
                this.$emit('click')
            }
        }
    }
    </script>

    <style scoped>
    .colored-box {
        background-color: red;
        border: solid 1px black;
    }
    </style>

Once your component is ready, you can use it in other files, and in a damn simple way:

    <LogButton text="Delete" @click="…" />

React folks: Is there no way to do this with React? I may need to use React soon, and if it can't do this I'm going to be pretty sad.

Can you maybe clarify what you think you can't do with React?

You seem to be building an argument based on the idea that there's "one true way" to write web applications. There isn't. People have very different ideas about what's best. While ostensibly different tools do the same job, they take quite different approaches. For example, take "gulp vs grunt vs make vs npm" for the build process. gulp uses "JS with a framework" for config. grunt uses json. make uses unix-y scripting. npm uses JS but plain node.js without a framework. Those are opinions, and there isn't a "right" one.

Suggesting there should be one tool for compiling web apps is a bit like suggesting there should be one C compiler for compiling C programmes. There can only really be one tool if there's only one way to do things, and that's simply not the case. With different approaches comes different tools.

But, all that said, it doesn't matter to an individual developer. Choose the tools that suit you, learn them, and be happy. Whatever approach you take to development is far less important than writing software that works for your users.

Nah, you misunderstand me. I'm saying webpack+babel should be a single program with a sensible default config. I didn't mean to imply anything grander than that.

> Choose the tools that suit you, learn them, and be happy.

If someone decides to use Webpack+Babel, I don't think they're going to be "happy" about having to memorize a list of at least 9 different npm packages and 35 lines of configuration. Not to mention re-memorizing the new sets of packages and configurations every six months when some maintainer decides that package X should be split into packages Z, Q, and R, or that the current configuration tree is "wrong" and needs to be tweaked in backwards incompatible ways.

Right now, FE JS development mostly has a terrible OOTB experience.

It doesn't help either that these js communities are splintered around every tiny issue and forked every other week (mean.js! is where I started the whole process). The feeling that there is zero permanence one week into a project does not inspire confidence either in my own project or the tools I have chosen.

I keep hoping the JavaScript community will have the same epiphany, but so far I'm still dreaming. Yes there are boilerplates that give you something working out-of-the-box, but still you need to keep up with which boilerplate is the latest and greatest. I'd argue Rails being so opinionated was one of the reasons for it's success.

[0] - https://www.quora.com/What-makes-Rails-a-framework-worth-lea...

That's what you get by shoehorning XML. Here's how you do it:

  var someThing = document.createElement("button");
  someThing.onclick = handleClick;

If it hurts, don't do that then - put all your build stuff and devDependencies in a separate module and install it into your next project like any other development dependency, adding new capabilities as you need them and bumping the version number when you need to like any other tool. You can start doing it yourself [1] or use one someone else made earlier [2] - there are an increasing number of these toolkits about.

> But seriously I can't use `<SomeThing onClick={this.handleClick}/>`?

You can do exactly that if you're using React or one of the many libraries which use React-like conventions (Preact, Inferno, Mithril.js etc.), so just use one of them.

> But why do I have to write a cryptic webpack.config.js for every project? Why do I have to install Babel and webpack separately? Why do I need to install 3 other babel related packages? Why do I need a .babelrc? It's just insane. There should just be one tool, one command. "modernjs build". Done.

You don't have to, and there are lots of tools which will take care of this for you (see [2] again). That's the exact same workflow I wanted, so I created it for the types of projects I'm working on [3] - it doesn't take much extra effort to turn your own preferred build setup into a command.

[1] https://github.com/insin/ad-hoc-reckons/blob/master/Creating...

[2] https://github.com/facebookincubator/create-react-app#altern...

[3] https://medium.com/@jbscript/quick-development-with-nwb-35f3...

No, you can't. This is broken:

   class Foo extends React.Component {
       render () {
           return (<SomeThing onClick={this.handleClick}/>);
       }
   
       handleclick () {
           this.setState (blah);
       }
   }

> it doesn't take much extra effort to turn your own preferred build setup into a command.

Here's the thing. Let's say, instead of selling people cars, we only sold parts. You shop on various stores for all the parts you need, depending on the kind of car you want, order them all, and then put the car together. The great thing about this is that every person gets exactly the car they want for their specific needs! And the people making the parts get to focus on a specific part, so the individual parts are will end up well designed and polished.

For a car nut, that's probably great. But most people aren't car nuts. For everyone else, this system is terrible. They don't know how a car works. They go online, search around, get overwhelmed, and decide to just follow whatever random "Build a Car in 30 minutes!" guide they stumble on. They end up with a car at the end, and now they can do what they really want to do; drive from point A to point B and forget about building cars. Until one day the radio breaks. They look online for a replacement, only to discover they don't make that radio anymore. In fact, the new radios don't fit in their dash configuration. So after hours and hours scrounging through oiloverflow.com questions, they finally piece together how to replace their dash with a new dash, without having to replace their steering column configuration. Then they get their radio, and all is well. Except now they've missed the movie they were going to see with friends, so they just go to bed and don't even use the car.

And the promise about each individual part being well designed and polished? It didn't pan out in practice. Some parts ended up really nice (React). Most parts just kept getting revised or forgotten and were never really thought through (react-router).

Most developers just want to get from point A to point B. Go from idea to app. Fiddling with packages, compiler configurations, etc, is not productive for them. "it doesn't take much extra effort to turn your own preferred build setup into a command" is the equivalent of asking everyone to build their own car. Just give them a pre-made car! If they're the type of person to want to customize their build tools and environment, they'll do that. But don't foist that burden on every single developer.

There's several strategies for ensuring that `this` in a function refers to a particular class instance, particularly in a React app. The basic approaches are re-binding the function every time you re-render; binding each function once in the constructor; using a decorator or utility method to bind each function once; and using the Stage 2 Class Properties syntax and writing the function using the arrow syntax. See http://reactkungfu.com/2015/07/why-and-how-to-bind-methods-i... for an overview of the approaches.

Let me write `'use sanity;'` at the top of a function (like `'use strict';`) and then let me use sane lexically scoped semantics.

Almost easier to make completely new keywords that allow you to designate where a special-scope begins and a "this"-like keyword that behaves a little differently.

Let's hope this becomes the reality soon!

It would break way too much of existing code.

Maybe I'm not completely understanding you correctly, but es6 and es7 does fix many of these problems, doesn't it? In which case the problem is there is no way to make es6 or es7 code compatible with older browsers other than transpiling. I don't know how you fix that without a time machine.

"bundle install" in the command line.

That's my approach to dealing with frontend libraries but I tend to cheat by using Rails or RailsComposer to setup my project.

On the other hand, yes, the SQL coursework I did a decade ago is holding up really well :) .

So they aren't that rare.

But doing just one thing is easier.

When I do back end stuff, I have to think about scalability and API design, which is hard enough in it self.

When I do front end stuff, I have to think about information architecture and perceived performance.

I can do both, but I don't have infinite time, so I focus on the things I like the most, which is the front end :)

There are always people who are good at something and bad at something different.

Ahh, the universal sign of someone who worked around IBM.

Generally they will be storng in one and weak in another.

In 2011 I was sales manager in Mexico, doing WordPress sites for free on the side just for fun. In 2012 I migrated to the US with my family (legally). Then I worked in maintenance for 6 months until they fired me because I couldn't talk English.

After that I decided to try to live from building websites. I started to learn JavaScript and CSS, because already knew some HTML.

So I landed some clients as freelancer doing fixes on old sites, updating WordPress. When I landed my first WordPress site from scratch I didn't know how to do it, so I bought a book on the topic and used the gig as practice while reading the book.

I was able to maintain my family doing responsive WordPress sites. Then I started to get issues with all the grid frameworks and stuff, it was too complicated to make a simple website responsive.

So I started to do what everyone tells you not to do: "don't reinvent the wheel". I got myself to build my own grid, I did it, and I still use it Today. The process was painful because I didn't knew any real CSS so forced myself to learn it, when I got it done I was very confident I could do any layout in CSS.

One freelance gig I got was a SEO tool to count the amount of words, paragraphs, syllables, etc. of a given text, it was really exiting, because I knew I had to learn JavaScript to do it. At that time Backbone was really complicated for me, so I did it but really mostly copy/pasting stuff, I was happy with the result but not with the methodology. One thing I really learned from this project, is how to setup my development environment with Grunt.

So at this point I knew enough CSS and how to setup task runners.

From 2013 to 2015 I did only freelance work, then I got a full-time job at a small advertising agency, doing WordPress sites.

I was able to get my paycheck doing stuff that wasn't complicated for me, get a PSD, make it a responsive WordPress site (with the grid I did) and done. So I was able to learn JavaScript on my free time, so I did what worked for me in CSS again, go a reinvent the wheel.

I did my own "Backbone"-like framework, and was able to learn about Object-oriented programming and how to do it in JavaScript using prototype inheritance. Then I found out about React, and started using it too, learned about functional programming, pure functions, immutable data, declarative syntax.

At this point I was using Gulp, Sass, Babel, NPM, learned how to use the command line too, Vim, Tmux, was using Linux as my primary OS, and other very cool tools.

So in 2016 I landed an interview for a company where the job title was frontend developer, so for me was like no more "make my logo bigger" website clients. I got the job, Today I do only JavaScript using React/Redux/React-Router, I learned Vue.js on the side and learned Python too, so now I can do my own backend using Bottle/Flask on my freetime, learned about MongoDB, Postres, SQLite.

And these days I'm building my own virtual dom implementation to understand better how it works. And yes, a new JavaScript framework gets released everyday, and yet I try to use as many as I can, spend a couple hours building a todo app, reading the source code to see what I can learn from it, etc.

Right now I'm loving preact, and couple days ago found out https://github.com/hyperapp/hyperapp which is really cool.

The point of my boring story is:

- frontend development moves fast, get with it. Don't expect to learn something and keep using the same shit for ever.

- learn JavaScript, not frameworks. If you understand the language you are going to be able to understand any framework better

- if you want to learn, reinvent the wheel

- avoid the hype

- if you are freelance and need to make a simple app and you are comfortable with jQuery, go fucking do it in jQuery and don't mind about the new cool stuff yet.

- Backbone, Angular, Ember, React, Vue, or Preact? Whatever, when I open the source code of a project built on any of those frameworks I only see JavaScript patterns, that's it.

If you get a job and they are using something you don't like or something you don't know, read the documentation, learn the basic idioms and try it. Again, at the end, it's just JavaScript.

I mean, I was 29 when I started my journey, no English, no CSS, no JavaScript, no knowledge about software development good practices. Now I'm 33 and very happy with my job as frontend lead developer.

Most front-end work is repetitive, with some minor variations. Rather than a framework, I think that perhaps an expert system for making web apps that is basically an interface for metaprogramming, would be a vast improvement over the current tech.

Internet/web: no

Web browsers: no

DNS: no

HTTP: no

Web Hosting: no

UI Design: no

HTML: no

CSS: no

SEO: no

JavaScript: no

DOM, BOM, JQuery: no

Web Fonts: no

Accessibility: no

... and so on. But maybe you meant just Javascript libraries, which seem to make up just a small part of the content, but ok... Let's use "Module/Package Loading Tools" as a sample, because this thing is really to big to go through everything:

Browserify: Started in 2012. So... nope

Rollup: Started in 2015. No (but close!)

SystemJS: 2013. Nope, sorry

Webpack: 2013. Nope

And let's arbitrarily add the behemoth:

React: 2013. Nope

It appears there was an awful lot of new frameworks in 2013 and that let to the impression of framework churn. To perpetuate that narrative four years later seems to be more groupthink than reality.

Now there are tools that solve problems that arise from other tools, it is getting very meta. An ecosystem like this cannot last indefinitely.