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

51–60 of 221 posts

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

#51

Post by BrandoElFollito »

stavros wrote: post #9
flohofwoe wrote: post #5

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.

With modern frameworks it is not even that. What you get is a compiled, minimized page where all of the technical interesting things are lost after the build step.

The only thing you can make use of is the design and the actual content.

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

#52

Post by camillomiller »

readingnews wrote: post #44
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…

I read your Ursus page with high interest. Do you plan on sharing the source/scripts/github? Do you plan on monetizing it? Personally, it sounds like something that would be great to check out.

Same question here! Cheers from Pberg.

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

#54

Post by BrandoElFollito »

MrJohz wrote: post #25
bradley13 wrote: post #24

Seems obvious enough: a static website runs no server-side code to generate content, because the content is already complete. Perhaps more debatable, but I would also say no client-side code should be used. Just HTML, CSS, and static media files. FWIW for my personal site, I run my own web server, which is incapable of running server-side code. It just copies files to sockets, nothing else.

I think the key point that the original article was making was that there is server side generation going on - some server still needs load the file and turn it into an HTTP response, with all the correct headers, metadata, etc, and with the correct failures when the file can't be found. This server-side code needs to be implemented (and configured, etc) somewhere. That said, as the second article points out, static…

Static content can be hosted at the edge so the client calls never reach your server.

There is obviously something that must serve the content but it is not necessarily you.

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

#55

Post by james-bcn »

seanwilson wrote: post #45

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…

What I would like is a good way to create structured data admin systems that can include HTML content, and then have my static generator access that to build the pages via a JSON feed or whatever. For example, having records for individual products including a body description which can be in HTML format. This means that other people can update the products, but we still have a static website. I thought Airtable would be suitable but surprisingly it doesn't support HTML fields very well.

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

#56

Post by BrandoElFollito »

crote wrote: post #34
alxmng wrote: 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.

Dynamic sites are a strict superset of static sites. A static website will always be easier to host, and it will always have a smaller attack surface simply because less code is needed - especially custom one-off code. There is no custom executable to run, there is no need for authentication, there is no need to write files to disk, there is no need to parse user-provided content, there is no need to access a databas…

The static sites attack surface is so small that it is zero :)

You get everything anyway, and nothing you do is used by the server.

Of course the server itself can be attacked, though it is much more difficult then with dynamic sites.

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

#57

Post by quickthrower2 »

For convenience I prefer wordpress. I am more likely to remember how to use a site in 5 years if maintaining for someone else if it is wordpress than some static site generating script. That is just me though.

For a personal blog the idea of going real old school and editing the files (maybe a simple bash script to bulk update menus etc.) is appealing though. Since my metric is “can I come back in a few years and figure out what I did”

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

#58

Post by ksec »

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…

This really should have been the case once we moved to SSD on server. For 95+% of all website, we likely have enough RAM to store 70% of the Hot Content in Cache and 30% of the content served from SSD at 10,000 IOPS Random Read.

Unless you constantly fiddle with the site design, the site and HTML generation should really be on devices and the whole thing should take less than a second to generate.

Unfortunately as other comments have said the current way of Github / Version Control / Text Editor are very much tech / Programmer focus. We need something like a hosted version of Wordpress, back to the old days of Dreamweaver / Frontpage.

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

#59

Post by roblh »

alxmng wrote: 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.

I built a little micro CMS backend for myself that I’m working on open sourcing which is pretty much this. It parses markdown files with frontmatter into html on startup and stores them in an in memory SQLite database. So you have no real content rendering overhead, and you get the little extra bonuses like full text search with FTS4 by default. I use it with sveltekit and it’s pretty cool, strikes a nice balance and is hilariously fast.

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

#60

Post by eric-burel »

littlecranky67 wrote: post #42
eric-burel wrote: post #37

Earlier quoted context omitted.

This is a actually the contrary they started caring more though all scenarios might not be covered yet. See this example from Dan Abramov: https://gist.github.com/gaearon/9d6b8eddc7f5e647a054d7b33343... It's not related to Vercel business model but to the fact that this use case is less common (in proportion) when using Next.js. I am not sure what you mean by static rewrites, isn't that covered by middlewares?

The link you posted from Gaeron uses the (now deprecated) pages router, directly supporting my argument. I did a migration from pages router to app router for my static-export project. Btw both are still present in v13, you can pick whichever you want, but long-term the pages router will be gone. With static redirect/rewrites I mean the feature in pages router where you put in the "redirect"/"rewrite" statement in yo…

Indeed it uses pages router, my point was more the timing because it has been posted recently while Lee Rob was tweeting about next export being reenabled (in 13.4 I think).

For shalllow routing you are probably right (I don't use them much so I can't tell much, but I do have a few critics regarding app router too) but regarding rewrites, an URL rewrite has to happen in a server so I still don't get your point. What was removed in v13 is the shortcut via next.config.js not the ability to do rewrites/redirects which can be done easily using middlewares or whatever your host provides. It's also recommended to setup i18n yourself in a similar fashion instead of using the built-in config, something that I've been advocating for a long time (https://github.com/vercel/next.js/discussions/17631#discussi...).

Gaeron example or the comments below show how to handle dynamic routes rewrites via nginx for instance.

Post reply on HN