Without RSC you have to wait for the user to download the application bundle before the request for content can even be sent to the server. So that means that the db queries and stuff are not even initiated until the client has the bundle and runs it, vs with RSC that stuff is all launched the moment the first request comes in from the user.
That doesn't seem to be how this implementation of RSC is intended to work. Here, client code triggers the RSC fetch, which is treated as any other sort of data fetch. Presumably, it still waits for client code to load to do that.
Also SSR, even in React, existed well before RSCs did, and that seems to be really what you are talking about.
SSR is different and does not provide the same performance of RSCs. With SSR you get the advantage of an initially rendered page, but you don’t have access to data or state. So you are just rendering placeholders until it hydrates and the client can request the data.
RSCs allow you to render the initial page with the content loaded right away.
That said, I am not sure about Tanstack’s implementation. Need to spend more time reading about this.
You have it reversed. SSR in react without RSC gives you access to data and state on the client. That's what the hydration does. RSC strips it out to make the bundle smaller. There is no hydration
I mean the state from the client, like cookies and URL params. You can get access to that in SSR through the framework specific APIs like getServerSideProps in Next, but it’s not a great solution.
> Without RSC you have to wait for the user to download the application bundle before the request for content can even be sent to the server.
This is an argument for not putting all your JS in one monolithic bundle and instead parallelizing data loading and JS loading. It's not an argument for RSC.
2nd RT: data (app server) and code (CDN) in parallel
Therefore you need two. But not all roundtrips are equal. A roundtrip to a CDN is much faster than a roundtrip to an application server and database, unless you have some funky edge database setup.
If you render on the server, your first roundtrip is slow because the client has to wait for the application server and database before it can show anything at all. If you render on the client then your first roundtrip is fast but the second one is slow.
Transit lines in many countries do support themselves by increasing productivity and tax revenue near the stations. It is not as direct as in Japan, where the train company itself captures the value created by its stations, but it’s effectively the same thing. Most places in the world with effective public transit systems are more like LA than Japan in how they are funded and operated.
So you can claim, and I agree, that it's supposedly an investment. Unfortunately, putting it in the hands of politicians to fund often means funds are taken away for other things. Where as, the private Japanese train companies fund themselves and it works.
This problem, along with general annoyances at Proton’s lack of focus on a good email experience pushed me over the edge to move to Fastmail. I’m so much happier. Proton Mail Bridge would often pin one core of my laptop CPU, draining my battery, and it was still slow to sync new email. With Fastmail, incoming mail is so fast that the verification codes are already there before I can alt tab over.
Proton’s pricing is really frustrating for me because I want to buy upgrades to only a few services like Pass and email. Your only option on their service is to select either Pass or Mail. You cannot buy both and you will be downgraded on one if you try to buy the other.
They really haven't improved Mail in a long time now. Still can't use your own keys, still can't have a clean unmangled export, still can't send using your own keys.
It's almost like Protonmail is intentionally hostile to key management outside of their control.
Same here, I've found too many bugs in Proton's email client and instead of fixing them they just release new products. FastMail support has been great, I think the developers themselves reply (some of the?) emails, going into technical details and being actually helpful.
I got a Garmin watch after being frustrated with the tech company watches lasting only hours on a charge. I charge this watch once a week and it does everything I realistically want from a smart watch:
- shows notifications
- tracks workouts
- silent alarm clock
- home assistant shortcuts
I'm a big fan of Garmin watches, it's really impressive what they've built. They're responsive, they have the smart features I want without the bloat I don't want, the battery lasts forever (if I don't use GPS at all it lasts something ridiculous like three weeks, with GPS it's still around a week). And they're so good I don't feel any urge to upgrade to a newer model even though the one I currently have came out in 2019. I bought it "renewed" 2.5 years ago at a significant discount and I could see myself happily using it for at least another 4-5 years.
Garmin watches are great! I wish the lighter/smaller models also had solar charger, but last time I checked only the bigger "ultra-durable" ones had it, but they're not that comfortable to wear.
I work on an open source server project that is deployed in many different contexts and with many different clients and front ends. GraphQL has allowed us to not feel bad about adding extra properties and object to the response, because if a particular client doesn’t want them, they don’t request them and don’t get them. It has allowed us to be much more flexible with adding features that only few people will use.
I want to be able to sync Orion with Firefox. I use non Apple operating systems on some computers, and I would love to have Orion sync with Firefox on them.
I have tried jj several times but I feel like it slows me down significantly because I can’t grok the workflow. I like to do a bunch of changes then quickly select them in my editor and commit them, breaking them up into different commits to keep them organized. With jj’s lack of editor integration, I don’t know how to do this with the cli alone so I end up with bigger messier commits.
Or if you don't care to set a commit message just yet: jj split -i
Or if you want to defer making sure each commit has the right content until later, just use jj new, and then later use jj squash and jj split to make the commits have sensible changes, and jj desc to set the descriptions.
The compatibility with git is the whole reason it's so popular (just run `jj git init --colocate` in your git repo).
You can use it without forcing your collaborators to switch from git and you can use it will a git forges as well.
I don't think you need `--colocate` any more, and maybe you don't even need `git`? I tried `jj init` in a git repo the other day and it did create a colocated jj repo, as far as I could see.
reply