aralroca

I removed the other one

Brisa is a framework but can be used as a compiler to export your Web Components to other frameworks. Take a look https://brisa.build/building-your-application/building/web-c...

Already added to the route-map. I share it here in case you want to add more proposals: https://github.com/brisa-build/brisa/issues/197

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:

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...

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:

https://github.com/brisa-build/brisa

No...! Although there are ideas inspired by React and Next.js (JSX, pages folder, etc), maybe it reminds you of Remix as well.

It's a POST request. Try this example and inspect the Network:

https://github.com/brisa-build/brisa/tree/main/examples/with...

In build-time, each server action is converted to an API entry point.

You have two options:

1. Prerender your pages have them static on a CDN and have them interact with your server (Laravel, etc).

2. Use the server actions or API endpoints as a Backend for Frontend to communicate with your other server.

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.

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.

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.

No, it's a new alternative to React, Solid, Svelte, etc.

Here the framework author. Feel free to ask any questions about Brisa. At 15:30 GTM we will announce what it is and make it fully public.

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).

Website: https://brisa.build GitHub: https://brisa.com/github Discord: https://brisa.build/discord X (formally Twitter): https://brisa.build/x

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.

The release notes: https://github.com/vinissimus/next-translate/releases/tag/1....

I wrote a little bit about Rome and my thoughts about it here:

https://aralroca.com/blog/do-all-roads-lead-to-rome

Hope it can be helpful to someone

To make the tests I have imported labels that I had made with labelImg, so I can assure 100% that yes, without any problem.