[HN Gopher] Show HN: Brisa Framework - Unifying server and clien...
___________________________________________________________________
Show HN: Brisa Framework - Unifying server and client using the Web
Platform
Author : aralroca
Score : 105 points
Date : 2024-10-05 11:19 UTC (1 days ago)
(HTM) web link (brisa.build)
(TXT) w3m dump (brisa.build)
| aralroca wrote:
| 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
| aralroca wrote:
| 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.
| brylie wrote:
| 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?
| aralroca wrote:
| 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.
| sgammon wrote:
| 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.
| aralroca wrote:
| 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...
| jitl wrote:
| 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.
| aralroca wrote:
| 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.
| jitl wrote:
| How does the props part work? That is the part I find
| confusing
| metadat wrote:
| Does Brisa have graceful fallback to still function (like how
| htmx works) in cases where JS isn't available?
| aralroca wrote:
| 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
| nsonha wrote:
| is your product roadmap empty? why would something like that
| even show up in the back log?
| lastdong wrote:
| 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?
| esses wrote:
| For whatever reason, I thought this was by design.
| genezeta wrote:
| It is. transform: rotate(2deg);
| jesperwe wrote:
| :-) I was expecting the counter to be degrees and to change the
| inclination. It didn't. The disappointment.
| kitd wrote:
| It wasn't just me then. I thought I was going mad!
| kayo_20211030 wrote:
| lol. me too. I was wondering what on earth I had to drink
| last night.
| aralroca wrote:
| 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.
| ilrwbwrkhv wrote:
| Where are the background jobs and the emails? Web Platforms needs
| those things.
| aralroca wrote:
| 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.
| aralroca wrote:
| 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
| albertsabate wrote:
| 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.
| wokwokwok wrote:
| > 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?
| aralroca wrote:
| 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.
| threeseed wrote:
| 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.
| delanyoyoko wrote:
| > why do I do want to render things server side.
|
| API key secrecy, SEO, etc
| gryzzly wrote:
| 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/
| dontdieych wrote:
| 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%.
| presentation wrote:
| 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.
| aralroca wrote:
| 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.
| dbrueck wrote:
| 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?
| misiek08 wrote:
| 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.
| pritambarhate wrote:
| 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.
| albertsabate wrote:
| 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!
| aralroca wrote:
| 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.
| 2024user wrote:
| So is this Remix (React Router) without using React?
| aralroca wrote:
| No...! Although there are ideas inspired by React and Next.js
| (JSX, pages folder, etc), maybe it reminds you of Remix as
| well.
| dewey wrote:
| 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
| albertsabate wrote:
| 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:
| skeeterbug wrote:
| 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.
| vfclists wrote:
| YAJF - Yet another Javascript Framework.
| sam_goody wrote:
| G == Framework?
|
| Is that a typo, or is there a joke I'm missing?
| vfclists wrote:
| Yup. It will be corrected in due cause :)
| presentation wrote:
| 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!
| albertsabate wrote:
| 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).
| aralroca wrote:
| 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.
| _heimdall wrote:
| 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.
| qwerty456127 wrote:
| > 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?
| albertsabate wrote:
| 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.
| erlend_sh wrote:
| 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!
| mightyham wrote:
| I haven't actually worked with Tauri, but shouldn't every web
| framework be Tauri compatible out of the box?
| stelmashchuk wrote:
| Really nice, exactly what I try to find
___________________________________________________________________
(page generated 2024-10-06 23:01 UTC)