Issue #52: Never Too Late

🎵 This world will never be what I expected, and if I don’t belong, who would have guessed it?.. 🎵

This issue of the newsletter is special, not only ‘cos 52 is my grandmother’s apartment number which will always be magic to me. And the title refers to not only this issue seeing the light of day a bit later than it should have. It’s rather because of so many other things. Like long development, proliferation of artificial things making real things out of fashion, finding something you missed before, and so on. Fancy digging into?

The Good

Meteor is not the most hype technology of these crazy days but it definitely is one of the most robust batteries-included fullstack approaches around for ages. One thing about that which went silently under many radars is the release of Meteor 3.5 — quite an important update to the corresponding platform infrastructure.

Meteor’s signature feature has always been real-time reactivity: you write a publication, the client subscribes, and the UI updates when the data changes. No sockets to manage, no invalidation logic to write. Since around 2014, the engine behind that magic has been oplog tailing.

And now this magic goes away in favour of the MongoDB Change Streams which is quite an exciting technology if you think about it.

MongoDB Change Streams invert the model. Instead of consuming the entire firehose and filtering it locally, the driver asks MongoDB to watch a specific collection with a specific query — and MongoDB pushes back only the changes that match.

The update brings an impressive 40% increase in connection capacity.

This direction echoes reactivity optimizations happening in the web frameworks not only on the server side but on the client too. Solid creator Ryan Carniato just wrote about the [unstable!] approach of async writes without hand-built optimistic-state machinery in the framework. And even though I’m not a big fan of optimism on UI, the idea and implementation are impressively solid (of course), in race condition mitigation part at least.

SvelteKit also actively works on bringing its own reactivity models to the next level with coming version 3, the release candidate for which recently went for public testing. I will miss svelte.config.js leaving in favour of vite.config.ts (well, everyone does this move these days after all) but other than that, there are lots of technical improvements, finished chores, and progressing experiments leaving the metaframework fans excited and giving some food for thought and discussions at the coming regular autumn Svelte Summit.

Quasar maintainers published two substantially important minor releases. The first of them, 2.25, is centered around accessibility and scalability for the metaframework (which already has a lot to be brave about) with really impressive performance gains. The second one, 2.26, brings cool improvements for consumer user experience, like better processing of hybrid devices access, along with some technical benefits and deeper cleanup.

The Bad

But that’s not the most huge cleanup around, that’s for sure. We know (and it’s hard to miss) that the importance of a tool or a framework vanishes lately, with proliferation of platform-driven development (where under “platform” you can read Vercel, Netlify, Cloudflare, to name a few) especially as all the platforms either already have their own metaframeworks or can vibecode one in a weekend if they feel like it. Same for different corresponding infrastructure parts. One of the AI powerhouses, Lovable, who recently migrated their infrastructure from Vercel to Cloudflare, decided to also adjust other bolts and nuts and shared some insights on their migration from Next.js to TanStack Start (which had recently become their weapon of choice for AI masterpieces built with the tool). Obviously this migration does not say anything about any pitfalls of Next.js by any means but the trend is quite characteristic. Interestingly, this slick experience is a good reminder that avoiding vendor lock-in is not exactly about staying away from specific metaframework choices but rather about proper decoupling of product business logic, browser-exposed code, and runtime-specific shenanigans.

Next.js on their side, sweetening this pill up slightly, shared some new technical details about their Instant Navigations feature (with neat demos attached) allowing to match the app-like experiences of SPAs without dropping server components’ performance benefits. Another not that merry news about eternal security-related fights came afterward, but as we know, it’s already a routine regular telegraph message for everyone (officially!) rather than any surprise or disappointment.

The Noteworthy

And talking about routines, I wanted to share some backstage news about this newsletter if you care to listen (and if not — I don’t blame you and would be happy to meet in the next issue!). My friend told me that they were blamed in their company’s Slack for sharing one of the links from this newsletter containing some analytics attributes. I mean, we see that a lot around but that’s indeed not something I planned to have in my newsletter as I personally hate that. So luckily I stumbled upon this interesting post about the topic from my host Buttondown and (hopefully! 🤞) stripped all the tracking stuff away from this publication from now on. And I’ll appreciate if you tell me the fix doesn’t work in response to this letter if that’d be the case.

Another thing I wanted to share is my deviation toward collapsing the amount of monthly issues of this newsletter to precisely one (with some exceptions!) because of the growing enshitification of the global web-development-related informational space. I appreciate full-stack web development sincerely as my labour of love but the amount of neuroslop, both in terms of the content and in terms of the actual tooling around, has become hardly bearable to intellectually fight through. I will still try to do it as often as possible, to help myself in self-educating and working on Gridmix, maintaining top-10 metaframework security risks and the encyclopedia, not to mention expanding this project’s scope to some side ideas, BUT consuming the corresponding content on the Web has become toxic and poisonous. I have left DEV.to and Bluesky because of that, and try to protect my human sanity from robotic non-human impact as much as possible. Things may change, but up until that, I plan to publish the issue #53 closer to the end of September and I’m really excited to see what the world of metaframeworks will bring us by this time.

It’s never too late for humanity to draw creativity back, especially with awesome tools like metaframeworks. Even though I bet it won’t be easy and there will be scars and wormholes.

👋