I love that you proposed it, it was in the initial route map, we removed it because it was too much for a 0.1 version, but we can put it back for the 1.0 route-map.
The currency of exchange between frameworks is Web Components. So you can use Brisa beyond a framework, you can use its compiler to have Web Components written with JSX and Signals that work in any other framework like Remix. However, for now, if you want to use React inside Brisa, you will have to do something similar to transform React to Web Components. Here is a little guide:
If you have JavaScript disabled, the onSubmit still works, the rest of the events do not, similar to other frameworks, this is because of the nature of the form and JS.
If there are proposals on how to improve this, we are open to you to write them on GitHub and we will take them into account:
HTML streaming from the server is 1 single request to the server and the user sees the changes much earlier. On the other hand, if you render from the client, only if you need data, you already have to make requests to the server and the user will see the data much later. However, if your pages are static, you can do this rendering process in build-time and you can avoid having a server and upload the files to a CDN already pre-rendered.
Other than this. We don't like to use cache, because a framework needing cache is a sign of a patch to cover a problem. We are fast by nature, we invite you to try it and you will see that the server takes 4-5ms to render.
However, an important part for the 1.0 routing is to do a lot of optimizations that we already have in mind.
I was given the opportunity to rotate many things at the beginning while trying styles. I removed all of them at the end, but I missed this one. It can be removed; it doesn't add anything. Thank you.
By rule, reactivity is broken if you declare a variable using the getter (.value) outside the JSX. This is because the component is called once, and during the rendering of the DOM elements, effect wrappers are added to register the getters (.value) of any signals.
However, to make life easier for developers, we make some optimizations in build time, to:
1. Support early returns.
2. Not having to use .value in the props (well, “WC attributes”) and being able to define default values, do destructuring, etc. without losing reactivity.
Apart from these exceptions, it is as I said at the beginning.
The fun thing is that the web components' events can also be captured on the server as Server Action. This way, inside the Web Component, is client code that can validate and call onAfterValidateForm, but then when you consume the WC with <web-component */} /> from your page, it is a server action and finish processing. The mental model is simpler, if it's in a server component, it's a server action, if it's inside a web component, it's a normal browser event. No magic.
We are going to present Brisa 0.1, the new full-stack JSX web framework that changes the game's rules in web development by integrating Server Components + Server Actions with Web Components + Signals, merging both worlds (server/client).
In this blog post, we explore how to use Next.js 13's app directory and consume i18n translations for both server and client components in an easy way. With this approach, you can reduce the size of your bundles and maintain the code clean.