[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 : 153 points
Date : 2024-12-13 14:43 UTC (8 hours 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?
| 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.
| 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?
___________________________________________________________________
(page generated 2024-12-13 23:00 UTC)