神刀安全网

How Catberry.js can fix the WEB or the story of the framework

The story of Catberry.js Framework

I want to tell you a story how I came up with yet another framework several years ago. I’m going to tell you why I did that and what things the framework can do much better than others even nowadays.

The framework I am talking about is called Catberry.js and it is open-sourced on GitHub . This overview section on its website explains a lot but it’s still worth to talk a little bit more detailed about some features.

The main purpose of the framework is to help creating fast and modular isomorphic web-applications using the simple component approach.

If the term “isomorphic” is unfamiliar to you, please read this short article that explains a lot. Long story short, you write JavaScript code once and it’s used in both server and browser environments. It makes possible rendering HTML on the server and changing the application state in a browser using the same set of components. The main feature you get automatically — your server-side app becomes a Single Page Application in a browser and works using the History API and you still have SEO because of the server-side rendering.

Why?

When I tell someone that I’ve developed a framework, it’s likely for me to see this:

How Catberry.js can fix the WEB or the story of the framework

I can’t get it but the majority of people is angry about new frameworks, they start hating you if you’re not using a framework they like, they try to convince you that your framework is useless even not reading the docs or trying to play with it. It’s horrible. If everyone thought like these people, the technology progress would stop at all. In my opinion, if you are sure that you can create something much better than the industry has now you must go ahead and build it, at least you must try. The motivation for creating the best things ever pushes the technology innovations in the industry and we should appreciate it and not discourage people.

I created Catberry.js because I saw that the WEB was broken, nobody cares about the customer experience anymore, developers just blindly use the tools and technologies which are popular/on hype, not those which deliver the best customer experience.

What’s wrong with the WEB?

Here is my short list:

  • Full buffering of the server output (in-memory buffer rendering), we’ll talk about this one later
  • Slow initialization: when you open a typical heavy Single Page Application you have to wait for seconds while the app is fully downloaded and the page is finally rendered
  • The browser bundle is really large, sometimes it reaches 1 MB in size and even more in rare cases
  • Different state of the page if you share a link after some actions on the page have been done. Another option — the app restores the state after the page has been fully initialized (SPA-only, no SEO)

How can Catberry.js fix the WEB?

Let’s take a look at the WEB nowadays.

Typical server-side rendering nowadays

When you’re using a typical/mainstream server-side rendering implementation (Express, Koa, React, etc) you’re using in-memory buffer rendering. It means that a browser receives nothing while your app is gathering necessary data from a database or web-services for rendering the whole page. And only when the whole page is ready the server sends it to the browser.

What the drawbacks are?

  • Users see a blank page until all the data required for rendering the whole page is not received from data sources
  • Browser does nothing and stays idle meanwhile
  • If the data receiving process is slow, users do not see anything for a long time (usually 5–10 seconds) and we loose their attention, the worst case — they close the page
  • Memory usage is higher, the server needs to buffer all rendering templates in memory for every user’s request which isn’t good in large scale

Why don’t we use streams?

The coolest thing I know in Node.js is the Stream API . Yes, you can implement your own streams and that’s really cool. Catberry uses a stream-based rendering engine on the server that allows rendering pages progressively.

How it works in Catberry.js?

  • Catberry implements a ReadableStream
  • The rendering process starts with the root template which is usually a static template without any data needed
  • The stream is looking for custom tags (components/widgets) in the HTML stream it pushs to the browser
  • If the stream finds a custom tag — it renders a template of the component/widget into the tag
  • The rendered HTML string goes through the same rendering process recursively finding all nested components
  • HTML chunks are being sent to the browser as soon as they are ready

Advantages of using Catberry’s rendering engine?

Apparently, we have some benefits from this approach:

  • After a minimal delay, browser starts receiving the page from the server (lower TTFB)
  • Browser requests images, CSS and JavaScript files concurrently without waiting for the whole page
  • Your users feel like the website is blazing fast despite the slow data requests on the server because they see the first part of the page almost immediately
  • Memory usage is much lower when you’re using streams and don’t buffer the whole page in memory

The screenshot below shows how browser does requests for additional resources while receiving a “slow page” (slow data requests) from the real app implemented with Catberry. It uses the streaming approach, therefore all resource references in the HEAD element are received very fast with first chunks of HTML and browser can request the resources immediately.

How Catberry.js can fix the WEB or the story of the framework

If it’s still not clear how the rendering works try to take a look at this animation .

Okay, we solved the first problem, what about the rest?

Slow initialization

It is automatically solved, because we have a full page from the server which is ready to use and the only thing Catberry does for the initialization process — it binds component objects to existing HTML. It’s really fast and takes milliseconds.

Bundle size

Catberry’s “Hello, World!” app is 28 KB in size (gzipped). In comparison, React rendering library is 40 KB in size (gzipped, only library). No doubt, it’s up to developers how large their applications are but still the core runtime is relatively tiny which gives more space for the app implementation.

Application state when you share links

As far as Catberry is an isomorphic framework it computes the full application state from the URL and has a very flexible routing system for that. If you used the routing system right your application would have the same state when someone opens the same URL. It does not include filled textfields or any private data of course, it’s supposed to be a component internal state.

In conclusion

So, after you finished reading this post do you think it’s yet another useless framework?

If so, well that’s unfortunate but it just means that Catberry is not for your purposes. Maybe you have other goals or requirements, which is normal.

In case you wanna see the framework in action, just visit one of these links:

Wanna get started with Catberry.js? Just follow these instructions .

If you found the framework interesting, please support it with a “star” on GitHub and NPM . Contributing is welcome.

Follow @catberryjs on Twitter

How Catberry.js can fix the WEB or the story of the framework

And contribute on GitHub

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » How Catberry.js can fix the WEB or the story of the framework

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址