Issue #9: From the Inside

🎵 Heavy thoughts forcing their way out of me… 🎵

This issue of the Metaframework Weekly newsletter is a bit meta. Not in terms of frameworks but in relation to the newsletter project itself. Though there will be a chunk of meta (hearing this word again and again is annoying I know but please bear with me) about the heroes of this project — the metaframeworks like Next, Nuxt, and Astro (less than usual probably, but still), the last topic here will be dedicated to the updates of this newsletter’s website and some backstage of development, along with the exciting plans for the future I wanted to share with you. However, let’s start with the conventional.

The Good

Traditionally, metaframeworks are considered something growing from front end (a framework like React, Vue, or Svelte, for instance) and expanding with a back end (which often can be quite invisible and secondary, if not non-existent). Lee Robinson has flipped this vision and came up with the article on building APIs with Next.js. They suggest thinking about ways to use Next.js-driven API routes as a separate API layer, considering all the related implications. As you will see, metaframeworks like Next.js are pretty capable of that (I practice something similar with SvelteKit), and understanding the possibilities helps to get rid of arrogant biases in this regard. You should mind the tradeoffs and make everything as explicit (at least for yourself) as possible, but still, this is another tool in your toolbox you shouldn’t neglect.

The Nuxt team has recently published a new minor version, and you know what?

There’s a lot in this one!

I was really excited about the delayed hydration support, create-nuxt “acquisition”, unjs tooling updates, and of course (as an old Angular fanboy) the decorators support. Maybe it’s eventually time for me to update one of my stale Nuxt 2 side projects.

And if good-ol’ means nothing to you, there’s some shiny new news too: the new meta-meta-framework on the block, called Accella. It’s interesting because 2nd-level meta is usually related to Next.js as the most popular metaframework, so maybe it’s a sign that Astro has become an incumbent too. Nevertheless, the tool draws some curiosity with its MVC approach, MPA focus, and integrated ORM. There are decent docs with comparison to other tools, so it’s worth checking out.

The Bad

I occasionally came across this insightful GitHub-gist piece from rxliuli on SvelteKit being a kind of less favorable version of Vue 3 (which is by itself an interesting and bold opinion and perspective). There’s a lot of discontent (partially justified of course) with SvelteKit in the developer community lately (I mentioned that in the previous issue too, for instance) but in general, that’s a matter of personal preference and vision, if you check the author’s experience described in the article. But it’s hard to deny, the Svelte 5 updates lack the straightforwardness of Vue 3 or Svelte 4, even while being quite beneficial and deep in technical terms.

Another Reddit user got stuck with rate limiting in SvelteKit and it’s funny, as in this ride of metaframeworks people often forget that it’s just a web technology and web ecosystem, and some parts of it rarely depend on the tool itself. Be that as it may, you can find some straightforward insights on this topic in the discussion — and feel free to apply that to all similar questions, especially related to web servers.

The Noteworthy Meta

And now, after some curious news from outside, I wanted to invite you to the internal news board of the Metaframeworks Weekly.

First of all, I participated in WebSummit Qatar recently and had some good casual conversations with peer web developers and software people from different companies in various industries. Long story short, almost all of them (excluding probably some weird cases of legacy Angular 6 apps and alike) build their websites and most of the web UIs with metaframeworks (and tools like Next.js and Astro specifically). People see the future of this ecosystem as bright and prevailing in the web software toolsets. That’s why I feel validated and driven to proceed with my research in the form of this project.

The second thing is, not sure if I mentioned that already here or elsewhere, but the website for the newsletter is open-source and available for external contributions. With that, there are lots of things I could make a mistake in (or went too opinionated about), starting from the details in the issues themselves, and finishing with the Metaframeworks Comparison. That’s why I hope for (and welcome) your participation in (and contributions to) making it better.

I have learned a lot during the work of the last three months: both about Astro, which this website is built with, and about newsletter curation which is a decent challenge by itself. I also experiment with some AI dev tools new for me, like Cursor. While I’m a big WebStorm fan, some of Cursor’s capabilities in helping with routine tasks like mass metadata updates or refactorings are invaluable. I still work mostly in good ol’ tools with disabled fancy autocompletes (hate that TBH), but I believe DX improvements from the disrupting AI startups may be handy sometimes, especially in some routine complex metaframeworks tasks. For instance, in the project’s repo you can find some useful Cursor AI rules, both related to Astro specifically, and more generic, about HTML/CSS and accessibility best practices. This is a nice tool for enforcing dev standards for teams that use AI assistants anyway, and it can tackle even sophisticated goals.

In my work I always try to go the progressive enhancement route, and this project is no exception. It started from the bare default Astro CLI blog template, and with time grew to get:

• Aforementioned Metaframeworks Comparison table, providing a good overview of the modern ecosystem, in addition to the regular news in the newsletter itself.
• Issue tags, allowing to filter the archive by topic, like this one. Interestingly, the tags are present in the comparison table too, at least for the metaframeworks mentioned in one of the newsletter issues.
• FAQ section with lots of details about the project and the website content, as well as some backstage information.
• View transitions, adding which was actually as simple and fun as adding a couple of lines to the Astro code, thanks to the Astro team.
• Lots of updates to the neighbouring Encyclopedia of Metaframeworks, contributions to which are also always welcome.
• A lot of ❤️ because of how interesting and engaging this experience has gotten for me.

As for plans for the future, I have a bunch of ideas on adding interactive experiences to learning the metaframeworks’ ins and outs, as well as some extended meta experiences to make consuming the metaframeworks content more engaging. I also have a draft for another adjacent helper project that may get you open-source tooling fans quite excited, so stay tuned, it’s gonna be a wild ride, I promise.

All in all, I want to thank all of you, the readers of this newsletter, because I feel the growing interest in the topic, no matter if the experience with metaframeworks for a person is positive or negative — we learn a lot on the way regardless of that.

👋