Remix Conf Europe

Remix Conf Europe 2022

Remixing How We Give

Sergio Xalambri

The New Frontier: E-Commerce at the Edge 

Hi there. My name is Michael and today I want to talk to you about the new frontier, e-commerce at the edge. I've been building e-commerce applications for well over 15 years from old school PHP 5.4 to now Node.js, TypeScript and more modern tooling. And that's what I want to talk about today. I want to tell you about the future of e-commerce. And that consists of two major trends that I want to cover today. One being headless, the second being the edge. Let's cover what I mean by these. First of all, headless. Here's a Google trend chart for headless commerce. As you can see, more and more people are searching it. There's a lot of interest there. But what does it mean? Let's Google it and find out. Well, when we Google it, we'll see the first page is just ads. If we scroll down, try and find out what it actually means, we will get one after the other content marketing blog posts. What can we tell from this? It's a buzzword. That's what we can tell. And if we try and read these and find out what it means, we're going to get lost in jargon and keywords. Let's skip that. And I'm going to show you a diagram to make it simple. We want to build a web-based e-commerce application, an online store. What do we need? We need a server. Okay. We need a database to store our product, customer, and order data. We need some business logic. This is what's going to take that data, put it into some templates, apply some business logic, and produce the website and all of its functionality. We probably have some cloud services, some caching layer maybe, some third-party APIs to call out to. But at the end of all that, we're going to serve to our customer some HTML. That product data from the database has been put in a template, and the server is returning HTML. This is what's known as a monolithic architecture, a traditional architecture for a web app. This has been around for a very long time and will be around for a very long time. And this is good. But we're not talking about that now. We're talking about headless. Headless is different. How do we get from monolithic to headless? Well, it's simple. We just got to remove the head, like that. Now what's happening? So we're no longer serving HTML from the server. Instead we're serving JSON through a JSON API. That could be a REST API or a GraphQL API. The client is responsible for taking that data and turning it into HTML. Typically that would be a JavaScript-based framework, would take the JSON and put it into a template. This is nothing new. We've been doing it for a long time. We used to call it things like AJAX. Now it's being referred to as headless. But that's all you need to know. I'm sure you've done it. If you've been building single-page apps, you've been using this already probably. Nothing new. But that's what we mean when we're talking about headless. Headless commerce is this applied to an e-commerce application. Let's look at some examples. So headless really caught on big in the content management space, first of all. You've probably heard of some of these services and projects. WordPress is an interesting one. This is like the original old-school monolithic CMS system, the granddaddy. But it's in here because you can use it as a headless CMS. It has a REST API and it has a GraphQL API. So you can use it just like this. In the commerce space, there's lots of software as a service and open-source products as well that you can use to build in this way. Again, you have pure headless offerings like Commerce Tools and Venger. And then you've got companies like Shopify, which are traditional monolithic system, but have recently bet really big on headless. And this is fantastic. You've probably heard of the Hydrogen Project. And you've probably also heard that they acquired Remix as well. So this shows that a real big player, and Shopify is one of the real big players in the e-commerce space, they're betting big on headless. And this is a very good sign. And this is a sign that this is a trend that is really here to stay and it's going to drive the future of e-commerce. So we've learned what headless is, but why are people interested in it? Why is it so big? Why is it the future? Let's look at some of the benefits. So first off, we see that it's pretty easy now that we've separated the client from the server. We can now serve multiple clients through the same API, a mobile app, maybe an in-store point of sale system, and who knows, even an internet connected fridge where you can order your groceries through the same API. And now that we've decoupled the UI, it means that we're no longer bound to the templating systems imposed on us by a monolithic system, be that the templates of Magento that you see here, or the WordPress style templating system that's used in WooCommerce, or liquid templates used by Shopify. A decoupled UI means that we can use absolutely any technology that we want to build our front ends. And this is a key point because in e-commerce, it's not uncommon that the server, the platform itself, is very long lived. It's a big investment and it's going to last five years, 10 years, even more. By decoupling the UI, it means we're no longer constrained by whatever technology the backend platform is built on. We can build the front end with whatever we like. Remix, for example. And that brings us to tooling. Let's take an example, Magento. This is a very big open source commerce platform. The last major version came out some years ago, maybe seven or so years ago. And at the time, they had to choose what are they going to build their UI layer on. So the tools that were available at the time looked something like this. And they chose some of these, like Knockout, RequireJS. And that was a fine choice back then. Now, if you were to start a new project and someone said, choose whatever tool you want, you may not choose these. I personally wouldn't choose those. I would choose something maybe more like the ones on this side. And the key point here is that with a headless architecture, you are free to do that. You're not constrained by tooling choices that had to be made a decade ago. You can use what makes sense now. And that's a huge thing in terms of not only developer productivity, developer happiness, but also in the results you can get in terms of the experiences you can create for your customers. And this also highlights a strength, a massive strength of the JavaScript node ecosystem. This incredible innovation, this pace of innovation, some people call it JavaScript fatigue. But on the positive side, we have an amazing array of tools that we can use. And there's continuous innovation. And the innovation is not only in frameworks and build tools, but it's also in the actual platforms that we can run our code on. That brings me to the next point that I want to cover, the edge. So what is the edge? Well, to explain this strange new concept, I have a special guest, the edge. I'm sorry, I had to get a dad joke in somewhere. This is the edge, the guitarist from YouTube. He's going to help explain what the edge is. So what is it? Okay, he says an edge server is a server located at the edge of a network. What do we mean by the edge of a network? Well, in the center of this network, we have a cloud region, EU central one. That's where we're hosting our e-commerce application. We have users all around who want to use it. And notice that they're not accessing the cloud directly. They're going through an intermediate server that's close to them. These servers are what we refer to as the edge or edge servers. Let's make this more concrete. Here's our node application running in Central Europe. This is running our remix app, of course, and we're using a headless commerce backend. And we have a potential customer down here in Sydney. He enters the URL of our website into his browser. His browser is going to send a packet all the way to our server in Central Europe. And that is 16,000 kilometers away. Just the network latency for that packet to go across is going to be over 260 milliseconds. Once it arrives on the server, we're going to be rendering HTML. This is a key point. We're talking about e-commerce. We're going to be doing server rendering, okay? SEO is king. So we're definitely going to be server rendering. So there's some work done there. Once the HTML has been rendered, we've got to send it back all the way back to Sydney. Again, 16,000 kilometers latency. So just before the first byte arrives, our customer is going to be waiting for like a second, two seconds. Who knows? How is this going to look like from his point of view? Okay, he's entered the URL. The packet's traveling 16,000 kilometers. The HTML is rendering. Okay the first byte has come back. We've got some HTML. That's good. Now the HTML is fetching some JavaScript, maybe some assets. It's making some more fetches for data that it couldn't server render, such as session-specific data. Ah, okay. The shopping cart just loaded. Some more requests going in the background. Lots of latency on every single request. Finally the image appears. The website's loaded. Not a great experience. How can we improve this? Something that we've been doing for a very long time is using CDNs, content delivery networks. This is actually a form of edge computing. This stores static assets like images, JavaScript files, CSS files on a edge server, for example, right there in Sydney, so that when those assets are required in the future, they're fetched locally instead of 500 milliseconds latency, there's 10 milliseconds latency. That solves part of the problem. But we still have to go all the way to the origin server to actually get the HTML file to know what resources we then need to subsequently load. How can we solve this? Well what if we could do the rendering not only in our origin server in Central Europe, what if we could render right there at the edge? As if we'd taken our node server and scattered it around the world. That would be cool. That's what we can do now. So as well as our static CDN, we can also actually render our page right there on the edge with something like Remix edge SSR, server-side rendering. So one really, really cool thing about Remix is that it can run on any JavaScript runtime. So we all know Node.js, but there are other JavaScript runtimes. There is Deno, there is Cloudflare Workers, there are probably others, and there are probably more to come. Remix is very smart. It abstracted that part away into adapters so it can run on any JavaScript platform. In this case, we could be running on a Cloudflare Worker, for example, Cloudflare Pages, and Remix can do the rendering right there. So the HTML is generated there in Sydney, 10 milliseconds away. There's still a problem, though. To get the product data to put into our page, we still have to make a call back to our headless server in Central Europe. We're still going to incur latency. But edge computing can help with that, too, because we can cache our API responses at the edge. So that product has already been requested in the past. The response has been cached right there in Sydney. So now let's look at it. When he wants to visit our website, he makes a request. The edge server can start rendering the page with Remix. When it needs data, it grabs it from the edge in an API cache. It returns it to the customer, and every resource that is needed by that web page to fully render it is right there in a CDN also. So everything that he needs is right there in Sydney instead of 500 or 1,000 milliseconds latency, there's 10 milliseconds or 50 milliseconds. Much better. So this is why I call it the new frontier. It's really a revolution in the way that we can serve applications and increase performance, increase global availability, and decrease the load that we actually have to serve on our origin servers. So this new frontier, as I said, consists of headless architecture and edge computing. Now what does this look like in practice? I've got a demo for you. Let me introduce you to Venger. Venger is an open source project that I've been working on for the past four years. It's an e-commerce framework, so it allows developers to build custom e-commerce applications. It's built on Node.js using TypeScript, and it's headless. It exposes its functionality via GraphQL APIs. Not only that, it's highly extensible. You can pretty much build anything on it. It supports multiple languages, multiple currencies, and it's got a growing and active community. It's used by lots of companies from Fortune 500s to unicorn startups, Y Combinator-backed startups, national supermarket chains, and everything in between. If you want to try it out, you can get started in one command, npx at Venger slash create my shop. It supports SQLite, so you don't even need to have a database running locally. You can literally be up and running in five minutes. Try it out after this talk or after this conference day. This is what I want to show you today. It's an online shop backed by Venger. It's built, of course, with Remix running on Cloudflare Pages, which is an edge computing platform. And the API is cached by Stellate, which is an API caching service which uses the Fastly edge network to cache API responses. So we've got everything in the mix that I've talked about. So this should be good. Let's take a look. So here's the website. It's available at remix-storefront.venger.io. I'll just take you on a really quick tour. Here's the landing page. We can drill down, look at these categories, camera, photo. Take a look at this. And as you can see, it's running pretty fast. We can filter, add to cart. We can take a look at the cart, modify it. All of this is happening against a real API. We can search. So that's what it's like to use. I'm sure you can agree it's pretty fast. But just how fast? Can we have an objective measure of it? Well, let's take a look at PageSpeed Insights. And we will take this product detail page and drop it in there. Now it's going to run its analysis. And what we're hoping to see, of course, is lots of green circles with big numbers approaching 100, hopefully. Let's see what it gives us. First of all, we're going to see the mobile results. Okay, lots of green circles and almost 100 in all of those. If we go over to the desktop version, okay, this is looking really nice. We have basically 100 in everything almost. Accessibility needs a little tweak. And these numbers right here are ridiculously good. So it's fast. It's objectively very fast. Let's see if we can get a measure of the benefits that edge computing is bringing in this situation. Our origin server in this case is in Europe. I'm in Austria. So we're not really seeing the full capabilities of the edge. But let's see if we can view this website from different locations around the world. Here's a page that I found that lets us do this. So it's going to make a request to this website from Singapore, Brazil, Virginia, California, Ireland, Australia. And let's see what the results are. So they all come in. Look at these. 6 milliseconds. 14 milliseconds from Brazil. Virginia, 1 millisecond. Australia 14 milliseconds. California 2 milliseconds. This is I can't think of a better illustration of this entire concept of headless and edge than this. The results speak for themselves. I'm going to shut up now. That's the end of the demo. Let's head back to the slides. So to recap, we've talked about the future of e-commerce being headless, edge computing built on Venger using Remix. Thank you for your attention.


Michael Bromley

Your Personal Remix!

Facundo Giuliani

Remixing a Symfony

Hey everyone, welcome. My name is Emily Kaufman. I'm a software engineer based out of Pittsburgh, Pennsylvania. I actually gave this talk at the, I was a backup speaker at the first Remix Conference. So if you ended up watching that already, this might sound pretty familiar, but my talk today is going to be about the performance journey that Harvey, the company where I work, has undergone over the past few years and how that ultimately led us to Remix. All right, so Harvey is a grocery delivery service where all of our products come from local farms and producers. So it started out, I think about 10 years ago, as a community supported agriculture program. If you're familiar with that, it's CSA. Basically you pay the farm some amount of money per year and then every week or every other week you get a box of whatever they happen to have produced in that time. So it's a really great way to support local, support your local farms and producers. So what Harvey did is it provided a platform so you could actually customize what you were getting in your box. So up until about three years ago, two and a half years ago, that's all Harvey really did. We had a number of farms on the platform from all over and we had provided the way for the customers to come in and, you know, log in, view the contents of their box, make, you know, additions if they wanted to swap out stuff and then they would wait for their delivery. And then the pandemic hit. So you might remember at the beginning the world was starting to close down. A lot of people in the Pittsburgh area turned to Harvey as their main source of groceries to avoid having to go into a grocery store. And on the other side of that, all these producers that were used to going to farmers markets or going to, like, or setting up booths somewhere so that you could come and actually make purchases, like they didn't really have a place to go anymore. And so they were coming on to Harvey as a producer in order to stay in business. So as I'm sure you can imagine, we had this massive influx of both customers and producers and Harvey began to grow and evolve from this CSA program into a full grocery store. So of course, during any kind of large scale growth in a short amount of time like this, you're going to experience some growing pains and we absolutely did. So this is a Lighthouse test that I ran in late 2020. Yeah. It was just a simple content page in Harvey, which is a symphony application. And we got this performance score. So this was like the JavaScript bundle, the API request, the database lookups, even with the minimal UI to render on this basic content page, we had a baseline score in the 30s. So this wasn't correct. Something wasn't adding up. And so this along with some upset customers, some customer feedback helped to catalyze this renewed interest and commitment to performance at Harvey. So the catalog page, which is where you go to view all the products, had recently, I think a year prior to that, been converted from the symphony jQuery twig combination into part of a new React single page application. And this was hit the hardest. So the dump to React had addressed many UX concerns that we had. It modernized our tech stack, but it was still falling short in terms of performance. So the underlying architecture just couldn't handle the weight of all the new products. It was taking upwards of tens of seconds just to add something to your cart or remove something or do a swap. And so many members were just dropping off the site entirely. But we have to remember that we had gone from offering maybe 30 to 40 products a couple years ago to probably over 600 at this point. And so the page just wasn't scaling correctly. So when we think about fixes for this, our first iteration was kind of this crisis mode. Our engineering team got together and we said, what can we do in the short term to fix a few of these issues? So we spent a few hours sitting around the network panel and the performance tab and just walking through every step of page load and organizing what we saw into a few groups based on who would actually be working on them. So we had DevOps and networking. We had the back end, which would include the API and the database, and then we had the front end. And from there, we took what we found and we triaged this into quick and easy wins, involved fixes, and this could be part of a future redesign. For DevOps and networking, we didn't have to do too much here because it's mostly handled by services and tooling, but it was worth it to at least sit down and walk through and make sure there weren't any bottlenecks. For the back end API, we had quite a few issues around image loading on the site. This is a hero banner that we have on almost all of our pages, and for some reason, it was taking like seven seconds to load and seemed to be blocking first paint. So we did a bunch of work around image optimization and caching, and that took actual seconds off of our page load time. So I can't speak to everything that my back end coworkers did, but more involved fixes included like updating the endpoints and database lookups to make sure that we're only querying the minimum needed, trying to avoid unnecessary and computationally expensive operations. An example of this is like anything that would have to go through a third party provider, like if we were checking a user's credit card information for one, we might only be doing this on like one or two pages, so it shouldn't be in a top level like layout component because then it's going to be happening way more than it needs to. Overall, all of these updates came around just because we sat down as a team and we stared at the dev panel for a few hours and just identified issues. For the front end, aka my problem because I'm the only front end developer at Harvey, this is how long it takes to actually download the content, you know, how big the script is, testing slower connections and all that kind of thing. So we identified several low-hanging fruit that we knew would be relatively small development effort but would drastically increase the user's experience. So we started there. For one, the bundle was just so big. It was too big. There was so much code that a user had to download before even getting to interact with the page and we used Webpacks. We used Webpack's bundle analyzer plugin, if you're familiar with it, and this helped us identify many problem areas that we were able to tackle. One of these being our use of moment.js localization packages. So we're mostly in the Pittsburgh area. We have farms all over but mostly at least in the United States. So there were many localization packages that weren't really relevant to us at this time so we removed those with setting the goal that we would eventually switch to using something else other than moment. I went through every dependency in the package.json and just tried to figure out why it was there, if it was still needed, if it could be updated, and we were able to remove a good chunk from there. So I have this fun anxiety-inducing screenshot of the performance tab. This is our catalog page. So one of the biggest problems that we had in the front end, especially on the catalog page, was just the sheer number of elements that we had. So I said before, at one point maybe we had 40 product cards. Each had an image and a few buttons. You know, normal e-commerce stuff. And now we have almost 600. So even without all the optimizations we're making now, two years ago, this page was fully functional. It was working fine. Because remember, Harvey never was meant to be bigger than a small CSA program. So one of the first things we did here after seeing this was to add lazy loading to the page and it immediately stopped crashing, which makes sense. But you can see in this screenshot here, we're basically trying to load like 500 images at once. Okay. So I won't dive too deeply into everything we did on the front end. Because I only have 20 minutes. But I have a non-exhaustive list here. So better code splitting. This could even be more thoughtful code splitting. Just really taking the time to think about what needs to actually be loaded on every route. So with our single page application, we hadn't put a lot of time into considering which modules actually needed to be on each page. So one of the things this led to was we split our member and our admin code into two separate projects with their own builds. And then I made a components library where the two could share from it. So that was able to reduce our bundle size by a lot. We started using text compression. We added this to all of our JavaScript files. And I think our CSS using gzip and that had a positive effect. So we were able to get a lot of a positive effect. Minimize and defer third party scripts. Sometimes this can feel like a constant battle with marketing. This is stuff like Zendesk, Hotjar, Analytics. Anything that maybe marketing is using to track events on your website. And so we went through these and just made sure that all the ones that we were using were actually still needed. And tried to identify places that we could defer them where we could. Minimize expensive API calls. I kind of touched on this before. But a lot of this was just moving where we were making these calls, like out of a layout and into a component or into a route level. Just so that they weren't all being made on every page. So all these changes that I mentioned, they led to a substantial difference in terms of page load. And especially on mobile. And they helped somewhat with the page interactions after loading. Like adding, removing, swapping card items. But we knew that our current design just wasn't going to support the new business model. The bigger grocery store model that we were trying to achieve. And so we knew it was time for a redesign. One thing we did, this is our redesigned page here. Instead of loading every single product on the page, we loaded them by category. So we just weren't having as many elements on the page anymore. Fun note on this, though. Our categories are growing big enough now that we're starting to look into pagination or something like that. Because of the growth. We removed parts of the product card. And like the description, the producer information. And we moved these into a details page. So that we weren't trying to load all of those for every product in the catalog. We generated multiple image sizes for each of these. So we had like a thumbnail, which you can see kind of at the bottom of this image here. We had a details view, which is this bigger one. The card view. And they matched how they'd actually be displayed on the page. We dropped some functionality. Like the swap button. We used to have it so if you were in your shopping cart, you could swap out. Like say you didn't want broccoli, you could swap it out for carrots. But it just wasn't adding enough value for the customer for the performance issue that it was causing. So we decided to get rid of it. And that kind of led to this way of thinking. Like when you include a commitment to performance as an essential tenet of design. So when you're thinking about performance every time you're building a new feature, the design is going to become leaner. So I find myself doing this a lot. So we'll be like, oh, we should add this to the site. This would do this. It would be really cool. And then we realized there's going to be a performance impact of it. And it's like, is it really worth it to add this much time onto page load? Like is it worth it to take that hit? And a lot of times the answer is no. Okay. Let's see if this loads. So our redesign page is going to be on the left. And the existing page is on the right. The redesign page, you can see, is loading substantially faster than the existing page. But it's still not enough. Okay. I wanted to get rid of all the spinners. And despite the fact that our load time was so much better, our lighthouse score was still fairly low, which was surprising. So, all right. Into a remix. In early 2020, I had bought myself a remix license as a birthday present to myself. And I had been messing around with it on several hobby projects, just testing out what it could do and just in general having a good time. It was for myself. And I realized that the co-location of page load data requests with the component, with the layout, might help us break out of this spin again problem that we were having, as the remix team calls it. So, I don't have anything deployed publicly yet, as much as I want to. But I was able to get our new grocery pages up and running with remix. And I think the results speak for themselves. I ran this lighthouse report just to get an idea of if, you know, it was going to make any difference for us. And yeah, you can see. So, one of remix's selling points is that it minimizes the request waterfall. And that was the case for us. In some parts of the application, we were making multiple API requests on page load. And you just had that spinner going in the UI. Let's look at this video. Okay. I'll do it again. So fast. There we go. Okay. So, this video is slightly skewed because the existing application has more third party integrations, like a support widget and a few more features overall. But you can still see that second wave of the requests that were fired in the use effects in the component. So, that's on our existing page. If I pop over to remix, this is the same waterfall, but on the remix version. So, in the remix version, we have a longer document load time, but a minimal number of additional requests. And since we're only loading what's needed for that one page, this JavaScript that does load is a lot smaller. So, this is all without taking full advantage of some of the features like nested routing, which we're starting to, you know, work on now. But yeah, it was like an immediate improvement for us. It was really exciting. So, going forward, our plan is to continue to keep moving these existing pages that are currently in our member facing code into our remix application until we get to a point where we have enough that we can deploy it and, you know, have it be public. But using the framework has just become a natural progression of our performance journey at Harvey, and it's absolutely been worth the effort. And it helps that I really enjoy working in it. So, if we've learned anything over the past two years, it's that performance and building for scale are non-negotiable when we're releasing new features. It has to be baked into everything that we do and constantly checked for regression. So, our product list, our customer base, they're still growing at a rapid pace. And yeah, I feel confident that what we're doing now is going to support what the business looks like maybe like five to ten years down the road. So, it's an exciting time. All right. Thank you for listening. Again, my name is Emily Kaufman. If you have any questions, you can find me on Twitter, or you can read the blog post behind this presentation on my website. So, thank you.


Emily Kauffman

React Advanced

React Advanced Conference 2022

React Native Animations Should Be Fun

Catalin Miron

Panel Discussion: UX and the Design/Dev Overlap

Anjana Vakil

Maggie Appleton

Steve Ruiz

React Summit

React Summit 2022

The Subtle Art of "Subtle Loading"!

Hey everyone, hope you all are having a good time. So I'm now today in this session, I'll be talking about the topic, the subtle art of subtle loading. So without wasting any time, let's get right onto it. So just a small intro about me. So I'm Nikhil and I'm a software engineer at Postman. I mostly handle stuff around the design systems at Postman, Postman's just a platform and Postman on the web. You can find me on Twitter or on GitHub. I'd love to connect, it would be a good chat. All right, so before diving in, I just want to mention that our users are like, we all know this fact that our users are very fast when it comes to using the UI. They don't want to wait for anything. They just want to use things in a flash. And this is where a small bottleneck comes in because we as developers do want to cater to this request because we want the users to use our applications faster. But we have this small sort of drawback, right? Because we have to fetch something from a server and that's why we show them some loading screens on the page, which the users definitely don't like. And this is sort of this bottleneck that we want to handle in a subtle way. And that's going to be an essential and sort of an essence of our talk, where if you see this definition, which what Google gives you, the word subtle actually says making use of clever and indirect methods to achieve something. And that's how we're going to play subtle with all these techniques. So let's look at what are tips that I recommend to make our UX better. So the tip number one would be to not to be sitting idle and keep fetching something, whether it's UI or whether it's data, just keep on fetching. Don't wait for anything. And we'll be using a small technique for concurrent mode and suspense to handle this case. Second tip is to what to load when. That is the question. Because although we are having many things in succession that are loaded, succession, but we want to load a thing which is semantically having a better meaning if you load one thing first and then the other thing in the next round. So semantically the loading sequence would also matter, which should be done by a simple API called suspense list. And third is to be optimistic. And don't worry about all of these techniques. We'll cover them up in a demo, which we'll now see. So all right, without wasting any time, let's quickly jump in. Okay. So if you see here, I have two applications, one running on synchronous mode and other one running in the concurrent app mode, or like you can say an async mode. So if I just give you a small introduction, let me just quickly re-fetch just to be on the safe side. Yes. So there's a profile section. If I go to about me, I see like a nice loader and then the data fetches and my about me section gets loaded. Similarly is the thing for a tweet. So there's a small button. I click on it and I see like an X-tree. So every time I do something, I'm seeing loaders. Now time for tip number one, which is to not to sort of do a waterfall thing where we wait for something to load and then we render the nested down components. So if you look at the concurrent app now here, in this case, we were waiting for a screen to load, but in concurrent app, while I was showing you the demo on the left, concurrent mode actually started fetching things in pavlet because concurrent mode can help you switch between tasks that are more in priority. So in this case, if I go to about me section, would I see a loader or not? Because should everything be loaded because concurrent mode was like working async to fetch the data in succession. It was not waiting for any loading to happen. So if I go to about me section, no loader, I didn't see any loader coming in. So it seems like it was already there. Similarly for the tweet section, it seems like this was also there. I didn't see any loader. All right, perfect. So this was tip number one. Now let's jump on with tip number two, which is inside this about me section. Now let me hide this synchronous mode and go to concurrent app. Now if you see, I reload this app and I, now let me go to the about me section. Now you'll see two loaders, but the second sentence is coming first and then the first description comes up later. Like it can happen because both of your async API calls can be in a race condition, right? Like whichever loads first, we don't know. But if you see this, like this, this description, I've intentionally added like a, like an Easter egg that the spelling is wrong, but in a meta description, I want to tell people that, Hey, now the spelling is this and not that. So the loading sequence that I talked about comes into picture. So the ideal experience should be like, no matter which loads, like which comes up first, like which API response is coming first, you want to show the first thing as a description. And then you want to show a meta description, right? No matter when they look. So if we go towards the code, maybe just quickly go ahead and yeah, I need some space here. Okay. So these are these two suspense blocks, right? That they're using. Now let's use suspense list here. So I use suspense list. I give a review order as forwards. Now this, like, what does this mean? This says that, okay, no matter what loads first or what loads afterwards, always load the first thing, which is the description. Always show the first things first and other thing afterwards. So I save it. So yeah, let's save this up and now let's refresh. Now what you'll observe is like, no matter what comes first or what comes afterwards, you're always going to see a description first, and then you're going to see the meta description, which is like a better experience. Like it makes a semantic ordering look better. All right. So that was tip number two. So what to load when? This was the question and this was the answer, right? Now coming up to tip number three, that is inside the tweet section. Now let me just toggle on synchronous mode to show you the difference. Now, if you see here, I have to like click on this button and then I show a loader to like show the next tweet is loading. But like if someone is on a faster connection, why do you want to show them a loader like for like some milliseconds? You can like just like not show a loader, like that's a subtle way of handling the scenario. Like so that the users on a faster connection feel that as if it was already there. So let's see how it happens in the synchronous or the concurrent app. So I click on the next tweet. I just like make it disabled for some time and I wait for the data if it's coming or not. So like I just like show the next tweet in an instant. So like let's see it once again. I click on the next tweet. There's no loader and waiting for some time because the connection is fast and then I see the tweet. All right. So that was tip number three is to be optimistic, like wait for things like as if they're just going to come up and you don't have to like show loaders for like those small instances. And this was using the use transition, like the start transition API that we use. So like just to give a gist, I just use a start transition, which gives me a function. So like you can use this function to wrap everything, all of your state updates inside this function. So as I've done here on this buttons on click, I've wrapped everything under the start transition and it waits for like this millisecond amount of time. So it says that, okay, if the data loads within this amount of time, I'll not show a loader. But if it takes longer than this, only then I'll start to see a loader, which is like kind of makes sense. Right. All right. So coming back to our top, looks like these three subtle tips can actually help us give us some good amount of experience and like with some smaller wins, like you, like we didn't actually do much, but just apply the small React 18 APIs and we were able to get some subtle API experience. So is this production ready? Would be, I think your next question that, Hey, now, when can I try this out in my apps? So I would be able to spot the folks who want to try it out that React 18 has like recently been published and it's now available on NPM. So feel free to try it out, use concurrent mode, suspense, and APIs like start transition. You're going to love these APIs and I'm super excited about it. And just as a side note, we at Postman are also really passionate about like building great things and making the lives of users easier using the platform. So if you would want to be a part of our journey, feel free to connect with us using Postman's careers page and we'll be happy to get you on board. All right. So with this, I will address my case and thank you for listening. See you guys.


Nikhil Sharma

JS Nation

JSNation 2022

Ensuring your Users are on the Right Path: the Future of Modals and Focus Management

♪♪ ♪♪ Hey there, my name's Sam, and I'm here today to talk about ensuring your users are on the right path, the futures of modals, and focus management. Now, that's a handful, and I submitted this talk to JS Nation a while ago, and since then, I think what it should be called is basically focus management in 2022. Now, the web has come a long way, and actually, for the first time this year, all the evergreens are supporting these amazing new features that we can use as either primitives or as part of some greater library. So, firstly, what is focus management, and why do you care? Now, I feel like this is the quintessential reason of why it's important. Now, we've got dialogue here, I can click around, I can hit submit, but what I can actually do while this is out operating is press tab a bunch of times and get behind this UI. I can still click some buttons that are on the page here. Now, you know, this is a demo, but lots of sites have this problem if you look around, and the challenge is that it's just really hard, and for the longest time, you know, we've got libraries and polyfills that try to really maintain this, you know, to try to solve this problem for you, but either they're not used correctly, they just can't do what you want them to do, or people just forget, and they just use a really basic mechanism and hope that users will never get there. And this example is obviously pretty tricky, you know, not everyone knows how to tab behind UI elements, but this kind of problem will leak out in other ways, causing users some weird behavior, and some examples here. To be very precise, the things I want to talk about today are dialogue and a note. Now, these are the two new concepts that are actually available in browsers this year, and they're both quite cool. They're actually quite old in terms of specs, they were written a long time ago, but like, as I've mentioned, it's the first time that you can use them in pretty much all evergreens with no hassle. So before we go any further, who is this guy? Why am I talking to you? I'm a former Googler, I was there for over 10 years, it was obviously really fun, I was on the developer relations team, and so part of my job was to do this kind of outreach. I've actually recently left Google and gone to a small early-stage startup in the green energy space called GridCog. It's a lot of fun, I would highly recommend working in climate, it's an important thing, and I'm always happy to talk to people about that orthogonally to the content of this talk. Having said that, our technology is still on the web, and so we want to use these features even in our SaaS product to make our user experiences better. And my general vibe of why I'm coming here and talking about these concepts in general, and why I want this in my browser, and why I want this in my web app, is that to me, these new features are letting us throw away tons of old code that did weird hacks and horrible things to browsers that really they weren't designed to do. So having new primitives in 2022 is really lovely, right? I can get rid of all this code and get on with the more interesting parts of my job, right? Not dealing with focus management, but actually writing applications that do interesting things. So the first component I'm going to talk about today is called the dialogue element. Now, dialogue can do a whole bunch of stuff. The spec is pretty wide. But the reason why we most care about it as web developers is I can create this element on my page wherever I like and then call show modal in JavaScript. What this does is then creates that dialogue in what's called a top layer. Now, the top layer is special. It does two things for us. One is that I can't tap behind it. You know, this focus problem has been solved. While it's visible, I can't interact with anything below it, including other dialogues that I previously opened. The second thing that's really cool here is that it actually exists outside the browser's kind of normal rendering layer. It's in a thing called the top layer. And what that means is even if you're inside some weird stacking context or your Z indexes are all bizarre, then actually the dialogue will always be on top. I actually like to demonstrate this by, if you can see here, that I've got this weird element that's transformed in bizarre ways. If I click this button, the dialogue is actually inside this transformed element, but the browser is just going to ignore all of that and hoist it to the top. So in that way, it's quite cool. You know, it's scoped and encapsulated in a way that you can use it in a component or some library and it will still appear right at the top, ready for the user to interact with it. Now, that's the most interesting part of the dialogue for me, but there's a few other things I want to cover before we go on. One of them is this backdrop element. And so every dialogue for free will have like a full screen element. You can change its color or background or whatever. It also has a built-in handler for the escape key. Now this is kind of bizarre, but kind of reflects when it was created back in 2014. But if I can hit escape on my keyboard now, then this dialogue will close. And that's fine, but a bit weird because there's no analogy on mobile or other platforms. You know, you can't press your back button on your mobile phone to close it. That will still, unfortunately, go to the previous page. There is something coming on the pipeline called Close Watcher as a bit of an aside, which is totally in draft state at this point, which does help deal with things like closing dialogues. And in fact, it's one of the examples called out in its description. But who knows if that'll come about. My advice, honestly, is if you don't want this behavior, you can actually add an event handler for the cancel event and then the user hitting escape will do nothing, right? And you can control that keyboard interaction or maybe you close the dialogue with buttons. You can do that entirely yourself. The next thing I want to talk about is Inert. Now this is a whole different feature. It has nothing to do with the previous dialogue, but it also lets you build interesting apps together. This is something where I can mark any subtree of my DOM to be inert. Now what this means is I can't click on it, I can't interact with it, I can't tap into it. This is basically like a better version of pointer events none. And that's something that people often use, right? They just say, well, I can't click on this area, therefore you can't use it, right? Well, no, as you can see in my example before, it's very easy to tap behind that area. So Inert basically gives you that for free, but also makes the whole anything in the space just unusable. Now this is a very broad primitive, right? Like I'll go through some examples later on, but it's worth thinking about, right? You can build a lot of things with it. One interesting downside is that you can't actually turn it off. So once a DOM tree is inert, that's it. I can't make some subsection un-inert. Now, whether you think that's a feature or a bug, well, that's up to you, but to me, it's kind of a feature, right? If I have a component system and say, well, everything within me is turned off, something within that system can't say, oh no, I really want to be turned on, right? So it turns everything off all the way down. And so the last component I want to talk about is actually quite ancient. It's the field set. Now, you might think of the field set as just some nice way to group input elements together, but what you don't know, or what you might not know, is that you can actually set disabled on the field set. What this does is kind of like a lesser version of Inert. It's going to propagate that disabled down to any HTML form elements within the field set. So links will still be clickable, but like an input or a button will be read-only and disabled. Now, this is actually not as good as Inert, right? It does fewer things. Inert's not quite there yet in Firefox. It's in nightly, which means it's probably going to ship soon, but this is like an interesting fallback that you can use if all your problem is just submitting a form, right? I don't want users to be able to muck with a form while it's in progress, and I don't want to modify every field. I can just wrap it in a field set and say, disabled, off we go. It has one weird nuance with Shadow DOM, but it's possibly a bug more than a feature in that it doesn't propagate through to elements within a Shadow DOM's shadow root. And so one of the reasons I'm excited to talk today is that these three elements just work. Firefox, Safari, and Chrome support nearly all of these features. As you can see, and as I mentioned, Firefox is slightly behind on Inert, but honestly, by the time you watch this talk, it's probably going to be there. You can just start using this stuff. These are primitives, though. You can use them directly. That's fine. You can also think about using them as part of a framework or a library. And I fully expect some libraries to basically have a fast path where they just say, we've got this amazing new feature. We don't need to do our old weird hacks. We can just leverage Inert, Dialog, or even Fieldset, although they might be doing that already. That's quite old. Now, with these amazing new primitives introduced, it's worth talking about how we've gotten here. Now, you know, browsers were written for an ancient time where documents were documents, right? You clicked on links, you could go to other pages, and there was no app-like experiences in sight. But as we've added more functionality to the web and made it this amazing platform to build interesting stuff on, we've needed to control its focus much more distinctly. The tools people have had available over the years are things like literally just removing links, you know, making a button disabled one by one. I mentioned Pointer Events. That came with IE11, and it was sort of a new era in trying to railroad or guide people through your application in like a nice, friendly, organic way. And so the challenges of doing things like Inert or Disabled was that Pointer Events, as I mentioned, can be really trivially escaped, right? I can't just hide an element behind a div. I could manually set elements to input disabled or, you know, disable the href on a link, but you've got to do it for every single one. You know, what if it was already disabled? What if you're in a shadow root? What if all these what ifs, right? And polyfills make this kind of better, but they're horrible hacks, right? And one of the challenges of these things is like I can't really intercept the user's intent or goals globally. Now, these new primitives we have actually let us do that in a much nicer way. And it's also worth calling out that making a dialogue without a built-in primitive is also quite challenging. The biggest one being it's often not clear whether you can hoist yourself to the top of the page. You know, does position fix do what you want at the position you're currently in? And as you saw from the demo before, with the actual built-in dialogue, that's no longer a problem. I can just have a component that makes a dialogue and it will just appear on top, which is pretty much what I always want when I encapsulate elements together. Frameworks, I will say, can help. And if you're building your app entirely within a framework like React, then dialogue may be a solved problem for you. I know that when I write React code, then we use a library that will actually hoist that element to the top level for you automatically, right? Like the fact that it's a dialogue within my React component is sort of irrelevant, right? It gets rendered somewhere else anyway. But some frameworks don't allow that. Some layouts are never going to support that behavior. So having a built-in dialogue primitive is quite lovely. In general, the thing you're trying to avoid is fighting against the browser. As I mentioned, browsers were fundamentally designed for documents, not apps. One thing polyfills try to do is intercept and override every single focus event in totally weird ways. But it's futile. There's always more cases. So now that we've got here and I've given you a bit of a history lesson, let's talk through some of the reasons why you might use these components. Now, Inert and Fieldset are pretty much good for controlling forms and controlling parts of your UI where users shouldn't interact with it after something is done. And so in this example, I've got this quite fancy form. And when I hit submit, yeah, I can block it all out almost immediately and say, don't mark with this. I'm, you know, processing a payment or something like that. I can even overlay a div on here showing my cancel button or some behavior that I really want users to flow through. And what's important here is I don't have to mark with the underlying form, right? I don't have to worry about disabling things. I can just mark the whole thing as inert and create some new interesting state for my users to be in. Now, this is a subtree. Maybe I can do it for a sidebar or a larger part of my app that the users shouldn't interact with for some time for whatever reason. Now, you know, you can go away with this talk and create some interesting experiences. And I've got some ideas here, but I think these are wonderful primitives, right? I think we'll see over the next couple of years, people using them in vastly different ways. So now let's talk about dialogue. And it's worth saying and getting out of the way, I'm not a fan of you using a real modal or even a giant div for blocking interstitials, things like sign up to my newsletter when I really just want to read your content. I think we all as web developers know that's a terrible anti-pattern. But having said that, there are going to be cases where we do need to show a real modal on your webpage. That can be because the user's, I don't know, saving some state that you're confirming, you know, do they want to leave? Are they sure they want to cancel? And in this example here, we've got a pretty good, nice dialogue that shows, you know, the user's type, some document content, but they aren't sure if they're ready to finish or whatever. And so we give them a few options here that make this experience feel quite nice. We've got a close button to get rid of it. We've got a cancel button. And we can use this modal in an interesting way. You know, there's a lot of stuff going on behind the page here and the user doesn't have to worry about it. They can just be focused on one thing for a given amount of time. And modals, you know, really shine in this example. Now, another thing we can do with the dialogue is also animate it. In the end, it's a div, right? It's a fancy div that has some magical properties and it renders in a weird place, but it's a primitive that I can use in any way I like. So when I show a dialogue, I can combine the show modal call with a, perhaps I'm going to start the dialogue off screen and then let it animate it in over a second. One interesting thing I can even do here is maybe disable the interaction on the dialogue with inert during that time. Now, maybe a second is too long, but you get the idea. Similarly, when it closes, yes, there is a built-in close method. Yes, there is an escape handle which I can prevent from happening. And when a dialogue closes, I can not actually close it for the same amount of time. I can say maybe for a short period, it animates out. And once that is done, I then properly actually close it. In the end, it's just a primitive, right? Like I should be wrapping this up behavior up in some other component or helper that does this for me because the close method is not something that a user should necessarily call directly. It's something that you can control. So I'd like to finish up this talk by talking about some other things dialogue can do. I think it's worth being complete, but I will be clear. I think these things are the least interesting part of dialogue. Now, for a better backstory, right? Chrome introduced dialogue in 2014. That's literally eight years ago. And Safari and Firefox have only just come to the table and built that feature out. And that's great, right? That's why the talk is here today. And I can say, please go and use dialogue. It's available everywhere. But I will say some of its weird features were built for kind of a different part of the web. Now, it has non-modal support. I can just toggle this open attribute and dialogue will appear and disappear, but it doesn't block the page. It doesn't render in weird ways. And so it's kind of pointless, right? It's just a div in this regard. It also allows a thing called form method dialogue. Now, this is kind of cute, right? You create a form and when it's submitted, it'll automatically close the dialogue around it. But the reality is, what we do for every other form on the web today, or we want to intercept it with JavaScript or whatever, is we literally overload its submit method and then prevent default. Now, I don't know why form method dialogue exists when I can literally do this to a regular dialogue that has an implicit form method that I just disable or ignore with JavaScript. In fact, I'm already using the dialogue with JavaScript. So it's bizarre to me that we have this weird dialogue type form that sets a return value on the dialogue. Now, you might find it useful, but honestly, I think it's part of a spec that hasn't really aged that well. So I'm only mentioning this stuff for completeness. I don't want to end on a downer, right? Like, the thing to take away from this talk is that dialogue is an amazing primitive that gives you a modal experience that can be used in a bunch of ways, but which exists in the top layer, can be nicely encapsulated and used in components, and hopefully will give you the thing that you've wanted for a long time, but have maybe feared the reams of JavaScript or the horrible hacks to get there. And no, it's very similar. And even field set, even though it's not available because Firefox is a little bit behind the fold, will also give you most of that functionality, right? You can quickly disable forms. And while it sounds like a really silly thing to have to be able to do, it's quite nice to have in your toolbox. So I hope you'll take away and go and run with these ideas. I will say one thing I haven't mentioned extensively is accessibility, or really at all. Now, all these things will kind of do the right thing, but I would encourage you to go have a read if this is important to you about how these things interact with the accessibility tree. I'm not an expert, and I don't think you should just use these features without any knowledge of that. So thanks for listening. I'm on Twitter. You can follow me in a bunch of places. I regularly blog about this kind of stuff. You can see my blog here and, you know, subscribe to it with your favorite RSS reader. And thank you for JS Nation for having me, and hopefully I'll see you around on the internets. Farewell. ♪♪♪


Sam Thorogood

Performance is User Experience: Optimizing the Frontend for the Users

Hello everyone and thank you for coming to my presentation. Today we are talking about performance user experience, optimizing the frontend for the user. My name is Chinaya Onwebu. I am a senior software engineer at HubSpot. What is software performance? We all know what software performance is, at least we have an idea. This is basically a measure of how well your application is running, how well it is performing its task and how well it is using the system resources that are available to it. On the frontend, however, software performance is all this plus how the user feels about the application. So if the user doesn't feel good about the application, no matter how fast your application actually is, your application is not performing well. Because the frontend is racing for the user, we measure performance of the frontend in relation to the user. So we call this passive performance. This is a subjective measure of how well your application is performing, how well the user thinks your application is performing. Passive performance is very difficult to measure. You cannot measure it directly. There is no way to tell how a user feels about your application. There are ways to measure it indirectly. First is you can use bounce rates. If you are getting a lot of bounces, you are getting a lot of users that are dropping off after the first few seconds on your website. It's usually a sign that your application is not performing very well. Users think that your application is slow. Maybe the pages are not loading. Of course, it could also be some other problem. Maybe it's not the content that they are expecting. That usually is a sign of poor performance or users think that your application is performing poorly. Research has shown that users will abandon a website between 3 and 5 seconds after waiting for the website to load. So if your application does not show content in the first 5 seconds, there is a very high chance that you are going to lose a lot of users. So how do we actually improve the passive performance of our application? You can always improve passive performance by improving actual performance. First of all, you want to reduce the amount of time between when the user enters your website, presses enter, and when your website actually loads. So we want to use a shared cache, for example. A shared cache is a cache that is shared between users. So if one user visits a page and this page is already cached, a second user visits the same page, the second user will retrieve a cache of this page. You can also use HTTP2. HTTP2 will massively improve your performance. This is especially true if your website loads a lot of resources. This includes websites that serve a lot of images, for example, or websites that load a lot of scripts, a lot of CSS. HTTP2 will make loading resources in parallel to be much, much faster than HTTP1. You can also preload important requests. There are several ways to do this. Preloading important requests will make your website or your application feel snappier to the user. Using a CDN will solve a host of issues on your application right out of the box. Using Cloudflare, for example, will give you shared cache without you having to do anything. It will also give you HTTP2 without you having to do anything. Finally, you can use server-side rendering. Server-side rendering makes sure that when the page loads, the user sees content immediately. So the user doesn't have to wait for all the JavaScript to load before they can see the content of your website. So using server-side rendering, users can already see the content, and then you can inject the script, hydrate the page later for user interaction. Then you can also improve passive performance directly by doing some tricks. These tricks do not change anything in your website. They do not change how your website actually performs, but they kind of change how the user perceives your website, how they perceive the application to be performing. And one of those is to avoid blocking the user. So if you are performing some CPU-intensive tasks on the front end, unless you are rendering images, you should avoid blocking the main thread. Always use worker thread for any task that will take more than a few milliseconds. The gold standard is 16 milliseconds. If it's going to take more than 16 milliseconds, you should move it to a separate thread. You should not block rendering. Blocking rendering is very, very easy to do and very difficult to avoid. But one simple rule to avoid blocking rendering is to only load the resources that you need at the beginning and then load the rest later. So in Webpack, for example, you can split your scripts into chunks, and then you can load only the important chunks first and then load the other chunks later or as they are needed. This way, you will not block the rendering of the page. You only request what is required at the beginning. You can also avoid using spinners and use skeletons instead. Spinners make users think that your website is slow. It is psychological. They do not know what they are waiting for. They just know that they are waiting for something. When it's possible, try to use progress bar instead of just a spinner. Progress tells the user the actual progress of what they are waiting for so that they are not just left in the dark. Use optimistic patterns. There are a lot of resources online that explains what this means. When you use optimistic patterns, you mark a task as completed before it's actually completed. And only when it fails, you actually tell the user that this has failed. Gmail is a very good example of this. When you send a message, Gmail actually tells you that the message has been sent before the mail has been sent. It makes you feel as if Gmail is instant, but it is not. Don't block the user. This is a very common mistake. What does it mean to block the user? If for example a user submits a form on your application and then you show a full screen please wait spinner, telling the user to wait until the form is submitted before they can continue. This breaks the user experience and this makes the user feel that your application is slower than it actually is. Instead of doing this, you can show a notification or you can allow the user to use other paths of the application while waiting for this form to submit. Finally, you should note and keep it in mind that the user expectation changes often while they are on your application. The expectation of a user that just arrived on your application is very different from the expectation of a user that is on the checkout page. New users are less patient than users that are already committed to whatever you have to offer. So you should keep this in mind and this will help you. Thank you very much for attending and hope to see you again next time.


#user experience