Call me old fashioned, but PHP still gets the job done better than just about anything else.
No post body was provided.
The absurd complexity of server-side rendering
291–300 of 395 posts
Re: The absurd complexity of server-side rendering
#292> After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun. I didn't get the memo when this was decided, and I'm still unconvinced. Let me see if I get this straight: The main reason for client-side rendering is that some web applications don't want to do a full page reload ev…
I can’t speak to the decisions on the parts of whoever is building the frameworks. But I will say the dev experience working on a frontend app using React, Vue, etc. is substantially greater than using something like Django templates. And I say that as someone who has written a great deal of both. I really wish I could be as productive in Django templates as I am with React, but alas. Once you go to component based U…
JSF and WebForms were already component based UIs 20 years ago, with page designers at development time, and 3rd party component vendors!
Re: The absurd complexity of server-side rendering
#293I'm convinced SSR is only a thing because of Lighthouse scores. Client-side rendering with client-agnostic REST APIs is a fantastic architecture. But noooooooooo we can't have nice things
It's a nice architecture when the API devs get to throw stuff over the fence to the frontend devs. It's less nice when you are the guy throwing stuff over the fence and then running around the fence to catch the stuff you just threw over it. It makes you start to wonder if there's anything you can do about the fence. The answer is "yes."
No post body was provided.
Re: The absurd complexity of server-side rendering
#294> After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun. I didn't get the memo when this was decided, and I'm still unconvinced. Let me see if I get this straight: The main reason for client-side rendering is that some web applications don't want to do a full page reload ev…
IMHO, this isn’t about “Modern JavaScript” or “JavaScript Culture” at all. It’s just $CURRENT_THING and the Cargo Cult is happy to oblige. Futhermore, dev shops (like my employer) profit from selling overcomplicated solutions. So in the end it’s just group dynamics that drive the usual hype cycle. Remember MVVM?
MVVM is pretty much alive in native frameworks, as it makes easy to write tests and share behaviours.
Re: The absurd complexity of server-side rendering
#295Do I live in a parallel universe where building SSR/SPA sites with Next.js is somehow incredibly complex? I know below the abstractions there is complexity, but building SSR rendered SPA's today with something like Next.js has never been more simple. I think web development has taken a huge leap forward where we now have stable tooling, a strongly typed language with TypeScript and top notch boilerplate free state ma…
It's easy to server-side render Next.js apps, but usually they still have to talk to a backend. I don't think Next.js' API routes are good for this, especially if you need messages queues, cron jobs, etc. Now you have three distinct parts, client-side rendering, server-side rendering and the API, usually all communicating via JSON. Traditionaly with PHP, C#, Ruby, Elixir, etc, your backend and frontend was tightly co…
In Next.js you'd typically use getServerSideProps on a page to talk to the backend at runtime. API routes have their place of course, but I've built fairly large-ish websites that almost entirely get their data via getServerSideProps.
Re: The absurd complexity of server-side rendering
#296Earlier quoted context omitted.
I'm not sure what about two bundles causes a huge level of complexity. Granted, I use Next.js, it does all of this out of the box. SSR is fast, it's provably faster than client side rendering for first load. You can optionally do client side hydration, so the time to meaningful content is fast from SSR, and subsequent page loads are done SPA style (if you want). It's never a fair comparison, but Stackoverflow is enti…
> Also, all forum software, which is SSR, despite being 20-30 years old, is usually faster than a SPA. Only because crap tons of hardware got thrown at the problem. I remember when forums were multi-seconds to load each page. It sucked. People complain about reddit a lot, but even on mobile, the reddit website is fast. It may be janky at times, but navigating between comments on stories is under a second, loading mor…
It sucked even more when forums used flat files (essentially runtime static site generation) rather than databases. We'd periodically have to prune the post history to restore site performance.
Re: The absurd complexity of server-side rendering
#297I make a difference between website and webapp. a website is a collection of webpages, where the maingoal is to display some mostly static information (i.e. an article) a webapp has the main goal of managing and reacting to a complex, non trivial user state. website, go server side all in, do not add the tax of client side rendering / hydration to the frontend. if necessary embed small enclosed client side webapps on…
A great distinction and way to think about your work.
However, I would prefer server side rendering as the best thing to do in all cases, because, while user state may be complex in webapp, it can be easily handled securely in a server side environment.
More so, until the ecosystem around webassembly becomes more mature, the choice of languages and frameworks on the server side are far more than what is available on the client side.
Thinking and architecting apps that render on the server is much easier than client apps.
Also, client apps are slow and laggy. It takes a lot of effort to make them work well, effort that could be used to improve bottomline otherwise.
Re: The absurd complexity of server-side rendering
#298Except for the confusion about terminology the article has some good points. We had an idea a long time ago in the web dev world that we could run the same language in the browser and in the backend. Basically reuse everything and save time. It think this is bad assumption to begin with. If I have a clean separation between frontend and backend, regardless if doing mostly server rendering or client rendering it is on…
That has not been my experience.
Input validation or more broadly data integrity is just the first, obvious issue. There are things that can help with that like json-schema, openapi, graphql and so on, which solve some part of this at some level. Let's go for json-schema, which is the simple, focused data driven and pretty well designed. Great isn't it?
But it doesn't stop there.
You now have at least two libraries in different languages with different levels of support for the spec, so you need to settle on the lowest common denominator. That's just the validation part, now you want error reporting, which means duplicating logic again. You probably want to convert the schemas or at least the data structures they validate into something that your languages work well with, that's duplicated logic again.
Then you also need to somehow pull them in, build them etc. which is duplicated tooling around your language environments. Now you have version dependencies of somewhat the same thing in two different ecosystems with different versioning issues.
Whenever I said "duplicating" I really meant "solving the same-ish problem in two different ways", so "duplicating" is an euphemism here. It's a proliferation of accidental complexity and coupling.
Isomorphic code is not just a 1:1 thing. It's not necessarily the same functionality that you maintain on both sides (like validation) it's _all_ the other stuff as well, unrelated in terms of single features.
Aside from validation and data integrity - and the whole jungle of stuff that comes with it - you also need a bunch of fundamental data structures, network I/O, possibly routing logic if you're doing anything that's dynamic on the frontend and serves UX beyond just displaying text and images in a nice way. You want quick, optimistic feedback on the client, so you're coordinating more state and data, which means more duplication again. You might want to move stuff from the server to the client and vice versa, when you discover basic optimization issues.
Isomorphic code is _leverage_ to a high degree from tooling to standard libraries to knowledge, familiarity and mastering a language and ecosystem as a programmer.
If you decide to use a heterogeneous ecosystem you better have good reasons for it such as legacy code, specific powerful libraries and integrations you need to use or high expertise in a particular language that cannot talk to both sides.
Re: The absurd complexity of server-side rendering
#299Hello. I'm here from 1999 and I'd like to help: https://htmx.org
Probably more like ~2005. I was a web developer in 2001 and XMLHttpRequest still felt like secret knowledge that you only found out about by digging deep into Microsoft documentation (and wasn't well supported if you weren't using IE). Most people I knew were making pages interactive by targeting forms to iframes.
Some of us were using JAVA Applets to make async requests ;)
Re: The absurd complexity of server-side rendering
#300I'm convinced SSR is only a thing because of Lighthouse scores. Client-side rendering with client-agnostic REST APIs is a fantastic architecture. But noooooooooo we can't have nice things
Now that the end-user is essentially using their browser as a thick client for that RIA/SPA, and the client-server interaction primarily supplies certification and replication services, we can congratulate ourselves on having more-or-less reinvented Lotus Notes.
Ouch, that hit too close to home :/ It's too early for whiskey where I live.