311–320 of 371 posts
Earlier quoted context omitted.
I'm unaware of their existence. I'm guessing they're big and expensive. Or maybe hard to get?
What kind of outputs? Fiber to analog is about $15 and the size of two hockey pucks stacked.
Earlier quoted context omitted.
Huh? How does HTMLx "chuck" away SSL (you meant TLS, right? I hope you're not using SSL) and encrypted cookies? How about you try it and see?
It’s fine to use SSL interchangeably with TLS IMO. It’s still called OpenSSL.
There are only few use cases, where the new kind of SSR (with hydration) is worth it. An example are e-commerce sites where you want the customer to see all your great products as soon as possible and then some seconds later to be able to interact with your side fluently to buy something. These kind of scenarios paired with low end devices are the only proper use case. And I say consciously "only proper" because SSR…
For something that could be a single point of failure, like Cloudflare workers was according to this post:
https://news.ycombinator.com/item?id=34639212
Edge workers are cool and all but if you don't need them, why add them as an intermediary / source of lock-in?
Of all the new ways of thinking, Remix is the leader in not promoting a specific paid delivery platform. So in that sense I can see why people might want to mitigate its advantages by trying to tie it to React.
(having said that, Shopify might tie it down more, but I see no evidence so far)
> Performance is higher with the server because the HTML is already generated and ready to be displayed when the page is loaded. If you can reasonably cache the response, SSR wins on first page load, no question. On the first page dynamic render "it depends", can be SPA or SSR. 2nd page render a well built SPA just wins. "it depends....." Server CPU cores are slower than consumer cores of similar eras. They run in en…
If there's any secret info being transmitted (ie, session tokens) and you're using TLS, you shouldn't be using compression.
Earlier quoted context omitted.
It seems such a waste... You're chucking all that cryptography (ssl, encrypted cookies) away only to be redone every. single. Dom change
Huh? How does HTMLx "chuck" away SSL (you meant TLS, right? I hope you're not using SSL) and encrypted cookies? How about you try it and see?
And I have written a library that does the full SSL handshake/upgrade cycle off of tcp sockets, and managed my own private CA, so I'm not a total idiot.
Earlier quoted context omitted.
It’s fine to use SSL interchangeably with TLS IMO. It’s still called OpenSSL.
I suppose, but it's not really that big of an effort to just use the correct term for the correct version of the technology.
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)?
Perhaps most significant is that a lot of data, state that is needed to render the content doesn’t have to be transferred to the client?
But realistically the amount of data is likely small for most applications and it's probably not the bottleneck.
Is SSR still much better for seo?
If we are comparing complex SPAs then it's not really relevant
Earlier quoted context omitted.
>Offloading the computing means the users have a worse experience Does it though? Loading a webpage barely registers in cpu usage etc on a reasonably modern device
> Does it though? Loading a webpage barely registers in cpu usage etc on a reasonably modern device. CPU usage is not the problem. In most cases the problem is latency including the network latency to issue and return a substantial number of remote API requests across the Internet to get the data necessary to render the page. In many cases unless you make page specific APIs that aggregate all the necessary data into…