301–310 of 371 posts
Earlier quoted context omitted.
They benefit from a .exe (or a .tar.gz or a .apk) downloaded when convenient and run locally
Any app with dynamic data would still need to make some sort of HTTP request before rendering some view with that new data. I don’t really get your point.
"A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete." - would like to have a word with you...
- SSR is always slower than static sites
- SSR is often slower than CSR - especially when using a small and fast framework like Solid, Svelte or Vue3
- When rendering on the edge and using a central API (e.g. for the DB) SSR is always slower when interacting with the site than CSR because of the extra hop from your central API to the edge to the browser instead of from the central API directly to the browser
- SSR is always more complex and therefore more fragile, however this complexity is handled by the frameworks and the cloud providers
- SSR is always more expensive - especially at scale.
- Traditional SSR with html templates will scale your site much better, simply because traditional languages like Go or Java or C# are scaling much better than NodeJS rendering the site via JS
We owe the technology of the "new" SSR and genius stuff like islands many very smart and passionate people.
Overall, this article not balanced at all. It is pointing out only some potential benefits. It simply is a marketing post for their product.
Earlier quoted context omitted.
What is it you dont trust? This Fear Uncertainty & Doubt clashes heavily with the excellent security sandbox the web browser is. What is the harm you are afraid of? What are you supposing the risk is/what's in jeapordy here?
JS allows for fingerprinting. I only run JS on a opt-in basis on like my bank and some pages I trust. You don't miss much really. https://amiunique.org/fp
Earlier quoted context omitted.
Getting an API for free is an anti-feature for all the temporarily-embarrassed monopolists on HN. More seriously, though, it's nice to be able to just build without thinking too hard about if you're getting your abstractions perfect. To me, this is the main advantage of SSR - moving fast doesn't leave behind a wake of idiosyncratic APIs that need to be (carefully, dangerously) cleaned up later.
In my experience moving-fast SSR absolutely does leave behind a wake of idiosyncratic APIs that definitely need to be cleaned up later. You still need client-server communication, so you still have an API, it's just an ad hoc API that speaks HTML and form data instead of JSON. And because you didn't think of it as an API while you were building it, it actually tends to be harder to clean up later, not easier.
If you don't do server side rendering, you don't (almost) automatically get a set of nice REST endpoints that return JSON/XML/ETC? I get that the abstraction might be nice for security, but at least for corporate intranet applications, a nicely structured, secured (e.g ODATA) webapi you query for client side rendering has the added benefit that it can be invoked programmatically with REST by other authorized parties.…
Why are those things mutually exclusive? You can have an API and then have a different app that uses that API with server-side rendering. I.e. instead of a client SPA you have a server app using the API.
Earlier quoted context omitted.
Yes indeed! The core aspect, however, is that your server is returning fragments of html that htmx places in the DOM extremely quickly. They have pretty good examples on their site illustrating some "modern" UI patterns. As an example, you may have an HTML table on your page that you want to insert a new row for some reason on let's say a button click. You place some attributes that htmx understands on your button th…
How well does their example work over satellite internet with 1.2sec latency? How about my cell connection when T-mobile throttles me to 64Kbps for going over my data allowance? How about my sister's cell connection, as she is on an MVNO and deprioritized sometimes to 128Kbps, sometimes to 6Mbps, and sometimes it varies within a minute between those two? FFS, people, learn to write proper software that does everythin…
Software that doesn't need the internet for its function shouldn't connect to the internet. Software that does need the internet should be able to operate under adverse network conditions.
The Voyager probes are 160 AU away, far past Pluto, with a roundtrip latency of 37 hours. The radio transmitter onboard is only about 10x more powerful than a cell phone. The hardware has been in the cold vacuum and hard radiation of space for four and half decades. In spite of this, NASA maintains active two-way communication with it today, and continues to receive scientific telemety data of the outer solar system.
I don't expect web devs to design for deep space, but the core functionality of a website should still work for a rural user with a spotty satellite uplink. Don't do go loading JavaScript or other resource calls until the basics are received. I still remember the days of Facebook being fully functional on a 2G cellular connection, using little or nothing more than static HTML and CSS (and that was before the magic tricks HTML5 can do).
Earlier quoted context omitted.
Why are those things mutually exclusive? You can have an API and then have a different app that uses that API with server-side rendering. I.e. instead of a client SPA you have a server app using the API.
Sure they're both viable options, but running 2 server-side apps that could be 1 server-side app and a folder full of HTML/CSS/JS served over CDNs certainly has some trade-offs. e.g. in terms of security, I'd prefer to have a smaller surface area server-side.
The claim that server side rendering is faster than client side rendering is interesting.. How come one machine(the server), is better than 1000 machines(the client)?