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.
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.
What works now:
* Tunnel proxies like ngrok. You can get an HTML page on the internet in 2 minutes with ngrok.
* Software like Caddy which simplifies certificate management.
* IPv6 and ISPs to drop NAT so we don't need proxies. Good luck.
* More upload throughput. Good luck.
* Services that make it much easier to register a domain name and manage DNS. Should be easier than buying and setting up a phone. This is ripe for the picking.
* Software designed with federated self hosting in mind. Like Inrupt Solid and similar projects.
OT: Text-to-speech has gotten really impressive these days. Took me a solid minute to figure it out.
Anecdata: I had a colleague think they were helping with something because they saw "domain forwarding" turned off for a domain that was used as a secondary domain for an existing site. It was all working absolutely fine, using server config and DNS. They turned it on and behind the scenes the "friendly", "easy to use" provider removed the custom nameservers and cleared the DNS records. When I initially turned the forwarding off again, it added some records to forward to its domain parking service. All of this was obscured and presumably done in the name of helping users.
If your call doesn't go through you check how many "bars" you have. If you have enough reboot. If it still doesn't work take it to a store.
If your car fails it displays a light. Check the manual or take it/have it towed to a shop.
There are annoyances but we know what to do.
The problem is that DNS was designed for developers. That's fine but we need an interface for the average Joe to own a domain name. Yes there will be challenges and tradeoffs, but we can sure do a lot better than where we are.
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.
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)
I use Wagtail as my CMS, so I dockerized it and put it on an ECS cluster. I then use Wagtail Bakery to publish the pages to S3. I then change the task count on the ECS service to 0. For a DB I use sqlite in EFS, so it's persistent and backed up.
I was previously running on an EC2, and cut the cost from about $15 per month to ~$1-2 per month. All I'm paying for is <1mb S3 storage, a single route 53 hosted zone, and one image in an ECR repo.
If I want to add content, I spin up the ECS task again and work away. Note that part of the reason for such a low cost is my website get VERY little traffic :)
Apart from the cost, I also have the advantage that it's lightning quick most of the time, with caching provided by CloudFront.
I did this to learn stuff. Seeing as I have little to say, my blog site is more of a technical playground than a valuable store of content.
I omitted that between the EC2 version and this current version, I built a really convoluted version with an ALB, Aurora, always-on ECS etc. That came to $80 a month. So then that motivated me to go the other way with the super cheap option.
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.
..or even Oracle Cloud Always Free Tier (which gives you 2x 1G VMs)
And OVH Cloud I believe has Singapore location:
No BSD options, but they've got a pretty good selection of Linux distros as ready made images.
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.
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) :)
Replace Cloud with Git: Store content without a server
Er, there has to be a server hosting Git somewhere.
I think someone just re-invented Netscape Communicator.
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.
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.
So what does it mean "Electron in a browser"?
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
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.
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.
I pushed out a starter template to make it easy to host a basic site with a few lines of code.
it's here (https://GitHub.com/ConflictingTheories/Calliope)
The point of static hosting is to simplify things, not feed into developer fever dreams of complex systems.
Wordpress is established, mature ecosystem that can provide almost any mainstream feature you could imagine.
I went to them after losing a weekend trying to stand-up my company's website after some ill-advised changes to my Wordpress instance (bad plugins caused Wordpress server to crash).
I haven't looked back since. Wordpress-based static hosting Just Works + makes sense
HardyPress was a similar alternative I evaluated. It had an issue failing to render some of my webpages to static....but maybe it's become better
(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.)
Assuming you turn on auto-updates to get security updates.. and do basic hardening like fail2ban.
Does it really need much handholding?
(Assuming you don't run vulnerable versions of various server software inside a docker container)
Curious, if going fully static is really that much better..
Can it use minio/s3 as a CDN ?
Can it also use one's own gitea/git instance ?
it's on [GitHub](https://github.com/ConflictingTheories/Calliope). It's designed for a simple clone and start.
"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.
If 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.
I guess they mean GitHub or GitLab or their equivalent - which are servers.