Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Why server side rendering is not used anymore

news.ycombinator.com

Post reply on HN
Print view View original

31–35 of 35 posts

Re: Ask HN: Why server side rendering is not used anymore

#31

Post by manigandham »

gkhartman wrote: post #15
tailspin2019 wrote: post #10

Earlier quoted context omitted.

Blazor Server is a pretty good websockets based framework for rich web applications. (Source: I have one deployed as a SaaS app)

I've wanted to try this, but that connection drop issue sounds like a deal killer when serving page data when compared with ajax polling. How does it handle connection failure? I've worked on event based software for desktop/mobile where the best case was to detect the connection drop on the client side then show a "reconnecting" message while it tries to regain it's websocket. It usually sounds easy to implement, bu…

Blazor is the UI framework, the underlying connection is actually handled by SignalR which uses several transports from WebSockets (by default) to server-sent events and long-polling.

The Blazor server framework and JS already handle connection drops automatically but you can also add your own logic (like forcing a page refresh if it takes too long).

Re: Ask HN: Why server side rendering is not used anymore

#32

Post by toast0 »

stdcall83 wrote: post #5
potamic wrote: post #4

What are SOC applications like? Generally for rich web applications with a lot of interactivity, you want to do client side rendering. Interactive apps can be deceptively complex to build and you really want to hire the right people for it. The spectrum of web developers you can find in the market is very wide which doesn't make it easy to find the right people. It also doesn't help that consultancies generally want…

Esentially something like this: https://www.xilinx.com/htmldocs/registers/am012/am012-versal...

At risk of being that guy on HN, this looks like the kind of thing that you would run and generate a static html and always use the same css.

If you're not happy with the perl tool, I'd run it to get all the HTML, then build a new tool in your favorite language that reads through the same source material and generates similar HTML (you can fix stuff you don't like as you go along, but don't change too much if the goal is to just get it done). I'd give an experienced developer about a week, or an average intern a month or three, assuming there's some hidden complexity, but not too much.

I'm not surprised software solutions companies aren't going to bid on a project that's 40 hours of work. And that you got someone to build a monstronsity instead.

Re: Ask HN: Why server side rendering is not used anymore

#33

Post by lmarcos »

arinlen wrote: post #23
cmer wrote: post #14

Hype. That is why. 99% of web applications don’t need to be SPA. And the majority of the other 1% probably need just a fraction of their app as SPA. Rails gets it right with a Hotwire IMO.

> Hype. That is why. I'm not sure this personal assertion holds any water. Think about it for a second. You need to have a front-end, and you have to pick your tech stack. You know all you need is to render a nice page with some user interaction support and some automation. You have a small team of front-end developers to pull that off. What are you going to pick? Is it a good idea to force upon your team a full stac…

You mention "frontend team", "server development", "backend code"... But it's all just programming, we are all just programmers (or problem solvers). We can use HTML today, Python tomorrow, and SQL on Fridays. You can learn K8s during spring, and focus on Go during winter time. On summer better to improve your Pinia skills, while on autumn one should read SICP. Christmas time is for bash, though.

Unfortunately, "modern" IT companies do make the distinction between "frontend" programmers, "backend" programmers, etc. They do this not because it's better for us (the programmers), but because it's cheaper for them. If you care about your career, do not specialize. On the other hand, if you only care about your job, then sure go ahead and become a "frontend" (or "backend") master.

Post reply on HN