[HN Gopher] Web Origami, for making websites where you can under...
___________________________________________________________________
Web Origami, for making websites where you can understand how
they're made
Author : ayoreis
Score : 206 points
Date : 2024-12-13 14:43 UTC (1 days ago)
(HTM) web link (weborigami.org)
(TXT) w3m dump (weborigami.org)
| ayoreis wrote:
| Also: https://jan.miksovsky.com/posts/2024/11-20-programming-
| langu...
| deanebarker wrote:
| 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?
| JeremyBarbosa wrote:
| 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.
| bryanrasmussen wrote:
| so, you're saying the claim of making websites where you can
| understand how they're made doesn't seem to hold up?
| magnio wrote:
| I'm not sure if we need another bundler, but this one surely has
| the best name.
| weego wrote:
| 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.
| chefandy wrote:
| 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.
| zwnow wrote:
| Whats wrong with just using HTML, Js and CSS for personal
| projects?
| sabellito wrote:
| 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.
| plonq wrote:
| Why do you care if your personal site is minified?
| groby_b wrote:
| Because some people care about low-bandwith users. Or
| about not being wasteful as a principle.
| nattaylor wrote:
| Doesn't compression make any minification gains
| negligible?
| chefandy wrote:
| Depends on what you're serving up. Blog? Yes. Video game?
| No.
| hereonout2 wrote:
| 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
| corytheboyd wrote:
| 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...
| chefandy wrote:
| 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.
| MortyWaves wrote:
| 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.
| animex wrote:
| 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?
| nkrisc wrote:
| How would that work? Now one request for a page becomes N
| requests for every bit of HTML the client needs to
| render?
| lmz wrote:
| 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.
| chefandy wrote:
| 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.
| nkrisc wrote:
| > 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.
| chefandy wrote:
| 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.
| toyg wrote:
| It is - it is called _frames_.
| johnisgood wrote:
| You can just have git submodules for that.
| chefandy wrote:
| 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.
| zwnow wrote:
| 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.
| chefandy wrote:
| 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.
| schindlabua wrote:
| 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.
| hombre_fatal wrote:
| 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/
| ramon156 wrote:
| Cool idea! Don't think I'm the target audience though. Maybe this
| is something for people who are starting out with web dev?
| turnsout wrote:
| 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.
| soco wrote:
| And still supporting HTTP. I don't know about this, anyone can
| suggest a reason to use HTTP nowadays?
| optymizer wrote:
| * 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
| tarxvf wrote:
| To allow access by devices (embedded, vintage) where SSL
| cannot run.
| quectophoton wrote:
| > * 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.
| dogboat wrote:
| Serve content that is reversed proxied by something that
| terminates SSL - cloudflare, cloud gateways, Nginx etc,
| ingress controllers ...
| hn_throwaway_99 wrote:
| 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.
| gspencley wrote:
| 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.
| TheRealPomax wrote:
| 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.
| j45 wrote:
| 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.
| msdundarss wrote:
| Thanks for making it open-source!
| nullbyte wrote:
| 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.
| jcalabro wrote:
| The logo is quite similar to Roc?
|
| [0] https://www.roc-lang.org/
| klntsky wrote:
| What's the motivation for making it another language as opposed
| to a framework / library?
| taco_emoji wrote:
| YAML? C'mon, guys
| bqmjjx0kac wrote:
| 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?
| xrd wrote:
| 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...
| wackget wrote:
| > 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?
| OuterVale wrote:
| 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.
| OuterVale wrote:
| 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
| johnisgood wrote:
| When I scroll down, the "VALE" stuff goes above the menu,
| making both unreadable. Might want to fix that.
| OuterVale wrote:
| Could you please elaborate on exactly what you're
| experiencing? Include your browser/OS if possible. Thanks for
| letting me know!
| johnisgood wrote:
| 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).
| OuterVale wrote:
| 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.
| johnisgood wrote:
| 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.
| hiked wrote:
| This doesn't look too bad, I'm very interested in it, it's helped
| me a lot
___________________________________________________________________
(page generated 2024-12-14 23:01 UTC)