Show HN: Brisa Framework – Unifying server and client using the Web Platform(brisa.build)
brisa.build
Show HN: Brisa Framework – Unifying server and client using the Web Platform
https://brisa.build/
74 comments
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.
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.
How does the props part work? That is the part I find confusing
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
Website: https://brisa.build GitHub: https://brisa.com/github Discord: https://brisa.build/discord X (formally Twitter): https://brisa.build/x
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!
Nice stuff, looks very simple and cool in a lot of ways!
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 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).
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.
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.
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?
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.
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.
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.
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.
I'm fully on board for this trend of frameworks made to be Tauri-compatible out of the box. This era of truly cross-platform app development via the web stack and is looking very promising!
I haven't actually worked with Tauri, but shouldn't every web framework be Tauri compatible out of the box?
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
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:
I have nothing against web components with jsx, but I really don't like the API that defines web component as just a function, and exposes a bunch of magic effectful hooks (React's brilliant idea). What is the point of web component if I can interface with it like a normal element aka having access to the instance?
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.
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.
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.
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.
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/
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?
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?
Over-taking that approach we have 20MB+ websites (images excluded) and maybe hardware is faster, but connections are not improving at the same pace.
Sad for me is also current state of responsiveness - we had 20 or maybe 200 times slower hardware and website felt faster than now. Maybe it’s how the stars are aligned, but maybe it’s building multiple virtual element trees and discard them every click or event that happens on webpage. I dream about feeling this 20x increase in responsiveness as hardware should allow.
Sad for me is also current state of responsiveness - we had 20 or maybe 200 times slower hardware and website felt faster than now. Maybe it’s how the stars are aligned, but maybe it’s building multiple virtual element trees and discard them every click or event that happens on webpage. I dream about feeling this 20x increase in responsiveness as hardware should allow.
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%.
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%.
they say that is to save a few milliseconds on first load. My theory is that this is done just to secure some cloud lockin
> why do I do want to render things server side.
API key secrecy, SEO, etc
API key secrecy, SEO, etc
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.
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!
Basically I would like to cache the server rendered pages for not logged in users. When you have thousands of active users such kind of cache helps a lot. Though this can be solved by SSG if the framework supports it.
> 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?
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.
https://github.com/brisa-build/brisa/tree/main/examples/with...
In build-time, each server action is converted to an API entry point.
[deleted]
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.
interesting idea! It seems like it uses Proxy-based reactivity for dynamic content/updates on the client side - but can it update the reactive state from the backend or read the state on the backend?
Also, there are a few typos on your site you might want to fix: https://triplechecker.com/s/Nc9Gu4/brisa.build?v=NUtEc
Also, there are a few typos on your site you might want to fix: https://triplechecker.com/s/Nc9Gu4/brisa.build?v=NUtEc
Hi, I guess at version 0.1, Brisa is not ready for production yet. If this is the case, any idea when it would be?
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
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?
wordofx(1)
Really nice, exactly what I try to find
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.
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.
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...
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...
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...
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.