Navigating Modern Frontend Innovations

Hi, everyone. I'm Renessa Ghosh. I am a developer advocate at CKDedder, and today we're going to talk about navigating modern front-end innovations and whatever that means in this world of rapidly changing frameworks. Specifically, we're going to talk about a few frameworks, React, Solid, and Quick.

But before that, let me tell you a little bit more about myself. So as I said, I'm Renessa Ghosh. I'm a developer as well as a marketer. I started my career off at IBM Cloud as a full-stack engineer. Then I moved on to developer marketing at DigitalOcean, and now I'm a developer at CKEdder. If you don't remember anything about me, just remember that I love to travel, and the country that I traveled to most recently was Iceland. So enough about me.

Today's talk. Today's talk, it's a lightning talk, so we're going to go quickly through three different things. React, we're going to talk about that powerful ecosystem that we all know and love, right? This entire summit is called React Summit. Then we're going to talk about Solid.js. It redefined this thing called reactivity, fine-grained reactivity. We're going to talk a little bit about that, and then we're going to talk about Quick.js where the big kind of innovation around that framework was optimizing these initial load times. It was a huge problem that they solved. And finally, we're going to say, what's the best decision for your project? And I'm going to give you a little bit of a framework to get started on. So let's get started.

React, it's definitely more than just a library today. It's a whole ecosystem. It's a whole community, right? It has been at the forefront of front-end development, according to me, for years, as long as I remember front-end development. And the things that really make it stand out are these things like virtual DOM and component-based architecture, really big innovations for its time.

So six things that I believe make React stand out, the component-based architecture. So React's design really revolves around reusable components, making it easier to manage and scale these large applications. Virtual DOM, that's pretty great because it uses this virtual representation of the DOM instead of directly interacting with the DOM like your typical HTML and JS and stuff do, and allows it to efficiently update the UI but only re-rendering the components that you actually need, right? And finally, what it does is it has this extensive ecosystem or evolving ecosystem, whatever you want to call it. But from solutions like Redux to Mobex to React Router, even things like Create React App, which of course now is degraded, and Next.js for server-side rendering, this ecosystem is just evolving, and it's so vast and so versatile that almost any problem that you might have with any type of web application has already been solved for by the community or by your React maintainers already.

So that kind of leads me to this wide adoption and community support. React's popularity really has stemmed from the fact that it has such a huge community and a rich ecosystem of library and tools. The adoption is so great, and the community provides so many wealth and resources from open source projects to professional support that just really enhance developer productivity and learning. And then finally, there's some things like it does integrate with modern tools. It's not just this old framework that sits in the back. Today, React integrates with Next.js and offers this comprehensive solution with tools like Vite, for example. Right? So it really is integrating into your modern tools, and of course, forward-looking. I think there was this new thing called the concurrent mode, which allows React to actually prepare multiple versions of the UI at the same time, which are very new and great things that are happening in React. So it is a great framework, right? And I want to make sure I'm saying that here. And let's look at an example of what a component typically looks like in React. You have a function component, you have time display over here, which is just a counter that updates the seconds. And here I have time and set time, and it keeps updating it with the use date. And 1,000 just tells me that every second I want to update my time and set the time to the new date and then keep clearing the interval as I'm doing this. And then I put it into a div, that piece of code, and it's all good to go. Right? And this kind of looks really simple, but what we're really doing here is handling this dynamic data, like time, very efficiently by just kind of putting it into this function, hooking it up with state, and letting it run. So that is really powerful. What we just did is a very simple piece of code and logic, but the separation of concerns and the ability to handle this dynamic data efficiently is really what sets React apart.

Now, let's think about SolidJS, right? We just talked about React and how great it is. SolidJS is rapidly, like, gaining popularity, whether it's Reddit, Twitter, everywhere. And it honestly is very similar in my head to React, because it adopts this reactive model that differs from React, but the code looks very similar, right? So, what makes this great? These are the six things. For SolidJS, there's something called fine-grained reactivity. I talked about this at the beginning.

I'm going to talk about it deeper now. Unlike larger frameworks that use a virtual DOM, like React, SolidJS actually operates on this fine-grained reactivity system, so it tracks changes at the level of individual pieces of state, which allows you to update the UI precisely and render and avoid these unnecessary re-renders, in my opinion.

Then, the fact that SolidJS just does away with virtual DOM, it says, we don't need that, right? It is a huge departure from frameworks like React. So, it maintains a code that looks very similar, and we'll look at that later, but it does away with virtual DOM. So, there's less overhead, quicker updates, and more efficient memory usage.

And then, compiled optimizations. SolidJS compiler optimizes dependency tracking and component reactivity during the build phase, so much of the reactivity logic is resolved at compile time, which means at runtime, you actually have less overhead. This is also slightly different from how React works. And then, a few other things. It does have a developer-friendly API. It has such an evolving ecosystem. So many people have adapted it. And in terms of use cases and scalability, it's super lightweight and efficient in nature, making it super well-suited for these high-performing applications and large applications.

And in terms of use cases and scalability, it's super lightweight and efficient in nature, making it super well-suited for these high-performing applications and large applications.

Let's take a look at what SolidJS's code looks like. So here, we can see SolidJS's reactive system in action. The createSignal function over here actually creates a reactive signal for the items array. So, when addItem that function is called, what is happening is only the components that actually depend on items will re-render. This is Solid's precise tracking. We're just writing a piece of code that we think is just the same thing and the same set items and all of that, but only the components that are specific and depend on the items array is going to update. And that's pretty significant because you're not changing much when it comes from a code perspective, but I wanted you to see behind the scene how this can change and evolve and really makes it really pretty for even dynamic list rendering.

QUIC is probably the newest contender in all of these three frameworks, but it is really cool because it's engineered to address one of the most challenging aspects of modern web development. And that is achieving fast load times without sacrificing functionality. So, what does that mean? Well, here are six things that make QUIC stand out from the other frameworks. Resumability, right? QUIC has this ability to serialize and deserialize the application state, allowing components to be paused and resumed exactly where they left off. Kind of like a video, but better. So, this capability actually ensures that the only absolutely necessary code and data are loaded and executed, which significantly contributes to that initial load times. Then there's server-side rendering, right? But it's a little bit of a twist. That's why I have that star over there. So, unlike traditional SSR, QUIC actually optimizes the delivery by sending out minimal HTML and minimal code needed to make the page interactive. And additional functionality, including functions, only load as required, which is such a step beyond traditional SSR solutions today.

Then it has this thing called incremental delivery. So, it's built on this concept of resumability that we just talked about, which allows QUIC to deliver incremental delivery, for both initial page load, I believe, as well as state. So, what this means is that after your initial page load, any further interactions can dynamically load more features and data on demand, tailoring to a very specific load that follows the user's actual path with the application. And finally, QUIC, which stands apart, it optimizes for SEO and performance. So, a lot of content creators, and anyone who wants to get their website discovered can get excited about this, because it really ensures that search engines can call and index its content very eventually, which is super crucial for SEO. And if any of us has worked with content, you want your site out there, you know how important this is. And then, of course, just like your other frameworks, it has developer experience and maintainability that are equally important. A quick code snippet of what QUIC looks like. This example, we can see that it's really similar. You have this use store, as well as component that you're getting from the QUIC builder.

This example, we can see that it's really similar. You have this use store, as well as component that you're getting from the QUIC builder. And what I want to point out is, if you look at the on-click handler, there's this dollar sign, right? That you're bringing in the component dollar sign, which is what you've brought in. And what that syntax, that dollar says to QUIC's compiler is that this function, the state.count plus plus, or any function that follows, should only be loaded and executed when the user clicks the button. So, honestly, when you load the page, that function, actually, that piece of JavaScript does not exist. So, imagine in a larger scale application, the number of buttons and the number of small pieces of logic that are just sitting there, but you don't really need to load it at the beginning. So, this kind of on-demand loading just enhances the page's initial load time, because you're deferring all of this non-critical code to execution, rather than initial page load. Which I think is such a cool innovation from QUIC.