Have to admit, while I really like the idea of Server components, I'm not sure I'd use them on a public site with potentially a lot of users. I know that Vercel and other cloud options are based around the concept, it just feels like a lot of excessive server overhead IMO.
Not sure if this is AI created content... that said:
If you are creating a library or component that others will be able to use, or interacting with a team of developers on a product, you are better off with TypeScript. The additional context helps a lot with regards to utilization and intent from within most enhanced editors. This is very useful and will have less blocking and make it less necessary to slow down to lookup documentation. You can also use JSDoc, but that itself is sometimes more cumbersome than the TS type syntax.
Only if you are working by yourself on very basic or throw-away code should you prefer straight JS at this point.
This is just my take on this... I spent years pushing back against TS, as it never added much (for me), it's only when interacting with others or producing libraries or modules for others that the benefits become strikingly clear.
I think my biggest concern for server-side components is the overhead at scale... or anything resembling scale. I know there are FaaS, Lambda, Vercel, Cloudflare, Deno, etc for functional and horizontally scaling hosting, but a lot of people are using a VPS or dedicated hosting for more predictable pricing. It would be nice to see some comparative overhead for say 10000 simultaneous users of an application in Brissa vs Next.js vs HTMX to see what the performance overhead, response times, etc look like in practice.
I think they all have good and bad, but I'm thinking there are other values in using Go or Rust with HTMX that outweigh the benefits of server driven component frameworks. Though the DX for the latter is at least interesting.
Personally, I don't like using the thenable syntax or response.json() directly with fetch api. I prefer to use async/await syntax against response.text() then JSON parse directly, keeping a handle to the original request... Then I can return the json body or text body with the error and the result code as part of the error raised. I'll usually put this directly in a function that will give me more information as part of the error chain.
Using thenables this way makes it a lot harder to do that.
It's worth noting that protocol buffers are *NOT* faster in JS than in other languages. You can often get faster results from compressed json than protobuf and other binary wire formats.
You might be able to use a binary extension/module for Node/Deno that can access the direct sockets to handle the encode/decode in a lower level language (such as rust).
It's definitely nice to cover this... that said, if you understand the loose comparisons it can be useful in practice. Especially when you're dealing with ETL workflows.
Maybe worth mentioning... Foo.prototype = Object.create(null); ...to break default inheritance from Object.