Unless you’re talking about SSG and not SSR, I think one potential issue would be that React’s SSR process is pretty slow and costly, at least from what I understand. I have to confess I haven’t heard of a pure-SSR React app before, as you wouldn’t get many of React’s benefits if it’s just being used as a templating language.
It's really no more costly than Django/PHP/Ruby mustache-style template rendering. I consistently see 100-150ms last byte timings from a Next.js app I host on Vercel.
I’ve heard great things about Google Domains but this kind of story is exactly why I probably won’t be using that service. It’s just too risky if you lose everything at once.
Honestly: don't upload unencrypted content to anyone, for exactly this reason.
I have cloud backups of family photos, but they're all through restic or rclone with the crypt filter applied. Privacy is about the right to put yourself in context.
For this type of encryption, I think the password could be “password” and that would be good enough. The primary goal is to frustrate automated scans, not targeted brute force attempts.
That's a problem with very easy solutions, considering what's at stake. Use a paperkey, NFC card, smartcard or even a printed data matrix sheet to store the keys and/or password DBs. The reason why all these aren't popular enough is that people don't consider privacy to be important - until something goes seriously wrong, like in this story.
Sorry, 99.99999% of the general population don't know what restic or rclone is. In fact, I won't be surprised if 90% of software engineers have never heard of them. These things aren't really know outside circles like hacker news.
As software engineers and the stewards of modern technology, we have a responsibility to build tools which enable capability for the rest of the people - particularly in the open source world.
People can't run their own encrypted messengers so we have Signal. People should be provided with interfaces, and advocated too, use cloud services for their data in a safe way.
Yeah, the way Google likely ties your accounts all together a wrong decision on any Google account even if not the same account for your domains could end up having all your domains stolen by Google.
What I'd like to know if if they actually deactivate multiple linked accounts when any one of them gets flagged. I have three accounts, one more for personal things, one more professional, and a third one with my current country as a location for getting local apps in the Play Store.
Google knows I am the same person, even though they are different accounts, so are the two other accounts safe when one of the three gets flagged?
As a basic consumer storing somewhat not important things on Google is potentially risky for the content on it but you aren't paying them anything so its probably worth the trade off. For a business or for something you pay for Google's support is atrocious and its not worth the hassle given all the horrendous failure modes it can put you in. One thing Google consistently is teaching people is do not pay them directly as they don't know how to treat their customers.
I ran into the same situation multiple time and was never able to find a solution besides throwing more money at servers. That might be due to my own lack of knowledge about running servers and performance optimization as I was (and still am) a front-end person first and foremost.
This is perhaps one of the most misunderstood and misused quotes I know of. It doesn't mean what people think it means, yet I hear it misapplied at least a few times every year.
(The quote has to be understood in its original context. It isn't really about performance as such, but about maintaining degrees of freedom and development flexibility until you understand the problem you are solving and can commit)
That's very kind of you to say! Personally I would love to read something on this topic by members of the original Meteor team. Although I was a "fixture" in the community, I was also an outsider compared to actual MDG staff, so my understanding of the actual situation on the ground was always a bit one-sided…
> That is the "rehydration", taking a React app that you wrote and the server buildchain "dehydrated" (baked into HTML + CSS), but then rehydrating it to add interactivity back. Yes, you could do all that manually, but Next.js makes it magically trivial... you never have to think about it, it just works. And it's lightning fast.
Actually I think the big trend in JS front-end development is realizing that you do have to think about it! React rehydration is often a very slow step (whether it's Next.js or anything else, I don't think it makes a difference), definitely not "lightning fast" on non-trivial apps with lots of data. Islands architecture goes a long way towards solving that but it's still a bit limited today.
React by itself is quite simple, but precisely because it's so simple a lot of third-party libraries have cropped up to fill out the gaps. I'm not sure if other ecosystems are really simpler, or if the complexity is just spread out differently… At least with React you have the option of not buying into Redux/GraphQL/etc. if you don't want to.
I think every framework sees this kind of drop once it gets widely adopted. Probably a combination of being confronted with real-world use cases, as well as the appeal of newer solutions that promise to do the same thing even better.
