I actually have a friend who wrote in Dojo, so was aware of its existence, but had no idea it was so influential/early in the First Frameworks era. Same with GWT/Closure, as has been mentioned by others. I did run this article by some mentors who have been in the industry since the 90s before posting, as I wanted to make sure I didn't gloss over it entirely, but unfortunately it seems they didn't experience those either.
And I think that's the core of the issue, even people who were around at that time do not remember all of these things. Ultimately, even those of us who are trying our best are going to miss details, and this is only going to get worse as we get further and further away from the beginning. Honestly it seems like this is a job for historians, and unfortunately I am not one, just a dev trying to share my thoughts and experience
> According to Wikipedia, XHR was introduced in 1999, 4 years after JS was introduced
Your way of commenting on XHR in this paragraph...
In this environment, it’s understandable that JS was generally seen as a toy language and not something you’d write a full app in. The most common thing you would do was include jQuery, throw together some scripts for a few UI widgets, and call it a day. As time went on and XHR was introduced and popularized, people started to put parts of their UI flow into a single page, especially for complex flows that required multiple back and forth interactions between the client and the server, but the majority of the app stayed firmly on the server.
...where you are talking about jQuery already being a common thing, which implies at the very least 2006 but more likely 2008-9, and then writing "As time went on and XHR was introduced and popularized", suggests the idea that XHR somehow was introduced much later, when jQuery was already common.
This is what I was referring to. It may have not been intentional, but the way you comment and present it suggests a mistaken timeline.
That's a good point, definitely not what I meant there. I think in my first draft I actually just said "JavaScript widgets" and when I updated it to jQuery I didn't update the rest of the paragraph. Thanks for pointing that out!
By "full-stack" here I mean frameworks which handle both the frontend and backend simultaneously, in a seamless way. The closest thing framework that I remember from the MVC/P era which attempted this was Meteor.js, but it was really horrendous to use in my experience.
Otherwise, it was very common practice to serve an Ember or Angular app as static files Nginx or directly on a CDN. Wrapping them in a server-side framework was always a bespoke process which required you to effectively maintain two frameworks, and stitch them together yourself (unless you count Ember + Rails in the early days, but even that is a stretch IMO). When SSR was introduced in any framework, it was usually not used to its full potential to be able to accomplish the use cases I discuss in the post, like authentication, API endpoints, etc. It was just used to render the app on the server. It did not fundamentally change the DX of the framework.
I honestly was pretty skeptical of these latest frameworks until I gave them a shot! It doesn't sound that revolutionary until you actually start using them, and things which were previously quite difficult become absolutely trivial. I highly recommend trying them out some time.
I am, indeed, too young to have accurate memories there! Of course right after I posted this I started hearing about GWT and Closure, that's a bit of egg on my face. I mentioned Gmail as an important marker, everyone I talked to remembered it as the _moment_ which proved that JS could write full applications in the browser, but I assumed that it was written with an internal framework of some sort (none of my mentors who've been in the industry mentioned it when I brought up Gmail, and there's no mention of it on wikipedia: https://en.wikipedia.org/wiki/Gmail)
That said, I think it's an important landmark and I may end up revising this post to add a bit more discussion about it. Thanks for pointing it out!
The buzzword circa 2006 was "Rich Internet Application" framework/platform and the concept was not even totally new then. It included GWT, but also an Adobe product built on Flash called Flex and some other vendor solutions that compiled to Javascript that I no longer recall the names of. The space was well-defined enough that there was a Gartner magic quadrant for it.
I had a big interest in RIA at the time. The big players were Adobe AIR, Microsoft Silverlight, Eclipse RCP, Netbeans, and I also considered JavaFX--I might be forgetting another one.
Silverlight had the best performance/fit for my purposes and sadly was the first of many to go away, largely due to the popularity of iPhone and these platform/tools being excluded. Too bad Apple only promotes Apple's innovations and actively suppresses others.
Not to toot our own horn, but I'd look into Cappuccino and 280 Slides too (we were YC no less!) and were the first iteration in the GWT era to extend JS itself and transpile in the browser.
Personally I feel that Cappuccino is one of the last frameworks that still cared about a kind of interaction design that’s no longer discussed on the web, replaced mostly by more devops/abstraction-oriented discussions.
I manage a web UI programming language in my free time, and the juxtaposition of folks claiming FP ergonomics benefits, then upon my request, showing a static, interaction-less end result whose improved version would obviate their pristine architecture, is pretty staggering. The typical defense is "hey we're not designers" but if you zoom out a bit you realize the whole environment doesn't foster engineers to care about design concerns anymore (barring a niche but valuable vertical of optimizing for payload size). This in turn puts pressure back onto designers who come to expect less and less of what they care about on the web.
Just the other day a newcomer shipped an animated row transition after fighting her framework for 3 weeks. The designer was delighted, but the manager didn't even get the point because he matured in whichever era of JS framework that de-emphasized acquiring taste in interactions.
I myself come from a Flash background, so rather than seeing an upward trend, I see a decline in UX concerns, followed by an incline of devops-related concerns in UI frameworks (accompanied by HN comments saying that in both cases the web should have stayed as a document format, only to end up with an awkward mix of document + app architecture their desktop apps through Electron anyway).
If I were to categorize these "eras", I'd rather take the perspective of wondering at which point, and why, framework process ended up more important than the product. Heck, a similar thing is happening on native too, unfortunately. Where did all the interaction designers go?
Maybe AR would nudge more folks to learn and focus on rendering, gestures, transitions, framerate, intent and the rest.
Honestly it’s a shame Cappuccino didn’t take off it’s actually a super interesting framework and was (is?) extremely powerful even by today's standards
No worries, as you weren't working then, but to give some context, what you have in the "first frameworks" I would probably call the third generation of frameworks. So the breakdown you have is nice, but probably only covers the second half or maybe third of the story.
When hooks first came out and I started playing with the API, I had the same feeling! It felt refreshing, but I couldn't quite nail down why.
I don't think it's that you don't have to worry about lifecycles, in the end. You still do - you have to understand the lifecycles of your functions which are different than those of a component class, but they are lifecycles in there own way. What I think really makes hooks feel nice is you can _close over_ the small, self-contained lifecycles, and introduce them at any point in the program in a composable way. That's pretty neat actually, and what we've taken away from hooks currently.
Maybe that's not the only benefit they have, but it's a pretty large one, so I'm glad hooks decided to explore this new direction, even if I'm not completely sold on it (as in, wouldn't introduce it in Ember just yet).
I definitely agree with this! In large codebases especially. This is ultimately why Ember has decided to move toward using JS imports to stitch components together as well, we recently merged an RFC to do just that.
This was my favorite part about Ember, and what I miss the most.
The Ember team is one of the least dogmatic teams that I have come across, and has been willing to change their entire strategy when presented with a better idea (while providing a well defined and fairly convenient upgrade path).
I still remember when React first came out, and showed how one way binding was so much better than 2 way bindings, and the Ember team was able to quickly switch to this new philosophy via DDAU, while still providing an easy upgrade path for our code. And all this was before 1.0 if I remember correctly.
Hey there! Author here. I actually did work through all of the examples and am very familiar with all of the hooks, I have done a lot of in-depth research while designing and working on Ember in order to understand the pros and cons of hooks.
Typically, when another framework makes a new API that is popular, my first reaction is to do research and try to understand how the API works, what its pros and cons are, and to see what I would like to pull back into our own work. As I noted near then end, there is actually a lot I like about hooks! While it does feel a bit overly granular and tricky to me, especially at the lowest level, it adds a composition primitive that didn't really exist before, and doesn't exist currently in Ember (though we're working on it, like I mention near the end).
I think we may just have a different sense of what drives complexity, and what can cause antipatterns at a high level. I would prefer something just a little bit less expressive, but with many of the same composability benefits.
> The React example is one file because it's an example. The idea is to demonstrate all the moving parts in one place. It's not presented as a representation of what you would build as a production app.
I'm very aware of that! I was actually just pointing out a difference there, and that difference is actually something that is _enforced_ in Ember (and actually something we're looking to change, as I discuss in the last section of the post), so I was mainly pointing it out in case people were wondering why I didn't have a more equivalent example.
I didn't use the later examples because they added too much more functionality for me to address in a single blog post, and I didn't want to split the files out in the example because I didn't want to change anything in general, in case people thought I was making bad-faith changes just to make React look bad.
Definitely agreed. We’ve been focused on optimizing for end-to-end, realistic benchmarks. One of the Ember core team members, Kris Selden, has been working on a testing framework specifically for this actually: https://github.com/TracerBench/tracerbench
Now that we have a full set of new features, and are comfortable with the performance as a whole, I think we can also start to tune for some microbenchmarks. Our primary concern was to not over optimize for microbenchmarks at the expense of real world performance in real apps, which can happen if you’re not careful.
A big part of Octane is reducing the amount of "magic" under the hood for a lot of features. For instance, autotracking and tracked properties now allow you to use plain JS for most computed values, which means that every stack trace that you have while debugging a getter will be a standard stack trace, without confusing computed property code in between!
I definitely encourage you to check it out sometime, a lot has changed!
The underlying implementation is the largest difference. Where MobX relies on pub/sub and observables to propagate dirty state, Glimmer’s autotracking uses a lazy system that incurs minimal cost until render occurs. We’ve found the overall performance of this system to be much better, and the primitive easier to optimize.
And on top of that, the fact that we use a simple reactivity primitive under the hood[1][2] means that we have been able to transition from an API designed for 2012-era two-way bindings to a unidirectional data-flow model with minimal disruption, and with free interoperability between code written with the two APIs (even in the same object).
This also means that we can design new functionality (like Octane's modifiers, and other upcoming reactive APIs) without worrying about how the parts of the system will work together.
We definitely looked at MobX and Vue as we were designing the final user facing API! The implementation under the hood is pretty significantly different, ours is not based on pub/sub or observables/streams, it’s based on a pull-based mechanism which we’ve found to be much more efficient at propagating changes in UI driven apps. But the end result is definitely similar, and we learned a lot from their implementations
And I think that's the core of the issue, even people who were around at that time do not remember all of these things. Ultimately, even those of us who are trying our best are going to miss details, and this is only going to get worse as we get further and further away from the beginning. Honestly it seems like this is a job for historians, and unfortunately I am not one, just a dev trying to share my thoughts and experience
> and the error of suggesting XHR came later
According to Wikipedia, XHR was introduced in 1999, 4 years after JS was introduced: https://en.wikipedia.org/wiki/XMLHttpRequest