7 ms·

I personally do all my sites with 100% server site rendering and bits of JS here and there if I need some interactivity that can’t be done with CSS alone. The

I personally do all my sites with 100% server site rendering and bits of JS here and there if I need some interactivity that can’t be done with CSS alone. The vast majority of websites out there probably don’t even need JS.

lmm 2y ago
> I personally do all my sites with 100% server site rendering and bits of JS here and there if I need some interactivity that can’t be done with CSS alone. So actually not "100% server side rendering" at all. And probably paying all the costs of using JS more extensively, but gaining fewer of the benefits.
- manuelmoreale 2y ago
  What the hell are you even taking about?
  - lmm 2y ago
    What does the term "100%" mean to you? How does that fit into "100% server site rendering and bits of JS here and there" in a way that forms a coherent concept?
    - manuelmoreale 2y ago
      100% of the rendered page is served by the server to the client. Most pages are HTML and CSS. In the rare occasions I need some interactivity (a gallery, some dynamic filtering, things like that) that functionality is provided by JS that’s included in the page, the same page that’s passed by the server to the browser. JS doesn’t render anything. If you turn it off the page is served anyway, some minor things might not work.
      - fsckboy 2y ago
        >100% of the rendered page is served by the server to the client. servers always send 100% of what they send. is what is sent 100% rendered already? well, browsers do a fair amount of rendering, that's what they do with CSS and HTML. and then you're adding on JS. we differ in the language we use to describe what is happening. perhaps you've rendered something from a database wrangled into the 100% page that gets sent, it's just not done rendering yet.
        manuelmoreale 2y ago
        Well if you want to play the semantic game then there’s no such thing as a server side rendering because yes, the browser has to render that page on your monitor. But I suspect that’s a pointless definition.
- zer00eyz 2y ago
  whoosh Yes you send a full, html page over the wire. It will render. script off. You can enhance it later.. You know a basic is this an email, is the pass word not empty check for a log in or some other fields if you have a basic contact form. The web worked before all the JS frameworks... It still works that way today. It's fast, low bandwidth and easy to cache.
  - cuu508 2y ago
    You don't need JS to validate an email by regex or password length (and more complex validation can happen on the server) https://developer.mozilla.org/en-US/docs/Web/HTML/Constraint_validation https://developer.mozilla.org/en-US/docs/Web/HTML/Constraint...
Aeolun 2y ago
I personally do all my sites with a close to 100% client side rendering as I can get with modern JS frameworks. If I wanted to SSR I’d use PHP…
- grishka 2y ago
  And what kind of problem do you solve with this approach? Your sites loading too fast?
  - xwolfi 2y ago
    Gnehehehe
  - LegionMammal978 2y ago
    At least for me, static page hosting costs me $0, whereas dynamic page hosting would very likely cost me > $0.
    - manuelmoreale 2y ago
      You can use a SSG and get the same result if that’s your main concern.
    - grishka 2y ago
      Where does your SPA pull its data from, if not from some sort of API that must be running on something that is capable of generating HTML as well?
      - LegionMammal978 2y ago
        Most of my personal projects haven't had any state that needs to be managed server-side: any needed data is either static or can be pulled from "someone else's" unauthenticated API. Which is how I prefer it, since all incoming data from users is a big liability these days.
    - wfme 2y ago
      Dropping an SPA onto Cloudflare takes under 5 minutes including sign up and is completely free.
threatofrain 2y ago
For every front-facing website there's 10 internal facing tools and dashboards. You don't "need" JS would be the wrong framing here. It's more like you don't need JS aversion when you're developing internal tools and you don't need the complication of SSR either (ask yourself whether the native or mobile app world is jumping on the idea of ultra-thin clients). We waited so long to improve semantic HTML that ML rushed ahead and will probably deliver semantic comprehension far in excess of whatever we can hope for with conventional means now.

lmm 2y ago

> I personally do all my sites with 100% server site rendering and bits of JS here and there if I need some interactivity that can’t be done with CSS alone. So actually not "100% server side rendering" at all. And probably paying all the costs of using JS more extensively, but gaining fewer of the benefits.

manuelmoreale 2y ago
What the hell are you even taking about?
- lmm 2y ago
  What does the term "100%" mean to you? How does that fit into "100% server site rendering and bits of JS here and there" in a way that forms a coherent concept?
  - manuelmoreale 2y ago
    100% of the rendered page is served by the server to the client. Most pages are HTML and CSS. In the rare occasions I need some interactivity (a gallery, some dynamic filtering, things like that) that functionality is provided by JS that’s included in the page, the same page that’s passed by the server to the browser. JS doesn’t render anything. If you turn it off the page is served anyway, some minor things might not work.
    - fsckboy 2y ago
      >100% of the rendered page is served by the server to the client. servers always send 100% of what they send. is what is sent 100% rendered already? well, browsers do a fair amount of rendering, that's what they do with CSS and HTML. and then you're adding on JS. we differ in the language we use to describe what is happening. perhaps you've rendered something from a database wrangled into the 100% page that gets sent, it's just not done rendering yet.
      - manuelmoreale 2y ago
        Well if you want to play the semantic game then there’s no such thing as a server side rendering because yes, the browser has to render that page on your monitor. But I suspect that’s a pointless definition.
zer00eyz 2y ago
whoosh Yes you send a full, html page over the wire. It will render. script off. You can enhance it later.. You know a basic is this an email, is the pass word not empty check for a log in or some other fields if you have a basic contact form. The web worked before all the JS frameworks... It still works that way today. It's fast, low bandwidth and easy to cache.
- cuu508 2y ago
  You don't need JS to validate an email by regex or password length (and more complex validation can happen on the server) https://developer.mozilla.org/en-US/docs/Web/HTML/Constraint_validation https://developer.mozilla.org/en-US/docs/Web/HTML/Constraint...

Aeolun 2y ago

I personally do all my sites with a close to 100% client side rendering as I can get with modern JS frameworks. If I wanted to SSR I’d use PHP…

grishka 2y ago
And what kind of problem do you solve with this approach? Your sites loading too fast?
- xwolfi 2y ago
  Gnehehehe
- LegionMammal978 2y ago
  At least for me, static page hosting costs me $0, whereas dynamic page hosting would very likely cost me > $0.
  - manuelmoreale 2y ago
    You can use a SSG and get the same result if that’s your main concern.
  - grishka 2y ago
    Where does your SPA pull its data from, if not from some sort of API that must be running on something that is capable of generating HTML as well?
    - LegionMammal978 2y ago
      Most of my personal projects haven't had any state that needs to be managed server-side: any needed data is either static or can be pulled from "someone else's" unauthenticated API. Which is how I prefer it, since all incoming data from users is a big liability these days.
  - wfme 2y ago
    Dropping an SPA onto Cloudflare takes under 5 minutes including sign up and is completely free.

threatofrain 2y ago

For every front-facing website there's 10 internal facing tools and dashboards. You don't "need" JS would be the wrong framing here. It's more like you don't need JS aversion when you're developing internal tools and you don't need the complication of SSR either (ask yourself whether the native or mobile app world is jumping on the idea of ultra-thin clients). We waited so long to improve semantic HTML that ML rushed ahead and will probably deliver semantic comprehension far in excess of whatever we can hope for with conventional means now.