Very cool. Every existing criticism about static site generators seems to be gone with this approach. Many interesting ideas in there, like the service worker instead of cloud, and an actual git flow in the browser. Looks almost like more than just a static site generator. This could get rid of the cloud itself.
We have to stop this. Words are either effective at communicating the speakers meaning or not. We all know what is meant by serverless and "without a server" and so you are only introducing ambiguity by purposely confusing the actual meaning with the literal meanings of the individual words.
If I call someone an asshole nobody is like "but actually an asshole is just one part of..."
Personally I dislike the "serverless" word too, it's still not clearly defined and there are indeed servers being used that can still somehow crash, run out of resources, be hacked, etc.
CDN is by all means considered "serverless". Yes in anything that is "serverless" there's a server somewhere but you don't have to maintain it, you get charged by usage only so no running cost. Now their claim about being deplatform resistant is probably not true though as someone is running that CDN and can just as easily deplatform you. But serverless in the ops community does not mean literally no server is running.
For instance Lambda must have a server running these tasks, it mean it is not of your concern and you don't pay for a long running process.
At the very bottom it is still putting content on Cloudflare, GitHub Pages, Netlify, Vercel, etc.
I can't tell if the content is encoded somehow (base64, etc). If not, this will be confusing for search engine crawlers, as they'll find duplicate content, and perhaps rank it higher.
I kinda feel like the premise is already pretty amiss - a simple, small site that serves static pages puts absolutely no demand on "running a server", you're perfectly fine with a basic hosting plan that will require little to zero maintenance and be really cheap.
The idea that you'd have to "run a server" or else "use ready made SaaS platform" feels like a constructed problem.
Not in the sense of that blogpost. They say about SAAS:
> Problem: The service provider will lock you in. No full control over your content.
this is clearly does not apply to basic hosting plans. You have full control, an there is no lock-in at all -- all of those hosting plans are basically equivalent.
This is a quite an interesting architecture that could also be used for developing on the browser. I imagine some of the existing browser development tools use something similar
For my personal site, I switched to Marijn Haverbeke's Heckle <https://marijnhaverbeke.nl/blog/heckle.html> several years ago. I realized that I could pretty easily do a rewrite that uses my browser's native JS engine + browser APIs instead of requiring NodeJS and depending on the slipshod fragility of the NPM ecosystem. The result is triickl:
What's more is that, because I also created some tools that allow triickl (and similar programs) to be packed into a single, self-contained file that can run in the browser (e.g. buildfoo.html or pages.app.htm), it's pretty natural to let there be a page on the target site corresponding to this file. The end result is that if you're using triickl, you can clone the site's source repo and then use buildfoo.html to generate the static assets. In other words, so long as you're able to get your hands on the source tree, then every computer is already a development system.
Ah, this comment makes it clear for me, and you're right...a
serverless CMS editor appears to be the main benefit. That would be valuable for some, but the message wasn't coming across for me.
I agree, many always start with the premise "hosting is hard", but maybe this was true 20 years ago, now hosting providers let you spin-up a server in a few clicks, have monitoring, alerts, automatic updates and more. The good part is that for 99.99% of the time, once you set-up a server it could keep on running without issues for many years.
I am not a sys-admin but I have used multiple hosting providers (shared, VPS, dedicated) and so far I never had a single server fail or suddenly stop working.
True, sadly shared hosting still limit with capped disk IO and bandwidth at a premium price which would be similar or more than competitive VPS in performance.
I'm still looking out for competitive VPS provider other than UpCloud if you have any recommendations.
I think this title is askew. The secret sauce here is that this has a GUI CMS that runs without a server. There's plenty of flat file static site generators that don't require a server.
Every single one doesn't require a server. 11ty deployed to Netfliy is probably the most simple way get started.
Because everybody is clamoring to label themselves a react dev, Gatsby is also en vogue. Jekyll is the OG.
But while they don't require a database/server/etc, static sites do require a spaghetti mess of fragile dependencies on build, so have fun troubleshooting that.
TBH I don't build static sites anymore. They're cool for one-off pages, but any site that needs new content and regular updating is going to turn into a nightmare if you go the SSG route. And don't get me started on the many downsides of Headless CMS's.
In fact, the "evil Saas solutions" that this landing page bemoans are now exactly what I want. I've gone full Webflow now. Saas is just a better model for everybody involved.
I recently dig up some old folders on my musheen and found harpjs back. It's a really nice static sige generator that I found easier to grasp than 11ty, gatsby, etc.
> Every single one doesn't require a server... Netfliy is probably the most simple way get started.
Netlify is... A SERVER (actually many servers).
The only ones that DON'T require a server are distributed. The only ones I'm aware of use IPFS or Hypercore protocols (formerly DAT). Hypercore's probably the easiest as it is built into the Beaker browser and has been around in an easy browser accessible form for a while now, but Brave has just added support for IPFS.
Pipette and Orkl are static blog apps for Hypercore. There are probably others. I don't know the IPFS world well, so I dunno what's there.
Practically speaking though, the limited number of people hosting Hypercore / IPFS nodes means that the content you want is likely not available on the network at the moment _unless_, you guessed it, you put some of it on a server that's always on.
I can't tell for sure, but it sounds like it puts an abstraction in front of the CDN (via the WYSIWYG editor), such that moving to a new one wouldn't be hard. It mentions Cloudflare, GitHub Pages, Netlify, and Vercel as backends.
I like the idea of a program (eh it's in javascript but whatever) that let people create personal websites without having to understand all the complexity of the web, and that allow people to keep control over their data.
It's in the "internet is for everyone so let everyone use it and create things with it easily" project category (which is my favorite) :)
My first thought based on the video is that its serverless, so it can't be deplatformed or taken down, but it does not appear to be the case since you are still hosting it somewhere, so those looking for having a blog that can't be deplatformed will be disappointed. I believe there are other products that DO do that to some extent, though.
However, taking out that premise, it still looks interesting, and I would love to try it out. I tried to get someone on one of the static site generators but just getting everything setup on their computer and then teaching them the needed workflow was not trivial, and not something I would try again with anyone less tech-savvy or without being there with them during setup and teaching. I've seen platforms that simplify, but then you are paying a fee again for that too.
Netlify CMS stores content on their cloud. This looks like it lets you store on your own git repository directly from the browser, avoiding potential lock-in.
Each post will be written in Dumbdown, but then also
a whole "blog" (posts, settings, pages, etc), you will be
able to view/edit in a single textarea, and copy/paste the
whole thing. So you should be able to write a whole site
in the client side JS app, use local storage for persistence,
and then copy/paste either the raw Tree Notation files to
import/export the site, or just the compiled HTML. Then
just need a one click "write this site to a Git repo", and
then GitHub/GitLab/etc can handle long term persistence,
version control, and site hosting.
Happy to talk more to the authors off offbase if it would help.
I think there could be some synergy here.
Thank you, in the video I intentionally positioned Offbase as a "static site generator" and a "blogging engine" just to focus the minimal viable product and avoid confusion, but the actual platform I'm working toward releasing is really a generic shell that can run anything, the blogging package will be the one thing I will focus on building myself, but since it will be a completely open platform where you can download any git repository into the browser, anyone should be able to build their own package. For example you can build a documentation engine package, or an image editor package. And going further, even the static site generator logic itself is nothing more than a single use case where it simply runs a template logic and writes to the virtual file system, while using the service worker to render the files in realtime, for example. You can think of Offbase as something like Electron, but in a browser. This means a lot of things that you used to need a server for, you can build with Offbase purely inside the browser. Which means, I think Offbase may fit right in with what you're trying to build, it should handle a lot of headaches you might otherwise have. Will try to get this rolled out public as soon as I can, it's almost there, just trying to deal with some last mile problems and documentation.
It lets you write to files. Except that these are files that exist in a self contained virtual file system in the browser. You can do things like fs.writeFile() or fs.readFile() (like electron, but without needing a desktop app, but directly inside the browser), and push that entire file system to a remote git repository, or pull from one.
I hate to be the person that needs to point it out, but you can't say replace "the cloud with x" and replace "servers with x" and then 500 pixels down the page talk about how you're pushing your static site to a CDN. Perhaps the target audience won't recognize how dishonest that is, but it's still a lie.
I genuinely thought at first that they meant the git repo was hosted in the service worker (like through isomorphic git) and I was like, what if you want to write on a different machine?
Perfectly sound architecture that does not need an intermediary like Netflify:
1. Browser-Side Service Worker
2. Git - mutable file system via REST
3. CDN - deploy to multiple CDNs
I didn't look at the code but I suspect it could be made to be isomorphic and run in Cloudflare Workers but the code surrounding credentials used for Git and CDN access probably needs to distinguish between the browser-side and server-side.
Could run Git entirely in the browser (isomorphic-git). Then use peer2peer to host the content.
The web editor/static site generator could be bootstrapped from a bookmark/URL that pulls the app from peer2peer.
My personal website uses cloudflare workers / cdn to host a CMS-over-GUI system. Has a lightweight automatic git-like CVS for visibility and versioning. Does basic auth too. Just wanted to bring up that this is a very real possibility. ¯\_(ツ)_/¯
(I wouldn’t have thought that there was any good option. If you reject the use of an intermediary proxy, then I think the only two options are: to do something forge-specific, which is rather limiting and quite contrary to the purport of the project; or to use the smart protocol over HTTPS, but that’s going to be CORS-blocked, to say nothing of the security aspect probably being a pain—if I recall correctly, GitHub for one now requires you to use a token for authentication over the HTTPS protocol, so it’s never just a single step any more.)
Maybe I'm missing something, but it appears that the only difference between this and other static site generators is that you can edit stuff in the browser, right?
I usually just edit my pages in VS Code, or any other markdown editor. Then I push to a Git repository, and my CDN (Netlify, Vercel, etc) builds the site automatically.
That is how I interpreted it, but I think their marketing is completely wrong. Developers will do what you do. Marketing / Small biz owners do not want to learn git, cdns, etc.
https://forestry.io/ removes the complexity, but keeps all of the benefits of git static hosted websites allowing non-technical people to manage static websites.
Developers wont use this, but non-technical people _might_.
97 comments
[ 10.4 ms ] story [ 160 ms ] threadIf I call someone an asshole nobody is like "but actually an asshole is just one part of..."
Please feel free to furnish us with a definition that includes this product but excludes the existing solutions.
edit: The original title said "with no server". I would understand "serverless", since I'm familiar with that jargon.
"Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."
For instance Lambda must have a server running these tasks, it mean it is not of your concern and you don't pay for a long running process.
I can't tell if the content is encoded somehow (base64, etc). If not, this will be confusing for search engine crawlers, as they'll find duplicate content, and perhaps rank it higher.
The idea that you'd have to "run a server" or else "use ready made SaaS platform" feels like a constructed problem.
> Problem: The service provider will lock you in. No full control over your content.
this is clearly does not apply to basic hosting plans. You have full control, an there is no lock-in at all -- all of those hosting plans are basically equivalent.
https://news.ycombinator.com/item?id=24495646
For my personal site, I switched to Marijn Haverbeke's Heckle <https://marijnhaverbeke.nl/blog/heckle.html> several years ago. I realized that I could pretty easily do a rewrite that uses my browser's native JS engine + browser APIs instead of requiring NodeJS and depending on the slipshod fragility of the NPM ecosystem. The result is triickl:
https://codeberg.org/triplescripts/triickl
What's more is that, because I also created some tools that allow triickl (and similar programs) to be packed into a single, self-contained file that can run in the browser (e.g. buildfoo.html or pages.app.htm), it's pretty natural to let there be a page on the target site corresponding to this file. The end result is that if you're using triickl, you can clone the site's source repo and then use buildfoo.html to generate the static assets. In other words, so long as you're able to get your hands on the source tree, then every computer is already a development system.
From the landing page I'm unsure what type of person would benefit from this and what problem you're solving for them.
I already can publish from git directly to Netlify's "distributed CDN." That's the default setup for all static site generators, no?
Or is the difference here that you get a CMS editor built-in to your static site?
Interesting premise I think, especially if they can make the git experience somewhat more friendly for less technical people.
Shared hosting doesn't need effort to maintain server and have been done for long time? There are a few free hosting.
There is a need for more than just CMS, I have been working on the new idea.
I am not a sys-admin but I have used multiple hosting providers (shared, VPS, dedicated) and so far I never had a single server fail or suddenly stop working.
I'm still looking out for competitive VPS provider other than UpCloud if you have any recommendations.
No BSD options, but they've got a pretty good selection of Linux distros as ready made images.
..or even Oracle Cloud Always Free Tier (which gives you 2x 1G VMs)
And OVH Cloud I believe has Singapore location: https://www.ovhcloud.com/en-sg/vps/vps-singapore/
Because everybody is clamoring to label themselves a react dev, Gatsby is also en vogue. Jekyll is the OG.
But while they don't require a database/server/etc, static sites do require a spaghetti mess of fragile dependencies on build, so have fun troubleshooting that.
TBH I don't build static sites anymore. They're cool for one-off pages, but any site that needs new content and regular updating is going to turn into a nightmare if you go the SSG route. And don't get me started on the many downsides of Headless CMS's.
In fact, the "evil Saas solutions" that this landing page bemoans are now exactly what I want. I've gone full Webflow now. Saas is just a better model for everybody involved.
http://harpjs.com/
Netlify is... A SERVER (actually many servers).
The only ones that DON'T require a server are distributed. The only ones I'm aware of use IPFS or Hypercore protocols (formerly DAT). Hypercore's probably the easiest as it is built into the Beaker browser and has been around in an easy browser accessible form for a while now, but Brave has just added support for IPFS.
Pipette and Orkl are static blog apps for Hypercore. There are probably others. I don't know the IPFS world well, so I dunno what's there.
Practically speaking though, the limited number of people hosting Hypercore / IPFS nodes means that the content you want is likely not available on the network at the moment _unless_, you guessed it, you put some of it on a server that's always on.
(maybe a bit rabbit hole-ish but you can rank by popularity and filter by language and template)
Can it use minio/s3 as a CDN ?
Can it also use one's own gitea/git instance ?
It's in the "internet is for everyone so let everyone use it and create things with it easily" project category (which is my favorite) :)
However, taking out that premise, it still looks interesting, and I would love to try it out. I tried to get someone on one of the static site generators but just getting everything setup on their computer and then teaching them the needed workflow was not trivial, and not something I would try again with anyone less tech-savvy or without being there with them during setup and teaching. I've seen platforms that simplify, but then you are paying a fee again for that too.
The whole "Git is eating the database world" trend is picking up steam.
MDN/Yari, mentioned recently on here was another similar one https://github.com/mdn/yari
I am planning on doing something similar to Offbase with Dub (https://github.com/treenotation/dumbdown/tree/master/dub).
Each post will be written in Dumbdown, but then also a whole "blog" (posts, settings, pages, etc), you will be able to view/edit in a single textarea, and copy/paste the whole thing. So you should be able to write a whole site in the client side JS app, use local storage for persistence, and then copy/paste either the raw Tree Notation files to import/export the site, or just the compiled HTML. Then just need a one click "write this site to a Git repo", and then GitHub/GitLab/etc can handle long term persistence, version control, and site hosting.
Happy to talk more to the authors off offbase if it would help. I think there could be some synergy here.
Uhh, the messaging is now even more confused.
Electron is a framework for creating native applications with web technologies like JavaScript, HTML, and CSS.
The browser is a framework for creating web-based applications with web technologies like JavaScript, HTML, and CSS.
So what does it mean "Electron in a browser"?
You're not replacing anything.
1. Browser-Side Service Worker
2. Git - mutable file system via REST
3. CDN - deploy to multiple CDNs
I didn't look at the code but I suspect it could be made to be isomorphic and run in Cloudflare Workers but the code surrounding credentials used for Git and CDN access probably needs to distinguish between the browser-side and server-side.
(I wouldn’t have thought that there was any good option. If you reject the use of an intermediary proxy, then I think the only two options are: to do something forge-specific, which is rather limiting and quite contrary to the purport of the project; or to use the smart protocol over HTTPS, but that’s going to be CORS-blocked, to say nothing of the security aspect probably being a pain—if I recall correctly, GitHub for one now requires you to use a token for authentication over the HTTPS protocol, so it’s never just a single step any more.)
I usually just edit my pages in VS Code, or any other markdown editor. Then I push to a Git repository, and my CDN (Netlify, Vercel, etc) builds the site automatically.
https://forestry.io/ removes the complexity, but keeps all of the benefits of git static hosted websites allowing non-technical people to manage static websites.
Developers wont use this, but non-technical people _might_.
ps: I have no association with forestry