Ask HN: Server side rendering is now a good idea? Thanks to the speed of the internet, I’m beginning to feel that logic on server side with PHP or other server side technology, is just as interactive as JavaScript - without the complexity of React, Angular [insert framework here] and associated package and state management. Oh, and security! Thoughts? |
CSR solves a different set of problems. One common problem is that front-end developers don't always have access to the back-end, nor do they always have the skills to deal with back-end. Sometimes it's just quicker to have back-end provide the data (i.e. an endpoint), and have the front-end deal with it.
I think, since before CSR became the popular trend, that front-end development had fragmented and proliferated so much that it has become fairly complicated. Front-end development used to be just a web "designer" would design it and make the page look pretty. Toss in some JS for interactivity + animation. Once they're done, hand it off to the web "developer" for hosting and integration into the web server. Now it has grown into this monstrosity where we can have the designer, UI/UX person, front-end API, etc. With the client doing all the rendering, web pages have started to slow down. At some point, folks are like, "Wait a minute! What about SSR? We can solve so much of our performance and security issues that way!"
Trends are often cyclical, with the previous trend being replaced by old trends making fresh rounds. I suspect we will see old ideas with fresh eyes, and a new way to reason about things.
I think that you do need interactivity through JavaScript at some point. And I find react and similar easier to maintain than an HTML/JS soup generated by PHP, JSP, or RoR.
I would take a look at https://fresh.deno.dev/ or https://kit.svelte.dev/ or https://nextjs.org/
- Qwik[1]: code is very similar to React, only the interactive parts are sent to the browser, and they only execute on demand (eg when you interact with the thing)
- Astro[2]: probably the most popular “islands” framework, lets you bring your own interactive framework
- SolidStart[3]: doesn’t mention in the docs yet for some reason, but also supports “islands” in SolidJS, which is also one of the fastest client frameworks and also will feel familiar coming from React
[2]: https://astro.build/
[3]: https://start.solidjs.com/getting-started/what-is-solidstart
Here are the essays:
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.
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.
For everything else, meaning 99% of the projects you will ever be paid to work on, server-side framework with just a little sprinkle of JS where needed is enough and 10x more productive.
Apps that need react and other similar frameworks are like excalidraw, linear, figma, etc. think most crud apps are fine.
However, react is still a great programming tool for me. I like the abstractions available with remix, next, qwik, and all that. I can still have a backend api team, and a separate web team that uses remix to consume the api. Simple models.
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.
A specific horror show I remember was a Netflix-like DVD shipping service, where you maintained an ordered list of DVDs you'd like to receive. Each DVD in your queue had a textbox with a sequence number (1, 2, 3...) in it. You could edit the numbers and on submit, the server would do a stable sort. "1" and "999" could conveniently push multiple items to the top/bottom of the list, but to precisely order the first five items - the most common use case! - you'd usually need multiple passes. Drag and drop would have been way better.
I believe that minimalist, well audited REST or Websocket protocols are FAR more secure than server side rendering. How can you audit the entirety of your UI for security flaws? How can you analyze data leakage formally over such a large surface area? You cannot. But you can analyze 10 REST endpoints passing JSON. You can analyze RPC over websockets. Often times such specifications can fit on 4 sheets of printer paper. Take it on the train with you. Print out a copy and look for security flaws while you're on the toilet. You can't do that with server-side rendering.
I guess if there is not much data-flow both ways, then server-side rendering could be much more secure. For example, if you have a page live rendering stock charts on a news site. One that is complex but doesn't allow for much configuration. Server side rendering would be more secure. However, if you are creating something like a CRDT based shared spreadsheet that supports formulas, server-side rendering could basically mean that you are giving untrusted clients the ability to run Turing complete code on your server ;) . You'll be far better off having as much as possible on the client and as small and simple a protocol as you can manage between the front end and the back end.
Basically, security wize:
- If drawing the page requires a huge number of data points to create a visualization that the client cannot interact with much, then server side rendering reduces the attack surface (you're just sending display information).
- If the page allows for a lot of user control over the data, you increase your attack surface by processing more untrusted information server side.
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...
Its been doing server side rendering for 20 years. If you got vaxxed in the USA, there's a good chance you used APEX to book your appointment.
I wanted to use SolidJS for its performances, but it has a poor ecosystem. I tried to ditch front-end frameworks all together and I ended up synching states between components manually. In the end, I guess React (or Vue) gives you a good balance between pro and cons.
I guess, ecosystem is important beside mere performance. This is not only true for fast shipping, but for developer experience too.
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.
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.
> 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.