Failing to consider jQuery a “framework” seems arbitrary and wrong.
Yes, jQuery provided massive compatibility fixes that the very fad driven “first frameworks” from the article lack, but to then dismiss it as just a compatibility layer is nonsense. jQuery was so widely deployed (well intentioned, but wrong :) ) people pushed for it to be included as part of the literal standards.
Beyond those core compatibility and convenience functions jQuery feature an extensive plugin architecture, and provided UI components, reactive updates, various form, and other user data supports. All of which sound not significantly different to the feature set of those “frameworks”.
This article then goes on to dismiss Ruby on Rails with a single sentence. Given Ruby on Rails pretty much created the entire concept of the integrated frontend and backend, with integrated databases, that seems bizarre?
Honestly, reading this post felt like it was written by someone who had encountered a few fad frameworks, added a few of the still major ones, and then called that a history. Honestly I don’t think this is worth spending time reading, if your goal is to actually learn something about the history of web framework.
It’s definitely true that there was a massive ecosystem around jQuery, but I think it’s fair to say it was (and so were MooTools and Prototype) doing a fundamentally different thing than the “frameworks” which emerged in the early 2010s. The shift from managing state and reactivity in the DOM to managing it in the framework layer was a major shift.
Ruby on Rails… isn’t a JavaScript framework. So it’d be pretty weird to spend a bunch of time on it in a post about eras in JS frameworks!
The author was a major contributor to and member of the Framework Core team for Ember.js for several years, helped build its modern reactivity system, and has spent quite a bit of time with others along the way. Your dismissal is kind of hilariously wrong.
I disagree with (1), unless the post were updated to state that it is talking about a specific framework architecture, rather than “frameworks” in general.
As I think about it, I agree on (2), because now that I recall people were still using separate libraries in client code. What it thinking of when writing the above was the adoption of the concept of “application frameworks”, which Ruby is a major early driver of, but as you say it didn’t actually interact with JS directly, you were using frameworks like jQuery, etc in the client, and rails was just providing the application data and state.
I think it’s a fair point on further reflection. By the time I was starting “application frameworks” were just the default, Ruby on Rails and Django had already been around and matured, modern JS frameworks were also trying to be entire application frameworks, etc. And in our modern context, when we refer to frameworks, we’re usually talking about application frameworks.
But that doesn’t mean UI widget frameworks are any less of a “framework”, it’s just that we were collectively thinking about software differently back then. I unfortunately don’t have that context, to me jQuery was always a “library” whereas Backbone was a “framework”, but I can totally see your perspective here. If I have time I’ll try to go back and work that in somehow in my discussion of the first era, thanks for reading and commenting!
Maybe we’re all a bit wrong and right here? That would seem to be the theme of eternal September in JavaScript frameworks.
Put another way,I think it’s possible for someone to know current JavaScript frameworks quite deeply and still miss the history or the underlying terrain that’s shaped it. A few things I thought of reading this:
On prior art for transpilation and components: ClosureTools was annouced in 2009, and included the tooling Google had been using for years to provide minified JavaScript with type checking (using JSDOC comments). Closure Library also included things like goog.ui.Component, and also shipped with a template library. These things had been used in Gmail and Google Docs for some time - though I’m not sure they’re used before anymore.
On prior art for full frameworks and server side rendering: similarly see Google Web Toolkit. The Google Wave launch for instance was all GWT, IIRC with server side rendering.
On “browser integration of components”: I can’t speak in detail, but I remember this Working Draft on Web Components coming out in 2013. . . I’m not sure but I don’t think much progress happened then. The author suggests that this will change. But I wonder like Bourdieu, how is today different from yesterday?
Put another way,I think it’s possible for someone to know current JavaScript frameworks quite deeply and still miss the history or the underlying terrain that’s shaped it.
Totally! The author fully acknowledges a knowledge gap in the era you’re commenting on and invites people to give exactly the kind of info you’re responding with. :D
Web components… have indeed not really made a ton of progress. There’s more motion on some of the fundamental problems in that space in the past couple years but they were stuck for a very long time. My own take is that they are trying to do something quite different from what the component-oriented view layers and frameworks were trying to do: the APIs are basically “How would you implement a new built-in element?” rather than picking up the themes around reactivity etc. that the view-layer-frameworks tackled. We’ll see if and how they change going forward.
FWIW, I admitted in the “before times” section that I didn’t have a ton of knowledge of how everything worked prior to 2012 or so, when I started coding 😅 definitely simplified and miss bits of history there for sure, but it’s hard to capture everything without writing a novel (or having been there).
Re: Google’s tooling, that’s amazing to hear about now, but I don’t believe these tools were really adopted by the community. At least, I’ve never heard of an app other than Google ones being built with them. I did point out that Google proved JS frameworks could work though, with Gmail being the first app most people seem to remember as being the moment when they realized how powerful JS had become.
Re: Web components, there has been a lot of progress here actually! In my work on decorators I’ve been collaborating closely with the folks who are pushing them forward, such as Lit and Fast, they are in fact a standard and part of the browser now. That said, they are severely limited compared to mainstream JS frameworks, I think in large part because the platform moves much more slowly than the ecosystem as a whole. But, if we step back, this is similar to the pattern we saw with View-Layer frameworks - letting patterns evolve on their own, and adopting the best ones. Some of the current patterns they’re working on include:
SSR standards
Contexts
Using imports instead of global namespace-based registration
Given time, I think they still have a lot of potential, but I also think that they’re not really usable for larger-scale apps at the moment (I had a particularly painful experience with Stencil.js last year, would not go back). But for smaller components and UI widgets, they’re pretty great!
Re: Google’s tooling, that’s amazing to hear about now, but I don’t believe these tools were really adopted by the community. At least, I’ve never heard of an app other than Google ones being built with them. I did point out that Google proved JS frameworks could work though, with Gmail being the first app most people seem to remember as being the moment when they realized how powerful JS had become.
It’s probably worth elaborating on the reasons for this because they repeat with different technologies:
The more popular products built with these tools didn’t survive, or have been supplanted by other products.
When the products have survived, the codebases have been modernized with replacement of the original frameworks. Many places have standardized around React for better, or worse.
Barriers to adoption meant that the frameworks only got serious adoption in niches. When Google’s Closure was attempting to make a splash, it was still primetime for Ruby on Rails. You can look inwards at what RoR offers, or you can look outwardly at how it sat within the web development ecosystem. People had started building SPAs, but they hadn’t displaced the approaches of the day.
Re: Google’s tooling, that’s amazing to hear about now, but I don’t believe these tools were really adopted by the community. At least, I’ve never heard of an app other than Google ones being built with them. I did point out that Google proved JS frameworks could work though, with Gmail being the first app most people seem to remember as being the moment when they realized how powerful JS had become.
I’d be curious to know @pzuraq’s view of things like htmx, hotwire and alpine. (I’m not sure it’s fair to lump alpine in with the other two, but it’s useful with them.) Wherein you deploy a little bit of javascript to avoid authoring much of your application in javascript while still ending up with reactivity similar to vue/svelte/react/angular/etc. From where I sit, at least some, if not the majority of, interesting development feels like it’s moving that way.
I think they’re interesting, for sure! I did include Astro in the full-stack side of things, I think it’s similar to what you describe. My experience overall is that these frameworks/techniques still have a lot of issues (look at GitHub’s issues with caching/state management for instance) and can be pretty tricky to use, but can work well for many types of use cases. If you’re optimizing for initial page load over everything else, they are probably a good bet.
However, it’s hard to see how they would handle more complex use cases, e.g. Google docs or AirBnB style apps. And what excites me about the full-stack frameworks era is we seem to be getting close to the point where we won’t have to make that tradeoff anymore, between a JS-lite but ultimately inflexible solution, or a full-JS but very heavy solution. It seems like we’re approaching a sweet spot with tooling and techniques that allows us to use a one-size-fits-all solution instead, possibly. Maybe there will always be a niche for needs-to-be-as-fast-as-possible style frameworks, but for maybe 90% of apps I don’t think that is necessarily the best thing to optimize for.
Astro didn’t jump out at me. That’s not one I’ve looked at so far.
I don’t think I see hotwire/htmx as optimizing for needs-to-be-as-fast-as-possible. I see them as optimizing for development velocity. With, e.g., (rails and hotwire) or (django and htmx) you can crank out your first implementation with a very small team quickly but still have an application that “feels” the way users expect it to on the modern web. I feel like I’ve done things solo that way that would’ve needed a team of 3 if I needed to manage real frontend/backend separation.
I agree that you couldn’t write google docs using these. I’m not so sure about AirBNB :). I think the improvement, especially in early-stage development velocity, might be pushing a swing back towards rails/django/laravel/rocket + htmx/hotwire/alpine for the 90% of apps that are not google docs. I’m not sure if it’s just a blip or if this is another era for your classification.
I was amused that the first three times I tried to read the article it showed the content briefly then replaced it with an error message about not being able to load a JS dependency.
Interesting, do you know what the dependency was? Would definitely like to fix that, the site is still relatively new so have been working out the kinks!
That does! I think I’ll add some basic error reporting, I didn’t want to include a full framework like Sentry (they seem to track a lot of info and are pretty huge, and I wanted the site to be as minimal and non-invasive as possible) but adding an extra error handling route will be a breeze, so I can get some indicator of folks hitting client side errors.
You know what, I think this may have been an update I made rolling out, the previous scripts/deps would have failed to load but the app may have been cached (Cloudflare has a fairly long caching period on the free plan I’ve found) so it was attempting to load them asynchronously and failing. Definitely something I’ll be more mindful of when making updates!
Always miss not seeing ExtJS not being in these lists. It was quite prevalent in that mid to late ’00s period and still has a foothold in some companies.
The other thing that always stands out to me with this general view of web is that somehow html/js are good goal. By this I mean that in native apps we don’t talk about primitives (drawing pixels directly) but in web we’re still obsessed with primitives.
I built a thing with jQuery UI. It is a regret, of sorts, because I wouldn’t be surprised if that thing still exists with more or less exactly the same UI I built only two years into my career, now fully a decade ago. While I know what people mean when they talk about it being a framework, it sat in a really, really different spot than the stuff we describe as “frameworks” these days: a curated bucket of interactions and widgets is the kind of thing we build on top of those frameworks.
In some sense, this is just a nomenclature problem: no one ever agrees on what is a “library” vs. a “framework.” The “I call you vs. you call me” distinction is clever and has something to it… but React, for example, 100% calls the components you provide while also regularly being described as a “view library, not a framework”. In some sense the best we can do is define how we’re using the terms, using them in idiomatic ways where possible but also being clear about where we’re saying something slightly different, and hope for the best.
Failing to consider jQuery a “framework” seems arbitrary and wrong.
Yes, jQuery provided massive compatibility fixes that the very fad driven “first frameworks” from the article lack, but to then dismiss it as just a compatibility layer is nonsense. jQuery was so widely deployed (well intentioned, but wrong :) ) people pushed for it to be included as part of the literal standards.
Beyond those core compatibility and convenience functions jQuery feature an extensive plugin architecture, and provided UI components, reactive updates, various form, and other user data supports. All of which sound not significantly different to the feature set of those “frameworks”.
This article then goes on to dismiss Ruby on Rails with a single sentence. Given Ruby on Rails pretty much created the entire concept of the integrated frontend and backend, with integrated databases, that seems bizarre?
Honestly, reading this post felt like it was written by someone who had encountered a few fad frameworks, added a few of the still major ones, and then called that a history. Honestly I don’t think this is worth spending time reading, if your goal is to actually learn something about the history of web framework.
I disagree with (1), unless the post were updated to state that it is talking about a specific framework architecture, rather than “frameworks” in general.
As I think about it, I agree on (2), because now that I recall people were still using separate libraries in client code. What it thinking of when writing the above was the adoption of the concept of “application frameworks”, which Ruby is a major early driver of, but as you say it didn’t actually interact with JS directly, you were using frameworks like jQuery, etc in the client, and rails was just providing the application data and state.
I’ll take response (3) as a mea culpa :D
I think it’s a fair point on further reflection. By the time I was starting “application frameworks” were just the default, Ruby on Rails and Django had already been around and matured, modern JS frameworks were also trying to be entire application frameworks, etc. And in our modern context, when we refer to frameworks, we’re usually talking about application frameworks.
But that doesn’t mean UI widget frameworks are any less of a “framework”, it’s just that we were collectively thinking about software differently back then. I unfortunately don’t have that context, to me jQuery was always a “library” whereas Backbone was a “framework”, but I can totally see your perspective here. If I have time I’ll try to go back and work that in somehow in my discussion of the first era, thanks for reading and commenting!
I really think we have failed at having the required communication structure for an Internet forum :D
Maybe we’re all a bit wrong and right here? That would seem to be the theme of eternal September in JavaScript frameworks.
Put another way,I think it’s possible for someone to know current JavaScript frameworks quite deeply and still miss the history or the underlying terrain that’s shaped it. A few things I thought of reading this:
goog.ui.Component, and also shipped with a template library. These things had been used in Gmail and Google Docs for some time - though I’m not sure they’re usedbeforeanymore.Totally! The author fully acknowledges a knowledge gap in the era you’re commenting on and invites people to give exactly the kind of info you’re responding with. :D
Web components… have indeed not really made a ton of progress. There’s more motion on some of the fundamental problems in that space in the past couple years but they were stuck for a very long time. My own take is that they are trying to do something quite different from what the component-oriented view layers and frameworks were trying to do: the APIs are basically “How would you implement a new built-in element?” rather than picking up the themes around reactivity etc. that the view-layer-frameworks tackled. We’ll see if and how they change going forward.
FWIW, I admitted in the “before times” section that I didn’t have a ton of knowledge of how everything worked prior to 2012 or so, when I started coding 😅 definitely simplified and miss bits of history there for sure, but it’s hard to capture everything without writing a novel (or having been there).
Re: Google’s tooling, that’s amazing to hear about now, but I don’t believe these tools were really adopted by the community. At least, I’ve never heard of an app other than Google ones being built with them. I did point out that Google proved JS frameworks could work though, with Gmail being the first app most people seem to remember as being the moment when they realized how powerful JS had become.
Re: Web components, there has been a lot of progress here actually! In my work on decorators I’ve been collaborating closely with the folks who are pushing them forward, such as Lit and Fast, they are in fact a standard and part of the browser now. That said, they are severely limited compared to mainstream JS frameworks, I think in large part because the platform moves much more slowly than the ecosystem as a whole. But, if we step back, this is similar to the pattern we saw with View-Layer frameworks - letting patterns evolve on their own, and adopting the best ones. Some of the current patterns they’re working on include:
Given time, I think they still have a lot of potential, but I also think that they’re not really usable for larger-scale apps at the moment (I had a particularly painful experience with Stencil.js last year, would not go back). But for smaller components and UI widgets, they’re pretty great!
It’s probably worth elaborating on the reasons for this because they repeat with different technologies:
For what it’s worth, ClojureScript heavily depends on the Google Closure Compiler to perform optimization of generated JS code, and the official docs encourage people to use some of the features from the Google Closure Library.
[Comment removed by author]
Olliej is saying that adding jQuery to the standard would have been wrong, not that jQuery itself is wrong.
I see, I have removed my comment.
I’d be curious to know @pzuraq’s view of things like htmx, hotwire and alpine. (I’m not sure it’s fair to lump alpine in with the other two, but it’s useful with them.) Wherein you deploy a little bit of javascript to avoid authoring much of your application in javascript while still ending up with reactivity similar to vue/svelte/react/angular/etc. From where I sit, at least some, if not the majority of, interesting development feels like it’s moving that way.
I think they’re interesting, for sure! I did include Astro in the full-stack side of things, I think it’s similar to what you describe. My experience overall is that these frameworks/techniques still have a lot of issues (look at GitHub’s issues with caching/state management for instance) and can be pretty tricky to use, but can work well for many types of use cases. If you’re optimizing for initial page load over everything else, they are probably a good bet.
However, it’s hard to see how they would handle more complex use cases, e.g. Google docs or AirBnB style apps. And what excites me about the full-stack frameworks era is we seem to be getting close to the point where we won’t have to make that tradeoff anymore, between a JS-lite but ultimately inflexible solution, or a full-JS but very heavy solution. It seems like we’re approaching a sweet spot with tooling and techniques that allows us to use a one-size-fits-all solution instead, possibly. Maybe there will always be a niche for needs-to-be-as-fast-as-possible style frameworks, but for maybe 90% of apps I don’t think that is necessarily the best thing to optimize for.
Astro didn’t jump out at me. That’s not one I’ve looked at so far.
I don’t think I see hotwire/htmx as optimizing for needs-to-be-as-fast-as-possible. I see them as optimizing for development velocity. With, e.g., (rails and hotwire) or (django and htmx) you can crank out your first implementation with a very small team quickly but still have an application that “feels” the way users expect it to on the modern web. I feel like I’ve done things solo that way that would’ve needed a team of 3 if I needed to manage real frontend/backend separation.
I agree that you couldn’t write google docs using these. I’m not so sure about AirBNB :). I think the improvement, especially in early-stage development velocity, might be pushing a swing back towards rails/django/laravel/rocket + htmx/hotwire/alpine for the 90% of apps that are not google docs. I’m not sure if it’s just a blip or if this is another era for your classification.
I was amused that the first three times I tried to read the article it showed the content briefly then replaced it with an error message about not being able to load a JS dependency.
Interesting, do you know what the dependency was? Would definitely like to fix that, the site is still relatively new so have been working out the kinks!
The error message didn’t say and I can’t get it to reproduce any more. I was (and am) using Firefox for Android, if that helps at all.
That does! I think I’ll add some basic error reporting, I didn’t want to include a full framework like Sentry (they seem to track a lot of info and are pretty huge, and I wanted the site to be as minimal and non-invasive as possible) but adding an extra error handling route will be a breeze, so I can get some indicator of folks hitting client side errors.
You know what, I think this may have been an update I made rolling out, the previous scripts/deps would have failed to load but the app may have been cached (Cloudflare has a fairly long caching period on the free plan I’ve found) so it was attempting to load them asynchronously and failing. Definitely something I’ll be more mindful of when making updates!
Cool, happy to help!
Always miss not seeing ExtJS not being in these lists. It was quite prevalent in that mid to late ’00s period and still has a foothold in some companies.
The other thing that always stands out to me with this general view of web is that somehow html/js are good goal. By this I mean that in native apps we don’t talk about primitives (drawing pixels directly) but in web we’re still obsessed with primitives.
Yeah - the bigger UI toolkits on top of jQuery - JQueryUI, Mootools, etc were in the “before times”.
I built a thing with jQuery UI. It is a regret, of sorts, because I wouldn’t be surprised if that thing still exists with more or less exactly the same UI I built only two years into my career, now fully a decade ago. While I know what people mean when they talk about it being a framework, it sat in a really, really different spot than the stuff we describe as “frameworks” these days: a curated bucket of interactions and widgets is the kind of thing we build on top of those frameworks.
In some sense, this is just a nomenclature problem: no one ever agrees on what is a “library” vs. a “framework.” The “I call you vs. you call me” distinction is clever and has something to it… but React, for example, 100% calls the components you provide while also regularly being described as a “view library, not a framework”. In some sense the best we can do is define how we’re using the terms, using them in idiomatic ways where possible but also being clear about where we’re saying something slightly different, and hope for the best.