Javascript

Double Click: Try Out the New Releases for jQuery UI & Lit

Oct 1, 2021

2 min read

Welcome to the Double Click! This is the weekly blog series that shines a spotlight on emerging technologies, technological concepts, and community projects that enrich the JavaScript Ecosystem!

This week, I’m diving into some updates from two web development technologies that have recently seen updated releases: jQuery UI & Lit.

jQuery 1.13.0-rc.2

jQuery UI is a popular JavaScript library that sees wide use across the web despite the technology not previously receiving an update in about five years. Omg!

That’s why I’m thrilled to see jQuery UI receive some much needed love in the form of this 1.13.0-rc.2 release, which contains no breaking changes, but sort of polishes off some of its deprecated features to support wider use in modern user interfaces.

The jQuery UI team has noted that it has struggled over the years to find reliable contributors, which may explain why it has taken five years to see any updated releases. However, the team notes that they presently don’t intend to significantly expand the framework, and that it will now enter a maintenance phase to simply ensure that it is compatible with future jQuery releases, and secure.

Lit 2.0

Lit has gone through a number of changes with this most recent release which officially launched last week.

They have a new logo, a new name (having previously been called "Lit Element”), a new npm, and a ton of new features.

If you aren’t familiar with Lit, it is a library that simplifies and supercharges the process of building and implementing web components from Google.

With this new release, the Lit team has slashed the size of the library to 6KB, just a fraction of the size of your average JavaScript framework, which increases its speed and performance.

But this isn’t the only significant improvement to the technology as the Lit team has also introduced new features like a class-based API for directive authors, templating enhancements, and reactive controllers.

But what most caught my attention was the significant improvements to the Lit site and documentation. Aside from undergoing some major UI transformations, the new Lit website also features detailed documentation that includes a sandbox where users can test out Lit 2.0’s newest features in the browser!

What are you excited about lately? Make sure to share with me on twitter @ladyleet.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

Tracy Lee

Partner, This Dot Google Developer Expert (Angular, TC39, Web) RxJS Core Team & Lead for RxJS Learning Team Contributor to Angular, RxJS, EmberJS

Key Strengths:

Teaching developer relations strategies
Influencer marketing
Developing brands
Community strategies and maintenance
Creating product launch strategies
Leading marketing operations efforts & standards
Effective conference presence & speaking strategies

@ladyleet @ladyleet

JSR - The cross-platform package manager for ESM

JSR - The cross-platform package manager for ESM Move over NPM, there’s a new package manager in town. JSR is a new open-source package registry for JavaScript and TypeScript. This particular release has caught my attention, and I’m excited to explore if and where JSR fits into our overflowing ecosystem. Setting the stage The JSR website has a page called Why JSR? I want to explore the _why_ a little bit further. I think that the _why_ points to JSR potentially being the future of the JavaScript ecosystem. NPM and JavaScript modules If you’ve found yourself confused about publishing and consuming packages and modules in the modern ESM era, you’re not alone. When NodeJS was created, there was no standard for JS modules. Node introduced CommonJS modules, and NPM provided a way to publish and consume these modules in our applications. It’s been years now since ES Modules became a standard and we are still in a weird module purgatory with no clear end in sight. JSR represents a fresh start, free from the baggage of the Node and NPM ecosystems. JavaScript runtimes and interoperability New JavaScript runtimes are popping up every year. WinterCG (_Web-interoperable Runtimes Community Group)_ was started to improve interoperability for the various runtimes with some standard APIs. Node has made steps towards this goal, but it might never get all the way there and NPM is coupled pretty tightly to that ecosystem. JSR supports several runtimes (depending on the package). This is a huge opportunity for it to become the package manager for the ecosystem at large. See cross-runtime support section for more details. NPM Compatibility JSR doesn’t end up being a complete departure from NPM since it includes an NPM compatibility layer. The docs highlight some limitations and provide deeper technical details on how this piece works. The simple overview is that you can install and use packages from JSR to a Node/NPM based project. The packages will get added to your package.json and node_modules directory. About the same as any package installed from NPM. JSR Overview At a high level, JSR is very similar to NPM. You can search for packages on the website. You can publish packages to their registry, and you can download packages from it as well. We touched on the two major features that set it apart from NPM: It only supports ESModules, and it has cross-runtime support. In the rest of the article we’ll explore the essentials (package management) and also some other really great features that feel like are bringing the JS package management ecosystem up to speed with our modern workflows. Native TypeScript I have to say I’m not surprised by this feature, considering JSR was developed by the same people behind Deno (a runtime that supports TS natively). It’s a great feature. If you haven’t figured it out yet TypeScript is a big deal and doesn’t seem to be fading away anytime soon. So what exactly does TS support look like in a package manager, though? If your runtime supports TypeScript natively (like Deno) - it can consume the TS files in your package directly. For environments that don’t, it will automatically compile your code to JavaScript and package it with type declaration files (.d.ts). Pretty, stinking, cool. The docs include a page called “about slow types”. It is probably worth a read on its own ,but the TLDR is that JSR will analyze your TS code and penalize you in certain ways if you have some type code that it considers to be slow. On the page, it outlines exactly what these penalties are, as well as what it considers slow types to be. Slow types will also come into play when we get into package scoring later in the article. Packages The docs have a page dedicated to packages. It covers some important stuff like deleting packages, versioning, documentation, and publishing. We’ll touch on some of it with an emphasis on the things that are done differently or better than with NPM. jsr.json file jsr.json is a configuration file that specifies a name, version, and exports of a package. It doesn’t include a list of dependencies like you would have in a package.json file. This is a configuration file for a package to be published to JSR. JSR dependencies are defined in an import map file or a package.json file, depending on the runtime. Adding packages to a project Adding packages to your project will vary depending on your target runtime. Here’s an example of installing it for Deno and NPM using various package managers. For Deno, an import map entry is created. For NPM, it gets installed as an NPM package using the JSR NPM compatibility layer. ` If the runtime has native JSR support, you don’t need to explicitly install packages. You can important them using the jsr: scheme. ` As you can see semantic versioning is supported and works similarly to NPM. Publishing packages If you want to publish a package to JSR, there are many important rules you need to be aware of. I recommend reading “Publishing packages” before moving forward with this. The main things to note are: ESModules only, npm packages are supported, JSR packages are supported, and node APIs are supported. So there aren’t many constraints. You just need to understand how exactly to do these things. IE: how do I use NPM dependencies, how do the imports work, etc? Once you’ve got all that down, you will be ready to publish your first package to JSR 😃 Documentation JSR emphasizes quality package documentation. It’s one of the factors in their package scoring algorithm, which we will discuss shortly. The important parts of a package’s documentation include: * a README.md file * symbol documentation - functions, interfaces, classes, etc * module documentation - docs for each exported module in a package The symbol and module documentation are written using JSDoc. The JSR website generates some nice documentation based on these 3 pieces on your package page. This means you can understand a package's entire public API without ever leaving jsr.io. Browser support The cross-runtime support is amazing, but I was curious where the original JavaScript runtime fit (the browser). According to the documentation: “You can use JSR with any tool that supports ES modules, and either has native support for JSR or supports npm packages using node_modules.” Since modern web browsers support ES modules, I will count this as JSR support. From what I can tell, though, there is one caveat. To include a module on a web page, we need a URL to download it from. Can we publish our package to JSR and use it to load a module via a script tag? According to the JSR usage policy, no. The “Unacceptable use” section states: “It is not acceptable to use JSR as a CDN for serving assets directly to web applications in a browser, except for development purposes.” So, it seems that this is a no-go for now. We will probably need to wait a bit for CDN services like jsdelivr to pull packages from the JSR registry, similar to what they do with NPM currently. Other notable features We’ve covered the most important bits about package management, TS support, NPM compatibility, etc. But there are still a few unique features that add an extra bit of sparkle to JSR. Scoring We mentioned earlier that documentation plays a part in a scoring algorithm. JSR analyzes all of the packages published to its registry and assigns them a score based on certain criteria: documentation, best practices, discoverability, and compatibility. This score is shown with every package listed on the website. You can also add a shiny badge to your README if you’re particularly proud of something. It’s still early on, so it’s likely this will evolve as time goes on. It’s an interesting gimmick, at the very least! Summary I am excited to have a new cross-platform compatible package manager that only supports ESM. As useful as NPM has been all these years, it carries a lot of baggage from “the olden days”. JSR’s native TypeScript support and reliance on modern standards is a breath of fresh air. It feels like I can publish a simple package without much ceremony. I’m excited to release my first package to JSR soon :)...

Apr 12, 2024

6 mins

JSRJavaScript

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes Introduction: Next.js, a powerful React framework, offers two essential features - Parallel Routes and Intercepting Routes - that enable developers to create highly dynamic and seamless user experiences in their applications. In this blog post, we will explore both Parallel Routes and Intercepting Routes, highlighting their functionalities, use cases, and how they can be combined to enhance application routing. What are Parallel Routes? Parallel Routes in Next.js allow the rendering of multiple pages within a shared layout. Rather than navigating to a completely separate page, Parallel Routes enable the simultaneous rendering of different pages based on certain conditions such as user roles or tab navigation. By leveraging named slots, defined using the @folder convention, multiple pages can be seamlessly integrated into a single layout, enhancing user experience and reducing code duplication. How to Use Parallel Routes: To utilize Parallel Routes in Next.js, you must define named slots for the desired pages within your application's folder structure. These slots are then passed as props to a shared parent layout component. For example, consider a social networking application where two pages, feed and notifications, must be rendered within a common layout. You can define Parallel Routes using the following structure: ` The layout component in app/layout.js will accept the @feed and @notifications slots as props and render them alongside the children prop. Here's an example of the layout component: ` It's important to note that slots do not affect the URL structure and are not considered route segments. This means the URL would be /mypage/@feed/views for a route like /mypage/views since @feed is a slot. Also, to prevent the application from rendering nothing or throwing an error, we could use the default.tsx file: ` In this example, the default.tsx file specifies the default content (or fallback) to render when none of the named slots match the current route. It acts as a catch-all for routes without a corresponding slot. Some Use Cases: *Conditional Routes:* Parallel Routes can conditionally render routes based on certain conditions, such as user roles. For example, you can render a different dashboard page for admins and users. This can be achieved by creating a layout component specific to the dashboard and checking the user role to determine which slot to render. *Tab Groups:* You can utilize Parallel Routes to create tabbed navigation within a section. This is especially useful for analytics or multi-page views. Adding a layout inside a slot allows users to navigate between different pages within that slot independently. *Loading and Error UI:* Parallel Routes can be independently streamed, allowing you to define custom error and loading states for each route. This enables better control over the user experience by providing distinct feedback for different app sections. *Modals:* Parallel Routes can be combined with Intercepting Routes to create modals with shareable URLs, preserved context on refresh, and customized navigation behavior. By intercepting certain routes and rendering them within a modal component, you can create a seamless modal experience. Understanding Intercepting Routes: Intercepting Routes in Next.js allows you to load content from another route within the current layout without changing the URL or refreshing the page. Using the (..) Convention: Intercepting routes are defined using the (..) convention, which is similar to the relative path convention ../ but for route segments. The convention allows for matching segments on the same level (.), one level above (..), two levels above (..)(..), or from the root app directory (...). For example, to intercept the photo segment from within the feed segment, you can create a (..)photo directory. Integrating Intercepting Routes with Parallel Routes - Modals: One powerful use case for Intercepting Routes is creating modals, which can be combined with Parallel Routes to solve common challenges such as making the modal content shareable through a URL, preserving context on page refresh, and handling backward and forward navigation. Let's make an example: ` Our folder structure will be: In this example, when a user clicks on a photo within the /gallery page, the route /photo/:photoId will be intercepted and rendered within the (..)photo directory, overlaying the gallery content. This means that the photo route is only one segment level higher despite being two file-system levels higher. In the example above, the path to the photo segment can use the (..) matcher since @modal is a slot and not a segment. Common Use Cases - Beyond Modals: Intercepting Routes can also be utilized in other scenarios. Some examples include opening a login modal in a top navbar while having a dedicated /login page, or opening a shopping cart in a side modal for better accessibility or creating wizards or multi-step forms within a single page. The possibilities are endless. Conclusion Next.js Parallel and Intercepting Routes offer powerful methods for enhancing the routing capabilities of your applications. With Parallel Routes, multiple pages can be seamlessly integrated within a shared layout, simplifying navigation and enhancing user experience. By incorporating Intercepting Routes, you can create dynamic overlays like modals, enabling content from different routes to be displayed within the current layout. By leveraging these features, you can unlock exciting possibilities and take your Next.js applications to new heights of user engagement....

Apr 5, 2024

3 mins

NextJSJavaScript

Intro to DevRel: 5 Reasons Why DevRel Teams Fail

Although Developer Relations (DevRel) defies traditional marketing strategies, prioritizing enhancing developer satisfaction ahead of promoting numbers that contribute to a sales funnel, it is still possible for DevRel teams to fail at delivering desired business objectives. And unfortunately, more often than not, this leads to the dissolution of DevRel efforts, and sometimes even role elimination. Below, I’ve compiled a list of five of the top reasons why DevRel teams fail. 1. Lack of Leadership Buy-In DevRel requires buy-in and support from executives and stakeholders within the company. Without buy-in, being able to work cross-functionally across the organization, get access to data needed for measuring success, have the ability to influence change within the organization, or get the budget for necessary activities to engage developers will be impossible. I asked Jason Lengstorf, the host and founder of Learn With Jason and previously on the Developer Relations team at Netlify and Gatsby, where he has seen companies fail at DevRel before: “Companies that want to invest in DevRel can collect as many well-known developers as they can, but giving them zero dollars and zero autonomy will force teams to rage quit or become content farms because that’s all you can do with no budget.” Other examples are departments not willing to share or give data that helps enable DevRel to understand the metrics they need to effectively baseline and track the success of their efforts. By not doing so, the DevRel team will not be able to justify their work to leadership, which will lead to those positions being cut first when budget cuts come around. Chris Woodruff, Founder of Advocatus, a Developer Relations consultancy, says “DevRel is seeing a lot of layoffs. It’s the easiest team for management to let go because they don’t fully understand the ROI and metrics. These are the holy grails of DevRel, and because they do not understand, they will always be the first teams to let go if management can’t see the actual return or how it affects the bottom line.” 2. Company Culture Fit If an organization's culture does not value collaboration and resists the presence of a DevRel team, DevRel will not be able to effectively advocate for developers or help teams be more successful with their target audience. Francesco Tisiot, Senior Developer Advocate at Aiven, an open-source data platform that makes setting up cloud databases simple, shared one of his experiences in his Developer Relations career. “I was one of the first DevRel hires in a company and we were in the marketing organization. Initially, there was pushback from engineering and product teams on our product feedback and feature requests since we weren't seen as experts. But, DevRel is about breaking barriers and building bridges, so, in leading by example, we demonstrated our technical knowledge and now have a strong impact on all the teams.” Michael Liendo, Senior Developer Advocate at AWS, an online platform by Amazon that provides scalable and cost-effective cloud computing solutions, shared how he was able to find the company culture fit within organizations he has served in the past. Being in a position of Developer Advocacy, and quite literally trying to advocate for developers that use the platform, he says, “Some of the biggest challenges for DevRel are actually internal. Engineers at many companies often focus on one piece of the product. As they're testing features, they may be creating workarounds without realizing they're workarounds. This means they often miss what a proper Developer Experience flow looks like. I've had to push for them to include me in design meetings, and get them to understand that I'm the Lorax--I speak for the community! A phrase I have been known to say is ‘this solves the problem, but it's not a solution’. I'm known for having a high bar for what is considered ‘good enough’ and though the end result is accumulated trust, it's a challenge to get there.” 3. Operating in Isolation DevRel cannot operate in isolation without integration with development, marketing, product teams, sales, or a subset of these. The team will struggle to make a significant impact. DevRel requires a collaborative approach and alignment and synergy with other teams. Francesco Ciulla, Developer Advocate at daily.dev, a professional network for developers that provides the latest tech news and articles, shares his thoughts on how DevRel organizations can be successful within larger organizations: “DevRel organizations can thrive within larger organizations by establishing clear communication channels and fostering meaningful collaborations. They must align their objectives with the company's goals and illustrate their value by sharing tangible outcomes from developer engagement.” 4. Lack of Strategy Proceeding into DevRel without a clear strategy will make it difficult for a DevRel team to establish its purpose within an organization and set priorities that will make an impact. There will not be a clear vision the team can drive towards, leading to wasted efforts and the inability to produce tangible outcomes. If DevRel does not have any goals set, they can only do their best to assume what efforts they should invest in to provide value to the organization. Worst yet, if they do not have any goals set, they may not choose to focus on providing value to the organization, but to a community that the organization has no interest in. Many DevRel experts have seen this happen time and time again in the community, and are always left scratching our heads. Many times, the “strategy” for an organization is to hire DevRel, but that is where the strategy stops. Decision-makers want DevRel professionals to come in and just “do what they do best”. Unfortunately, when decision-makers say this, they typically have an idea of what outcomes they want DevRel to drive, but don’t want to share those thoughts because they feel like DevRel professionals should know what to do. Expectations left open to interpretation often lead to a poor impression of the performance of the DevRel team by decision-makers, and those teams are never able to establish a sense of trust or direction within that organization. Jeremy Meiss, former Director of Developer Relations at CircleCI, says, “One of the biggest problems we have seen in this industry is the startups that were counseled by their VC, founders, or board that they need a DevRel team because the other similar companies had one and it was great for them. They push for it, and one of the early hires is DevRel. Generally, that DevRel hire is someone relatively new in the industry, so you can coax them to start at a new company without clear goals or objectives. New hires like this come in without a lot of experience in the field of DevRel and have not experienced it at different levels of companies. They are heavily pushed by marketing, the CEO, the CTO, and other departments into thinking DevRel should look a certain way, but don’t have the foundational knowledge to be able to push back because they are not yet in this area.” Jeremy’s illustrative explanation of why a lack of strategy ultimately results in the failure of a DevRel team within an organization is one that is common across many devtool startups that have popped up in recent years. 5. Lack of Metrics and Reporting A well-rounded set of DevRel metrics typically comes from multiple areas of the organization, whether that be marketing, sales, product, customer success, or customer support. Without free access to cross-functional team data, it is difficult to show the value and ROI of DevRel. Establishing a baseline set of metrics if you’re new within an organization, or understanding the baseline metrics that currently exist is critical in ensuring the success of your job in DevRel. Tessa Mero, Head of Developer Relations at Appwrite, has a very specific set of metrics her team focuses on. She shared a few of those metrics: - Growth of our GitHub Repo (stars) - Growth of our Discord Community - Improved engagement in Discord community - Growth of our Twitter followers and engagement - Growth of our Appwrite Cloud developers - Number of views or impressions on any video and written content, whether it's internal or externally created - Amount of content created weekly (written or video) - Number of projects created with Appwrite for Hackathon sponsorships - Number of attendees / questions at a conference talk - Number of connections at conferences - Number of community support questions answered, improving rate of responses AND rate of how fast we respond, in all public forums - Number of support tickets responded to - Number of community feedback taken and moved into our DX/Product discussions - Number of feedback from UI/UX perspectives and working with design team to follow up with the devs/users with what we did with the feedback - Number of engagement/activity from our Appwrite heroes/ambassadors This is just one example of and a subset of metrics a DevRel team should consider tracking, but what you track and how you track it is dependent on your goals and the product. Metrics and what your leadership considers a good ROI can vary greatly from organization to organization. I spoke to another Developer Relations expert in the industry and she shared her experience with the company she just left and the reason she left - and it was focused around metrics. She was initially interested in joining the team because of the lack of metrics. However, over time, as she got more experience and as she became more visible, her workload became difficult to prioritize. Since there were no metrics, there were no objectives to measure against to say what was good and what was bad. She felt like she didn’t know what she was doing well or not doing well. Once metrics began to be implemented, the company started pushing her to do more, and she had nothing to push back with because the high-level goals were not there. There was no way to prioritize the workload. The company started tracking things like page hits, unique visitors, unique views of videos, number of subscribers, activity on twitter, and other similar numbers, but it was hard to tie any of these back to the ROI for the company. How do you quantify and determine if 100 new subscribers on YouTube is better than 100 new subscribers on twitter? If you can’t quantify it, how do you prioritize it? What Successful DevRel Teams Do Differently With the nature of DevRel and the multitude of levers and factors that determine success and failure, it’s important to allow space for a team or set of individuals to experiment and iterate before making judgment calls. One company that serves millions of developers on its platform is starting up a new meetup program and testing the ROI of sponsoring meetups around the world. Since they are in the testing and experimentation phase, they don’t yet know how to measure success, and that is clear to leadership. The current strategy is sponsoring local meetups for a few months and seeing what the result is. Why are they so seemingly laid back in their approach? Is it the right approach? The reason for the relaxed nature of the testing phase is that they don’t want to be pushy to the meetup organizer to find something out or measure something. They are not expecting anything, but will evaluate what metrics they could use to establish success criteria. This approach is a thoughtful and empathetic one, and clearly, the DevRel team has an understanding of how to approach community members in a way that will not turn them off. Internally, the simple numbers they are looking at are the number of RSVPs, the number of attendees that show up, and the difference between the two. DevRel is naturally iterative and requires a team to experiment, test, and refine their strategies. Effectively engaging developers is not black and white, and a strategy that works for one community or company may not necessarily work for another. Furthermore, building domain expertise and gaining a deep understanding of the developer community they serve takes time. Experimentation and iteration help teams refine their knowledge, identify patterns, and develop strategies that resonate with developers. This expertise becomes an asset in driving long-term success. It’s also important to acknowledge that building domain expertise within a segment as well as building relationships and trust with developers in that segment takes time. The technology landscape changes quickly and new technologies are being released weekly. Developer sentiment is fickle and changes just as quickly regarding favored approaches and products. That being said, the above pitfalls remain common causes for DevRel teams to fail, and by remaining mindful of and vigilant against them, DevRel teams both new and old can succeed in supporting key business objectives like developer retention, community growth, and product development....

Feb 14, 2024

9 mins

DevRel

Improving INP in React and Next.js

Improving INP in React and Next.js In one of my previous articles, I've explained what INP is, how it works, and how it may affect your website. I also promised you to follow up with more concrete advice on how to improve your INP in your favorite framework. This is the follow-up article, where I'll focus on how to improve your INP score in React and Next.js. How to prepare for INP in React and Next.js? The first thing to do is to ensure you're using the latest version of React. The React team has been working on making React more INP-friendly and has already made some improvements in the latest versions. To enhance your INP score, consider fully taking advantage of new features introduced in React 18, such as Concurrent Rendering, Automatic Batching, and Selective Hydration. However, there are also some general areas to focus on, such as SSR and SSG in Next.js, Web Workers, or optimizing your hooks and state management. Concurrent Rendering The Concurrent Mode in React uses an algorithm that breaks rendering down into so-called "fiber nodes" and schedules the renders based on their expiration and priority. This effectively allows the user to interact with the page while the rendering is still in progress. In previous React versions, all updates, such as setState calls were treated as "urgent" and once the re-render had started, there was no way to interrupt it. Concurrent Mode changes this by being able to prioritize the updates and interrupt a non-blocking state update started with startTransition. For a simple explanation of concurrency in React, you can check out Dan Abramov's explanation. As part of the Concurrent Mode, React introduced several lifecycle methods that allow you to prioritize the rendering of certain parts of your UI, such as: - useTransition hook that allows you to update the state without blocking the UI, - useDeferredValue hook that allows you to defer the rendering of certain parts of your UI, - startTransition API that, similarly to the useTransition hook lets you mark a state update as non-blocking. It lacks, however, an indication of whether it's still pending. Automatic Batching Introduced in React 18, Automatic Batching reduces the number of re-renders that happen on state changes even when they happen outside of event handlers, e.g. in a setTimeout or Promise callback. This feature comes out of the box and you don't have to do anything to enable it, and it makes a great argument for upgrading to React 18. Selective Hydration Selective Hydration allows you to take hydration off the main thread by wrapping your components in a Suspense boundary. This way, components can become interactive faster as the browser can do other work on the main thread while the hydration is happening. To fully take advantage of selective hydration, consider the following: - Prioritizing Above-the-Fold Content: Use Suspense boundaries strategically around any parts of your application that may take the server longer to deliver to ensure they don’t block critical content from becoming interactive as soon as possible. - Hydration on Interaction: Implementing hydration upon user interaction for non-critical components can drastically reduce the main thread's workload, enhancing INP. Vercel even has a small case study showing how using selective hydration improved the performance of a Next.js site. Server-Side Rendering (SSR) and Static Site Generation (SSG) in Next.js Not everything has to run client-side. Next.js excels in SSR and SSG capabilities, which can significantly impact INP by delivering content to users faster. Optimizing SSR with techniques like incremental static regeneration (ISR) or leveraging SSG for static pages ensures that users can interact with content faster, improving the perceived performance. Workers Offloading heavy computations to Web Workers can free up the main thread, enhancing the responsiveness of React and Next.js applications. This strategy is especially useful when dealing with third-party scripts. Offloading such scripts in Next.js can be easily done by specifying the "worker" strategy on your Script component. Be aware that this feature is not yet stable and does not work with the app directory, though. If you want to take things one step further, you could use Partytown, which helps you offload any resource-intensive scripts to Web Workers. It comes with a React component that you can use to wrap your third-party scripts and offload them to a Web Worker, and it's compatible with Next.js as well. Hooks and State Management State management in React applications can easily get out of hand, leading to unnecessary re-renders and effectively an increased INP. Sometimes, using a state management library like Redux or MobX can help you consolidate your state and reduce the number of re-renders. However, they are not silver bullets and can also introduce performance issues if not used properly. If you are dealing with a lot of re-renders due to prop changes, make sure you are leveraging memoization. As of now, you may need to work with useMemo and useCallback hooks to memoize your values and functions, respectively. The upcoming React 19’s Forget Compiler, however, will apparently memoize everything under the hood, making these hooks obsolete. Using memoization properly can help you reduce the number of re-renders and improve your INP. To investigate your hook dependencies and re-renders, you can leverage React Developer Tools or use this handy helper hook I found on the internet to trace your re-renders: ` Conclusion Improving INP in React and Next.js is not easy and can require much investigation and fine-tuning. Still, it's worth doing to avoid being penalized by Google in its search results and provide a better experience for your users. Adopting React 18's new features, leveraging SSR and SSG in Next.js, utilizing Web Workers, and optimizing hooks and state management can significantly boost your INP score and deliver a faster application to your users. Remember, INP is just one among many performance metrics emphasizing the need for a comprehensive approach to performance optimization...

Apr 19, 2024

5 mins

Web PerformanceReactNextJSJavaScript

Double Click: Try Out the New Releases for jQuery UI & Lit

Tracy Lee

You might also like

JSR - The cross-platform package manager for ESM

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

Intro to DevRel: 5 Reasons Why DevRel Teams Fail

Improving INP in React and Next.js

You might also like

JSR - The cross-platform package manager for ESM

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

Intro to DevRel: 5 Reasons Why DevRel Teams Fail

Improving INP in React and Next.js