Our great sponsors
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
The link you posted from Gaeron uses the (now deprecated) pages router, directly supporting my argument.
I did a migration from pages router to app router for my static-export project. Btw both are still present in v13, you can pick whichever you want, but long-term the pages router will be gone.
With static redirect/rewrites I mean the feature in pages router where you put in the "redirect"/"rewrite" statement in your next.config.js. These will be respected and work in a static export environment. If you try to perform a static export using app router, it will error and tell you that you have to remove "redirect"/"rewrite" from next.config.js and it is no longer supported.
Yes, you could use a middleware for redirects, but that is exactly my point: Middlewares do not work with static exports, they are middlewares for the server-side next server. Which is not present in a static export (and requires running your own server again, or use vercel's offering).
The same holds true for shallow routing for static exports, it is a feature still present in pages router, but not in app router. There is a GH issue of a lot of users complaining about this, but no feedback from the maintainers whether this is planned to bring back: https://github.com/vercel/next.js/discussions/48110
https://github.com/graphitemaster/incbin
So here's the interesting part - we decided to build executables in a way that data in those executables could not be changed (makes sense since it's compiled and the compiled code runs on the machine, and for security reasosns).
That said, think about what a container (e.g. docker) is. A running container is kind of like a packaged executable, except it also has a filesystem.
So if you pack data (which can be modified and runtime!) into a container, it's a similar concept to an embedded resource in an executable, except it can change.
Now, in a container, any changes made to data at runtime inside rhe container won't persist unless the container is given persistent storage.
What I've been wondering lately is why we didn't invent some kind of single "executable plus volatile data space embedded within the executable", so that programs and data (say, a database) could couple together into a single file.
Just a musing but tangentially related to your "baked data" - basically, embedded resources in executables just embeds the encoded data right into an executable.
For scripting languages, of course, we can just make a script file that contains a variable with the encoded data as base64 directly.
For the latter 2, it's only good for relatively small static data of course, but it would be interesting to build tech that somehow lifted that constraint of executables.
Products like [decap CMS](https://github.com/decaporg/decap-cms) try to bridge that gap, but I agree that this space needs to be further developed. In fact I think there needs to be a bunch more work to allow mere mortals to use version control and branch workflows in day to day work.
I think one big missing part still with static sites is how you host the CMS to edit it.
Correct me if I'm wrong but Decap CMS (previously Netlify CMS) runs in the browser and makes reads/edits via GitHub which can then trigger rebuilds and deploys, but it still needs a small server/proxy I think because CORS stops your browser communicating directly with the GitHub API. Netlify hosts a GitHub backend that proxies requests for you but now you're tied to Netlify.
GitLab and BitBucket will have the same issue I think: https://github.com/isomorphic-git/isomorphic-git#cors-suppor...
Is there a simple solution here with minimal configuration?
Lektor CMS is sort of a prototype-ish thing doing this: https://www.getlektor.com/
It has (used to have? Can't find them on the site now) pre-packaged binaries that you would drop into a folder structure generated by the technically-minded person, and the content editor can simply click on that binary, which opens the backend of the CMS in the web browser, make changes and click deploy.
I haven't used it, but Publii[0] might be along the lines of what you're thinking of. I ran across it in a previous HN discussion, and it seems to be static site generator with a pretty user-friendly graphical interface.
[0]: https://getpublii.com/
I agree and, as the author of vite-plugin-ssr[1], that's what I recommend to my users: go for static whenever you can.
I think it's something every web developer should be aware of. Static is indeed a lot simpler than dynamic.
I've wrote more about it over here[2] (SSG = static, SSR = dynamic).
[1]: https://vite-plugin-ssr.com
I’ve been down this path enough times that I built https://sitepress.cc/, which lets you embed content in a rails app with features that are present in Jekyll, Middleman, etc. like Frontmatter, site hierarchy traversal, etc. It keeps content as files in the app/content directory, but when it’s time to pull data in from the Rails app for SEO, it’s all right there in the Rails app. There’s no “Headless CMS” crap to jump through.
For me, this is another way of keeping everything in a monolith, and which requires a lot less context switching. If I’m building a feature and I want to create marketing or support content for it, it’s all right there in the same repo. I just create the markdown files I need, commit them to the repo, and I’m don.
The thought of switching between a static content site or something like Webflow just seems silly. I think they only makes sense for huge teams.
Recently, while talking to a friend who hosts her website on Wix, I noticed that she was using it as a portfolio website and I asked what wix-specific features she was using and her answer was "domain management" and this got me thinking...what if the steps were pretty straight-forward, could someone who is not a web dev or technical get a website up on github? So I started putting together a template that looks very similar to her website and also includes instructions on how to host it on Github Pages for $0/year versus what she is currently paying Wix at around $100/year. The template is here: https://github.com/usmanity/rose
It's on https://github.com/nicbou/ursus. A slightly older version is on pypi. It's been running for a few months now, but only for two websites.