Live data from Hacker News

The theory versus the practice of “static websites”

utcc.utoronto.ca

81–90 of 221 posts

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

#81

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…

> Static makes so much sense for sole-author sites with technical owners. Totally agree for this narrow use case. But you're also correct that if you're a startup with a marketing site--going the Gatsby/Hugo/etc. route is a total disaster. Have seen so many technical founders make this mistake. What happens is you realize, crap, my team needs to publish content for SEO and build new landing pages...and they aren't ab…

99% of ppl pushing headless CMS are ppl who get paid for building *and more importantly, maintaining* headless CMS sites.

Yes, they have their place but it's far morw niche than the hype wants you to believe.

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

#82

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.

Dynamic pages do have some overhead, as discussed in the article. But it is still vastly superior to running the site in the browser.

Because the generation is done once, and it is darn quick. After that all of the numerous advantages of a static page still applies from a users perspective. The resource use is many orders of magnitude less and the page is much more responsive. The user experience is vastly superior, we haven't cared about that in the last decade.

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

#83
At my agency we probably build two custom sites a month. We used to do this with PHP WordPress templates, then we moved to Nuxt server side rendered on Node (Heroku), but now we are all static site Nuxt on Netlify and it’s SO MUCH better. Headless WordPress as backend. As long as you/client can deal with the build times it’s fantastic from a speed, SEO and uptime POV. Also just way cheaper to host it. Incremental Static Generation seems like the ideal solution, looking forward to that with Nuxt 3.

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

#84
post #32

Earlier quoted context omitted.

Exposing your home devices to the internet is a really bad idea , because it exposes you to doxxing, DDoSing, whatever security issues your 5-year-old smartphone may have, and a plethora of other risks. People used to do this in the 90s and early 2000s, but it turned out to be a hilariously bad idea security-wise. Even the enthusiasts these days use a dedicated server somewhere in a datacenter. Services like Github P…

Other than DDoS, all other issues you mentioned apply equally to all internet facing apps like Whatsapp etc. A static file server can be hardened to the point where only DDoS remains a significant threat and that hardly applies to an average Joe. IF my little site of a few boring pages & pics gets DDoS'ed, then I can move to Wordpress, Cloudflare or whatever.

There’s also a nice middleground - you can just proxy your site through Cloudflare. This masks your IP and protects against DDoS, the only caveat being you need to move your DNS to Cloudflare.

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

#86

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/

Can you describe your process? Do you just hand type import-free HTML and rsync it up to a web server?

I’d make so many syntax errors without at least some sort of lint/build step.

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

#87

I think one big missing part still with static sites is how you host the CMS to edit it. Correct me if I'm wrong but Decap CMS (previously Netlify CMS) runs in the browser and makes reads/edits via GitHub which can then trigger rebuilds and deploys, but it still needs a small server/proxy I think because CORS stops your browser communicating directly with the GitHub API. Netlify hosts a GitHub backend that proxies re…

my experience is limited but I once saw "frontmatter" extension to VS Code which seemed very powerful to serve as CMS and even edit your site's templates.

currently this extension works on locally installed version of VS Code on you laptop,but doesn't work on Github Codespaces.

if we could somehow get that to work (within the free tier of github codespaces, with reasonable limits on usage time) i think it would be a winner -- completely online version controlled setup with no dependency on a dev environment installed on your own machine, while serving static sites off say just S3, and still getting a full CMS experience.

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

#88

Earlier quoted context omitted.

Other than DDoS, all other issues you mentioned apply equally to all internet facing apps like Whatsapp etc. A static file server can be hardened to the point where only DDoS remains a significant threat and that hardly applies to an average Joe. IF my little site of a few boring pages & pics gets DDoS'ed, then I can move to Wordpress, Cloudflare or whatever.

There’s also a nice middleground - you can just proxy your site through Cloudflare. This masks your IP and protects against DDoS, the only caveat being you need to move your DNS to Cloudflare.

My usual model is to configure the servers to be hosted locally and rsynced anywhere else. I'm currently going through this exercise right now. I start by making everything good local and then can publish anywhere.

I love having a completely independent working local copy. My environment is perfect for my needs or I change it.

Basically my deployment plans and disaster recovery are indistinguishable.

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

#89

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.

Depends how much you want to want to avoid showing a spinner during first load _and_ when moving between pages.

And how much skill you have to not mess up basic browser functionality.

As a reference point, GitHub still breaks the back button for me like 40% of times when I'm navigating their source code (me using Chrome on OSX because I only need to do this on my work laptop). I don't even know how they manage to do this.

In my experience, sites that generate HTML server-side tend to feel faster and more reliable than anything that depends on rendering client-side. Loading a booru with 50+ images per page with a cold cache in my browser, always feels quicker and more pleasant than loading text-only GitHub pages that should already be cached everywhere and haven't been modified for days.

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

#90
the very important thing about static sites are that you can much more easily "fire and forget" a static site - put it up on an S3 bucket site or whatever and you are pretty much in the clear about worrying about it.

put up a "fire and forget" site using any kind of PHP or (perish the thought) wordpress (assuming self hosting), and if you dont check that site a few times a year, it will be all Russian porn ads before you know it.

Post reply on HN