Web Origami, for making websites where you can understand how they’re made | Hacker News Reader

Web Origami, for making websites where you can understand how they’re made

weborigami.org

222 pointsayoreis69 comments

My interest in this is piqued. I’m really happy to see people doing things to simplify personal standalone website authorship making it expressive and flexible without a bulky content management system or jumping through hoops for some front-end toolchain. I know when I’m developing things I’m often as or more concerned with satisfying multiple use cases or functionality extensibility, but having a nice focused tool polished for one use case is nice. When I was deep in web dev and had my machine set up with a selection of go-to docker setups for different dev needs and the knowledge of how that all needed to be orchestrated was fresh in my mind, deploying most of the SSGs or whatever seemed trivial. Now in the odd event that I have a personal project or whatever that indicates more than just a few static handmade pages, the first thing I do after looking up what todays web world consider to be the “obvious” best tools and practices is see how many people are asking about counterintuitive config issues or other getting-started type problems. As cool as whatever application might look, I know I’ve got about two good hours in me of recall, research and troubleshooting before I just say “fuck it. Guess I didn’t want to do that project anyway.” The point of those tools is to save time and energy — you don’t have to get very far outside “the loop” for it to take more effort than it’s worth to get back in for a lot of them. Simple tools for simple tasks are great when you know you’ll never ever need built-in hooks to wrangle graphql queries and automatically invalidate CDN caches and generate 10 sizes of images optimized for every conceivable device or whatever.

Whats wrong with just using HTML, Js and CSS for personal projects?

I do that. Duplicating the header, menu, and footer manually on every page is a pain in the ass. Not to mention the lack of minification.

Not sure I follow, do you not use templates and scripts to generate the static pages?

I was a web developer 25 years ago and for the majority of projects we only made static sites, all templated and minified. My skills are somewhat "of that time".

Recently I was asked to build a site to demonstrate some new software. It consisted of over 10k pages that once built would rarely, if ever be updated.

I just scripted and templated the generation of every single page hosted it in S3. This may sound ridiculous in this day and age but it takes a few minutes to rebuild and update the entire site.

Guess my point is I don't really find duplicating things to be a pain in the ass

I don’t think it sounds ridiculous, it sounds like you picked the right tool for the job. Don’t bring dynamic solutions to static problems…

What the grandparent comment was referring to was eschewing static site generators in favor of entirely handmade html and css. The person you’re responding to was arguing in favor of static site generators for the reasons they listed. I was advocating for a simpler breed of SSGs than we have now for simple tasks, and this project seems to fit that niche. Most SSGs these days are only trivial if you’ve got current web developer knowledge at your finger tips.

Yes, that's what I meant.

That isn’t ridiculous and is in fact how the bulk of modern static site generators work. Hugo, Jeykll, Astro (the one I use), etc.

I think this issue better addressed in HTML spec. Basic functionality to include html snippets files in other HTML files should be standard. What am I missing?

Well, the HTML spec is missing that, has been for decades despite people asking for it, and to my knowledge has never even made it to a roadmap.

How would that work? Now one request for a page becomes N requests for every bit of HTML the client needs to render?

That’s sorta the case with frames and asynchronously loaded stuff anyway though right? I think they just consider the problem solved in practice through scripting and frames. Besides, HTML doesn’t have room for that— they need room for all the features nobody uses and cares about. XD I’ve been writing HTML to some extent for 30 years and I periodically come across shit— not even new shit— that I swear I’ve never even heard of.

> That’s sorta the case with frames and asynchronously loaded stuff anyway though right?

Yeah, and that's not something to emulate. And if so, it sort of already exists in the spec: iframe.

I’m not sure how it could possibly make the problem worse if the problem is already endemic to modern websites in a form far more heavily used than that ever would be.

You could cache the intermediate bits. Hell you could do this right now (somewhat) by doing script src=menubar.js and the script containing document.write calls. Not great for performance.

Wouldn't that just ends up re-inventing XML and <xsl:include> ?

It is - it is called frames.

Serverside includes are a thing in Apache or nginx.

If you don’t mind a little coding, it wouldn’t take long to build a tool that lets you store the bodies as template files, wraps them in the header/footer, and minifies them.

Even less effort is pandoc’s standalone mode which lets you provide a wrapper template.

Yeah SSI solved this 30 years ago. It's kind of a fire and forget solution too.

Why do you care if your personal site is minified?

Because some people care about low-bandwith users. Or about not being wasteful as a principle.

Doesn't compression make any minification gains negligible?

Depends on what you’re serving up. Blog? Yes. Video game? No.

You can just have git submodules for that.

Nothing, if they’re simple enough to do that. Not all of them are. I’m a commercial artist and designer, so things like layout are important and need to be updatable on multiple pages because individual pieces often have their own pages. Updating 15 nav headers in a gallery on your site to save a couple of hours setting up something better suited to the task is just terrible architectural planning. At the same time, I don’t need an embedded rich text formatter and CDN support and azure integration and blah blah blah. Use the right tool for the job, and my job often calls for something ostensibly like this, which fits a neat niche.

Yea my point was that people love to overcomplicate their stuff. Having a whole infrastructure for a personal project that isnt even started yet is insane.

That depends on the project. I’m a technical artist— sometimes my personal projects get pretty elaborate and pretty technical and don’t have the equivalent of an MVP that can be put together with a few handmade pages. Even something like a simple gallery of images that each have their own page (or the functional equivalent) is going to involve a ridiculous amount of manual work right off the bat. The only dumb way to approach it is not considering the right tool for the job.

So... it's a static site generator? I've looked through the site, but I'm having trouble putting it in context. Sounds like it takes data and turns it into a static website. Is that right?

That's how I read it too? And while the documentation has lots of examples, I get a bit lost in that you start with some form of JSON file, which consumes either YAML or HTML files, who in turn can consume Markdown files. It doesn't seem (from my reading!) to have the level of abstraction I would expect from a SSG.

so, you're saying the claim of making websites where you can understand how they're made doesn't seem to hold up?

Interesting, and I love Static Site Generators (SSGs), but as soon as you introduce branching and logic to the page creation, you've effectively ruled out non-programmers. So I don't know how it will achieve the stated goal of "a language for making websites where you can understand how they're made."

The audience you're left with (programmers) will bristle at the DSL and wonder why they don't just use "___" <-- fill in their favorite SSG.

I love this.

And, I have my own take on it.

My static site generator Svekyll (https://extrastatic.dev/svekyll/svekyll-cli) has an option you can add to the _config.yml: "view_source"

If you do that, it provides a link at the bottom of each post which says "view source to this post" If you click on that, you can see all the files used to generate that post, and then download a zip which is a fully packaged tiny svelte app that builds into that blog page.

For example, this blog post on embeddings has a bunch of svelte components, embeds an embedding model right inside the page and runs it via JavaScript. If you scroll all the way down, you can download the zip file, unzip it and run "npm i && npm run build && cd build && npx http-server -o" and you can see the fully built blog.

https://webiphany.com/2024-04-29-distance-sean-shawn

PRs describing this feature:

https://extrastatic.dev/svekyll/svekyll-cli/-/merge_requests... https://extrastatic.dev/svekyll/svekyll-cli/-/merge_requests... https://extrastatic.dev/svekyll/svekyll-cli/-/merge_requests...

Also: https://jan.miksovsky.com/posts/2024/11-20-programming-langu...

This site would benefit from a comparison with other static site generators.

I dare say it's not that difficult for a programmer to roll their own SSG with whatever is at hand.

Does it have any clever properties that naive solution wouldn't?

* Like reproducible builds or incremental/cacheable builds?

* Does it require the entire site fits in memory at build time, or can it generate terabyte-sized sites without breaking a sweat?

I'm using Origami on my website over at https://vale.rocks. I recently did a brief writeup about the implementation of my site, including touchings on Origami. I'm really loving it!

https://vale.rocks/posts/the-implementation-of-this-site

When I scroll down, the "VALE" stuff goes above the menu, making both unreadable. Might want to fix that.

Could you please elaborate on exactly what you're experiencing? Include your browser/OS if possible. Thanks for letting me know!

https://i.imgur.com/tfB0qsa.png

Does this help? This happens as I scroll down till it is over the menu.

I am using Vivaldi 5.7.2921.65 (Stable channel) stable (64-bit).

I very much treat this site as a testing ground for my learning and therefore generally start using new features as soon as they are newly available in Baseline. Hence, your browser, which hasn't been updated in over a year, is having issues rendering all the modern features. You might want to consider updating your browser, as it has some known security vulnerabilities.

Appreciate the photo and report though.

You are right, it is a bit dated. The website works with Firefox. I will update Vivaldi later and see if it works. I will get back to you if it does not work with the latest version of Vivaldi, which is Chromium-based.

This looks great! I love the simplicity of the syntax. I feel like other static site generators can get too crazy with syntax and features, making it hard to learn. I think Origami is really nice in comparison. Also great looking docs.

The metaphor is strained at best, and confusing at worst. It's a very high-concept pitch and so is the technical documentation, but the use case is aimed at people doing something, ultimately, very simple. I'm not sure that friction works at all.

Unnecessary complexity can decrease the shelf life and lifetime of a piece of software.

Best to keep it simple to let any complex needs arrive on their own, instead of prematurely complicating things.

> The Origami language syntax is relatively simple and intended for people who have some experience working with HTML and CSS. Knowledge of JavaScript isn’t required, although if you do know JavaScript you can do a lot with Origami.

So you need to learn HTML and CSS so you can use Origami to... avoid building a site with HTML and CSS?

It isn't at all about not building with HTML/CSS. It's a language that makes building with HTML/CSS and other web standards easier.

Thanks for making it open-source!

Don't hate it but it feels like the Origami language should just be a typescript library. I'm not a fan of DSLs in general though.

Yeah, I don't see how using a DSL helps get any closer to "understanding how the website is made" especially once you look at its templating system.

I think a better description of the project is that it's built around its async-tree abstraction: https://weborigami.org/pattern/

Cool idea! Don't think I'm the target audience though. Maybe this is something for people who are starting out with web dev?

This doesn't look too bad, I'm very interested in it, it's helped me a lot

I'm not sure if we need another bundler, but this one surely has the best name.

The logo is quite similar to Roc?

[0] https://www.roc-lang.org/

What's the motivation for making it another language as opposed to a framework / library?

YAML? C'mon, guys

And still supporting HTTP. I don't know about this, anyone can suggest a reason to use HTTP nowadays?

  * To serve content that can be accessed on networks using captive portals
  * To serve content on localhost while developing
  * To serve content on devices where setting up letsencrypt or other SSL is either too much of a hassle or not important
  * To stand up a quick HTTP server on hacked servers

Maybe others can come up with more examples

> * To serve content on devices where setting up letsencrypt or other SSL is either too much of a hassle or not important

This is my use case, serving homeserver stuff from a ".internal" domain, only accessible through WireGuard. I ain't gonna mess with a custom CA just for this.

If one of my devices gets compromised enough to be able to sniff network packets that pass through the WireGuard interface, I have bigger problems to worry about.

To allow access by devices (embedded, vintage) where SSL cannot run.

Serve content that is reversed proxied by something that terminates SSL - cloudflare, cloud gateways, Nginx etc, ingress controllers ...

Why do you say "still supporting HTTP"? AFAICT this is just a site builder, but doesn't enforce how the site is deployed.

It includes "builtins" for accessing other resources (i.e., as a client) using HTTP, but I hope it should be obvious why that is a necessity.

Sure: your web server doesn't need to care about the "S" part in the slightest in order for the web site to work over HTTPS.

Reverse proxies have existed for a very, very long time, you simply run a local HTTP server and you let the reverse proxy take care of https-to-and-from-the-WAN-side part. Even in dev context, that takes at most a few minutes to set up these days thanks to letsencrypt's certbot.

Others have offered good reasons but I'm going to offer another one, and I mean this seriously:

- Because I want to

Not everything is security sensitive. Some information is entirely public and has no need for encryption. While SSL is also provides protection against man in the middle attacks, which helps you to trust that the information you are reading has not been compromised and altered, this is also a security requirement that just doesn't exist in a lot of use cases.

So yeah, private internal networks where information security just isn't a requirement because the information is not at all sensitive and nothing bad will happen in a worst case scenario ... don't force things on people that don't require those things.

I can sort of understand the rationale for web browsers pushing encryption for public websites, with the amount of ecommerce that happens in current year. But if your use case doesn't fall into that bucket, and if you've done your own risk analysis and came to the conclusion that you don't need encryption for what you're doing because nothing bad can possibly happen then there's no need to jump through the hassle of setting up certificates.

Reply on news.ycombinator.com