8 ms·

I'm old enough to remember when servers rendered everything and you used CSS and Javascript to enhance the pages after they were rendered. The web is in such a

I'm old enough to remember when servers rendered everything and you used CSS and Javascript to enhance the pages after they were rendered. The web is in such a dark and overengineered place. It's almost unbelievable. It's why my approach to building apps is server-rendered first and then enhanced after the fact.

solardev 3y ago
As a different perspective, I'm also old enough to remember when CSS and Javascript were invented, and I've been making websites since that time. IMO web dev has never seen better tooling than today, and user experience has improved tremendously over the years. What we used to call AJAX has grown from a neat side toy to a basic part of everyday life in the form of client components and SPAs. The server is still as powerful as ever if you want it to be. But having such awesome client-side power is nice for interactive apps like dashboards, maps, games, forums, office apps, online IDEs, etc. It enabled the wholesale migration of everyday apps from bespoke desktop apps for each OS to a universal platform across all laptops and desktops. All that power of course required more complexity. It's very different trying to write a blog or landing page in HTML/CSS vs trying to write a whole web app. Angular and React were invented to help develop apps that were several times more complex than their precesssors, at a time when JS runtimes (and the language itself) were still really primitive compared to the server side languages of the time. Yeah, there was a really painful period there in the late 2010s where different JS frameworks each solved a tiny part of the problem. These days it's less of an issue. Next won, became the default, and deservedly so. It's really good, and has an appropriate level of abstraction for mid complexity apps, and allows a good mix of server-side rendering and client-side pages. Adding React Server Components makes that division a cleaner first class citizen. That only makes sense at a certain complexity though. If you don't need it, don't use it. If you're making a largely static blog or documentation site, there are simpler architectures. You can still use HTML and sprinkle in a few lines of JS as needed. You can still use WordPress or Wix for most small business needs. But if you're building more complex apps, god, React is an absolute dream compared to trying to round-trip every minor interaction to the server for recomputing the UI and sending over an entire HTML page every time, losing context and page position and half filled forms and whatever. It also encouraged the use of form data as state, and work was often lost on an accidental back button or the frequent server crashes before the advent of trivial cloud scaling. IMO it's only overengineered when misapplied. Some of these tools are really useful, even essential, in the proper use cases. Maybe the sad part is that we overteach them and encourage their use even when they're not necessary (or perhaps counterproductive). Right tool for the job and all that. Edit: not really pitching React over Vue or Svelte or HTMX or whatever, just that client-side complexity has its uses. Pros and cons, not strictly better or worse.
- gmokki 3y ago
  Why would server side rendering send the entire HTML page on every time? Or lose context or page position? All those have been smoothly handled by pure server side frameworks such as wicket or tapestry for over a decade.
  - solardev 3y ago
    What do you mean? Maybe I'm misunderstanding something, but Wicket itself says it uses Ajax components for client updates. As far as I know, it's not possible to do client-side rerendering without Javascript. Many frameworks these days do a hybrid approach of server and client-side rendering, sometimes with rehydration, sometimes not. But my understanding is that they all require some level of Javascript to redraw UIs on the client. If I'm misunderstanding (or just plain wrong?), could you please elaborate?
- ttfkam 3y ago
  Well, React certainly has succeeded in increasing the client-side complexity, that's for sure. They seem to be making good inroads on increasing server-side complexity as well. Kudos to their contributions to excess CO2 emissions! I have yet to see a React project with more than five contributors fail to turn into a big ball of mud within 18-24 months, requiring either a periodic rewrite or resigned acceptance of trudging through large volumes of mud to get anything done.
  - solardev 3y ago
    Well, I've yet to see any web project of that scale survive more than 2 years. What do you think would be a better stack with similar frontend interactivity? (Genuine question, not being snarky)
    - ttfkam 3y ago
      I have seen Angular projects last pretty long avoiding code entropy. Angular is opinionated, rigid, and verbose, but goddamn if that structure and predictability don't pay off in the long term.
Cthulhu_ 3y ago
You guys are using Javascript? I jest; our first geocities page was just HTML with maybe a visitor counter, marquee and whatnot. Our first PHP application / project in school actually didn't use JS yet, it used frames for a static menu and header and just straight form submission to get data to the back-end. Those were the days. But when I did my first college level internship (1 year of internships is part of college education over here), it was Java back-end, JSX templates for the presentation part, and it was enriched with PrototypeJS for things like dialogs and an animated accordeon (back when animation was still "update the height of this element a couple times a second"). My first job involved using a lot of JS to still enhance a page; add to cart, image carousels, that kinda thing. jQuery era. And my next job involved building a user interface for customer support staff to look into SAP or something like that, poorly built in BackboneJS. The next assignment was once again using BackboneJS to rebuild the investment banking front-end for customers. That was - as with most applications I've built btw - a great use case for single-page applications (as they were called then). No SEO needed, fast enough to render purely front-end, API heavy (that was also the time when people realized you could build one API for both web and mobile), etc.
- ttfkam 3y ago
  You guys used PHP? I started out with include directives with Apache, *.shtml files, and cgi-bin. SEO didn't even exist yet. You were either in the Yahoo! registry or you weren't. You just put your website URL at the bottom of the printed glossy brochures at the trade shows. "Mobile" wasn't a thing. Almost no one had any kind of cell phone. Pagers were still common. PalmPilots were brand spankin' new, a few hundred dollars (not including the 14.4kbps modem), and did not have web browsers. (I'm not gonna claim things were better back then.)
toddmorey 3y ago
That’s exactly what this approach (sever components) is for
butlike 3y ago
I agree for the most part. Collapsable dropdowns and jQuery drag-and-drop are nice-to-haves, but I also clearly remember the hellscape of state management in js/jQuery and I'm not to keen on going back to that.
- and0 3y ago
  Early JS state management was horrific, yeah, but modern libraries (while a little hard to wrap your mind around initially) are really powerful.
- xutopia 3y ago
  To this day I don't understand people saying this. Can you describe a project or instance where it was tough? I never had any issues even in complicated projects with thousands of lines of JS.
  - dham 3y ago
    Developers didn't understand event delegation, so entire codebases were filled with $.live, on and off events. If you componentized behaviors with jQuery it wasn't all that bad, although I'll admit it could get somewhat gnarly. The problem, from what I saw was nested forms and trying to hold state on the client when the server should have been asked for the state. This lead to template duplication and trying to hold too much state on the client.

solardev 3y ago

As a different perspective, I'm also old enough to remember when CSS and Javascript were invented, and I've been making websites since that time. IMO web dev has never seen better tooling than today, and user experience has improved tremendously over the years. What we used to call AJAX has grown from a neat side toy to a basic part of everyday life in the form of client components and SPAs. The server is still as powerful as ever if you want it to be. But having such awesome client-side power is nice for interactive apps like dashboards, maps, games, forums, office apps, online IDEs, etc. It enabled the wholesale migration of everyday apps from bespoke desktop apps for each OS to a universal platform across all laptops and desktops. All that power of course required more complexity. It's very different trying to write a blog or landing page in HTML/CSS vs trying to write a whole web app. Angular and React were invented to help develop apps that were several times more complex than their precesssors, at a time when JS runtimes (and the language itself) were still really primitive compared to the server side languages of the time. Yeah, there was a really painful period there in the late 2010s where different JS frameworks each solved a tiny part of the problem. These days it's less of an issue. Next won, became the default, and deservedly so. It's really good, and has an appropriate level of abstraction for mid complexity apps, and allows a good mix of server-side rendering and client-side pages. Adding React Server Components makes that division a cleaner first class citizen. That only makes sense at a certain complexity though. If you don't need it, don't use it. If you're making a largely static blog or documentation site, there are simpler architectures. You can still use HTML and sprinkle in a few lines of JS as needed. You can still use WordPress or Wix for most small business needs. But if you're building more complex apps, god, React is an absolute dream compared to trying to round-trip every minor interaction to the server for recomputing the UI and sending over an entire HTML page every time, losing context and page position and half filled forms and whatever. It also encouraged the use of form data as state, and work was often lost on an accidental back button or the frequent server crashes before the advent of trivial cloud scaling. IMO it's only overengineered when misapplied. Some of these tools are really useful, even essential, in the proper use cases. Maybe the sad part is that we overteach them and encourage their use even when they're not necessary (or perhaps counterproductive). Right tool for the job and all that. Edit: not really pitching React over Vue or Svelte or HTMX or whatever, just that client-side complexity has its uses. Pros and cons, not strictly better or worse.

gmokki 3y ago
Why would server side rendering send the entire HTML page on every time? Or lose context or page position? All those have been smoothly handled by pure server side frameworks such as wicket or tapestry for over a decade.
- solardev 3y ago
  What do you mean? Maybe I'm misunderstanding something, but Wicket itself says it uses Ajax components for client updates. As far as I know, it's not possible to do client-side rerendering without Javascript. Many frameworks these days do a hybrid approach of server and client-side rendering, sometimes with rehydration, sometimes not. But my understanding is that they all require some level of Javascript to redraw UIs on the client. If I'm misunderstanding (or just plain wrong?), could you please elaborate?
ttfkam 3y ago
Well, React certainly has succeeded in increasing the client-side complexity, that's for sure. They seem to be making good inroads on increasing server-side complexity as well. Kudos to their contributions to excess CO2 emissions! I have yet to see a React project with more than five contributors fail to turn into a big ball of mud within 18-24 months, requiring either a periodic rewrite or resigned acceptance of trudging through large volumes of mud to get anything done.
- solardev 3y ago
  Well, I've yet to see any web project of that scale survive more than 2 years. What do you think would be a better stack with similar frontend interactivity? (Genuine question, not being snarky)
  - ttfkam 3y ago
    I have seen Angular projects last pretty long avoiding code entropy. Angular is opinionated, rigid, and verbose, but goddamn if that structure and predictability don't pay off in the long term.

Cthulhu_ 3y ago

You guys are using Javascript? I jest; our first geocities page was just HTML with maybe a visitor counter, marquee and whatnot. Our first PHP application / project in school actually didn't use JS yet, it used frames for a static menu and header and just straight form submission to get data to the back-end. Those were the days. But when I did my first college level internship (1 year of internships is part of college education over here), it was Java back-end, JSX templates for the presentation part, and it was enriched with PrototypeJS for things like dialogs and an animated accordeon (back when animation was still "update the height of this element a couple times a second"). My first job involved using a lot of JS to still enhance a page; add to cart, image carousels, that kinda thing. jQuery era. And my next job involved building a user interface for customer support staff to look into SAP or something like that, poorly built in BackboneJS. The next assignment was once again using BackboneJS to rebuild the investment banking front-end for customers. That was - as with most applications I've built btw - a great use case for single-page applications (as they were called then). No SEO needed, fast enough to render purely front-end, API heavy (that was also the time when people realized you could build one API for both web and mobile), etc.

ttfkam 3y ago
You guys used PHP? I started out with include directives with Apache, *.shtml files, and cgi-bin. SEO didn't even exist yet. You were either in the Yahoo! registry or you weren't. You just put your website URL at the bottom of the printed glossy brochures at the trade shows. "Mobile" wasn't a thing. Almost no one had any kind of cell phone. Pagers were still common. PalmPilots were brand spankin' new, a few hundred dollars (not including the 14.4kbps modem), and did not have web browsers. (I'm not gonna claim things were better back then.)

toddmorey 3y ago

That’s exactly what this approach (sever components) is for

butlike 3y ago

I agree for the most part. Collapsable dropdowns and jQuery drag-and-drop are nice-to-haves, but I also clearly remember the hellscape of state management in js/jQuery and I'm not to keen on going back to that.

and0 3y ago
Early JS state management was horrific, yeah, but modern libraries (while a little hard to wrap your mind around initially) are really powerful.
xutopia 3y ago
To this day I don't understand people saying this. Can you describe a project or instance where it was tough? I never had any issues even in complicated projects with thousands of lines of JS.
- dham 3y ago
  Developers didn't understand event delegation, so entire codebases were filled with $.live, on and off events. If you componentized behaviors with jQuery it wasn't all that bad, although I'll admit it could get somewhat gnarly. The problem, from what I saw was nested forms and trying to hold state on the client when the server should have been asked for the state. This lead to template duplication and trying to hold too much state on the client.