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

Ask HN: Server side rendering is now a good idea?

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 43 posts

Re: Ask HN: Server side rendering is now a good idea?

#21

Post by mrvenkman »

throwmeup123 wrote: post #17
sergiotapia wrote: post #8

It's a lot simpler for sure these days. I've built my indie startup with Phoenix Liveview. It's all server side rendered, with liveview sprinkling in interactivity. Can you tell it's server side rendered? https://www.gamedrop.gg/lists/slymilano/exciting-game-releas... https://www.gamedrop.gg/game/hogwarts-legacy I think there are similar tools in other platforms like Rail's and Laravel.

Tried it on my old kindle fire and the performance is amazing. If you are targeting regions with mainly low performance devices this is how you should do it. Love it.

You highlighted another advantage: HTML is quicker to parse.

Re: Ask HN: Server side rendering is now a good idea?

#22

Post by danpalmer »

mrvenkman wrote: post #14
caprock wrote: post #4

You might want to look into what the creator of htmx has to say about this topic. He's here on hn and may even show up for this thread. Here are the essays: * https://htmx.org/essays/

Fantastic article. And I appreciate you sharing it with me. The idea of introducing a new attribute to a HTML tag, whether it be "_" or "_foo" or "_do" doesn't quite sit properly with me. Especially if it's not part of the HTML5 standards.

It’s explicitly part of the HTML spec that you can do this, and that the semantics of those attributes are application/user defined, and should not be interpreted by the browser.

Re: Ask HN: Server side rendering is now a good idea?

#23

Post by Alifatisk »

I agree with you, you can ship very interactive ui without the complexity on the frontend.

Have a look at stimulusreflex for example [1], the state is handled on the backend leading to you shipping less bloat to the client!

1. https://docs.stimulusreflex.com/#faster-uis-smaller-download...

Re: Ask HN: Server side rendering is now a good idea?

#24

Post by trynewideas »

danpalmer wrote: post #22
mrvenkman wrote: post #14

Earlier quoted context omitted.

Fantastic article. And I appreciate you sharing it with me. The idea of introducing a new attribute to a HTML tag, whether it be "_" or "_foo" or "_do" doesn't quite sit properly with me. Especially if it's not part of the HTML5 standards.

It’s explicitly part of the HTML spec that you can do this, and that the semantics of those attributes are application/user defined, and should not be interpreted by the browser.

Out of genuine curiosity, where's this defined? I went looking and could only find https://www.w3.org/TR/2011/WD-html5-20110405/Overview.html

> For flexibility, attributes names containing underscores (the U+005F LOW LINE character) are also reserved for experimental purposes and are guaranteed to never be formally added to the HTML language.

> Note: Pages that use such attributes are by definition non-conforming.

in a broader context of "experimental purposes" being for "vendor-specific proprietary user agent extensions to this specification", which "are strongly discouraged. Documents must not use such extensions, as doing so reduces interoperability and fragments the user base, allowing only users of specific user agents to access the content in question."

Is that it? That seems different, but I don't see anything else similar. Or am I looking in the wrong spec?

There's also https://html.spec.whatwg.org/#attribute-name-state which defines attribute names as not inclusive of underscores.

Re: Ask HN: Server side rendering is now a good idea?

#25

Post by andrewf »

The speed of light isn't getting any faster. Examples: https://www.cloudping.co/grid

I'd be wary of taking asynchronous actions and making them synchronous. For instance, if you had a list of items each with a delete icon next to it, you don't want to turn deleting three items from click-click-click into click-wait-click-wait-click.

Chrome Dev Tools can simulate added latency as well as restricted bandwidth, so you can plug intercontinental latencies in and see how much a particular site is affected.

Some things will be fine. I'm posting this on HN from Western Australia, no problems.

Re: Ask HN: Server side rendering is now a good idea?

#27

Post by rjbwork »

WhiteBlueSkies wrote: post #26

Whatever removes React is the way to go, it's the most poorly thought of library out there.

Can you elaborate on this please?

I'm a backend engineer with little interest in the frontend morass de jure, but my company is looking to move to React. Reasons are that Vue2 is being EOL and there's a lot of work to move to Vue3, it's about the same workto just start over in React and there's a larger pool of talent for it.

I don't really know much about the whole situation, but it seems to highlight the cause of my general disinterest in the ecosystem. Would be nice if you could shed some light on it.

Re: Ask HN: Server side rendering is now a good idea?

#28

Post by dieselgate »

trynewideas wrote: post #24
danpalmer wrote: post #22

Earlier quoted context omitted.

It’s explicitly part of the HTML spec that you can do this, and that the semantics of those attributes are application/user defined, and should not be interpreted by the browser.

Out of genuine curiosity, where's this defined? I went looking and could only find https://www.w3.org/TR/2011/WD-html5-20110405/Overview.html > For flexibility, attributes names containing underscores (the U+005F LOW LINE character) are also reserved for experimental purposes and are guaranteed to never be formally added to the HTML language. > Note: Pages that use such attributes are by definition non-conforming. in…

Not sure what parent post was referring to explicitly but data attributes were the first thing I thought of in this general context

Re: Ask HN: Server side rendering is now a good idea?

#29

Post by WhiteBlueSkies »

rjbwork wrote: post #27
WhiteBlueSkies wrote: post #26

Whatever removes React is the way to go, it's the most poorly thought of library out there.

Can you elaborate on this please? I'm a backend engineer with little interest in the frontend morass de jure, but my company is looking to move to React. Reasons are that Vue2 is being EOL and there's a lot of work to move to Vue3, it's about the same workto just start over in React and there's a larger pool of talent for it. I don't really know much about the whole situation, but it seems to highlight the cause of m…

I tried to elaborate in a previous comment(on some other post) but moderation deleted my comment. It's very difficult to hide disgust and disdain for this library if you've used it. The reasons are as follows:

1) React boasts that is just JS but has arbitrary rules like don't use useEffect in loops.

2) Even after 9 years even the core features are not clearly explained. The authors clearly did not know what they were doing.

3) There is no in-depth treatise of the library anywhere. A tweet here and a tweet there or some blog posts which you can't even figure out if they are outdated. If you visit the docs you'll see the most trivial examples because anything more complicated and now you are neck deep in trouble due to state menagement.

4) See this: https://news.ycombinator.com/item?id=34142168. It's a mystery if useEffect is for side-effects or not. If you use any other well-documented library you will see things clearly explained in the docs. With React it's just hype based woo-woo. It is responsible for degrading web development into plug-and-play style of poorly written components glued together because the core idea is just bad.

Re: Ask HN: Server side rendering is now a good idea?

#30

Post by dieselgate »

rjbwork wrote: post #27
WhiteBlueSkies wrote: post #26

Whatever removes React is the way to go, it's the most poorly thought of library out there.

Can you elaborate on this please? I'm a backend engineer with little interest in the frontend morass de jure, but my company is looking to move to React. Reasons are that Vue2 is being EOL and there's a lot of work to move to Vue3, it's about the same workto just start over in React and there's a larger pool of talent for it. I don't really know much about the whole situation, but it seems to highlight the cause of m…

I get the impression parent comment was being a bit sensationalist. React has pros and cons but people generally wouldn’t remove react in favor of jquery (or something else). You mentioned a very valid case of beginning to use react - it’s commonly used and works
Post reply on HN