HN user
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.
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 was amazed the first time I looked into the viewfinder of a medium format SLR. After mostly using mirrorless digital cameras, even returning to a 35mm/full frame viewfinder feels like magic. The 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. Digital viewfinders/mirrorless cameras certainly provide more utility in certain cases, but they’ll never match the “experience” of ground glass
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?)
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?
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(?)
This looks great! I've been using Serverless Framework for a project and have not been too satisfied with the experience. Could you explain the integration with that framework a little more? I see the two options for services with Seed are the Serverless Framework or Serverless Stack (which I have no experience with, but looks like a compelling alternative). Is Seed just compatible with existing Serverless Framework yml configurations, or does it integrate with your Serverless Framework account somehow? I see you offer an integration with Serverless Pro, which confused me as this appeared (to me) to be a full replacement for Serverless Framework.
I've been using Dgraph in building some PoCs and it's been great. My current confusion is around the push for a plain GraphQL compliant query endpoint as I'm not sure what the intended purpose is. Presumably it's not for direct connections between a front-end web client and the DB using something like Apollo Client. Should front ends still be going through some sort of API server that ingests GraphQL or REST style requests and queries Dgraph to build results? That's what I'm currently doing to implement things such as custom logic, side effects, authentication, etc. I'm not seeing the benefit of the plain GraphQL endpoint in that case, since I would be managing a separate GraphQL schema in the DB that is likely a subset or is similar to the API server's GraphQL schema. I've been sticking with GraphQL+- since it works great and I need an API server in between the front end and DB anyways. I've built some helper functions to map plain GraphQL request trees into expanded GraphQL+- queries for expanding edges since my API schema closely matches my Dgraph schema.
Would love some insight into the plans or use case for the plain GraphQL endpoint.