8 ms·
I worked with a team of developers tasked with creating a few 100% static websites. Single page, no interactivity, nothing dynamic. They were talking about whic
by geoffeg 2y ago
I worked with a team of developers tasked with creating a few 100% static websites. Single page, no interactivity, nothing dynamic. They were talking about which React components to use, server APIs to build, etc when I asked why they didn't just write HTML or use a static site generator and host the page in S3. They didn't know how to write vanilla HTML, they had never used it for more than bootstrapping a React app.
- amelius 2y agoYes, 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.
- epistasis 2y agoYou can't add interactivity to a static HTML site? Or shift the static pages into modern frameworks?
- willsmith72 2y agoI mean let's not go too far and pretend there is 0 advantage to JS
- frostiness 2y agoYou 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.
- epistasis 2y agoUnderstood. Makes me think of YAGNI though. https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
- jpc0 2y agoYou mean this: https://react.dev/reference/react-dom/client/createRoot 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?
- no_wizard 2y ago>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!"
- amelius 2y agoNo because a page-load e.g. breaks the animations.
- epistasis 2y agoAre 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?
- WorldMaker 2y agoCSS does support page change transitions now.
- deleted 2y ago[deleted]
- theamk 2y agoNot 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.
- tharkun__ 2y agoAbsolutely. 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+
- towelrod 2y agoYes, 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 https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it 2. https://www.ronjeffries.com/xprog/articles/practices/pracsimplest/ https://www.ronjeffries.com/xprog/articles/practices/pracsim...
- xnx 2y agoYou 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."
- exe34 2y agoYAGNI should be tattooed on some people's eyelids.
- ASalazarMX 2y agoOn 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.
- deleted 2y ago[deleted]
- juunpp 2y agoAs 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.
- xnx 2y agoI 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.
- ffsm8 2y agoIt's not anymore! Multiple options around, I personally love this https://lit.dev/ 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.
- petre 2y agoAnd it uses html instead of stipid component templating that reinvents html with different semantics.
- scotty79 2y agoYou 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.
- mainguy 2y agoI 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.
- jpc0 2y agoBuild 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#navigation-api https://html.spec.whatwg.org/multipage/nav-history-apis.html...
- mainguy 2y agoUmm, 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.
- apatheticonion 2y agoIt's frustrating the lack of simple tooling out there for static site generation. I have had to write bespoke static site generator build scripts just to get things working. Everything is React and SSR these days - like people please - it's not that complicated. TypeScript is an acceptable amount of overhead. Use React only if you absolutely need it and even then, use it super carefully because it has no seatbelts. Petite-vue is a nice middle ground for 99% of websites and I am sad that this approach (templating) to build dynamic content doesn't have more investment.
- riezebos 2y agoWith Sveltekit it's quite easy to generate a static site, I've had good experiences with it
- ravenstine 2y agoWriting good HTML is not what employers, hiring managers, HR, and resume algorithms consider to be a skill worth paying for. You gotta know React or GTFO. From the perspective of a newbie developer, why waste time learning the grandpa way of making webpages when React can do all the things? I'm not saying that situation is ideal. Most of the web should be less JavaScripty.
- FabHK 2y agoI'm still fascinated by a website linked on HN some time ago that was written in MarkDown, but then not translated to HTML and served, but sent as MarkDown along with a JavaScript renderer that would then translate and render it on the client. Sure, it works, but why? (As a marginally related aside, I've recently spun up my mother's old 12" Powerbook G4 from 2005 or so. It worked fine and was reasonably fast and snappy (for a HD based machine), except when I opened the browser. A few tabs brought the machine to a standstill. Goes to show how much crap is on the modern web.)
- ffsm8 2y agoThat's an unrealistic complaint. These laptops had <1gb RAM. You should be amazed if you could open multiple website. Each website is essentially a full program with sandboxing etc - and surely you'd be aware that opening I.e. Photoshop 4 times on such a resource restricted system would be just as impossible. And it wasn't any different back then. At last not on Mac, as I had an iMac and vividly remember the same issue. The last devices before they switched to Intel had pretty bad performance, that was the reason why they switched soon after.
- littlecranky67 2y agomdwiki.info? I wrote it because back in 2012 you had a "Public" folder in Dropbox that also was a public static web space. So a way to create a homepage without installing any software and without need to learn html. Times have changed, Dropbox removed that feature - and no one uses Dropbox even anymore.