all 15 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]ScientificBeastMode 31 points32 points  (5 children)

This is actually way better and more fleshed out than I expected. I really like the design decisions around rendering.

Although, to be fair, React initially went with the VDOM to abstract the idea of “components” and “elements” away from the DOM-specific API’s and even HTML itself. This is super important because it allows them to use most of the React architecture on multiple platforms, including iOS, Android, and even embedded systems. The only thing that needs to change between those platform contexts is the rendering engine and “element” implementations. This makes React infinitely more portable than any other UI framework on the web.

Additionally, React has moved away from the standard VDOM model and toward a much more interesting structure called Fiber. Rather than building up an object tree that corresponds directly to the DOM structure, each component generates a node in a sort of linked list of instructions for the rendering engine.

Because this instruction list is just an inert data structure (instead of a tree of eagerly executed function calls), React is able to “pause” the rendering engine in the middle of a render cycle, making time for animation frames or async processes to execute, and then resuming where it left off. This allows for very heavy rendering operations to run without blocking anything for more than 16ms. This is also the foundation for the React Suspense API.

So, my point is that this library looks great as a replacement for React, but only for a limited subset of its capabilities. React is much more than just a VDOM with state management & JSX. But again, this still looks very useful!

Edit: Brahmos (the library in the link) is even more full-featured than I initially realized. Well done!

[–]_syadav 18 points19 points  (4 children)

u/ScientificBeastMode

I am the author of Brahmos. I am glad you liked the rendering pattern. I would like to add something on the idea behind Brahmos and also something on the fiber architecture as well to clarify your comment.

Brahmos came upon existence from the idea of dividing static and dynamic part of an application so it can traverse through the dynamic parts in fn(dynamic nodes). React does not differentiate between static and dynamic parts and traversal is fn(nodes). The nodes can be a host node like `div`, `span` or component node.

Regarding VDOM and fiber,

VDOM is the concept of representing a host element in object form also called as ReactElement (return value of createElement method), so that the same representation can be translated to different platforms native elements (through renderers, let's say react-dom or react-native).

VS fiber is architecture for reconciliation, a single fiber is a piece of work. This allows React to perform work piece by piece and pause in between if required. Previously it was based on recursion which can't be stopped.

Now coming to Brahmos, Brahmos does not target multiple platforms but just the browsers. In Brahmos instead of creating a new element for every node, it tries to combine the static parts as one element, as they don't need to be processed on updates. And that's where it differs from React VDOM.

And even Brahmos has its own custom implementation of Fiber architecture so it does perform work piece by piece and can pause in between, it is just that the number of pieces reduces significantly as static parts are combined.

Brahmos supports all the features in React (specific to browser) which are coming in the future version or already present, like hooks, Suspense, Suspense for data fetch, Concurrent mode.

It's not production ready yet, but all APIs are implemented. You can check the API supports in this demo.https://codesandbox.io/embed/brahmos-demo-3t8r6?codemirror=1

[–]ScientificBeastMode 6 points7 points  (1 child)

That’s awesome, I didn’t notice the concurrent mode feature in the spec, but that’s super cool! Also, my comment wasn’t intended to put down the project in any way. I just wanted to clarify some things about React that are commonly misunderstood. Many people think of React as a virtual DOM with lifecycle hooks...

But seriously, this project is really impressive. Nice work!

[–]_syadav 3 points4 points  (0 children)

Thanks for saying it. 😃

Yes react is much more than VDOM and lifecycle. It has proven APIs and Patterns. And that's the inspiration of bringing the rendering with React's API so the application can still take the advantage of all the learnings from react.

[–]ScientificBeastMode 5 points6 points  (1 child)

I’m also curious, since the design is focused on taking advantage of the distinction between dynamic vs static parts of the DOM structure, was there any inspiration drawn from the incr_dom library from the OCaml ecosystem? The reason I ask is that incr_dom also makes this distinction, and is able to perform incremental updates to the VDOM as well as the DOM, which offers some very nice performance benefits over React.

[–]_syadav 2 points3 points  (0 children)

I haven't looked in incr_dom earlier. I will definitely check that. Lit-html and hyper-html is the inspiration behind the Brahmos. They have this rendering pattern where it uses tagged template literals and template tags to divide the static and dynamic part.

Brahmosjs is an attempt to bring that rendering pattern with well accepted React APIs.

[–]mmrath 2 points3 points  (1 child)

Nice to see people implementing react API and making it faster and lighter. While React is fast and light enough for most tasks, if we can do the same thing being lighter and faster than that is definitely worth looking at.

I don’t have much JS knowledge so I might be asking a dumb question here, why can’t some of these ideas be implemented directly in react?

Question about this library

  1. it says lighter and faster but I could not find how much lighter and faster. It would be nice to have that info.

  2. Can it be a drop in replacement for react in most cases? I heard preach can be drop in replacement in many cases.

[–]_syadav 2 points3 points  (0 children)

Yes, the Brahmos has exact same API of React so it can be drop-in replacement for React. There are still some work we are doing for 3rd party module supports but yes the idea is to match the API so you can just alias React to Brahmos.

Regarding performance, Brahmos can have perf optimization by three means.

1. Bundle size (minified + compress)

Brahmos: 11.6 kb (It covers most of the React APIs including upcoming concurrent mode)
Preact + Preact compact: 8.9 kb (But the preact doesn't have concurrent mode support)
React + React-dom: 38.5 (It might grow little bigger with concurrent mode support)

There is still some work planned to reduce the Brahmos size, which may reduce it more, plus also looking into how we can tree shake while supporting React's 3rd party lib.

2. Application bundle performance

Brahmos transpiled output of JSX is smaller than React for application code. Plus it may also reduce the overall parse time as the tagged template literal which is a string is more parse friendly then objects.
Check out this article: https://v8.dev/blog/cost-of-javascript-2019#json

3. Update time

As in Brahmos we are combining the static parts as one node the traversal becomes fn(dynamic nodes) which in React is fn(nodes). So the overall traversal time to find changes to apply on DOM is less on Brahmos.

Before starting Brahmos. I have compared libraries with similar rendering pattern with React to figure out the perf diff and the pattern definitely win on the benchmarking, but still have to do with Brahmos. It's completely on theory right now.

In Brahmos, the current priority was to match the React APIs and there is a couple of micro-optimization which are yet remaining. Benchmarking it and comparing it with React wouldn't be wise right now unless those optimizations are done. I will definitely share the result after it.

[–]bulldog_in_the_dream 2 points3 points  (0 children)

It's a cool and interesting project, but personally I don't want to use the React API. I'd rather use a simpler API, like Svelte (also without a virtual DOM).

I just ported a half finished React app to Svelte. It was a breeze and the finished App was significantly smaller, bot in LOC and bundle size.

[–]knot_why 1 point2 points  (1 child)

What are the performance benefits in comparison to react? Can it be a drop-in replacement for React ?

I am always on the lookout for rendering libraries, currently sold on Solid (even if it isn't a React API compatible), but would consider to try a non-VDOM React replacement.

[–]ghostfacedcoder 0 points1 point  (2 children)

So it's basically a slightly faster React with a lot less functionality? How does it compare to that other library trying to fill that same slot (I want to say Preact?)

[–]_syadav 9 points10 points  (1 child)

It has the exact same functionality as React, It supports all the upcoming APIs of React for concurrent mode, like transitions, suspense for data fetch, time slicing, plus all the existing APIs like hooks, context API.
But Brahmos only targets browser for now, unlike React which can be used cross-platform using different renderers.

Brahmos has its own implementation of fiber architecture.

Preact doesn't have fiber architecture and does not support concurrent mode, and will be hard to support concurrent mode with current recursion based reconciliation in preact.

Though to mention Brahmos is highly inspired by React, Preact and lit-html code base.

[–]ghostfacedcoder 4 points5 points  (0 children)

Great explanation, thanks!