Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The theory versus the practice of “static websites”

utcc.utoronto.ca

Post reply on HN
Print view View original

201–210 of 221 posts

Re: The theory versus the practice of “static websites”

#201

Post by sixdimensional »

simonw wrote: post #126
sixdimensional wrote: post #125

Earlier quoted context omitted.

Tangentially, I've been exploring something kind of fascinating... So, in compiled binary executables it was not uncommon to include encoded binary resources, like files or images. Not tons of them, because they would explode the size of the executable. For example, for C or C++ https://github.com/graphitemaster/incbin So here's the interesting part - we decided to build executables in a way that data in those execut…

Have you seen redbean? It's exploring ideas that are in that kind of space: https://redbean.dev/

I had not, thanks for sharing this is really interesting! I see "Self-Modifying PKZIP Object Store" and this is very much what I had in mind. Neat, will have a look!

Re: The theory versus the practice of “static websites”

#202

Post by ishanmahapatra »

nicbou wrote: post #3

I run a content website for a living. This year I switched from Craft CMS to my own static site generator. I no longer think about the server or the CMS. I no longer need to keep it updated. I got rid of the heavy database and the elaborate caching setup. Now it's just a static file server. If it was just the blog it would be even easier to host. The website is more reliable and requires virtually no maintenance. The…

Did you name your SSG Ursus after the bear on Berlin’s flag?

Re: The theory versus the practice of “static websites”

#203

Post by jamiedumont »

forrestthewoods wrote: post #46

My blog is static and doesn’t even use a static generator. For the mildly capable programmer I’m fully convinced this is the way. https://www.forrestthewoods.com/blog/

This is my approach too for my photography portfolio. It’s undoubtedly more work for a single edit/update/addition but over time the simplicity means that I’m not doing maintenance or migrating content between different tools that it’s less work in the long run.

Re: The theory versus the practice of “static websites”

#204

Post by nicbou »

eviks wrote: post #186
nicbou wrote: post #182

Earlier quoted context omitted.

I spend most of my time editing markdown, and this was never an issue. On the other hand, now I can use any search and editing utility I want, not just whatever my CMS provides. A good example is adding a space after the § character, which I use a lot. It would take five seconds to fix it across the website. A good text editor theme makes a big difference. I fine-tuned an existing Markdown theme for Sublime Text to b…

> and this was never an issue weird that broken search basics are not an issue, you extol the virtues of site search in your blog, that engine is capable of matching "shcfua" to "Schufa". Markdown, on the other hand, fails in search long before getting to fuzziness > § character, which I use a lot. It would take five seconds to fix it across the website True, and then forever to hunt down those few instances where §…

Search can be anything you want. It's just text. You are free to use the tools that work for you.

I see the diff in Sublime Merge before committing, so I'm far less likely to break something. I used to make so many errors because the WYSIWYG editor caught a random keypress.

Personally, I want those indicators to be there. I'm editing the text and the formatting. I want both to be on the screen.

Frankly I don't need to convince you that this is better. I work with this 40 hours a week and it's better for me. Feel free to take a different approach, but also accept that this approach is tested and true for me.

Re: The theory versus the practice of “static websites”

#205

Post by nicbou »

eviks wrote: post #134
evandale wrote: post #112

Earlier quoted context omitted.

> how do you find a "__bold__ in a phrase" or "bold in a __phrase__" reliably? Can't you use regex? _[^_\n\r]+_ edit: I think double underscores are easier, you should be able to use __.+__ and there's no reason to have to avoid matching single_underscore words.

I meant searching for a "bold in a phrase" phrase when it can have various markup in arbitrary places (also, it's not just __, you might have some other valid marker) But anyway, you can't really use regex here as it's too complicated and error prone for such a frequently needed operation, you need a better mechanism line index or a built in functionality to ignore all markup

So look for **? This has been working well for me.

Re: The theory versus the practice of “static websites”

#206

Post by Gordonjcp »

shortcake27 wrote: post #80
Gordonjcp wrote: post #66

Earlier quoted context omitted.

So taking a fairly simple forum that I run as an example, on every page load you'd pull down 100MB or so of database, and then query that down to just the one chunk of a few hundred bytes to display a post, in the browser? Why is that supposed to be better?

You wouldn’t pull a 100mb database to query in the browser; that’s not how static sites work. Instead, you’d rebuild the relevant pages whenever the content in the DB changes. Now, for a forum, I’m not sure this is a good idea, unless you have a super fast optimised build process. Even then, the delay in build is not what people expect from a forum. But the OP is not suggesting pulling a 100mb db down into the browse…

But OP mentioned doing all the "dynamic" stuff in the browser.

I know how static sites work, I run dozens of them for people.

I don't see how using WASM improves the situation any.

Re: The theory versus the practice of “static websites”

#207

Post by Gordonjcp »

whstl wrote: post #77
Gordonjcp wrote: post #66

Earlier quoted context omitted.

So taking a fairly simple forum that I run as an example, on every page load you'd pull down 100MB or so of database, and then query that down to just the one chunk of a few hundred bytes to display a post, in the browser? Why is that supposed to be better?

You naturally don’t do this, you can have multiple HTML pages, like a static blog. Or like a lot of forums did in the 90s/early 2000s.

Forums didn't have multiple HTML pages in the early 90s, they stuck everything into a database like they do now, and pulled it out with PHP3, or even Perl (the one I wrote was PHP-FI, then converted to PHP3, and is now entirely lost).

Re: The theory versus the practice of “static websites”

#208

Post by whstl »

Gordonjcp wrote: post #207
whstl wrote: post #77

Earlier quoted context omitted.

You naturally don’t do this, you can have multiple HTML pages, like a static blog. Or like a lot of forums did in the 90s/early 2000s.

Forums didn't have multiple HTML pages in the early 90s, they stuck everything into a database like they do now, and pulled it out with PHP3, or even Perl (the one I wrote was PHP-FI, then converted to PHP3, and is now entirely lost).

Nope. You're wrong. A lot of them did use static pages back then.

Especially the ones predating PHP. Also a couple of the most popular open source Perl ones. I remember Matt's wwwboard working like this, for example.

Some of them didn't. But A LOT certain did.

Re: The theory versus the practice of “static websites”

#209

Post by whstl »

Gordonjcp wrote: post #206
shortcake27 wrote: post #80

Earlier quoted context omitted.

You wouldn’t pull a 100mb database to query in the browser; that’s not how static sites work. Instead, you’d rebuild the relevant pages whenever the content in the DB changes. Now, for a forum, I’m not sure this is a good idea, unless you have a super fast optimised build process. Even then, the delay in build is not what people expect from a forum. But the OP is not suggesting pulling a 100mb db down into the browse…

But OP mentioned doing all the "dynamic" stuff in the browser. I know how static sites work, I run dozens of them for people. I don't see how using WASM improves the situation any.

"Doing dynamic stuff in the browser" doesn't imply doing every single thing in the browser.

One can perfectly store data as JSON or even Markdown itself on separate files but do the templating in the frontend, for example.

Pretty easy and doesn't require downloading 100mb of data.

Re: The theory versus the practice of “static websites”

#210

Post by NoZebra120vClip »

csense wrote: post #91
modernerd wrote: post #22

Earlier quoted context omitted.

Static makes so much sense for sole-author sites with technical owners. Would be great to make the tech more accessible to those without the skills to recompile and deploy. It's such a fast and affordable way to build websites, but existing tools like Hugo assume a lot from users that can put the tooling out of reach. (Enjoyed your write-up too. I wrote the original version of html-to-markdown that you used in your m…

> Would be great to make the tech more accessible to those without the skills to recompile and deploy Originally, hand-writing HTML was a supposed-to-be-accessible-to-non-technical-users way to make a website. Until the late 1990's, HTML was used sort of like Markdown is used today.

And then there was Wikitext.

Wikipedia only recently perfected their Visual Editor in a way that made me feel comfortable using it, but it's still a situational decision whether I use VE or edit the source directly.

And at $dayjob I am accustomed to poring over raw MarkDown, due to lack of a viable WYSIWYG application.

Post reply on HN