I play a lot of World of Warcraft on my M3 MacBook Pro which has a native MacOS build. It's a CPU bottlenecked game with most users recommending the AMD X3D CPUs to achieve decent framerates in high end content. I'm able to run said content at high (7/10) graphics settings at 120fps with no audible fan noise for hours at a time on battery. It's been night and day compared to previous Windows machines.

AGI led utopia will be pretty easy if we're all under contractual obligation to not criticize any aspect of it, lest we be banished back to "work"

I've found libraries like Zod useful when interacting with external data sources like a database. Slonik[1] uses Zod to define the types expected from a SQL query and then performs runtime validation on the data to ensure that the query is yielding the expected type.

I don't think it's necessary to use Zod/runtime validation everywhere, but it's a nice tool to have on hand.

[1]https://github.com/gajus/slonik

The provided example under "The problem" shows the biggest footgun in using Tailwind. I think it's an extreme example, and is just as bad as needing classes like "header-lower__wrapper-inner" that just have "display: flex;" applied to it.

I've been using Tailwind in combination with "normal" CSS where it's warranted and there are plenty of sites out there practicing the same thing. Atomic utility classes just make sense for some things. It's a tool that you can use correctly or incorrectly.

Have you tried Slonik (https://github.com/gajus/slonik)? It won't generate types from queries automatically, but it encourages writing SQL vs. a query builder and allows type annotations of queries with Zod. Query results are validated at runtime to ensure the queries are typed correctly.

Happy People: A Year in the Taiga by Dmitry Vasyukov. The English narration was written/voiced by Werner Herzog and matches the tone of the documentary perfectly. If you’ve ever had any interest in homesteading, or just getting away from it all, I would highly recommend it.

I watched this, and enjoyed it, but was later surprised to learn that Herzog had started with a completed documentary but made major changes to the narrative---for the worse! There are few scenes that he edited to tell a different story than they did in the original, seemingly with minimal concern for truth. It really hurt my image of Herzog.

So I'd second the recommendation, but add that if you get a chance, you should try to view Vasyukov's original as well. Herzog's version might be a bit snappier, but I don't think it's actually better. The original is available in four parts on Youtube. Here's part one: https://www.youtube.com/watch?v=fbhPIK-oBvA

> he experience of seeing the image rendered by the lens on the ground glass in “full screen” with your eye’s superior color depth and dynamic range is really something.

Sure, but it's not what you end up with once you stop looking at pretty projections and hit the shutter button.

Not in-depth, but two things that have stood out to me in assessing Render vs Fly are Render's lack of Multi-region apps and release phase scripts for running migrations. Easy multi-region apps seem to be a main selling point of Fly. However, both of the features I mentioned are on Render's roadmap (Multi-region apps has been on their roadmap since 2019, so maybe not a priority?)

these were the reasons we chose fly in the end; very happy with it

Glad to see progress in this space.

I couldn't find anything describing the paradigm used for the JavaScript frontend. From the video, it looks like things are fully server side rendered, i.e. no client side routing as-in SvelteKit or Next.js? Are the Svelte components hydrated+interactive after page load? In my experience so far with SvelteKit and other SSR+SPA frameworks, there are too many tradeoffs with hydrating then opting to CSR for subsequent navigation. I like the browser's built-in implementation of navigating between pages because it preserves things like mutations to the document and scroll position out of the box, with no additional JavaScript. If you collapse a comment in this thread, navigate back to the home page, then use your browser's back button, the comment you collapsed should still be collapsed. In my experience with SPA CSR, you'll need to track and restore the JavaScript state driving that collapse on your own (a combination of the window.history object and CSR hooks), since navigating back to the page is a full client side re-render of the page.

I've found Svelte+React have good support for TypeScript, especially for guaranteeing the types of props passed to components, are there plans to support this? With controllers in Go and Views in Svelte/React, is there any way to help with correctness of data passed as props to the Svelte components?

I only browsed for a wee bit, so take this with some salt, but it _looks_ like the framework is running a JS VM isolate alongside the Go server struct[1], which gets called with whatever script file is being rendered. Since it looks like the render files are, at least in the case of Svelte, individually compiled JS files that are SSR rendered via the V8 isolate, I _believe_ you're correct that there is no CSR (though there might still be JS-hydrated code if the Svelte component included something involving an interactive component).

I think the idea is to ingest a JS "template" and spit out the rendered HTML+JS, kind of like traditional SSR templates, but it could be possible to shoe-horn in an entire client-side router that gets initialized as a DOM object somewhere.

EDIT: I could be wrong, please correct me if so.

[1] https://github.com/rogchap/v8go

Nice sleuthing! Bud heavily relies on https://github.com/rogchap/v8go

Hey, excellent question.

You're correct that Bud server-side renders the Svelte files, then hydrates them on the client.

This is similar to what most other JS frameworks do, it works like this:

1. Create two builds: one for server, one for browser. This is done using ESBuild. This is actually done lazily upon request, similar to how a CDN like esm.sh would build JS to be imported. This will hopefully allow the build system to scale for larger apps. Vite was my inspiration here, but it's all done in Go.

2. V8 and the Svelte compiler are baked into the bud binary. When a request comes in, V8 evaluates the compiler running the server-built page and returns HTML. That's a mouthful, hopefully that makes sense.

Happy to go into more depth here or via email hi@livebud.com.

I should add that lazy builds only happen in development. In production, it's all bundled at once.

This is great, I'm not sure why this is being misinterpreted so much. Serving generated HTML from Node using Express many years ago was also great at the time. You can still do that, but in my experience the tooling is quite dated/fragmented and the ecosystem+language has evolved significantly since then. Nowadays, SSR+Node generally refers to front-end frameworks with SSR capabilities (Next, Nuxt, SvelteKit, etc.) or generation of static files. Building a dynamically server side rendered site using TypeScript+JSX but without the issues of client side frameworks, hydration, SPA routing, etc. sounds revolutionary, even though it shouldn't(?)