Offbase: Static site generator in a browser | Hacker News Reader

Offbase: Static site generator in a browser

offbase.org

157 pointsskogard92 comments

You may want to rethink the messaging here.

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?

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.

Chromebook without the Linux partition? Constantly changing devices? ...?

Interesting premise I think, especially if they can make the git experience somewhat more friendly for less technical people.

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.

The buck stops earlier than that. "Replace the cloud/server with git" - where is git hosted? On your server or the cloud.

You're not replacing anything.

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?

yeah. if it ain't on a server / cloud no-one will be able to access it regardless of if it's in git or not.

Yeah, and I would coin CDN as Cloud Debris Network, where abandoned pet projects and crap content is orbiting forever forgotten.

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. ¯\_(ツ)_/¯

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.

So much complexity to get an HTML page on the internet. IMO the future of data ownership is self hosting from devices like raspberry pi's and upcycled Android phones.

What works now:

* Tunnel proxies[0] like ngrok. You can get an HTML page on the internet in 2 minutes with ngrok.

* Software like Caddy which simplifies certificate management.

What's needed:

* 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.

[0]: https://github.com/anderspitman/awesome-tunneling

On the domain/DNS side, how do you see things being simplified? Services like GoDaddy already try to do this, but in hiding functionality or renaming key terms to dumb them down, they confuse things further for anyone using mainstream materials to reference or learn from. TTL is often dumbed down to an "auto" setting - fair enough, but beyond that how much more can you simplify within the existing technology frameworks? (Admittedly all the verification and security records are getting a bit out of hand, but they aren't compulsory.)

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.

I see it being simplified the same way phones and cars have been simplified. These are very complex systems with simple interfaces and well understood failure modes.

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.

If every link in the chain supports IPv6, can you connect directly to a computer behind a NAT by using IPv6? Or are IPv6 connections NATed too and we’re likely stuck with this for the foreseeable future?

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.

There are also other static site generators with a CMS component. Lektor - https://www.getlektor.com/ - comes to mind.

Can you list a few? I have been wanting to play with an SSG. (Googling sends me down a rabbit hole.)

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.

> 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 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.

http://harpjs.com/

A list of 332: https://jamstack.org/generators/

(maybe a bit rabbit hole-ish but you can rank by popularity and filter by language and template)

Gatsby is the hot one for react. Jekyll is the granddaddy and probably has the most broad support. Gridsome for vue is good too.

I recently moved my personal website (https://chrxr.com) to a static site in a rather complicated fashion.

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.

https://rakhim.org/honestly-undefined/

Now I feel bad about my planned two-parter on my elaborate blog setup :)

Looking back at this comment, I realize now that it's pretty pointless... just excited to play with stuff. Sorry folks! Enjoy your day.

So you’re saying, something like this would save you loads of time? Or do you think it’s unnecessary?

I think this is catering to a specific audience who is not me :) I actually find that the complexity of self hosting is the interesting part.

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.

"Not everyone can afford the time, money, and effort to maintain a server."

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 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.

Look at BuyVM, OVH (SoYouStart/Kimsufi), Netcup.eu. All very solid providers and I have servers/VMs with all of them.

..or even Oracle Cloud Always Free Tier (which gives you 2x 1G VMs)

I think that most of the VPS providers have similar prices, I personally use DigitalOcean as I really like their interface.

True, I have been comparing performance and long-term contract which I have research on shared hosts and VPS providers.

I like Linode personally.

No BSD options, but they've got a pretty good selection of Linux distros as ready made images.

I have Linode years ago and moved on when the pricing and performance weren't competitive as UpCloud.

Same, I have been using Linode for almost 10 years for small projects.

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 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) :)

"Offbase solves the problems above by getting rid of the server altogether:"

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.

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.

Isn't that basic hosting plan still a ready made SaaS platform?

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.

Isn't putting something on Github to host it still a ready made SaaS platform?

Yes but you can run offbase of a local git repo (judging from the post)

only in the sense that you'll pay rent for it, it's not "software" and will let you run your own stack with no added cost and full portability.

This is great!

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.

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.

> You can think of Offbase as something like Electron, but in a browser.

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"?

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.

Where can I go to learn how to do this? It's an awesome concept. Are there any resources you can point me to?

A CDN is a server. It is actually a lot of servers!

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_.

ps: I have no association with forestry

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

I've been advocating for this type of thing, especially since a lot of the tooling around NodeJS is so bad, viz:

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.

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.

if anyone is interested. I have a similar project called Calliope which is open source and based on similar principles. except that you get the admin panel and can either serve or static generate your site.

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)

Just signup for Shifter (https://www.getshifter.io/) and call it a day.

The point of static hosting is to simplify things, not feed into developer fever dreams of complex systems.

Plus, 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

ps 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

How does it pull from and push to a Git remote?

(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 still think a plain old PHP site works just as well, and is easier and more flexible than any SSG system.

How risky is it to run an Ubuntu server?

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..

Its not really risky, but it requires some knowledge that not all people are willing to learn in order to host a html file to share thought.

OoOoooh that seems cool !

Can it use minio/s3 as a CDN ?

Can it also use one's own gitea/git instance ?

Using a service worker to run the build process is actually pretty neat.

I just moved all my simple websites to Calliope which is very similar but you can self host it if you want or wrap it docker behind a load balancer or generate the static site.

[Calliope](https://calliope.site)

it's on [GitHub](https://github.com/ConflictingTheories/Calliope). It's designed for a simple clone and start.

I put my static sites on free tier netlify. Super easy.

I tried to do something similar with a fully client-side static site generator called CMS.js (https://github.com/chrisdiana/cms.js) a few years back. Would have liked to get to the point where the content editor was fully client-side too. I personally like the concept though.

CDN is still a server. It can still go down and can get hacked. You can still lock yourself into a CDN provider.

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.

Doesn't https://www.netlifycms.org combined with Netlify itself (or any other CDN) achieve the same?

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.

Right on the landing page of Netlify CMS it says: "Content is stored in your Git repository alongside your code..."

A similar idea that uses git to store data is Mavo: https://mavo.io/.

Hmm...it uses the CDN's servers. So "no server" or "getting rid of the server" seems a tad inaccurate.

You're being generous. It's a blatant lie for marketing purposes. Its "solution" is the same as the second problem it claims to avoid.

I got flagged for saying someone is lying and was told

"Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."

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.

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..."

> We all know what is meant by serverless and "without a server"

Please feel free to furnish us with a definition that includes this product but excludes the existing solutions.

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.

I genuinely thought they meant that the site is client only (perhaps distributed outside of internet) and was curious how that works.

edit: The original title said "with no server". I would understand "serverless", since I'm familiar with that jargon.

> Replace Cloud with Git: Store content without a server

I guess they mean GitHub or GitLab or their equivalent - which are servers.

Good use of AI voice over in the video on the homepage.

Is that really an AI voice? Sounded real to me.

That's the idea, should sound real. You can search online for AI voice over websites. It's becoming a booming business.

What is wrong with Jekyll and Github Pages?

Gopher 2.0

Reply on news.ycombinator.com