Call me old fashioned, but PHP still gets the job done better than just about anything else.
The absurd complexity of server-side rendering
321–330 of 395 posts
Re: The absurd complexity of server-side rendering
#322Earlier quoted context omitted.
This was my PHP experience with CodeIgniter 15 years ago. Nothing new under the sun.
That's good, I think? I'm not claiming that Laravel was the first or the best PHP framework, just that they were using it. (Admittedly I assume it's a reason their code is so well organized.)
Re: The absurd complexity of server-side rendering
#323Call me old fashioned, but PHP still gets the job done better than just about anything else.
And usually leads to a BBOM architecture
I've seen microservices that had absolutely no guardrais going off the hill too many times. At my previous job "migrations" where bash scripts with SQL in them because they "didn't like ORMs and they were slow". LOL. They were handling signup form POSTs and profile updates.
Re: The absurd complexity of server-side rendering
#324I'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
As soon as you have to work on both sides of the API, it is not and advantage anymore.
I think separating the backend from the frontend is a way to increase the amount of work required in order to gain a saner way to split it into chunks for different teams.
As a single person, or a small team, doing an SPA and an API only backend, if not done for learning purposes then it is just either madness or CV padding, or something else....makes no sense at all to me.
Re: The absurd complexity of server-side rendering
#325Hello. I'm here from 1999 and I'd like to help: https://htmx.org
Re: The absurd complexity of server-side rendering
#326The original server side rendering (HTML rendered on the server by your choice of language) is simple, efficient and most sites on the internet still use it, including this one. The article is talking about ‘modern’ js style server side rendering combined with client side rendering, which is of course a huge dumpster fire and encourages absurd complexity on both sides of the equation, starting with the fact the app i…
Such a basic building block seems to be fading away nowadays, even some times presented as a "novel" thing or a "feature" (eg: remix)
Re: The absurd complexity of server-side rendering
#327Earlier quoted context omitted.
> People complain about reddit a lot, but even on mobile, the reddit website is fast. only on mobile is Reddit fast.
Pardon me while I load up reddit on my 4 year old $1000 Costco Special laptop. Yup, that was fast. OK let me disable ad block. Under 3 seconds to first render. Comments appear in under 2 seconds. Reddit performs very well. The new UI is legit faster. There is a bit of stupid here and there with it, and if you aren't logged in the experience is horrible, but speed is, IMHO, not one of the site's problems.
Re: The absurd complexity of server-side rendering
#328There are cases when server-side rendering (without SPA) is easier and faster. For example: documentation sites, blog-like sites, internet stores, sites like Hacker News. In all these cases, you can save on development time by writing just one application instead of two (server and client), and improve performance (no need to load multimegabyte JS applications and make multiple AJAX requests to display a page). Of co…
I feel like not many people realise this is an option but it can work really nicely.
Re: The absurd complexity of server-side rendering
#329The complaint in the article is technical, but my issue with the SSR + hydration approach is that it doesn't actually work for the users. Mainly because if you need a page that is indexed by Google, there is a high chance your users will browse it and open pages in new tabs. So the approach of "there is a small initial penalty, but everything is faster later" no longer applies -- you get that initial hit quite often.
Re: The absurd complexity of server-side rendering
#330Earlier quoted context omitted.
Hiya, I wrote this gist. I do actually think Monads or similarly expressive type constructs would allow us to eliminate this class of issue for good. Hopefully the rise of Wasm makes this problem irrelevant for functional programmers, but that’s a whole other can of worms. That said, it’s probably impractical to try and achieve that sort of type safety in JS via the Monad route, but maybe a clever TypeScript extensio…
Monads are just type constructors with two operations: bind and pure. I fail to see the connection and why do you need a type constructor with a bind and pure operation at all to solve SSR.
Say you have a `ServerIO a` and `ClientIO a` type. Browser APIs, like addEventListener, would use the ClientIO type. Server specific APIs like fs would use the ServerIO type. That would prevent the entire issue I've described, and allowing users to confidently make changes to their shared code.