What’s really nice about it is the focus on core simplicity: no build is required to run anything, built on standards and vanilla ESM.
By default it is good for static sites or server-rendered sites, with backend GET/POST/ETC handlers (basically just REST, with HTML templating), but doesn’t have the full-stack-reactive DB-connected features out of the box that Meteor has.
What is really interesting is it is build less by default, just plain JavaScript (but add build steps via plugins if you want to).
I like the thought exercise of imagining something like Meteor built from a simplicity-focused foundation like Mastro’s, where out of the box the full-stack-reactive features (via plugins) would simply run without a build (add builds optionally, for example if you write TypeScript, CoffeeScript, Less, etc, but no build at all to start with).
This reminds me of some of the simplicity ideas we chatted about in other threads like this one:
Edit: sorry, I think I pocket-posted a draft from my phone!
Looks interesting - are you working on this one or just something you came across? At first I thought you were sharing your own but then I realised your name and the maintainer’s name are different (sorry, it’s a hot Friday downunder and the brain isn’t working).
I wonder if it’s targeting something a bit like the server-side chunks of Astro (I guess Nitro might be a better comparison) but without the complex build machinery… but seeing as there’s a Markdown compilation plugin, my main thought would be that there’s a chance/risk/opportunity(?) for this to converge on something with all those other tools in the end anyway.
After all, when it comes to the WinterTC style APIs, there’s already some convergence on this general style of framework with Astro, Nitro, Deno Fresh, Hono etc which is nice. WinterTC is a huge influence behind that but it’s nice to see those ideas filtering through across the ecosystem now where they’re no longer “weirder” than using the Express API or some arbitrary Cloud function interface.
That said, and perhaps going in the opposite direction from API standardisation and file-based routing, I find myself drifting more to things like Django and (in spirit) AdonisJS, which are both getting some love from Galaxy recently. Every time I get stuck into a file-based routing project I just feel things become less coherent from a broader architectural perspective. Too many times I’ve needed to move routes around or alias things, or wanted my business logic pretty close to my routes.
Less helpful thoughts: the name triggers my Esperanto-senses, and now I can imagine a whole package ecosystem based on the ill-advised use of Esperanto grammatical suffixes.
This framework is really interesintg, but as I can see it’s more for focused in frontend, right? in specific for *content-driven websites at least in the present moment
Can you share a little bit more yous plans fot the future @mb21 ?
what exactly do you mean with “frontend”? That it doesn’t ship with auth and a database included, or…?
The “content-driven” part mostly refers to Mastro being proudly server-first. While you can add a bundler, SPA-router etc, that’s not really what Mastro was designed for. If that’s what you need for your project, you’re probably better off with a Vite-based framework like SvelteKit, Solid Start, or similar. But for most websites (perhaps as opposed to webapps like Google Docs), this adds a lot of complexity, and often leads to worse performance for most users.
(sorry, it’s a hot Friday downunder and the brain isn’t working).