HN user

aralroca

295 karma
Posts19
Comments26
View on HN

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:

Brisa to other frameworks (or Vanilla.js): https://aralroca.com/blog/reactive-web-components-with-ssr

React to Brisa: https://brisa.build/building-your-application/components-det...

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.

The only cache is via "Cache-Control". By default is this one:

https://github.com/brisa-build/brisa/blob/2e14f765f425c129a6...

However, is possible to change any response header including this one:

https://brisa.build/building-your-application/routing/pages-...

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.

We are not using a Proxy, the implementation of the signals is as follows: https://github.com/brisa-build/brisa/blob/main/packages/bris...

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 onAfterValidateForm={/* */} /> 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.

[dead] 3 years ago

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.

I think it's a little crazy. The implanted material over several months your body may not accept it. This should be tested very well. And I don't see a big benefit, since you can pay with your cell phone.