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

The Static Site Paradox

kristoff.it

Post reply on HN
Print view View original

81–90 of 370 posts

Re: The Static Site Paradox

#81

Post by Calavar »

dhotson wrote: post #14

Most people's expectations of what a "basic website" should do have gone way up over time. Even as a programmer, I've fallen into the static site generator trap a few times. It's annoying to start a side project with a static site generator and then realise I want to add a small feature and suddenly I wish I'd just started with a simple Rails or PHP app. Nowadays, if I want a static site I just start with a folder of…

Maybe you just haven't found the right static site generator for your needs?

Jekyll is the most well known in Ruby space, but it's tailored to a specific niche - authoring a blog with Markdown or another lightweight markup language. You can certainly massage it into doing other things, but it's not that ergonomic as a general purpose static site generator.

If you want something that's easy to copy/paste into rails, a rack based static site generator like middleman is great because you can start writing with erb/haml and ActiveSupport from the very beginning.

If you're looking for the simplicity of handwriting HTML and CSS but you want some niceties like includes, partial templates, link helpers, nanoc is a good static site generator that's progressive. Start with plain HTML/CSS, only add additional features as you need them.

Re: The Static Site Paradox

#82

Post by jeanlucas »

shepherdjerred wrote: post #77
jeanlucas wrote: post #7

> Find an SSG (or handcraft everything yourself) I think this came a bit too late? Astro solves this well, there are other solutions too. From startups building webflow-like SSG platforms to frameworks like astro that requires basic markdown and html.

Yeah, I’ve found Astro to be the perfect solution without compromise. You can have a 100% static site without JS, and you can add in JS only as needed. It doesn’t feel heavyweight like similar/older SSGs doc and it lets you write TSX-like syntax for reusable components (which I really like).

Plus it is easy to plug in a CMS if you need to upgrade for a team solution involving non technical people

Re: The Static Site Paradox

#83

Post by 0cf8612b2e1e »

fullstackchris wrote: post #36

Strongly agree. Wordpress brags as powering whatever % of the internet... but if youve ever taken a look at some of that PHP source code... yikes Mind boggling to me such an overly complex system has such a large market share. I'll take my Gatsby TypeScript React components / > any day

Technical purity does not win business. Solutions do. WP has delivered a rich ecosystem that lets normal people put content on the web. Even if it annoys programmers at its technical debt.

Re: The Static Site Paradox

#84

Post by troymc »

If you like WordPress and want to use it to create a static site, you can.

1. Run a local installation of WordPress on your PC. For one option, see localwp.com (no affiliation).

2. Use WordPress to design whatever website you want, using almost any WordPress plugins you want. Just don't make any calls for time-varying external resources!

3. Use one of the WordPress plugins for exporting a WordPress site as a static site, i.e. as a folder of files that you can upload to GitHub Pages, Netlify, Neocities, or wherever. For one option, see simplystatic.com (no affiliation).

Re: The Static Site Paradox

#85

Post by steve_adams_86 »

graypegg wrote: post #68

In 2016, I was working at an agency making brochureware for local businesses. I remember one of our clients wanted us to add a small iframe for a reservation system to their website they had built. They sent us a single word document. Turns out they were just exporting it as HTML (which it seems like Word does still support today!) and throwing it onto some cheap shared web hosting provider. It worked great for them.…

I love when businesses do stuff like this. If it works, it works.

My job isn't to ridicule them because it could be better, but make their solution better and ensure my solution for them works as well as theirs, if not better, without hampering the success they already had with what they were doing already.

A lot of developers don't want to admit this—in my experience at least—but tons of these ad-hoc web solutions actually work better than a ton of strategies experienced web developers would implement on their own.

So much of what counts is what the business offers and how they relate and interact with customers. Sometimes all that takes is a word doc exported to HTML. We can use our skills to improve it, but the real magic is in the humans running the business. I love it.

I find something fun is that finding ways to improve these solutions can actually be genuinely challenging. Sure, you can make a better website, you can deploy it with sophisticated infrastructure, etc. but at the end of the day, do their customers prefer it? Does it improve their business? Sometimes that part isn't trivial at all.

Re: The Static Site Paradox

#86

Post by derekzhouzhen »

There is no paradox at all: simplicity is beautiful but complexity sells. The author thinks that value come from realized utility. However, in most market segments, value came from perception. With complexity (even useless ones), you can boost perceived value. How do you impress people when all the greatness is under the hood?

I use several SSGs and wrote one myself. I still can't recommend any SSG to people willing to pay.

Re: The Static Site Paradox

#87

Post by hiAndrewQuinn »

The killer app of WordPress is comments. No SSG, almost by definition, allows comments; WordPress blogs almost always come with them built in.

If you want something like Hugo to really take off in the blogging sphere, all you need to do is create some good looking themes with comments. Figure that out at scale - maybe by using per-blog sharded SQLite, which you can host as a third party for pennies on the dollar - and you have a tiny golden goose on your hands.

Re: The Static Site Paradox

#88

Post by pyrolistical »

steve_adams_86 wrote: post #85
graypegg wrote: post #68

In 2016, I was working at an agency making brochureware for local businesses. I remember one of our clients wanted us to add a small iframe for a reservation system to their website they had built. They sent us a single word document. Turns out they were just exporting it as HTML (which it seems like Word does still support today!) and throwing it onto some cheap shared web hosting provider. It worked great for them.…

I love when businesses do stuff like this. If it works, it works. My job isn't to ridicule them because it could be better, but make their solution better and ensure my solution for them works as well as theirs, if not better, without hampering the success they already had with what they were doing already. A lot of developers don't want to admit this—in my experience at least—but tons of these ad-hoc web solutions a…

Bingo. This is why google sheets is the best cms. Just have a data pipeline that rips the data out and upload it the webserver

Re: The Static Site Paradox

#89

Post by andybak »

nephanth wrote: post #64
dhotson wrote: post #14

Most people's expectations of what a "basic website" should do have gone way up over time. Even as a programmer, I've fallen into the static site generator trap a few times. It's annoying to start a side project with a static site generator and then realise I want to add a small feature and suddenly I wish I'd just started with a simple Rails or PHP app. Nowadays, if I want a static site I just start with a folder of…

Now I'm wondering what kind of features you end up adding to your website that need server-side code. Comment systems?

How about a contact form?

Re: The Static Site Paradox

#90

Post by graypegg »

JellyBeanThief wrote: post #79
graypegg wrote: post #68

In 2016, I was working at an agency making brochureware for local businesses. I remember one of our clients wanted us to add a small iframe for a reservation system to their website they had built. They sent us a single word document. Turns out they were just exporting it as HTML (which it seems like Word does still support today!) and throwing it onto some cheap shared web hosting provider. It worked great for them.…

I mean, isn't the whole idea of a web browser kind of contrary to the ideals of the web? It implicitly divides people into speakers and listeners. In a parallel universe, web browsers are called webitors, and they can edit websites as well as view them. People can suggest changes. People can publish annotations. Web hosting is like email--pick (or build) any service you like and pick (or build) any client you like. T…

Under the hood, the bones of that system are there! `PATCH` is a HTTP verb for a reason.

Though making the web this big publicly editable pile of documents would create a lot of spam. You already have to filter a lot if you have a form on a website, imagine if instead of filtering structured data, you had to filter diffs.

I think maybe a good half measure is just bringing web authoring tools BACK to web browsers! Netscape Navigator had one if I remember correctly. This would just allow you to write HTML files to disk though.

Bonus point for some standard protocol where you login with HTTP Basic Auth, and POST/PUT/PATCH/DELETE HTML directly to a page. You'd need some special server that understands that, but ideally it would be open for anyone to implement. You point your browser to https://yoursite.com/my/page.html and assuming you've logged in with HTTP Basic Auth, your browser suggests creating the page, rather than rendering the responded error page.

Edit: Protocol is the wrong word, someone correct me what this is really called. HTTP based... editing? A standard API? It's now something I want to make so I'll need to figure that out haha.

Edit 2: CamperBob2 in a sibling comment mentioned wikis. Just realized I'm describing a wiki lol

Post reply on HN