I’m confused about server actions, what if I want to do something on the front end when a form is submitted before it’s passed to the server action (in the context of a server component)? Like frontend validation of the form, then call the server action afterwards on success. It seems like unlike the NextJS approach it just automatically knows that click handlers and form submissions are to be serialized and handled as a RPC on the backend always. So is there a way to trigger that behavior from web components? Would you pass a server action function as a prop to a web component or something and it would be translated into an RPC somehow? If so that’s pretty magical.
Nice stuff, looks very simple and cool in a lot of ways!
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.
This was a great battle for us too. Let me reply slowly.
- Currently web-components support attachInternals which let's you redefine the input validations and any input internal.
- On the web-components you can attach a prop starting with the prefix on* which will be an event prop and can trigger an action outside the web-component, you can also connect a server action here.
- The form onSubmit works as usual, so you could submit the form using onSumbit and handle it however you like.
- We are still looking for new approaches to sending forms using web-components on the easiest posible way :) Brisa does not do any magic on web component form, we are providing the enablers (at least for now, good ideas are welcome).
While dynamic forms are possible to achieve, the easier way of handling a form on Brisa is a native form generated on the server. Join our discord server for more questions (https://discord.com/invite/MsE9RN3FU4).
This looks very smart, it’s like a SolidJS that is web-component native first and foremost. I like this framework substantially more than the previous web component systems I’ve seen that feel much more like “library” and it’s a bit choose your own adventure. I am a fan of React/Solid so I appreciate that Brisa has a lot of nice React things like tree of function components and taking care attribute vs property difference. I’m not sure how I feel about the signal implementation, it’s really unclear to me how this magic works and after reading a few pages of the docs I’ve encountered many times “doing X may break reactivity, so do Y instead”. I maintain Notion’s reactivity framework so I’m not new to this overall, but the use of Proxy magicks is always hard to understand. Perhaps with use it will become second nature and I certainly like avoiding dependency arrays but I’m left uneasy.
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.
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).
This looks really interesting, congrats! It checks a few key boxes I was always hoping to see solved in Astro, namely first-party support for web components and a clean option for HTML-partials and tools like HTMX. I'm guessing a bit on the second one, bases on the site I'm assuming routes that ship raw HTML partials works out of the box.
My main hesitation is RPC event handlers. That's been the trend for a couple years now, for me its always a bit too much magic. I always prefer controlling the API URL being called, both for clarity and to ensure that URLs being called are always stable and more easily testable and reusable.
Currently this is possible by using web-components. If you like to make the client do the heavy lift, you can do that using the web-components and keep the pages as simple as possible. Feel free to open a discussion on github issues (https://github.com/brisa-build/brisa/issues) if you are missing anything.
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.
Reloading that page causes content shifting. Or when on Mac the search bar also switches the displayed shortcut from the Mac version to the Windows version as it's presumedly done on the client side. Maybe not a good look for a demo site.
Thanks for reporting @dewey. We are using Github for keeping track of all issues, the Brisa team will appreciate if you could report it to https://github.com/brisa-build/brisa/issues :pray:
Can someone explain the use case for these frameworks i.e. why do I do want to render things server side.
I understand if it was the early 2010s where mobile devices had limited power but today every user's phone and computer is going to be more than capable of handling whatever Javascript you throw at it.
Agreed, and so far the replies to your question are (for me at least) deeply unsatisfying. We already had SSR back in the CGI days, and it was awesome when we moved a lot of that stuff to the client. I know this is all a giant Wheel of Time, but I'm not ready for us to go back just yet. :)
SSR to help with page loading seems like a poor reason. I'm sure there are exceptions, but so many sites make gobs of requests for bazillions of elements (trackers, ads, etc.) anyway. Seems like there is lower hanging fruit we should check out first.
Doing it for SEO just makes me sad - a major architectural change just to try to keep up in the never-ending chase to make Google happy is depressing.
The big upside in moving dynamic rendering to the client for me was that it then made it far easier to have a cleaner separation of duties between a web designer and a developer. You take a graphical designer and have them master HTML/CSS and they can then create the initial design, make it into valid HTML/CSS files, be responsible for things like site responsiveness on different screen sizes, browser quirks, most of accessibility tasks, etc. The developer's job is to "wire it up" - things like populating the data, making the site react to user input, and so forth.
The big win was that this division of labor is not only enabled at the outset, but it is relatively easy to maintain through the entire life of the site. We had tons of sites where there were design refreshes with little (and in a few cases, no) developer work. When I see SSR tools now (as well as client frameworks that chop up the HTML into chunks and then intertwine them with code) my first impulse is to wonder how that gets maintained and updated. Like, when the UI is redesigned and reorganized, does all of that code have to be rewritten? When something doesn't work right on Safari, can the web designer help much or is it all on the shoulders of the dev?
EDIT: for more detail even on my M1 Max MacBook Pro, it is still very noticeable how long it takes JS-heavy SPAs to become interactive. Clicking things doesn’t even work for several seconds often because downloading and executing JS takes that long.
Now take into account users around the world on crappy internet connections with slow business laptops or the cheapest Android phones ever trying to load your SPA… bad times.
Even putting device performance aside, doing fetches and computation on people’s browsers somewhere distant in the world on a crappy 3G connection, rather than between colocated servers on speedy networks, is a recipe for bad web performance.
And that’s putting aside the need to protect secrets, optimize SEO (to serialize webpages for robots that won’t run your JS), simplify your application (server rendering eliminates the need for 90% of frontend state management, no need to expose API endpoints just to expose data on pages), the list goes on.
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.
Even in MBA M2 2003 laptop, still so many sites are slow.
80% of contents are texts, I can't understand why this whole internet become slower. I bet it would be slower even if we get personal quantum computer or whatever that has supercomputing power.
more animation, more effects, more popup, more crap ... that does not improve UX even 0.001%.
especially with mobile there are millions situations where your internet is bad, slow and patchy. you have A LOT of people using low-end devices in battery saving mode so also throttling the already bad performing devices – read this series if you need to understand why doing server side rendering is an exercise in accessibility https://infrequently.org/2024/08/the-landscape/
Does is support any kind of caching for server side rendering? Without caching running JS framework based SSR is slow and hard to scale in my experience.
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.
Currently Brisa on version 0.1 does not provide caching for SSR. Would you be able to provide an example of what are you looking to have as cache? We will be looking at optimisations for the v1. Thanks for the feedback!
I typically use a web application framework on the server to provide critical functionality like authentication, authorization, object relational mapping, etc. For example, I’m frequently using Django for server-side web application development due to its comprehensive features. How can Brisa integrate with a conventional server side web application framework (Rails, Laravel, etc.) to handle some of the user interface components while still leveraging the power of the web application framework?
> You can capture browser events on the server, such as forms, click events, Web Components events, etc. And you can propagate them through your server components.
How do you process events to server components?
Is this the same model as web forms / blazor (ss) where every interaction is streamed over a web socket to the sever?
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:
how about when the 1mb javascript bundle failed to download because your bus entered a tunnel? labeling users idiots is really really not OK, but ultimately hurts your employe and your product bottomline. Check this article https://infrequently.org/2024/08/the-landscape/
This looks really cool! Congrats on launching. How does Brisa compare to, say Remix? Can they be used together or are they competing technologies? Can I use Brisa with React code or just Web Components?
I am an old Polymer fan and so I love to see any developments in that space. The site is nice and worked well for me on mobile.
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:
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.
Awesome 0.1 release. Brisa simplifies the SSR complexity with a focus on Web Components. Defines server and client data flows using the power of signals. With minimal overhead and a straightforward structure. Brisa has a short learning curve, high efficiency, and a clear approach to data management.
I’m confused about server actions, what if I want to do something on the front end when a form is submitted before it’s passed to the server action (in the context of a server component)? Like frontend validation of the form, then call the server action afterwards on success. It seems like unlike the NextJS approach it just automatically knows that click handlers and form submissions are to be serialized and handled as a RPC on the backend always. So is there a way to trigger that behavior from web components? Would you pass a server action function as a prop to a web component or something and it would be translated into an RPC somehow? If so that’s pretty magical.
Nice stuff, looks very simple and cool in a lot of ways!
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.
Really nice question(s).
This was a great battle for us too. Let me reply slowly. - Currently web-components support attachInternals which let's you redefine the input validations and any input internal. - On the web-components you can attach a prop starting with the prefix on* which will be an event prop and can trigger an action outside the web-component, you can also connect a server action here. - The form onSubmit works as usual, so you could submit the form using onSumbit and handle it however you like. - We are still looking for new approaches to sending forms using web-components on the easiest posible way :) Brisa does not do any magic on web component form, we are providing the enablers (at least for now, good ideas are welcome).
While dynamic forms are possible to achieve, the easier way of handling a form on Brisa is a native form generated on the server. Join our discord server for more questions (https://discord.com/invite/MsE9RN3FU4).
This looks very smart, it’s like a SolidJS that is web-component native first and foremost. I like this framework substantially more than the previous web component systems I’ve seen that feel much more like “library” and it’s a bit choose your own adventure. I am a fan of React/Solid so I appreciate that Brisa has a lot of nice React things like tree of function components and taking care attribute vs property difference. I’m not sure how I feel about the signal implementation, it’s really unclear to me how this magic works and after reading a few pages of the docs I’ve encountered many times “doing X may break reactivity, so do Y instead”. I maintain Notion’s reactivity framework so I’m not new to this overall, but the use of Proxy magicks is always hard to understand. Perhaps with use it will become second nature and I certainly like avoiding dependency arrays but I’m left uneasy.
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.
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
[flagged]
No, it's a new alternative to React, Solid, Svelte, etc.
Meh uses the same crap templating as react.
JSX is not a templating language. It is a functional DSL
It’s not a DSL. It’s an extension to JS to write HTML like code to describe a UI. It’s basically glorified templating.
No, jsx is an ergonomic mechanism for describing a hierarchy of deferred function calls
lol no.
how does it compare to primatejs?
Interesting. I'll have a look then :-D
This looks really interesting, congrats! It checks a few key boxes I was always hoping to see solved in Astro, namely first-party support for web components and a clean option for HTML-partials and tools like HTMX. I'm guessing a bit on the second one, bases on the site I'm assuming routes that ship raw HTML partials works out of the box.
My main hesitation is RPC event handlers. That's been the trend for a couple years now, for me its always a bit too much magic. I always prefer controlling the API URL being called, both for clarity and to ensure that URLs being called are always stable and more easily testable and reusable.
> Brisa pages are dynamically server-rendered JSX components, so there's zero JavaScript shipped to the browser by default.
Why is this good, why not let the client hardware do the client logic?
Currently this is possible by using web-components. If you like to make the client do the heavy lift, you can do that using the web-components and keep the pages as simple as possible. Feel free to open a discussion on github issues (https://github.com/brisa-build/brisa/issues) if you are missing anything.
Congrats on the launch! Just a quick heads-up - have you noticed that the increment and decrement buttons on the main page are slightly inclined?
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.
For whatever reason, I thought this was by design.
It is.
It wasn't just me then. I thought I was going mad!
lol. me too. I was wondering what on earth I had to drink last night.
:-) I was expecting the counter to be degrees and to change the inclination. It didn't. The disappointment.
Reloading that page causes content shifting. Or when on Mac the search bar also switches the displayed shortcut from the Mac version to the Windows version as it's presumedly done on the client side. Maybe not a good look for a demo site.
Here's a recording in case it's helpful (Safari, macOS): https://img.notmyhostna.me/Sn347jhnsgVlFwc4PZWs
There is a 800kb font file loaded from the css. Can reproduce in dev tools by disabling the cache. The shift happens when those fonts are applied.
Thanks for reporting @dewey. We are using Github for keeping track of all issues, the Brisa team will appreciate if you could report it to https://github.com/brisa-build/brisa/issues :pray:
Can someone explain the use case for these frameworks i.e. why do I do want to render things server side.
I understand if it was the early 2010s where mobile devices had limited power but today every user's phone and computer is going to be more than capable of handling whatever Javascript you throw at it.
Agreed, and so far the replies to your question are (for me at least) deeply unsatisfying. We already had SSR back in the CGI days, and it was awesome when we moved a lot of that stuff to the client. I know this is all a giant Wheel of Time, but I'm not ready for us to go back just yet. :)
SSR to help with page loading seems like a poor reason. I'm sure there are exceptions, but so many sites make gobs of requests for bazillions of elements (trackers, ads, etc.) anyway. Seems like there is lower hanging fruit we should check out first.
Doing it for SEO just makes me sad - a major architectural change just to try to keep up in the never-ending chase to make Google happy is depressing.
The big upside in moving dynamic rendering to the client for me was that it then made it far easier to have a cleaner separation of duties between a web designer and a developer. You take a graphical designer and have them master HTML/CSS and they can then create the initial design, make it into valid HTML/CSS files, be responsible for things like site responsiveness on different screen sizes, browser quirks, most of accessibility tasks, etc. The developer's job is to "wire it up" - things like populating the data, making the site react to user input, and so forth.
The big win was that this division of labor is not only enabled at the outset, but it is relatively easy to maintain through the entire life of the site. We had tons of sites where there were design refreshes with little (and in a few cases, no) developer work. When I see SSR tools now (as well as client frameworks that chop up the HTML into chunks and then intertwine them with code) my first impulse is to wonder how that gets maintained and updated. Like, when the UI is redesigned and reorganized, does all of that code have to be rewritten? When something doesn't work right on Safari, can the web designer help much or is it all on the shoulders of the dev?
That’s a very optimistic claim
EDIT: for more detail even on my M1 Max MacBook Pro, it is still very noticeable how long it takes JS-heavy SPAs to become interactive. Clicking things doesn’t even work for several seconds often because downloading and executing JS takes that long.
Now take into account users around the world on crappy internet connections with slow business laptops or the cheapest Android phones ever trying to load your SPA… bad times.
Even putting device performance aside, doing fetches and computation on people’s browsers somewhere distant in the world on a crappy 3G connection, rather than between colocated servers on speedy networks, is a recipe for bad web performance.
And that’s putting aside the need to protect secrets, optimize SEO (to serialize webpages for robots that won’t run your JS), simplify your application (server rendering eliminates the need for 90% of frontend state management, no need to expose API endpoints just to expose data on pages), the list goes on.
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.
Even in MBA M2 2003 laptop, still so many sites are slow.
80% of contents are texts, I can't understand why this whole internet become slower. I bet it would be slower even if we get personal quantum computer or whatever that has supercomputing power.
more animation, more effects, more popup, more crap ... that does not improve UX even 0.001%.
> why do I do want to render things server side.
API key secrecy, SEO, etc
especially with mobile there are millions situations where your internet is bad, slow and patchy. you have A LOT of people using low-end devices in battery saving mode so also throttling the already bad performing devices – read this series if you need to understand why doing server side rendering is an exercise in accessibility https://infrequently.org/2024/08/the-landscape/
Does is support any kind of caching for server side rendering? Without caching running JS framework based SSR is slow and hard to scale in my experience.
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.
Currently Brisa on version 0.1 does not provide caching for SSR. Would you be able to provide an example of what are you looking to have as cache? We will be looking at optimisations for the v1. Thanks for the feedback!
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.
I typically use a web application framework on the server to provide critical functionality like authentication, authorization, object relational mapping, etc. For example, I’m frequently using Django for server-side web application development due to its comprehensive features. How can Brisa integrate with a conventional server side web application framework (Rails, Laravel, etc.) to handle some of the user interface components while still leveraging the power of the web application framework?
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.
> You can capture browser events on the server, such as forms, click events, Web Components events, etc. And you can propagate them through your server components.
How do you process events to server components?
Is this the same model as web forms / blazor (ss) where every interaction is streamed over a web socket to the sever?
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.
So is this Remix (React Router) without using React?
No...! Although there are ideas inspired by React and Next.js (JSX, pages folder, etc), maybe it reminds you of Remix as well.
Does Brisa have graceful fallback to still function (like how htmx works) in cases where JS isn't available?
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
is your product roadmap empty? why would something like that even show up in the back log?
[flagged]
how about when the 1mb javascript bundle failed to download because your bus entered a tunnel? labeling users idiots is really really not OK, but ultimately hurts your employe and your product bottomline. Check this article https://infrequently.org/2024/08/the-landscape/
Bad examples are bad.
smart, deep, intellectual conversation. must be only idiots replying to you.
This looks really cool! Congrats on launching. How does Brisa compare to, say Remix? Can they be used together or are they competing technologies? Can I use Brisa with React code or just Web Components?
I am an old Polymer fan and so I love to see any developments in that space. The site is nice and worked well for me on mobile.
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...
Where are the background jobs and the emails? Web Platforms needs those things.
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.
YAJF - Yet another Javascript Framework.
G == Framework?
Is that a typo, or is there a joke I'm missing?
Yup. It will be corrected in due cause :)
Awesome 0.1 release. Brisa simplifies the SSR complexity with a focus on Web Components. Defines server and client data flows using the power of signals. With minimal overhead and a straightforward structure. Brisa has a short learning curve, high efficiency, and a clear approach to data management.