When I start talking about Catberry the first question I usually have is: “What’s different in comparison with React?”. So, I decided to collect all my thoughts on this topic and write a short post with the comparison.
I am personally not a fan of React at all (despite of working with it anyway) and in my opinion the hype around it is very overestimated. I think that a huge company behind it played the main role why the library is so popular and on hype now, like Angular was in the past. Unfortunately, developers stopped doing researches on the rest of the options and choose technologies not because of technical supremacy but the hype and the size of community. But have you ever thought how the community is built around the technology? My guess is because of enthusiastic people who see a potential and benefits of the technology and who try to contribute in it making it even better. As far as people stop doing that and focus on the only solution on the market built by a big company which has almost unlimited resources — the technology progress is doomed. Everyone talks about React nowadays, nobody wants to listen about anything else.
Let’s start with the React’s foundation — Virtual DOM. Catberry does not use any Virtual DOM implementation, all the mutations are applied to the real DOM using morphdom library (you can read more in its readme ). This approach brings support for many template engines, you can use whatever you like (Jade, Handlebars, Dust, etc.). Obviously you can’t use any template engine with React (which is a rendering library itself) except it’s JSX language.
What about performance you might ask? It’s about 15% lower on large amount of components on the page (tested against TODO app with 1000 items). If you have a real app — you won’t notice the difference at all. On the other hand, using Virtual DOM requires ~4x more memory in a browser (see the timeline screenshots below).
As you can see, Catberry requires more time for parsing HTML by the browser (a rendered template) but React spends more time in scripting doing all its Virtual DOM magic and it almost compensates all the DOM “slowness”.
Because of very complex Virtual DOM implementation React library is about ~40 KB in size (gzipped). Catberry’s “Hello, World!” app is ~28 KB gzipped — this difference you can notice. And keep in mind that React does not include a router, data layer or anything you need for a complete app — it’s just a rendering library that does not define an architecture of your app. You can imagine how much is the final size would be. Catberry on the other hand has everything you need to build an app: very flexible routing system , Flux Stores , and bundle builder . If it’s not enough you can easily build or install plugins for your app.
Well, if you decide to use React you have to choose all the additional stuff to build your app — as a result all React apps are very different and the on-boarding process for new developers is very long and complex. A Catberry app has a predictable structure which is described in the docs and its CLI generates a new project for you. When a new developer started working on our big React+Redux project it took about 2 weeks to start implementing features. A new developer came to our huge project built using Catberry it took two days before he started building real complex features — as for me, it tells a lot.
JSX (I guess, might be Virtual DOM) has problems with HTML support, for instance, only since the version 0.14 React started supporting some HTML attributes and SVG. Here is a quote from its changelog :
React DOM now supports these standard HTML attributes: capture, challenge,inputMode, is, keyParams, keyType, minLength, summary, wrap. It also now supports these non-standard attributes: autoSave, results, security.
React DOM now supports these SVG attributes, which render into namespaced attributes: xlinkActuate, xlinkArcrole, xlinkHref, xlinkRole, xlinkShow,xlinkTitle, xlinkType, xmlBase, xmlLang, xmlSpace.
But it turned out that SVG still does not work and they claimed a full support in React 15 :
Historically our support for SVG has been incomplete, and many tags and attributes were missing. We heard you, and in React 15 we added support for all the SVG attributes that are recognized by today’s browsers
But, I see the developers are still not sure if it works:
…so any SVG tags that were previously unsupported should work just fine in React 15
Catberry uses progressive rendering (don’t mix up with streaming which almost everyone is trying to implement in their frameworks). React just builds the whole page in a buffer on the server and your user sees nothing until the whole page is built and served. You can take a look at the cool animation on http://catberry.org that explains the difference. The main idea used in Catberry that you can apply/render changes step by step for every component on the page and not wait for the full data set required to render the whole page. It’s used on the server and in a browser as well.
The Catberry’s server-side rendering is fast, you can compare its performance with a bare Express app on a small page size. AFAIK, React’s performance on the server is not that good, unfortunately I don’t have actual data to claim that but regarding the Virtual DOM features React should do a lot for rendering a page. At least the developers removed those long ugly auto-generated IDs for elements since React 15 not it became much better.
Catberry finds components on the page and attaches the client-side script to existing DOM (like React does) which takes milliseconds. But in comparison with massive Virtual DOM, Catberry has a tiny logic layer on top of the DOM required for managing components and updating their content using state changes.
React has a state for every component, but how it works depends on a data layer you’ve chosen. Anyway there is no strict workflow working with the state for the whole app in case of bare React.
Catberry has two types of state in the app:
- Component state — You can store data just using `this.someData = ‘something’` inside the component and it works as expected. It does not make sense to send every keypress to a Flux store you can keep it local if you want.
- App state — should be always computable from URI using routing rules. Routing rules produce parameters for stores which use them to request data from an API service and produce data for components.
Catberry uses custom tags for its components (like web-components do), you can navigate through the components in markup without any additional tools like React requires. Also, you can always navigate to component’s source code or its store seeing the custom tag because the project structure is predictable as mentioned before. If you want even faster there is a plugin for Chrome Dev Tools and JetBrains WebStorm . Catberry does not have those strings and switch operators for Flux actions there is a convention to handle actions defining methods in the stores with a prefix “handle”.
The worst thing about Catberry
It’s the size of the community, of course. That’s the main reason why people reject using it in their project. They are afraid to rely on the technology because it does not have a strong community. The framework is 2 years old and it’s not that popular probably because I didn’t do much to push it. However, several companies are building their products using Catberry now and we have contributors coming which is great.
Fortunately, this drawback we can easily fix: if you’re interested in technologies (not hype) — join us and let’s build our strong community.