elviswolcott

While I agree with your concerns about licensing and copilot, this criticism doesn't seem particularly relevant to the article that was shared.

If you're having problems, kbd.jse.li is currently blocked by OpenDNS seemingly.

The status page is now showing degraded performance for the Cloudflare API and Recursive DNS.

Getting windows signature devices is a good start. It doesn't get rid of the baked in telemetry, but it does ensure you're getting a fresh copy of windows (with Candy Crush and whatever store apps they decide to install) without any of the bloatware OEMs like to install.

The issue with doing them client side (other than the missed cache opportunity of using a server) is that it means you're having every user in the chat send a request to an arbitrary URL from their device. Also CORS makes this impossible 99% of the time.

From the article:

> Importantly it should be noted that 93% of Beyond Meat’s consumers are in actual fact meat–eaters, not vegetarian or vegans as popularly perceived.

From their website:

> We hope our plant-based meats allow you and your family to eat more, not less,of the traditional dishes you love, while feeling great about the health, sustainability, and animal welfare benefits of plant protein.

Doesn't sound like their value proposition is really built around vegetrains/vegans at all.

I looked through it earlier but missed the "continue this thread"

> SSR can be done correctly, even with React

This stands out to me, and I agree completely.

I dug around in devtools and found a few interesting things looking at the static-tweet.now.sh (Next w/ Incremental Static Regeneration). It seems like the performance is more or less on par with domvm as far as network usage EXCEPT for the initial bundle (which is mostly react & dependencies). For subsequent visits, this is cached and performance is great, but devtools tests with a clean cache so this is hidden.

Admittedly, that's a huge qualifier. It doesn't seem like Next is doing anything wrong with SSR other than using a framework with a huge bundle. As a result, the huge bundle ends up getting sent even for a page (or entire site) with no interactivity.

In theory, it might be possible to avoid sending the bundle for routes that don't need it, but this ends up being a fundamental limitation of react afaik.

Vercel (the folks behind Next) put it really well

> React at Facebook is… > …unlike React at ${anywhereElse}

The large initial bundle pays off for a site like facebook or a web app which really takes advantage of all React has to offer (wether that's performance, tooling, or dx), but definitely deserves more second guessing than it recieves.

I'm really interested in your comment about how Gastsby, Next et. al. are doing SSR wrong. For context, I'm an SSR newbie, currently trying to migrate a site I started away from Gatsby (realized it's not the right tool for the job).

To me, it seems like Incremental Static Regeneration is the best of both worlds - you get a static site without huge build overhead and SSR niceness.

However, peeking in dev tools, sure enough your site is a bit faster in nearly every lighthouse metric compared to static-tweet.now.sh despite being decidedly more complex.

Could you expand on how Gatsby and Next are doing SSR wrong and what it takes to do it right (i.e. what is DOMVM doing instead).

I'm sorry if you've answered this elsewhere in the thread, I looked around and didn't find anything.

Admittedly in this case I'm mostly just trying to push Gatsby to it's limits. For a photography site, there ends up being very little overhead with a static site (if you can do incremental builds). I also explored NextJS (SSR) and just making a good old SPA, but decided to go with Gatsby because at the end of the day, a distinct majority of the storage cost is just the raw images. I think Gatsby ends up making the most sense because you get to take advantage of a CDn for caching (most don't like being used just as an asset cache) and I can just leave it there without worrying about a server.

I’m yet to figure that out! I’m procrastinating on that but until I have everything else figured out (it’s for a family member so no strict timeline). I’m thinking in the end the setup will be something with a CMS for editing the photo metadata, a file storage system for the images, and everything else in git. The build would pull from all 3, run and then the processed images will be pulled out and hosted on their own. I’m planning that it’ll just run and take a long time on a droplet unless I figure something better out.

Gatsby is a fairly complex static site generator. At the highest level, it provides an ingest layer that can take any data sources (CMS, markdown, json, images, or anything that a plugin supports) and bring them into a single centralized GraphQL data source. Pages (which are built using React) can query this graph for the data they need to render. Gatsby then renders the React pages to static HTML and converts the queries to JSON (so there's no actual GraphQL in production).

This process is fairly fast on small/simple sites. Gatsby is overall very efficient and can render out thousands of pages drawing from large data sources rather quickly. The issue is that Gatsby isn't just used for personal blogs. As you can imagine, a site with thousands of pages of content that is processing thousands of images for optimization starts taking a long time to build (and a lot of resources). For example, I'm building a Gatsby site for a photographer than includes 16000+ photos totaling a few hundred GB. Without incremental builds, any change (e.g. fixing a typo) means every single page needs to be rebuilt.

Incremental builds means you don't have to rebuild everything. Because the data is all coming from the GraphQL (which Gatsby pre-processes and converts to static JSON), it is possible to diff the graphs (i.e. determine what data a commit has changed) and determine what pages it affects (i.e. which pages include queries that access that field). From there, Gatsby can only rebuild that changed pages.

This not only means faster build times, it also means that only the changed pages and assets have to be re-pushed to your CDN. This way, content that hasn't changed will remain cached and only modified pages will have to be sent down to your site's users.