Live data from Hacker News

The theory versus the practice of “static websites”

utcc.utoronto.ca

11–20 of 221 posts

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

#11
post #9

As an "outsider" who dabbles in wasm I never understood why running custom code on the server to generate "dynamic" webpages would be better then a dumb server which just serves files, and the dynamic part is running in the browser instead (other then that 90's web browsers sucked for this type of stuff). E.g. nothing will ever beat a dumb file server with a cdn in front when it comes to simplicity and scalability.

Because you can't guard your competitive advantage as easily when you need to send your entire codebase to the client, and it turns out companies like that stuff.

What's the "competitive advantage" of a webpage though? It's usually just some code snippets copied from StackOverflow and a database ducktaped together right? ;)

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

#12
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…

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

Same here, I'm using Sphinx and loving it !

I very much appreciate the ability to get all nitty gritty whenever I want to implement something "special" like the Favorite Git Aliases post which when edited gets turned into a .bash_aliases file and pushed to Gitlab and mirrored to GitHub! :D

For those curious it's over at https://jdsalaro.com , I don't have much details on my stack or why but I will be documenting bits here and there. I did start with my Markdown and Myst Cheatsheet for Sphinx (https://jdsalaro.com/cheatsheet/sphinx-myst-cheat-sheet/) and how to load the environment.pickle (https://jdsalaro.com/howto/sphinx-load-environment-pickle/)

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

#13
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…

All About Berlin is a great little site - good work.

https://allaboutberlin.com/

Fast, complete in what it does, to the point.

[ IMHO it could use a section on TV Series and Movies set in Berlin past and present with a quick rating on how realisticly they portray actual Berlin ... but that's just me :-) ]

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

#14
post #9

Earlier quoted context omitted.

Because you can't guard your competitive advantage as easily when you need to send your entire codebase to the client, and it turns out companies like that stuff.

What's the "competitive advantage" of a webpage though? It's usually just some code snippets copied from StackOverflow and a database ducktaped together right? ;)

Careful, they might steal your for loops.

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

#15
post #2

I’m skeptical cheap and easy is something inherent with static sites. I think a dynamic setup can have both those qualities, but there isn’t yet CMS/blog software that hits the sweet spot: self-contained, simple to setup, manage, and host.

Indeed. These days we have 24x7 net connections on both our mobiles as well as home LAN/desktop whatever, but you still can't get a single, 1-click, drop-dead simple program that you can use to both author as well as serve web-pages and images right from your own device. Thanks largely to dynamic IPs, NAT, firewalls, ISP upstream throttling and developer apathy (since their livelihood may depend on the complexity of…

[deleted]

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

#16
post #2

I’m skeptical cheap and easy is something inherent with static sites. I think a dynamic setup can have both those qualities, but there isn’t yet CMS/blog software that hits the sweet spot: self-contained, simple to setup, manage, and host.

Publii is a nice, easy to use, self-contained GUI for creating static websites. And Open Source, too.

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

#17
post #9

Earlier quoted context omitted.

Because you can't guard your competitive advantage as easily when you need to send your entire codebase to the client, and it turns out companies like that stuff.

What's the "competitive advantage" of a webpage though? It's usually just some code snippets copied from StackOverflow and a database ducktaped together right? ;)

Yes, but that's enough for a billion valuation nowadays, so...

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

#18
post #2

I’m skeptical cheap and easy is something inherent with static sites. I think a dynamic setup can have both those qualities, but there isn’t yet CMS/blog software that hits the sweet spot: self-contained, simple to setup, manage, and host.

Indeed. These days we have 24x7 net connections on both our mobiles as well as home LAN/desktop whatever, but you still can't get a single, 1-click, drop-dead simple program that you can use to both author as well as serve web-pages and images right from your own device. Thanks largely to dynamic IPs, NAT, firewalls, ISP upstream throttling and developer apathy (since their livelihood may depend on the complexity of…

This isn't the only reason. People who are trying to get attention will flock to where attention is directed. For better or worse, centralized platforms are a good place to do that. It's the same reason protestors, charity drives, people handing out free tickets to a new concert venue, do this in downtown parks and public squares, not their front yards. Popular photographers hold shows in galleries, not their own living rooms.

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

#19
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…

This is very interesting. Impressive how much efficiency and performance is gained. This also means that fewer resources (electricity) are consumed, that less bulky hardware is used and, most importantly, that security is improved. A static website is more difficult to attack and the only possible flaw is in the web server and not in the code of the website. I usually use Hugo. It is very complete and rich in features. I have also created a multilingual website using it. Have you considered integrating Turbo Hotwired into your static website? You could have an improvement in the responsiveness of the navigation and a reduction in the load on both the server and the client side. If necessary, Turbo can also be integrated with Mercure for live page streaming.

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

#20
Big fan of NextJS and its static page export for that reason. I build and deploy just static .html/.js/.css to whatever CDN or static webserver of my choice. Since all indivudual pages/routes are pre-rendered during build, the first load is blazing fast and indexable by search engines. Also the way NextJS chunks the .js code and pre-loads contributes to the fast-load experience. For rich functionality you can interface any REST API you like, and be as dynamic as you want. Plus, MDX plugin makes it easy to creates competely static areas/content focus sites within the same project.

Unfortunately, I get the feel that with the release of v13 app router, they don't give the static export feature enought love. Features from the pages router were dropped for static export (shallow routing, static rewrites/redirects). I fear they are dropping static export all together in the future, as you don't need their comercial vercel offering at all when using static export.

Post reply on HN