Hacker News Reader

Comment by amelius | Hacker News Reader

Yes, but remember: static HTML is a one-way street. Better tell your manager otherwise they will one day come up with functionality that can't be done in your website and it's your fault.

EDIT: For example: manager/designer wants to add an assistant to the website; it should be draggable; it should also animate and keep animating smoothly no matter where the user navigates on the website. If your website is a SPA, this is conceptually easy. If your website is static this is going to be a nightmare and suddenly a simple change requires lots of work.

View on HN

You can make an example that will invalidate any technology choice. Design for the requirements you have.

"That's a very nice car you've made. Unfortunately, if the designer later decides that it needs to survive artillery rounds, you'll wish you had built it out of armor steel as I recommended in the first place."

YAGNI should be tattooed on some people's eyelids.

On the outside of their eyelids it would do nothing for self-awareness, so I'm assuming written on the inside... which they won't be able to see unless they look at something super bright, like the sun, with their eyes closed.

... I guess this season some of us have more time to overthink things.

Still, YAGNI needs careful consideration. What looks like YAGNI right now might be reasonable flexibility that will be needed as the project matures. YAGNI makes perfect sense when delivering a proof of concept, but it's not that straightforward when designing for long-term use.

As if requirements are set in stone.

The parent comment is a bit exaggerated but it still has a point. One needs to be able to predict things and make sure whatever you do today isn't so rigid that it can't adapt to other things in the future without a major overhaul. Typically this means being cognizant of the assumptions made along the way, and making the minimal set of them. This kind of insight requires experience. People preaching YAGNI just don't seem to have much of it. They just read "YAGNI" in a blog post and then yell it at other people.

I agree no one should follow recommendations blindy, but I have seen WAY more instances (firsthand and second-hand) of people mis-architecting for circumstances that never come.

When it comes time to make a change, it's often not as big a deal as it was made out to be, and you have the benefit of everything that has been learned along the way. No one gets it right the first time anyway, so don't overthink it.

The requirements you have today are a lot more set in stone than the requirements you don't have today, that you imagine you might have tomorrow.

Not at all.

There are plenty of things you can do with static websites, especially given you can have site generators and/or can write javascript by hand too (shock!).

For example if the requirement is to have website editable by non-programmers, that's where static site generators shine. Sure, one has to press "deploy" button and wait a minute before changes are visible... but you get to keep all the features of static pages, like trivial scalability and very high security and availability.

Even if you have to have dynamic functionality (like a shopping cart), there is no need to do the whole website dynamically. Sure, have an API server which may even render the cart page, but the rest of the website can be fully static, maybe with a tiny bit of javascript to render the "number of items in the cart" icon.

Absolutely. I built something like that during high school for a local artist. Had and interactive backend that allowed him to upload his creations and it would regenerate static HTML when he was done with that. That was my first paid developer job basically.

I re-used it later on in university to hand it in as a project (easiest course ever) and got commended for not putting load on the servers and making the site slow for users by using something like PHP to re-generate the same stuff over and over as users browsed the site. A+

Yes, but remember the much more important rules of programming:

You aren't gonna to need it[1]

Do the simplest thing that can possibly work[2]

1. https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it 2. https://www.ronjeffries.com/xprog/articles/practices/pracsim...

Build a router and set inner HTML.

This would maybe be a few hours of work if going from a static site to a SPA was actually in scope. Strip headers from the current pages and now serve the body as content from an API.

You don't need your entire site to be built with react to use react within your site and building a JS based router is not very difficult and will get even easier if the Navigation API[1] becomes better supported.

This would actually be harder if you now still need a static site with an across page assistant. I would probably push back on some requirements and store state locally in the browser. Effectively hot reload the assistant on each navigation but even then it's doable, even using react.

1. https://html.spec.whatwg.org/multipage/nav-history-apis.html...

It's not anymore!

Multiple options around, I personally love this

https://lit.dev/

You can develop that element and then just drop that onto your static page via /assets/ and you're golden. Easy to develop, simple to deploy and tiny file size.

And it uses html instead of stipid component templating that reinvents html with different semantics.

You can't add interactivity to a static HTML site? Or shift the static pages into modern frameworks?

I mean let's not go too far and pretend there is 0 advantage to JS

You absolutely can, but it's way more common to only know how to create a blank site with a framework than to migrate an existing site. React used to have a section in its documentation for how to add it to your site without adding a build system (not common knowledge, unless it's setting up a blank site through a script) and they've since replaced it with a brief tutorial telling you to migrate your website to a JS module with a link to a suggested build system.

All of this matters because the person that has to do this setup might not be you. It's certainly a problem with the frameworks themselves that porting a website (even just to add a little functionality) isn't as easy as setting one up initially but there's not really much an individual can do here. It's one reason I like frameworks like Preact so much, they're actually trying to fix this.

Understood. Makes me think of YAGNI though.

https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

You mean this: https://react.dev/reference/react-dom/client/createRoot

How you bundle react is left as an exercise to the reader but the data is still there?

>How you bundle react is left as an exercise to the reader but the data is still there?

The Francis Scott Key of web development

"...and the data was still there!"

No because a page-load e.g. breaks the animations.

Are these frameworks incapable of having the static content as something that can be served? Are the links in the existing content unable to be updated to whatever need to happen for the page transitions?

CSS does support page change transitions now.

You can easily put React components into static website once you need them wherever you need them.

That's one of the selling points of react that was initially important that you can use it in limited fashion.

I was going to say the same, I have a webxr (virtual reality) site that has a few react components on it, plus a few vanilla javascript libraries in the main page template.

Umm, how is it a one way street? Just add a <script> tag and implement what you need... I'm not 100% convinced that using react from jump street "Just in case we need something in the future" is a great idea. That having been said, I'm not sure I've built a completely static html page in the last decade.... So I often start with react/angular.

Reply on news.ycombinator.com