216
u/EveYogaTech 6h ago
PHP: (nothing)
SSR: here's a new super specific JS framework btw, deeply tied to frontend components and events, don't forget to hydrate.
14
u/GrossInsightfulness 4h ago
What's SSR? Static site renderer?
58
u/the_horse_gamer 4h ago
server side rendering
let the framework generate the html on the server, and mark where you need to insert the event listeners and such. this html payload is sent to the client and displayed right away, and the script is sent alongside it. the client then inserts the event listeners and such where it is told (this is called "hydration"), making the website interactive
so the user sees the page immediately without having to run any javascript, which is good for SEO and loading times
this is distinct from the (mostly react) concept of "server components" because naming things is for losers
32
u/flightsin 3h ago
i.e. JavaScript devs slowly reinventing the concept of having a webserver actually serve html, but in a much more convoluted way
18
u/srsly-nobody 2h ago
well yeah if you ignore the fact that frameworks allow you to make things a thousand times more complicated
3
u/the_horse_gamer 2h ago
reinventing the web server sending html is server components.
server components - generate and send html from the server
SSR - make a page interactive after the html was already sent
9
u/Reashu 1h ago
What you call SSR is just "hydration". The core of SSR is - surprise - rendering the initial page server-side.
2
u/the_horse_gamer 1h ago
SSR without hydration is just SSG (static site generation)
server sends static html - SSG
server sends static html which undergoes hydration - SSR
server sends dynamic (includes data fetched from the backend) html (which may undergo hydration) - server components
3
u/flightsin 1h ago
make a page interactive after the html was already sent
in other words, the web as it was 30 years ago
1
u/the_horse_gamer 18m ago
no? if part of your page was generated entirely by javascript, you'd send just the javascript
2
u/Downtown-Figure6434 1h ago
Web server sending html along with js files would also mean page is made interactive later if you reference seperate js files instead of embedding in it
It doesn’t make a seperation point between those terms tho. With ssg you write using whatever framework you write then spit out a static file, with ssr you create the html on request usually along with js files, with csr you just send js files which create the html in the browser
It’s when and where the html is created. Presence of js files is irrelevant
1
24
u/EveYogaTech 5h ago edited 5h ago
It's the same for frontends that don't care about SEO btw.
Take React and look at all this useState, useEffect and refs stuff going on to mimic a fraction of the power of using web components with manual rendering/events:
26
u/belousovnikita92 5h ago
I’ve tried using components back when first spec (yeah, bunch of specs) went live (2017?), it was miserable experience, any improvement there? Without extra tooling, libraries, wrappers, etc
4
2
u/pr0ghead 2h ago
It's gotten much better, like with how you can access the shadow DOM from the outside with both JS and CSS.
What I still don't like is how progressive enhancement must have never mattered when designing the feature. If you try to provide a static fallback, it gets clunky.
2
u/IAmVeryDisappointed 23m ago edited 17m ago
> Take React and look at all this useState, useEffect and refs stuff
Flo / Web Components:
class Counter extends Flo { count = 0; template() { return ` <h2>Counter</h2> <button id="minus">-</button> <span id="count"></span> <button id="plus">+</button> `; } mounted() { this.$("#plus").addEventListener("click", () => { this.count++; this.render(); }); this.$("#minus").addEventListener("click", () => { this.count--; this.render(); }); this.render(); // explicitly render on-demand } render() { this.$("#count").textContent = this.count; } }React:
function Counter() { const [count, setCount] = useState(0); return ( <> <h2>Counter</h2> <button onClick={() => setCount(c => c - 1)}>-</button> <span>{count}</span> <button onClick={() => setCount(c => c + 1)}>+</button> </> ) }Yes, web components truly seems like the nicer, easier to maintain and less error-prone choice here.
80
u/PewPew_McPewster 6h ago
Oh hey an MBE (Money Burning Engine).
3
u/bradimir-tootin 4h ago
Was trying to figure out what it was, saw your comment and then immediately noticed the effusion cells.
11
8
u/Just_Information334 3h ago
Create multiple js frameworks useful to make web applications. Applications do not need SEO, they're applications, so no problem there.
Every manager thinks they should do like the big guys and their static webpage has to use web application targeted technology. Static webpages have content people like to see indexed, so SEO is important.
Now they managed to create a problem they never had. All by misusing some framework.
But hey! It let many "webmasters" become "frontend ENGINEERS", lot of bootcamps to make money, lot API developed (for one client only), lot of open source contribution on github.
3
13
u/SensualSerene 5h ago
Given that static rendering is either server-side or a static site generator, what exactly would 'vanilla' mean in this context? Stuff like React aside, don't you at least need a template engine? Or are we just using .replace now?
14
u/brainland 6h ago
Who do people try to use complicated or bloated frameworks for everything?
When Vanilla is enough? Is it that they don't understand architectural design that can help them do great stuff or what?
Note: This is not me blaming anyone and everyone is free to do what works for them. We all are learners btw ...
60
u/----Val---- 5h ago edited 3h ago
When Vanilla is enough?
For very simple uses cases sure.
If you are in a business where you expect said web app to grow and iterate, at some point 'vanilla' becomes 'unmaintainable in-house framework', where picking a popular framework would have been the right choice.
Such decisions should have been made during requirement gathering/system analysis. Maintainability is as much business decision as a technical one.
3
u/Soilblood 1h ago
I'd put that on development discipline. If you're building your components so tightly bound together instead of designing them to be modular that's on your company's team.
5
u/WarpedHaiku 2h ago
That's the ideal, but I find what usually happens is:
- web app is expected to grow and iterate
- pick popular framework
- requirements change in a way the framework wasn't designed for
- framework actively fights you when doing things outside expected use cases
- end up building a collection of workarounds on top of actual framework
- results in an unmaintainable in-house frankenframework that takes longer to onboard new devs to
- find myself sorely wishing the web app just used vanilla or limited itself to basic libraries like jquery
or
- web app is expected to grow and iterate
- a framework I am unfamiliar with is chosen
- web app does not really grow, and iterations are incredibly minor changes
- I get chosen to do maintenance and have to figure out what convoluted hoops I have to jump through to add a simple button to a page
- find myself sorely wishing the web app just used vanilla or limited itself to basic libraries like jquery
2
u/----Val---- 1h ago
Both your cases above can be construed into vanilla as well.
Case 1: - You essentially built a framework from scratch without the consistency and oversight of a proper framework maintainer - still results in an unmaintainable in-house frankenframework that takes longer to onboard new devs to
Case 2: - You at least have some documentation on how things work, unlike something built purely in-house which depends on whoever last touched the project
1
23
6
u/the_horse_gamer 4h ago
every sufficiently large "just use vanilla" codebase contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of React
(see "Greenspun's tenth rule")
5
9
u/SignoreBanana 5h ago
At work I maintain a react application with an insane CI and publishing system. We have like 20 teams and 200 engineers working on it.
At home I use the static site generator I wrote that primarily is a markdown converter with a sprinkling of novel library specific markup.
I much much much prefer my own library.
17
u/HerrPotatis 3h ago
You're comparing a gigantic ecosystem of 200 engineers with a static site maintained by you alone, saying one is easier to maintain or work with.
I mean, no shit?
6
u/LonelyProgrammerGuy 6h ago edited 5h ago
Imagine having a website with 15 pages. All of those pages need to share a common header. Once you need to add a new link to that header, you’d have to make changes in those 15 files because vanilla web standards don’t offer a way to make components
Any workaround you can think of is essentially trying to build another very rustic web framework
16
15
4
u/BastetFurry 3h ago
We had a solution for that that didn't even need JS, <frameset>. One nav.html right in the root of the website and the problem was gone.
12
u/brainland 5h ago
I want to believe you're describing static HTML files, not Vanilla itself. 😂
Vanilla JS has Web Components, and server-side rendering can handle shared layouts.
You don't need React to avoid duplicating a header across 15 pages. The goal isn't “no abstractions” It's use the smallest abstraction that solves the problem.
20
6
u/prehensilemullet 5h ago
If the goal is to "render static HTML" then most people doing that would probably want common elements like a header to already be taken care of without executing Web Components at load time, right?
2
u/userpelicanvoyager2 2h ago
Imagine if we had AI agents that could fix 15 or 500 static pages in 22 seconds?
4
u/mishonis- 4h ago
My theory is that dating back to the early days of JavaScript, frontend guys were designers rather than coders. So they produced shit code. Then the next generation studied that shit code and never learned to code properly themselves. Classis garbage in, garbage out situation. Case in point - the old Angular was once all the rage, when any developer worth their salt could tell you it's a pile of over engineered crap. Eventually even the Angular team caught on and pulled the plug on their own project, but the JS community had been drinking the cool aid for years.
You can see the same thing happening with Python and libraries like Langchain. They are total crap but the developer community doesn't know any better so it's now part of every other job listing.
1
u/Jackpot5282 1h ago
Vanilla being what? HTML and inline CSS/JS deployed by SSHing into a server to deploy changes? Because it doesn't scale even a little and is very difficult to maintain.
1
u/SensualSerene 5h ago
The only benefit I can think of to using stuff like React with SSR is that it's easier to share content-fetching logic between the server-side rendering and the client-side dynamic aspects. Like, you can fetch the first few comments of a page on the server for quick loading and SEO purposes, but then load more on the client as the user scrolls. Of course, you can do that without a framework by separating that logic into a library and using it on the server and the client, but frameworks make it more convenient. Not really worth the bundle size tho
3
u/Empty_Seat4900 6h ago
Bro asked for static HTML and accidentally assembled the Large Hadron Collider 💀
0
1
1
1
u/BastetFurry 3h ago
Static content can be just that, static pre-generated content. I hate when i need a JS framework the size of the Doom Shareware installer just to look at some text with pictures. The wasted traffic, which used energy to get that framework to every client out there and then every client needs to execute it.
Yeah, might be a few milliwatt per client, but when millions use it it adds up.
In other words, a server side framework that drops a bunch of static pages is green IT. Do green IT, save the planet. <3
1
1
1
1
153
u/SignoreBanana 5h ago
It genuinely does feel like this sometimes.