171–180 of 286 posts
One of the fastest, lowest latency websites I use is HN, and it’s entirely server rendered. It’s also a massively popular website with probably thousands of hits per minute. Anyone who tells you server side rendering is too slow, probably has no idea what they’re talking about.
The reason client-side rendering is so popular (IME) is that it creates a clear separation between frontend and backend devs. You can use separate repositories, languages, deployment flows/cadences, code review, etc, with an API as your connection point (and the fact that you get an API by default with CSR is also nice). I don't think CSR is going anywhere, mainly thanks to Conway's Law.
Lots of hype from people who obviously never managed a real website or a real-world software project.
On the non-technical side, traditional server/client separation is well understood by everyone and has all the tools any team ever needs, while SSR takes some learning -- it is added cost that does not transfer in many places.
On the technical side, SSR only has clear advantage for very specific scenarios, e.g. e-commerce site where rendering time and responsiveness across different devices is a top priority. For the vast majority of websites out there, SSR likely only increases your server load and cost when you could leave all the rendering to client which is free resource. As browsers and computers themselves get faster, you don't even need to do anything to get better performance on client machines. Otherwise, this does not matter any more than Pepsi vs Coca-Cola or vim vs emacs.
If SSR is clearly the better choice for a team/product, go ahead, otherwise don't waste time on it.
This article misses the single most important reason to use SSR: single language applications are single build applications. Frontend builds are basically a requirement for any application with a UI. You're always going to have CSS, and some degree of user interaction for even the simplest website, which means JS/TS. One of the most important developments for frontend assets in the past decade is dependency managemen…
"Frontend builds are basically a requirement for any application with a UI" I disagree with this premise. Dynamic languages don't have builds either.
This article misses the single most important reason to use SSR: single language applications are single build applications. Frontend builds are basically a requirement for any application with a UI. You're always going to have CSS, and some degree of user interaction for even the simplest website, which means JS/TS. One of the most important developments for frontend assets in the past decade is dependency managemen…
I don't know your background but most teams don't view "single language" as an advantage over other options. People choose a certain language because of internal infrastructure, libraries/ecosystem, performance, and whether it is the best suited for a project etc, rarely because "we use that language for backend so we should also use it for frontend" or vice versa
This article misses the single most important reason to use SSR: single language applications are single build applications. Frontend builds are basically a requirement for any application with a UI. You're always going to have CSS, and some degree of user interaction for even the simplest website, which means JS/TS. One of the most important developments for frontend assets in the past decade is dependency managemen…
I say save yourself the trouble and just avoid all "modern" web development tooling. Avoid "frontend builds" at all costs (everything except for esbuild is insanely slow anyway). Most websites do not need npm for frontend (or backend). Most web applications are barely "applications" at all but rather mostly-static content with a few forms, tables, and/or menus. I use vanilla html/css/js for frontend + golang for the…
It's messy and you end up writing helper functions for pretty much everything. Need a href aware navbar? Custom function and macro time. Bleh.
Performance is great, maintainability isn't.
I dislike graphql because it's too mich overhead. RESTful is not good enough, only good for admin UI CRUD.
I moved to json rpc calls. So I can have the best of both worlds.
However what I'd really like to have is a proper SSR component framework that is interactive or rather reactive.