The implication in this post is that frameworks are standing still. That browsers have evolved and frameworks are built based on some past version of browsers that no longer exists.
In reality frameworks, browsers, and web standards are coupled together in an important triangle that creates the progress Joe calls out.
Frameworks iterate at an incredible pace compared to standards and browsers. The multitude of frameworks and libraries implementing the component pattern directly influence the spec. Members of W3C TAG and TC39 take the lessons learned from JavaScript development and fold it back into specs.
A great example is promises. This is a standard JS pattern, and now native feature, that began life as a library, became several libraries, then an independent spec, then finally a formal ES6 spec (domenic can correct me if I have the history wrong). When we talk about Move the Web Forward this is what we mean: http://movethewebforward.org/. Frameworks represent the shared and negotiated best practices of a development community- from this we can formalize solutions into specs.
To make a second point: Developing for the web means developing for a spectrum of platforms. A framework like Ember (which I work on) provides you known support for a variety of platforms. I don't need to consider if 5 different libraries all have fixed the ARM optimizations errors on iOS8. I can know all the features in Ember have it fixed. In fact I don't even need to think about the error, most likely.
A third and final point: Of course frameworks don't just influence browser features. The conversation is two-way. Unlike a simple scratch-an-itch library, framework authors are constantly looking foward and thinking about how they can better align with upcoming features. Ember has iterated on its Set, Map, and promise APIs to make them match the specs. Sometimes as we align with a feature we discover unexpected architecture problems with the spec (Object.observe, web components) and push the feedback upstream. Sometimes a spec helps us solidify an un-spec'd solution, and we need to expend effort trying to move apps to that new pattern (ES6 classes).
Most developers who buy into SPA architecture and build complex JavaScript applications understand the value of a framework. They are not panaceas (and setting them up as one is making them a straw man), but they absolutely play a very important part in the JavaScript and web ecosystem.
Which is more than I can say about this post's FUD ("Remember all those MochiKit widgets you wrote? Yeah, how much good are they doing you now that you've migrated to Ember, or Angular?" they work just fine thanks) and call to limit your ambitions for a great client-side app.
The implication in this post is that frameworks are standing still. That browsers have evolved and frameworks are built based on some past version of browsers that no longer exists.
In reality frameworks, browsers, and web standards are coupled together in an important triangle that creates the progress Joe calls out.
Frameworks iterate at an incredible pace compared to standards and browsers. The multitude of frameworks and libraries implementing the component pattern directly influence the spec. Members of W3C TAG and TC39 take the lessons learned from JavaScript development and fold it back into specs.
A great example is promises. This is a standard JS pattern, and now native feature, that began life as a library, became several libraries, then an independent spec, then finally a formal ES6 spec (domenic can correct me if I have the history wrong). When we talk about Move the Web Forward this is what we mean: http://movethewebforward.org/. Frameworks represent the shared and negotiated best practices of a development community- from this we can formalize solutions into specs.
To make a second point: Developing for the web means developing for a spectrum of platforms. A framework like Ember (which I work on) provides you known support for a variety of platforms. I don't need to consider if 5 different libraries all have fixed the ARM optimizations errors on iOS8. I can know all the features in Ember have it fixed. In fact I don't even need to think about the error, most likely.
A third and final point: Of course frameworks don't just influence browser features. The conversation is two-way. Unlike a simple scratch-an-itch library, framework authors are constantly looking foward and thinking about how they can better align with upcoming features. Ember has iterated on its Set, Map, and promise APIs to make them match the specs. Sometimes as we align with a feature we discover unexpected architecture problems with the spec (Object.observe, web components) and push the feedback upstream. Sometimes a spec helps us solidify an un-spec'd solution, and we need to expend effort trying to move apps to that new pattern (ES6 classes).
Most developers who buy into SPA architecture and build complex JavaScript applications understand the value of a framework. They are not panaceas (and setting them up as one is making them a straw man), but they absolutely play a very important part in the JavaScript and web ecosystem.
Which is more than I can say about this post's FUD ("Remember all those MochiKit widgets you wrote? Yeah, how much good are they doing you now that you've migrated to Ember, or Angular?" they work just fine thanks) and call to limit your ambitions for a great client-side app.