Using the React Ecosystem With the World's First O(1) Javascript Framework?

Reshapability in the next generation of front-end framework with OOV one loading time. I spice up a little bit of my TED talk and it's called Reshapability in the next generation of front-end frameworks with OOV one loading time.

Hi, my name is Ruby Jane Kabagnot. I'm originally from the Philippines but I have been working in Oslo Norway for the past few years now. And I think some people are already familiar with the term Reshapability. This was coined by the creators of QUIC including the so-called father of Angular JS, Misko Hevry, who said this idea of reshapability is a mental shift or a paradigm shift from the way the current generation of front-end frameworks works, which is the hydration process.

And so to explain the Reshapability, we need to understand the so-called hydration process of the current generation of frameworks. Because the fundamental problem in this hydration thing in front-end frameworks is that our application or app needs to hydrate at least once in the server and then do the same thing in the browser. But you may ask so what? Well, basically, it just means that the so-called DTI, or Time to Interactive of the application becomes slower. And this can be very frustrating or felt by your end users, especially if you got a big application or your users are using a slower network connection or just older devices. And of course, no one wants a frame website that takes forever to download, right?

And why they need to hydrate? So to explain this further, the hydration in JavaScript frameworks is like turning your static painting or static painting into an interactive touchscreen. So basically, the server provides the initial painting or HTML. And then we need but we need to actually touch controls or the event handlers, right? And the features which is the application state to make everything interactive or your application interactive. But the thing is, this step can slow down the initial loading time of the application. So making your painting look touch ready when it's not, which is really frustrating for your users. Like what I said, simply put the hydration step in the client side is to make our application interactive. So what about Quick? So Quick is a new web framework that makes your web apps or our web application loads instantly, no matter how big or complex they are. Basically, it just uses, they said one kilobyte or one KB of JavaScript to start. So ensuring a fast performance of any scale. Now, unlike other frameworks, Quick doesn't require hydration, so your apps are interactive right away. So this is achieved by feature what they say, region mobility. Basically, Quick focuses on super fast load times. And even on, even if you're using mobile or because it's just serving HTML as needed. No, sorry, it just loads the HTML needed and loading and just loaded the JavaScript incrementally. So overall, Quick aims to deliver the fastest possible user experience by optimizing your server side HTML and rendering, HTML rendering and lazy loading the JavaScript. So what is this region mobility? So because Quick is different because it does not require hydration or eager execution of your code on the client side. It uses region mobility. So meaning not requiring hydration is what makes the Quick application startup almost instantaneous. So the browser or your client does not need to do anything because it already has all the information that it needs. It has information that needs in so-called stateful HTML to basically determine where the things are in the application, which includes these three important things that you are event listeners, the framework code, and the application code.

So Quick. So the way Quick operates is that the page can become interactive without downloading and executing the JavaScript on the client. So this means that the page is almost instantaneous or over one loading time. So this is the primary premise of the Quick framework is that to serve HTML with minimal JavaScript with only increasing interaction as needed.

So here's an image of the hydration for the typical current frameworks, front-end frameworks, and this is reachability for Quick. So how is Quick doing this reachability? In a nutshell, Quick knows how to serialize your closures. And this is the thing that other frameworks are not able to do. So what are closures? So closures are if you remember JavaScript closures are a function that has a state or data. So basically, Quick can take that closure and serialize it, which is essentially how Quick is able to just resume or bring your app into life right away from the server to the client without having to do the hydration process. So this is the thing that what makes Quick resumable or replayable is because the client doesn't need to execute all the components to figure out where the listeners are.

So Quick is progressive, so this means that the user starts to interact with the page because Quick will start downloading, executing all the necessary code for that interaction. So in this way, Quick applications act more like streamable apps rather than downloading everything upfront before interaction. So bridge streamability is supposedly simple in concept. You save the server site state and then move it to the client and then continue or resume where the server left off. But it may be simple in concept, but it's hard to implement until Quick. So because Qwik can take that closure and serialize it. This is essentially how Qwik is able to just resume or bring your app into life right away from the server to the client without having to do the hydration process or eagerly executing your code. So this is the thing about what makes Qwik resumable or replayable, is that because the client doesn't need to execute all the components to figure out where the listeners are.

Getting started. So you can choose your preferred package manager. So you can run the following command. You can do the npm create Qwik app latest, pnpm, yarn. And then we have this thing now, bond, which is the latest runtime now, JavaScript, that is competing for our attention. So I know it's powered by ZIG, so it aims to be an all-in-one JavaScript runtime and toolkit. Yeah, so anyway, back to Qwik. So the CLI will guide you through the interactive menu to set the project name, and then select one of the starters, and ask you if you want to install dependencies.

So let's see Qwik in action. So I have here the homepage or the landing page of a simple Qwik app. And if you open up DevTools here, we can see that there's no JavaScript delivered to the browser because this is just a simple side page and no interactivity required. And we have here a counter component.

So I have here two buttons. And there's still no JavaScript, right? Until the alert button prints an alert message. And the current button as it wanted the counter. But you don't see any JavaScript here until we click the alert button.

So the click alert button only adds only the particular piece of code, and it contains the message that gets downloaded. Not the increment button. Even the framework code gets downloaded for the whole application. So now let's click the alert increment button and let's see how this particular piece of code gets downloaded. And of course the framework code.

So what's amazing about that is that because how the code was was implemented. Let's take a look at it. So we have here our simple standard counter component. And if you're familiar with React, you know this syntax looks pretty much like React with its use of JavaScript or J, sorry, JSX. So we have our buttons, the increment and the elite button in one single DSS file. And yet, QUIC only downloaded the JavaScript that it needed. So QUIC was able to break apart the function of the alert message and extract it out. So when we click the alert button, remember, just the alert message gets downloaded and nothing else. It didn't even download to the client the framework code or the increment button because it doesn't need to do it at that time. Only when we click the increment button did the the framework code gets downloaded to update the UI.

So how does QUIC do it? So you'll notice here there's this dollar sign and there's a component dollar sign. So whenever you see this dollar sign in your function or your component or event listeners, that should tell you that this function or component is being lazy loaded. You as a developer, but what's amazing about that is that you as a developer doesn't have to do anything special in your code to make this fine-grained lazy loading to happen. With QUIC, it just works out of the box. So QUIC has this thing called QUIC Optimizer that will run in the build whenever you're building the QUIC application. And it will search for all the dollar signs to create separate files for each function or component or event as soon as it will find.

So the question is, how does QUIC do it? So let's take a look here at the Allow button here, and it has this OnClickedProperty. And it has a URL or QRL in QUIC that contains all the information that QUIC needs to lazy load and execute. So QRL is a particular form of URL that QUIC uses to lazy load your content. So there are specially formatted URLs that are left as attributes in the HTML to tell QUIC where the handles for the code should be or for the code should be loaded from. And it points to JavaScript chunks to be lazy loaded.

And also, QUIC has this thing called QUIC Loader. So QUIC Loader basically does the job of registering global events. And if an event occurs, search the DOM, pointing to the URL that should be lazy loaded. It is about one kilobyte when minified. So basically QUIC Loader is the one that knows how to download the rest of the application on a native basis.

And also, we have this QUIC JSON. This is how QUIC is doing the serialization of the application, including the application code, the framework code, and more significantly how it can serialize your event listeners. So the app state is stored in QUIC JSON, making the HTML CDN cacheable.

So what about QUIC React? So QUIC React allows within QUIC. So basically, the advantage of using QUIC React is that you can use existing React components and libraries within QUIC. Because another thing about QUIC React is that it has a huge community of build tools that make your life easier for us as developers. So yeah, QUIC is newer and promising, but it's not yet at a point where it can pull a lot of people away from the React's bustling ecosystem. So yeah, that's a good thing, right? So yeah, before you can use QUIC React, you can need to configure the QUIC Project to use QUIC React. So if you don't have a QUIC application yet, then you need to create one first and then follow the instructions and run the command, add react to your application. And the above command will then install the required dependencies in your package JSON. So like React, QUIC uses JSX syntax to define the HTML output. So QUIC React allows you to use React within QUIC. So the advantage, like what I said, is using QUIC React is that you can use your existing React components and libraries within QUIC.

So let's have a quick demo on QUIC React with material UI. So here we can make your interactive React apps without React ever loading in the user's browsers. So in this case, we have React components using the QUIC framework. So if you interact with this application, you see that the React never loads. You can see in the DevTools that React does not appear. But you can see it adds this attribute client visible to make it so that certain components hydrate when visible on load or whatever. So here in the DevTools you will see that React loaded but only for this particular one component. So this using the QUICify utility in QUIC to essentially turn React components into pure simple HTML that only runs on the server and then you can optionally make them reactive using signals in QUIC that loads extremely little amount of client-side code to add interactivity. So this can help make your application use React components basically lightning fast. QUIC React. Here's a Quick React, the rules are the following, you just don't mix React and QUIC components in the same file. Then this is the recommended folder that you can put your React components or folder.

You can also, like QUICify, convert the React components into QUIC components. So QUIC and QUIC CD. So QUIC basically is a regime-multi-framework at its core. So QUIC CD is a metaframework built around QUIC. So it offers directory-based routing, nested layouts, file-based menus and data endpoints. So basically QUIC CD is what is Next.js to React, and then Knox is to Vue. And then Svelte is to—sorry, Svelte with KIT to Svelte.

So to recap, QUIC and its visionability. So there's no hydration, which means performance scales well of all one notation. So the developer experience is good and very performant. And basically, QUIC gives us this fine-grained, lazy-loading feature out of the box. It will automatically split up your application into smallest possible chunks of JavaScript code.

So QUIC is a big metal shift from where things are in the front-end framework, but I believe it's a very exciting time for that front-end world.