Echo JS 0.11.0

Carefull with things like Array.prototype.forEach with built-in functions.  forEach passes a asecond argument for the position within the array, this can have unexpected consequences, such as if you're passing parseInt, or another function that optionally accepts a second parameter.

An anonymous lambda is often the best option.

I prefer Caddy over NginX, and also you should really precompress your static assets as part of your build process.

Was kind of hard to find the link back to the project site on github...  It was under the install section, but an about section with license and the project identified would be good to have.

https://github.com/iDev-Games/Trig-JS

Source repository: https://github.com/vroby65/DroneCommander/

I's suggest also looking at generic pool libraries, so you can pool and limit expensive workers.

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.

This is EchoJS not EchoPython.