zlacker

I’d love to get rid of JS for my personal sites, but I know of no clean and simple way to render dynamic content otherwise. Server-side rendering seems a bit messy. I want a clean REST API separate from the UI.

How can I generate pages with dynamic content easily? Ideally with absolute minimal dependencies.

>>enw+(OP)
Check out next.js. You can write vanilla React basically but fetch the props from an API prior to rendering on the server.

>>enw+(OP)
A REST API is purely a server-side issue, so you don't need JS for that (unless your server is Node of course).

You still need Ajax (at least) for truly dynamic content. The bad news is that Ajax requires client-side JS. The good news is minimal Ajax functionality only takes about 30 lines of pure Javascript. The bad news is you will need to write those 30 lines yourself because every JS library is at least 100x bigger than that and packed with cruft you don't need.

My advice is to pretend React doesn't exist, learn Javascript, and write just the Javascript you need and no more.

>>dreamc+f1
That still uses Javascript, and that seems to be the parent's point.

>>enw+(OP)
While it can definitely be a bit messy, out of the box SSG/SSR support on Next.js is trivial (it’s on by default and there’s an indicator that shows when a page will be built static and clear/simple APIs for dynamic SSR). Certainly not minimal dependencies, and you will hit a webpack wall if you need to change the build. That said, I’m working on simplifying this for my own site (Preact instead of React, static Markdown content, separate style loading, hopefully soon automatic partial hydration for whatever JS does end up on the wire) and I plan to break it all out into simple libraries so people can do similar with the same toolchain without the webpack nightmares I’ve experienced.

>>enw+(OP)
Depends on what you mean by "dynamic". Some "do something when the user clicks"-style things can be done with CSS. The best example I know of that is https://git-send-email.io/

>>enw+(OP)
How is server-side rendering messy? It's just putting html strings together based on data, no frameworks or libraries needed.

>>cyral+e1
How is that not JS?

>>slmjkd+df
That's what I mean. It feels much messier than JSX, where "putting strings together" is a clean first-class citizen.

With SSR, you need some component that's aware of every change, and that triggers those re-renders at sensible times (every render takes server resources). This all feels messy, compared to rendering just-in-time on the client-side.

>>enw+hi
I wonder what use case you're talking about, I don't have a lot of cases where re-render needs to be dealt with, unless I'm making a web app like a multi player photoshop in the browser, in those cases I won't use SSR. For most information based sites, e.g. Hacker News, Twitter, there's no need to track change and re-render, all the data can be ready on the server side like querying database or making request to third party APIs, then it'll just be piecing HTML strings.

>>enw+(OP)
It does feels messy if you insist on using rest api for your server-side pages (rendering react components in server-side?). Just abandon it and use html template-based system instead, like what most server-side frameworks do (django, rails, laravel, etc).

>>Arnavi+S3
Abusing HTML form inputs as a way to store application state in DOM is hostile to usability and accessibility - please don't do this for any sites humans need to use. HTML does have progressive disclosure elements built in with `<details>` and `<summary>` which work without JS (I was hoping the demo was showing that or something like it)

>>err4nt+2a1
Those HTML elements are radio buttons being used to choose between options of OS, mail server, etc. Each radio button is associated with a label that contains the correct text. Selecting a radio button unambiguously makes a `display:none` element no longer be that.

What part of it do you think is bad for usability or accessibility?

>>edgyqu+if
It runs on the server. The browser can have JS disabled.

>>Arnavi+0P1
Everything you just said - these form inputs aren't related to a form, and assistive technology won't have any clue about the clever CSS selector hacks and what their effects are.

If you want to build something that's nice for humans and machines, look up best practices for this sort of thing - plenty of information is widely available on how to build things in usable and accessible ways (and it's simpler to do it correctly than to use these 'hack'-like workarounds anyway!)