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

61–70 of 370 posts

Re: The Static Site Paradox

#61

Post by foul »

> Weird as it might be, it's not a great mystery why that is: it's easier to spin up a Wordpress blog than it is to figure out by yourself all the intermediate steps

Or you could just use publii, an office suite of your choice, or type bad html and css by hand, then pass raw files on very cheap hosting providers, enjoying a clunky, and sometimes ugly, "website".

The industry for this use-case works on looks and discoverability: the dichotomy of the WP big bloated piece of crap vs static clown generators stands upon having a pretty website which is also functional for Google. Any other alternative (like the builders or the directories) works the same but they also forfeit property of the site from client. It's just because these solutions are pretty for cheap, it's fast fashion.

Re: The Static Site Paradox

#62

Post by timw4mail »

oneeyedpigeon wrote: post #30
wakeupcall wrote: post #10

Earlier quoted context omitted.

What about fully client-rendered templates/sites that require JS for visualization? (ie, no graceful degradation at all). Technically static, but absolutely of the worst kind in my opinion.

I totally agree — technically static, but an abomination that should be avoided at all costs!

An abominable default, sadly.

Re: The Static Site Paradox

#63

Post by oliwarner »

D13Fd wrote: post #60
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…

I run a blog for an organization. We do one post per business day on average, with typically around 3 posters. I set it up years ago with Django/Wagtail/Puput and it has happily chugged along ever since. I can’t imagine how annoying it would be to manage if people were creating their own new files for every post and writing their own HTML…

But you've had to maintain that Python/Django stack, as well as a server.. Right?! I've done hundreds of Django release upgrades. They're not automatic or time-free.

Most SSGs, especially those geared to blogging accept nicer markup systems like Markdown. Keeping track of things, even in a multi-user system isn't hard.

Getting non-technical people used to a git workflow is the hardest part.

Re: The Static Site Paradox

#64

Post by nephanth »

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?

Re: The Static Site Paradox

#65

Post by daoistmonk »

lqet wrote: post #12

> If you didn't know any better, you would expect almost all normal users to have [2] and professional engineers to have something like [1], but it's actually the inverse: only few professional software engineers can "afford" to have the second option as their personal website, and almost all normal users are stuck with overcomplicated solutions. I am confused, the inverse would be that professional engineers have [2…

i read it as: "can't afford the overhead of complexity of running such a complicated stack for my personal x"

Re: The Static Site Paradox

#66

Post by superkuh »

I would never recommend someone making their first site use a static site generator or anything PHP or dynamic like that. Just make a simple html document in a wysiwyg editor and upload it to the server.

Re: The Static Site Paradox

#67

Post by chambers »

> Don't you find it infuriating when lawyers and accountants fail to clarify how their respective domains work, making them unavoidable intermediaries of systems that in theory you should be able to navigate by yourself? Whenever we fail to make simple things easy in software engineering, and webdev especially, we are failing society in the exact same way.

I think the better word for this is "straightforward"; see the Mythical Man Month:

> For a given level of function, however, that system is best in which one can specify things with the most simplicity and straightforwardness. Simplicity is not enough. Mooers's TRAC language and Algol 68 achieve simplicity as measured by the number of distinct elementary concepts. They are not, however, straightforward. The expression of the things one wants to do often requires involuted and unexpected combinations of the basic facilities. It is not enough to learn the elements and rules of combination; one must also learn the idiomatic usage, a whole lore of how the elements are combined in practice.

> Simplicity and straightforwardness proceed from conceptual integrity. Every part must reflect the same philosophies and the same balancing of desiderata. Every part must even use the same techniques in syntax and analogous notions in semantics. Ease of use, then, dictates unity of design, conceptual integrity.

Re: The Static Site Paradox

#68

Post by graypegg »

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. They could always keep their online menu updated because... it was exported from the word doc they create the print menu from. At the time we sort of made fun of them internally... which I feel bad thinking about now. It's actually a genius idea when you have a million other more important things to do at a restaurant.

It's still easier to make a static site. I think the authoring tools to generate HTML just currently suck, or if they don't suck they have some process that needs to run on the server to serve the site.

Re: The Static Site Paradox

#69

Post by slmjkdbtl »

rwbt wrote: post #56
oneeyedpigeon wrote: post #52

Earlier quoted context omitted.

A contact form is a terrible alternative to an email address. Many sites have dropped comments altogether. Yes, these things might be nice-to-haves, but they shouldn't be the factor that determines whether you have a static site or a scripted one.

I have to politely disagree. If you ever run a website for business/portfolio etc. the number of people more likely to contact you using a contact form is far greater than just telling them to email you. Contact forms also scale well if you need to categorize and channel the queries to different people or need more specific info.

Yes, and almost all clients will ask you to put a contact form on the site.

Re: The Static Site Paradox

#70

Post by zahlman »

KnowtheRopes wrote: post #16

Yes, static websites are great! I'm using Jekyll with GitHub - it's 100% free. I agree, though, there is a learning curve.

I've been doing this too, but as a Python expert who always meant to learn Ruby but never really got around to it, I hate having to wrap my head around the suite of Ruby development tools (Bundler and the Gem system etc.) to do local builds, and it's currently taking up a seemingly absurd amount of disk space when this is the only reason I have any of it installed. Considering switching over to Nikola soon so that I can just use Python in the ways I'm familiar with.
Post reply on HN