Our great sponsors
- SurveyJS - A Non-Cloud Alternative to Google Forms that has it all.
- Appwrite - The open-source backend cloud platform
- Amplication - open-source Node.js backend code generator
- Mergify - Tired of breaking your main and manually rebasing outdated pull requests?
- Sonar - Write Clean JavaScript Code. Always.
- InfluxDB - Collect and Analyze Billions of Data Points in Real Time
-
astro
The web framework that scales with you — Build fast content sites, powerful web applications, dynamic server APIs, and everything in-between ⭐️ Star to support our work!
As long as you have npm installed it'll work. Npm create is an alias for the npm init command [1], which will look for a package with the prefix 'create-', install it, and run its bin file. It looks like this is the file that ends up being run: https://github.com/withastro/astro/blob/main/packages/create....
-
Hugo (https://gohugo.io) maybe? I tried it for a small static site about internal documentation, and I'm very glad I did. The hardest part was reading the documentation, the installation, content generation and rebuilds were painless.
-
SurveyJS
A Non-Cloud Alternative to Google Forms that has it all.. SurveyJS JavaScript libraries allow you to easily set up a robust form management system fully integrated into your IT infrastructure where users can create and edit multiple dynamic JSON-based forms in a no-code form builder. Learn more now.
-
Not sure if you've heard of Publii?[0]
It's a static blog generator type thing, tried it a few times casually and it seems ok for non-devs to get something simple up and running.
The SEO defaults aren't perfect but they're easy enough to change in the software.
-
eleventy 🕚⚡️
A simpler site generator. Transforms a directory of templates (of varying types) into HTML.
Check out Eleventy[0] - written in JavaScript but largely no-nonsense with (relatively) few dependencies.
-
To add onto this, we recently added plugin support for templates, so you can write your own template functions if you'd like! https://github.com/caddyserver/caddy/pull/4757
-
gutenberg
A fast static site generator in a single binary with everything built-in. https://www.getzola.org
-
-
Appwrite
Appwrite - The open-source backend cloud platform. The open-source backend cloud platform for developing Web, Mobile, and Flutter applications. You can set up your backend faster with real-time APIs for authentication, databases, file storage, cloud functions, and much more!
-
-
That same thinking is what led me to build [Primo](https://github.com/primodotso/primo) - a SSG in a desktop/server CMS. It’s the only thing me or anyone I know who’s uses it uses to build normal websites anymore bc it’s so much faster to get a site up and easier to write code/content.
-
I haven’t done any serious work with either, but I’ve been following both closely (and have contributed a bit to Astro early on). So this isn’t the hands-on response you specifically asked for, and may not contain new information to you. I’m posting anyway in case it adds context for others.
Qwik City[1] is probably more directly analogous to Astro, Qwik being more analogous to Astro’s integrated renderers. But that highlights one of the key differences.
Astro’s compiler mostly focuses on server rendering of static content (.astro templates, MDX) and bundling client resources along with the logic necessary to hydrate islands. Astro defers to those renderers (and in some cases their own compilers) for any further optimization of the client bundle.
Qwik’s compiler optimizes the component code directly, serializing state into the HTML it renders server-side, for the client bundle to resume from that state. Its output is conceptually similar to Phoenix LiveView (which was mentioned in another sub-thread).
Both are compelling approaches. I think Qwik’s will probably (eventually) have an optimization advantage because that’s a core focus of the client library. Astro will likely have an adoption advantage because it’s client-library-agnostic.
Another framework in the space often gets passed over: Marko[2], which has been doing partial hydration for years at eBay. Marko is probably more similar in approach to Qwik (and as I understand it, getting more similar as they’re going resumable too), but like Astro has its own templating language which enables its compiler optimizations.
Also worth watching SolidJS[3] (whose creator has also worked on Marko), which is tracking partial hydration/resumability on its roadmap. I’m not sure what their approach will look like but there’s quite a lot of insight both in the issue and the creator’s tweets/replies on the topic.
Personally I think there’s a gap between all of these approaches which could leverage type-level analysis to go much further. But that isn’t really feasible when types being available or accurate isn’t a safe assumption.
-
I haven’t done any serious work with either, but I’ve been following both closely (and have contributed a bit to Astro early on). So this isn’t the hands-on response you specifically asked for, and may not contain new information to you. I’m posting anyway in case it adds context for others.
Qwik City[1] is probably more directly analogous to Astro, Qwik being more analogous to Astro’s integrated renderers. But that highlights one of the key differences.
Astro’s compiler mostly focuses on server rendering of static content (.astro templates, MDX) and bundling client resources along with the logic necessary to hydrate islands. Astro defers to those renderers (and in some cases their own compilers) for any further optimization of the client bundle.
Qwik’s compiler optimizes the component code directly, serializing state into the HTML it renders server-side, for the client bundle to resume from that state. Its output is conceptually similar to Phoenix LiveView (which was mentioned in another sub-thread).
Both are compelling approaches. I think Qwik’s will probably (eventually) have an optimization advantage because that’s a core focus of the client library. Astro will likely have an adoption advantage because it’s client-library-agnostic.
Another framework in the space often gets passed over: Marko[2], which has been doing partial hydration for years at eBay. Marko is probably more similar in approach to Qwik (and as I understand it, getting more similar as they’re going resumable too), but like Astro has its own templating language which enables its compiler optimizations.
Also worth watching SolidJS[3] (whose creator has also worked on Marko), which is tracking partial hydration/resumability on its roadmap. I’m not sure what their approach will look like but there’s quite a lot of insight both in the issue and the creator’s tweets/replies on the topic.
Personally I think there’s a gap between all of these approaches which could leverage type-level analysis to go much further. But that isn’t really feasible when types being available or accurate isn’t a safe assumption.
-
