The hype of the 2010s is over. Frontend development is not that hot anymore. The SPA revolution is gone, React won and became a server side framework apparently. Reactive state updates don’t get anyone excited anymore, Redux became boring (including the Toolkit, sorry), we can now write CSS in all languages imaginable and unit test it to our heart’s content. GraphQL became a curse word for some people. And the list goes on. Also many of us got jaded by the soulless hype machine so Signals, Runes, HMTX or Server Actions don’t ignite the same spark in a lot of us.

So what do we do now? I think this is a perfect opportunity to take a step back and critically evaluate what we have been really doing while riding the hype train of the last decade and some. What did we achieve while learning all the hot stuff and what can we take away to do better in this current decade? Maybe frontend was always about more than what the industry put in our focus?

Innovation hasn’t stopped of course and I will share my views on what are the most influential current trends, but now I want us to think about some more fundamental questions:

• What’s the real point of working on the frontend?

• What are the problems we are really supposed to solve?

• What’s the real value add of frontend engineers? In other words, what will prevent us from being replaced by sophisticated Figma to React tools?

What’s The Point of Doing Frontend?

It’s a crucial question, that we are honestly not conscious enough about as the FE community. Let’s clear this up once and for all. In my mental model, frontend has 2 pivotal roles:

• It acts as an interface to the value provided by the backend systems. The frontend can block, hinder, deliver or enhance that value.

• It adds its own unique features, that’s impossible to be created at any other point of network based applications.

We, frontend developers, work to create and deliver these two things. (Besides the meta-goal of improving work effectiveness and efficiency itself.)

Many recent innovations like Next.js API routes/handlers, RSCs or the Remix “paradigm” of loaders and actions fall into the first category, helping us in more effectively surfacing the value of the BE systems. Even the Qwik style 0 hydration, instant-on applications belong to this category as the application itself is initially “value provided by the BE (host) system”. Hyperfiddle takes this to the next level with compiler-level networking built into the apps. This space is still dynamically evolving. I think even more than the other category. Just think Prisma, or Drizzle.

Unique to the client value is less hot, but still going strong today, first things coming to mind are the View Transitions API, Container Queries or anything related to styling, accessibility, information architecture, SEO, observability or UX in general. Another, now well-established tool I learned to love during the recent years in this space is framer-motion.

To identify the specific value that any given frontend creates we need to identify the contents of these 2 broad categories for that given project.

The definition of “value” is a very contended one and I see a lot of developers who don’t understand it deeply. In the Full Context perspective I use the following form which I think captures the essence quite well: Value is anything that solves a real life problem of the users, that helps to achieve the mission of the businesses or that helps to reach the personal goals of the developers and other colleagues.

Customer experience, company mission and developer experience are some of the key reasons why we should be writing frontend code.

So let’s lay it out plain and simple. It all boils down to how your work helps with the matrix of:

(CX || Mission || DX) x ( BE Value || FE Value)

Here are some examples of what these categories could mean for a frontend developer:

• Delivering BE value:

  • CX: Make the customer more happy with things like optimistic updates or streaming HTML responses, or a local first/offline first approach to enrich the BE capabilities. Improve request/response times by minimizing both the payload and the requested data. Understand your APIs and the http/websocket protocols deeply to improve performance and security.

  • Mission: A baseline example is meeting a feature requirement by integrating with an API, like adopting a new payment provider to enter a new market. More BE aspects related to mission are: achieving a non-functional requirement like https for regulatory compliance or even simpler stuff like setting up a proper cross domain policy across systems.

  • DX: Make work easier and more fun for both BE and FE engineers by adopting contract testing via Pact or by using tRPC to streamline communication. Maybe generating some TypeScript types from OpenAPI specifications, perhaps reusing validation logic or other code bits across the network divide.

• Adding unique FE value:

  • CX: Better SEO, more accessibility, better rendering performance, fancier buttons, instantaneous UI feedback on interactions, meaningful error messages, well timed tips or recommendations.

  • Mission: The baseline example is similar here too: enabling delivery of a feature requirement by integrating a client-side tool/technique like: localization or branding/theming support to reach the target audience. It could also be about meeting non-functional requirements, like collecting analytics data to gain more user-insight (Snowplow SDK?).

  • DX: QwikCity, SolidStart, Astro, React Router v7 public-alpha, or simply ditch Webpack for Vite. Anything that the hype-train hauls our way. In all seriousness, anything that makes the codebase easier to understand and easier to change are the big wins here. Improving consistency, removing redundancy, eliminating flakiness and increasing productivity is the name of the game.

    Thanks for reading Full Context Development! Subscribe for free to receive new posts and support my work.

What Are The Problems We Are Supposed To Solve?

If you take this idea one step further, we are really doing all of this for the people who are interacting with the code/software we deliver. Working on the frontend could become a human-centric activity, even with its technical & abstract nature, if we ultimately focus on those interactions and their impact on the lives of others.

This sits at the heart of the Full Context approach too, the Beyond You idea, could be interpreted as: look at what would make the people from the 3 domains - business stakeholders, coworkers and users - love the software more. That’s our real job as frontend developers or in general as software engineers, to deliver improvements that will:

• Make our company more profitable - so that business stakeholders will love it more.

• Make our users’ lives better - so that customers will love and use it more.

• Make our colleagues’ lives easier - so that your teammates will be happier and love their job a little more.

What do those problems look like in our FE dev day to day lives?

It all comes down to knowing the goals and pain points of the people from the 3 main groups. What makes the lives of the users, colleagues or business stakeholders hard at the moment, what are the inefficiencies or unmet needs?

There are many ways to tackle this, but one super helpful tool I have up my sleeve is the 15 Product Qualities. All 3 dimensions can interpret software as a product in their own domain and map the Product Quality attributes to actionable insights that can guide a frontend developer or technical leader in finding the highest impact problems to tackle.

As this is very broad in scope (at least 45 aspects to think about…) I won’t repeat the mistake I’ve committed several times in the past and attempt to cover all of them here. Instead I will simply share 3 common issues that I believe have the highest chance to help you make some noticeable impact at your job… right as I cover the next big question:

What’s The Real Value Add Of Frontend Engineers?

Our coding ability is not the most important skill that we have! I would argue that’s just a baseline requirement. Where you should really focus on to make significant impact is finding the places where your unique professional and technical insights meet with the questions or needs of the people from the other dimensions and use it to answer/solve them in a way they could never achieve without your insights. That’s the true value add of any frontend or rather any software engineer and it won’t be replicated by code generating tools any time soon! Let’s see some tangible examples.

Three high-impact areas where frontend developers can really shine

1. Making collaborative decisions about what is the best place for data or computation. Putting a piece of information on any of the following places: client memory, browser cache, service worker, CDN, edge infra, a message queue or database, has tremendous user-experience, cost, and architectural implications and we can lead or contribute to these discussions in very meaningful ways. Same is true for computation, you can suggest where something is best calculated at and how often. All these decisions require a deep understanding of the project’s context and can steer it towards success or failure in major ways.

   Personal example: In 2019 I was tasked with leading the frontend project setup of Gradyent AI, a web app that optimizes district heating networks with a digital twin (AI). One of the fundamental decisions to make was to decide how to render the interactive map displaying the near real-time properties of the heating networks. The company’s founder brought in a map expert consultant and the stack they were pushing for was BE focused both in terms of storage and computation. That’s until I’ve found DeckGL. I convinced the founder and the consultant that rendering the interactive map on the client is the best move for us both in terms of infra costs, available skills in-house and user experience. I think it’s one of the key technical driving forces of the success of this application to this day!

2. Making collaborative decisions about logging and analytics, that cuts to the heart of what happens, or covers unusual events the other colleagues couldn’t even think about. This requires your to understand the real life usage of the product as well as the perspective of key business stakeholders but is also an area where you have unique insights into the situations the frontend code can end up in, that’s often only visible to you, the developer. Should that case be visible in the logs/metrics? With what data? And what does it tell to the business stakeholders when it happens? Should it be reported on dashboards or alerts? All questions that you can raise and find the answers to, together with colleagues from other areas. In my experience, it’s often very helpful to increase your exposure/visibility, to deepen your understanding of the business domain and to make a better product, a win-win (3x)!

   Personal example: When I implemented my own online product fullcontextdevelopment.com I’ve tried to log every error case in a way that’s emphatic and action oriented for end users. Not long after launching the product, I got a DM on X (Twitter at the time) from one of the first customers about them facing an issue with signup. It was very embarrassing, as the payment was taken but their account wasn’t activated. However they told me they were impressed by the error message, something along the lines of: “Sorry to fail you at the critical time of the first login! Don’t worry however, your payment was safely processed, this is an issue on our end, if it doesn’t resolve after a few more retries please reach out to support (link)”. One of the most memorable, organic appreciation that the extra effort I’ve put in ever received from someone who is not a colleague.

3. Making collaborative decisions about improving the UX/UI design. You as a developer might offer alternative approaches to the look and feel of the product that make more sense from some perspective. Often it’s about reuse, how to reuse or just slight tweak something-already-existing to achieve the same goal but for 20% of the effort. Another common topic is consistency, sometimes designs are made in isolation, but in the context of the whole application/site it might make sense to just stick to an already established pattern. You might be more familiar with those, bringing that perspective to the discussions. Frontend devs can also often shine a light on unhandled edge cases. What should we do when the network fails? What about a retry? What should happen while the request is in-flight?

   Personal example: While working at Snowplow I was developing a wizard style, multi-step form for setting up a connection to different cloud storage solutions. As I was using it during development and went through the steps countless times I’ve realized, if we changed the UI a bit we could get to the same result while reducing the number of questions by 1/3. I’ve set up a call with the designer, explained my idea and got the green light right away. We both were happy about the outcome, and as an extra benefit this whole process helped in building a good working relationship between us while also improving the product for the end users.

Final Words

Hope this gives you some inspiration to look for ways to put your unique frontend skills and insights into good use! Let me know in the comments a story of how you did that, or what other techniques you have to make an impact. I believe by shifting our focus on the outcomes of our decisions rather than the options that we can choose from, we will make the next decade of frontend development better for everyone!

And now let’s get back to writing code that makes someone love the software even more!

Hi Web Perf Piranhas

(yes this will be the theme here, it will also make sense later)

In this chapter I will share something profound that fundamentally changed the way I look at web performance. There is a Next.js app that’s objectively the most performant of them all. (And I wrote it! 😎 But you can too!)

What does that mean? It means we actually have an objective goal! Unlike with most things real-life, we know for certain what’s the ideal we are supposed to aim for as web performance engineers. And that’s great news, it will make our jobs way less ambiguous!

I know it doesn’t make much sense so let’s put an end to the intro. Here is the Fastest Next.js Website of The Galaxy! And here is the source code too! Take a good look and if you are confused about what you see (or don’t see) come back here and continue down below.

That’s right, it’s an empty page with the least amount of HTML I could squeeze out of a Next.js build. If you feel cheated or let down I get it, but believe me, whatever you feel, if you had any emotional reaction at all, that feeling will actually help to make this lesson the more memorable and this worths remembering for sure!

Most of you already know that web performance is a tradeoff. But what the fastest web app of the galaxy can help us realize, is that we have to sacrifice everything our sites have in order to achieve ultimate performance! This is a transformative realization with deep implications. Let’s unpack it!

That means we should eat away the meat of the websites we work on like a hungry pack of piranhas! This idea might not feel right, it might not seem useful, but it actually is when you learn to utilize it!

Every technique we employ to improve web performance is making our website either permanently or temporarily (that’s when we do clever stuff) more alike the ideal website!

Just think about what cutting the page up into multiple chunks and delaying their loading really does. Or what the downscaled placeholder images do to our initial bundles. What’s the practical result of caching resources? That’s right, all of these techniques make our websites in certain situations more like the fastest website of all.

The more you are willing to sacrifice to make your website resemble that ideal form the better performance you will get! The more you deviate from it, the more performance will suffer. It’s a cold, hard truth we have to accept as web performance engineers.

Our work is all about finding the optimal way to minimize the difference between the empty website and ours, and making the price to be paid acceptable. These guides will teach you how to find the right balance in your specific situation.

🧠 Performance Mindset

This is a lesson that’s extremely important to really ingrain a performance mindset in us. The conclusion: become the bloodthirsty web perf piranha you are supposed to be and eat up those sites with endless appetite.

If you enjoyed this chapter check out the full table of contents for the series!

Hey Full Context Developer

(I’m writing in a personal quality, opinions are mine and are not reflective of Tesco’s)

This is Part 2 of my interview with Hugo Jobling a Principal SWE and colleague of mine at Tesco.

You can find Part 1 here where we talked about his career, what it’s like to develop software for this company and his experiences using React for over a decade.

In this final part we discuss his opinion about Remix, that he signed up for as soon as it went public - for a license fee back then - and used ever since. We also share some insights about an app it powers in nearly 2k Tesco stores in the UK. Let’s jump into it!

🎛️ Remix

- Learnings from buying the license at day one to using it in production

Joe: I think it’s fair to say that early adoption of the right technology can open the door to rare and valuable career options. It definitely paid out for you. But you also bet on Remix very early. Can you tell me a little bit about how that happened?

Hugo: I guess part of it is just like cultivating taste. It’s the same as with movies or music. There are people who have good taste and then they recommend things that are also good, right?

As you start to watch more good movies, you start to have an appreciation more of what is a good movie and what isn't. I think you can do the same thing with technologies.

Joe: That’s a really interesting analogy I haven’t heard before but thinking about it, it makes a lot of sense!

Hugo: Or take directors for example. There are certain directors who I know, if they make a film, it's probably going to be a decent film. The same thing happens in the JavaScript space. After a period of time, you start to hear the same names come out again and again. A few years ago Pete Hunt was a name you would hear about in the React space or Dan Abramov or Kent C. Dodds.

Joe: Yeah, all the classic React names, I’m very familiar with them too. So would you agree if I sum this up as “To cultivate a great tech taste all you have to do is follow the right people”?

Hugo: That sounds about right. One of the things that resulted in me making an early bet on Remix, is it's Ryan for a start! Ryan Florence is a known quantity in the React space. And actually, he's another one of those characters who I first encountered in the Ember community, and then he moved across to the React space. I think this is another one of those interesting tech envy things, right?

The React frameworks now are doing stuff that Ember was doing 10 years ago. The idea of routing and data fetching as first-class concepts is not new. That was around back in the Backbone days. And we're just rediscovering that those things were a good idea before and they're a good idea now.

I saw Ryan and Michael be like, hey, we're going to make a framework that's based on some of the concepts of how we've been thinking about React Router. You can buy an early adopter license for $200, and you'll get a hoodie. And I was like, early adopter license, day one, give it to me. So I signed up, started playing with it. And while using it, I was like, you know what? This has some good ideas. Having built and worked with large scale React applications for years, you realize, as everybody realizes, that it's called Create React App, it's not called Maintain React App. And there's a reason for that, right?

Joe: That one always cracks me up. It’s spot on!

Hugo: Yeah, there comes a certain point where that won't take you any further. There was a big period of time where your next step was custom Webpack config. There was no good next natural evolution. And then there was a period of time after that where for a certain class of application, there was a really good answer for that problem. And it was Next.js.

But the problem with Next.js that I found was that it wanted you to be building content websites.

So you're building Hulu, it's really good for Hulu because the primitives they needed were hooked into the framework. Next.js was really good for doing a single data fetch to load up the page and then display a bunch of stuff on it. But where it always fell down was, now I've got some user generated data on the application and I need to get that back to the server.

Next.js did not really have that good a story for it so you end up having to build custom API routes to be able to post data back to the server. Then you get into this whole mess of, OK, now I've got to pick a form library, and I've got to build an API route for every single page I've built.

There's a mismatch between how I'm getting the data onto the page and where it's going once it's on the page. So what I really liked about the conceptual model and the philosophy behind Remix was that they saw that gap. They realized that a huge proportion of web applications are mostly tables and forms. So they said: let's build a really good story behind tables and forms.

And then they went one little step further as well. In the last few years, the web platform has come up with good primitives for how you do this stuff. So you have the Fetch API, you have a capital-R Request, capital-R Response. And so we can build a framework around those core primitives that in addition to having a good answer to how do I get my form fields back to my database, doesn’t make you learn another framework’s own way of doing things. You're just using the stuff you already know. You already know fetch, Remix simply gives you a way to hook it into your application.

Joe: These are some really important observations and very good advice for people looking to adopt Remix. I’ve written about the framework extensively on my previous blog and my take was very similar.

Remix is best fit for web apps centered around users not only fetching but interacting with data that lives in a database. That’s the use-case where it can really shine.

Hugo: So again, it's a trade-off. If you're building Google Docs, you have to deal with the fact that two people on the other side of the world need to be able to edit the document at the same time. In order to get the performance, reliability etc… you needed, you had to make your back end much more complicated. And you had to invest in having a bigger team of people. If you are building that type of product, you're going to have to bite that bullet. But if you're not building that application, if you're building for example CRM systems internally at companies you're doing just basic stuff, or you're building a point-of-sale system that lives on the same physical device as the APIs, you have a different set of constraints. And so picking a technology designed to solve somebody else's problem makes you bite off all the complexity without reaping the benefits because you don't need those benefits.

The reason that I look at tools like Remix for our problem space is that its baseline is assuming you don't have all these Facebook or Google scale problems. It has more of a progressive enhancement approach. What the baseline experience assumes is, just load all the data to the page at the top of the page and render the entire page.

And then if it turns out, hey, that's too slow, Remix has the escape hatch, the concept of deferred data where if you can say, these 3 bits of data need to be loaded for the page to render, but this one can wait. Then the page can get that as a Promise, put it in a Suspense component. And then it works hand in hand with the built-in concepts in React. It's just a thing that React already supports and gives you the way to show a loading spinner for a period of time after the page is loaded. You can build that, but the default is not that every part of the experience has all these complications.

With Remix you only get the complexity where you need the complexity.

When I worked with Apollo GraphQL type applications, I was looking at a page and I had to ask. How did the data get on this page? Where does that come from? I have to look at every component on the page to find out what components specify the data it needed. Whereas, when you go to a Remix codebase, I just find the URL then I find the root component that matches that URL. That's where the data came from. Very conceptually simple. Another can of worms is async behavior inside of a useEffect which absolutely sucks. It's a nightmare to work with. And this is why, again, I like the Remix data fetching because it pushes that stuff outside of React, into a loader which is just normal JavaScript async/await code. And so you don't have to worry about useEffect and all of that nonsense inside. You can have nice clean components.

I tend to think: I'm not that smart. I want things to be simple, and I want the tools to make me look smarter than I am. When I work on a Remix application, I'm really productive because when I'm following the happy path, the pit of success, it pushes you along like a tailwind.

Joe: That’s the feeling we all want to get from the tools we use! Do you think that’s why others are adopting Remix as well?

Hugo: I would be surprised if not! But in a sense it’s also a part of the evolution of React. We are expanding the types of applications that are easy to build through frameworks. Take a business that’s, say, building a company blog and they've already got React developers. So having a React framework that lets them work on this is really useful. For that, maybe Next.js is good enough. Then they need the CMS to be built. You could have WordPress in headless mode, or you could use Ghost in headless mode but we've already got these React developers. Wouldn't it be good if we had the same skill sets applied to all of those? That’s where Remix comes in. So I think that's part of what is pushing this. We already have these skills. Let's expand the set of problems I can solve with the skills I already have.

We're not taking a bigger slice of the pie, we're making the pie bigger.

Joe: Thinking about Remix this way just gave me that warm Christmas type of sensation for a second. But now that we’ve talked about its upsides I’m also really interested in the situations where it’s not a great fit! The only serious problem I’ve run into was when I tried to take some state coming from the Remix API, put it into some real client-side state-management solution like Redux, work with it for a while and then wanting to sync it back to the Remix server. I’ve never pulled it off properly.

Hugo: I mean, the question is like, why would you?

Joe: I was simply doing it out of technical curiosity but there are many application in the Level 3 Web Complexity Category like the web version of Figma or Excel where you simply don’t want to have every little state change to get propagated to the server but still need a scalable state management solution in-browser.

Hugo: Yeah, Remix typically seems to want the server to be the source of truth for data in your app. It's not looking to help you build an application that has a lot of client-side state. There's a small subset of problems where you do actually need a single page application because you need to be doing real-time processing, right?

🙋‍♀️ RAP

- The Remix app that runs in almost 2k Tesco stores

Joe: Hmm, that made me curious, doesn’t the RAP fit that category? I know it’s a Remix application running in the Tesco stores working with real-time data. Can you introduce it to us and share how you tackled this issue there?

Hugo: So the RAP stands for Remote Attendant Person. It’s the application that runs on a dedicated machine in places where we have the self-service tills that lets a Tesco employee look at the state of the tills in one place. They can see things like, oh, this person needs me to go over and approve an age approval, or this till got an error and the printer needs to be fixed or whatever. And the employees can take action remotely like, if a person at the till is obviously 50 years old, I can just hit approve on the over 16 age approval without having to walk all the way over. So it's connected to the tills in real-time through individual web socket connections, and gets a feed of all the events happening on them, which then causes it to update its own state. The RAP and the tills have to sync together because if I approve an age approval on the RAP, it needs to disappear on the till. If I approve it on the till, it needs to disappear on the RAP.

Joe: That’s a great overview and now it’s more clear to me what might cause some problems with the Remix architecture for this use-case. So if the RAP app has all these real-time connections to the till machines in the client, it needs to react to the incoming events in-browser as well. Sounds like a classic SPA thing with client side rendering but then how does it benefit from the SSR capabilities and actions/loaders that give Remix a lot of its powers?

Hugo: The first version of the RAP I built was loading the list of tills in the background, render that client-side, and then have each of those independently create its own WebSocket connection to the back-end. That worked, but then you had the thing you were describing, which is like, why am I even using Remix at this point? All it's doing is giving me ESBuild and a page to render. The way I solved that problem was to move the real-time data to the server and have that push it to the client. It's much easier to trust the server to be the source of truth especially because they're only events, there is no state managed on the server. We manage the state locally. And that's done using a state machine library called XState because then we get the benefits of that it's actually deterministic. I can be sure that I've handled every event correctly or I've handled all the error cases correctly.

In the way the RAP is architected the whole app is a deterministic state picture that's based on events coming in and it just spits out a deterministic state. There's an EventSource that the server uses to send messages to the front end and then the UI just renders the corresponding new state.

Joe: In a sense, that doesn’t sound too Remix-y to me.

Hugo: I don't know how much they would promote it but with Remix you can have a real-time data feed on the API routes using Event Source. And then you just fire Server Sent Events at that, and it dumps a stream of messages out to the client side. You can make that as sophisticated or not as you want. It's just a text-based protocol. So in the RAP, the way we're doing the live updates with that is a JSON protocol where we send new states line by line. So every time the server updates, we send a new state to the application. It supports named messages so you could say, update, and then an update payload, delete, and a delete payload. And with that you can have a more complex mapping to say these messages go to this handler and these messages go to that handler. Then the interaction model, if you want to do it that way goes like, a form submission mutates some data, and then the update gets pushed back to you through the EventSource rather than it being the response.

Joe: This sounds quite nice as a concept. A clean mapping of events to state to UI going from the machines through the WebSockets to the Remix server to the application ending up in XState and rendered by React. How does it do in the real-world?

Hugo: There's no active development going on it but the fact that it didn’t need a release in the last 6 months is a testament to its stability. It's pretty reliable. One of our Engineering Directors the other day was saying, oh, I had a look at the code base. Seems really nice and neat and reasonable. So I think that's good. I mean, you should have a look at it yourself and see what you think.

Joe: I will for sure, I’m super excited to check the codebase of a live Remix application. I think this is a good place to (w)RAP things up. Thanks Hugo for sharing all your insights with us. It was an exciting conversation!

✍️ Author’s Note: Since the interview I’ve done so and I really liked the project. I also had a few interesting internal discussions with other developers involved with it and the generic sentiment is very positive about the RAP codebase. (In case if you wondered). But Tesco is a huge company and I came to know about other Remix projects running in our estate. Let me know if you want me to cover some of those too, or if you would like to see similar interviews in the future!

Hey Full Context Developer

(I’m writing in a personal quality, opinions are mine and are not reflective of Tesco’s)

Today, we are doing something different. As the title says, I will write about Remix but the format is going to be new for this publication. The framework has been out for a couple of years so enough time has passed for the frontend community to learn about how and when to use it best. I thought now is the right time to re-evaluate its benefits based on real-life experience.

And to do that, a special opportunity presented itself. As you might know I recently joined Tesco and it turned out that the principal software engineer on our project, Hugo Jobling was a very early adopter of Remix. I recently managed to grab a few hours of his time to talk about it. Some of you might remember, the framework was first published as a pay-only product. Hugo bought it in the earliest days and used it ever since in multiple projects. One of them is running in close to two thousand Tesco stores across the UK.

Below you can read the edited version of the interview. I arranged it in sections focusing on specific topics. As the whole thing turned out to be quite long I will be releasing it in parts! Here’s the overview. The first part will cover the first 3 topics and the second will focus on Remix and the RAP.

• 📖 Career

  • Hugo’s professional history, following the evolution of the web from the very beginning of the 2000’s as a kid to adopting React in 2013 to becoming one of the earliest users of Remix

  • How he made ethical choices about certain industries

  • Where can an engineer be the most effective

• 🛒 Tesco

  • Why Hugo joined this company. (I chime in too)

  • An insider’s look of working at Tesco as a software engineer

  • Some of the unique benefits Tesco offers for professional development

• ⚛️ React

  • What he learned from using React for a decade

  • How he made successful early adoption decisions multiple times

  • What were the unique benefits of early adoption for his career

• 🎛️ Remix

  • How to cultivate a great taste for technology choices.

  • What types of applications are best suited to built with Remix

  • How Remix offers more than Next.js

• 🙋‍♀️ RAP

  • What’s a RAP and why is there one in almost 2,000 Tesco stores

  • How to handle real-time data with the Remix architecture

  • How well does it do in production

Recording this interview was super fun and insightful. I’m sure you will enjoy it too. Huge thanks to Hugo for the conversation. You can find out more about him at: thisishugo.com (which is a tiny Remix site btw…) For a teaser here are some quotes:

“Having been built and working with large scale React applications for years, you realize, as everybody realizes, that it's called Create React App, it's not called Maintain React App. And there's a reason for that.“

“When I work on a Remix application, I'm really productive because when I'm following the happy path, the pit of success, it pushes you along like a tailwind.“
- Hugo Jobling

👋 Intro

Joe: Let me start with a quick rundown of my plans for this conversation. I would like to cover two main topics. First, to get to know you a little bit better as a software engineer and as a person. And then, to learn about your experience with Remix and what are some of your takeaways from using it on multiple live projects.

✍️ Author’s Note: If you are already familiar with what Full Context Development is and the history of this newsletter feel free to skip to the next paragraph.

Let me tell you a bit about what this Full Context Development stuff is and how I came up with it. It’s obviously strongly connected to this newsletter too, which grew out of my work on my own project. I developed an “online book” - you can check it out at: fullcontextdevelopment.com - where I tried to distill my experience about making good technical decisions based on targeted business outcomes and to extend it with deep research from the knowledge of the wider software development industry. It sucked quite a bit I guess, only attracted 12 customers. What actually got some real interest from people over the internet was the tech reviews I wrote as a marketing effort. I’ve reviewed Remix and Next.js using the system I established in the book. And they got published in React themed newsletters like This Week in React, React Newsletter and Awesome React Weekly from LibHunt. From then on people started to sign up to my own newsletter through the book’s website. That’s how all of this started. The main goal of what I'm doing here is to give people insight into the most recent front-end technologies by answering questions like: How much value will they provide for your projects? How will they impact business results? How could they influence your career? The core of this approach is simple, all we have to do is focus on five impact factors: CPU-DB. Customer Experience, Productivity, Utilization, Direct Costs and Business Opportunities. I’ve spent around two months distilling those 5 factors while I was looking for the smallest subset of “things“ that can connect the full range of business outcomes with the complete set of technical attributes of software and programming. And people are signing up to the newsletter. Not in droves, not like crazy, but steadily and the pace is accelerating. That's something I’m super proud of and grateful for.

📖 Career

- From building websites at 10 to Principal Software Engineer at Tesco

Joe: I’ve been planning to write about Remix recently, and as I heard about your experience with it, I thought it would be the perfect opportunity to get someone’s perspective who actually used it in production for years about the strengths and weaknesses of the framework . Later, when we had the chance to talk more in-person, during your visit to the Tesco office in Budapest, I realized that you are a really interesting guy to talk to.

Hugo: Well, give the appearance of one.

Joe: No kidding, and I'm super excited to do this interview. I would love if you could introduce yourself for the readers, maybe by walking us through your career. I know you started out in tech journalism. How did that happen? And then how did you transition into software development?

Hugo: After finishing my A-levels I wasn't going to go to university. I had a six-month fixed-term contract job working for the Department of Work and Pensions, just to have some disposable income. I knew that wasn't going to be a career so I was looking for other opportunities. I used to read this website called Trusted Reviews. (Spoiler: this is a link to all of Hugo’s contributions there.) During this time, they posted a job advert, and I was like, how high can it be? I could write. I like writing. I like tech. Also I was active on the forums. So they knew who I was. I sent in an application, did an interview, and they're like, try again in six months. So I did try again in six months, and then I got a job there.

Joe: Oh nice, that’s not how the story usually goes! How did it continue?

Hugo: I was there for just about four years. And then that company got bought by a bigger organization. The founder left. He was a really great mentor to me. And him leaving just killed the culture of the company and I wasn't really keen on working there anymore. So I became a freelance writer doing individual paid articles, which at the time was a shrinking field and very competitive.

Joe: I guess this was the perfect time to consider a career change. But why software engineering?

Hugo: By that time I'd been playing with development for ages. I did a programming course at school and we did web development as part of our IT GCSEs. But I've been building websites basically since websites are possible to build. I got like 25 megabytes of hosting space for my 10th or 11th birthday and I was building my own, little personal website. It was horrific. I'm glad Archive.org hasn't got it anymore, because it was truly terrible.

Joe: Now you really made me want to have a look at it! But I know how some things are better left in the past so let’s get back to your story of moving into development.

Hugo: I simply thought, OK, how hard can it be? Let's start doing some web dev work. I just started out doing like, oh, you want a single website for your little thing that you're going to do. So I did some of that and then pivoted into a full-time web dev job at a local business developing a point of sale application so clearly I've developed a pattern.

✍️ Author’s Note: Our teams are working on the UIs of the newest Tesco tills so it definitely looks like a pattern.

Joe: How did your career continue from there?

Hugo: So I did that for a few years then took a role at a local-ish e-commerce company. Then I decided that the money was better in London, so I better go work in London. My first job there was at a consultancy, just doing typical consultancy stuff, building prototype apps and the like.

I think that's a useful type of work to have done at some point, especially at small consultancies because it does force you into having to communicate with stakeholders, to learn to cut the chaff and move fast to deliver by the deadline.

It teaches you the mindset of building MVPs, while actually focusing on the minimal and the viable, and solving problems as opposed to playing with cool tech. Because if you spend one out of your two weeks playing with fancy toys, then you will have very dissatisfied customers.

✍️ Author’s Note: This makes absolute sense from the Full Context perspective. It’s no wonder I defined 2 out of the 3 real goals of our work as solving the problems of the users and the problems of the business.

Joe: It was a really valuable experience to have for me too, that’s for sure. I worked in a similar environment for roughly a year, a few months more, and it gave me a really good understanding of how my choices connect to the life of the businesses (clients) I work for. It’s one of the main influences why I started to write my book. But back to you journey.

Hugo: So there's the e-commerce, then the consultancy place, then I worked at a venture capital firm for a short period of time building an in-house software tool. From there I went to a sports betting place called Ladbrokes Coral, which is quite a big UK gambling company.

Interestingly, again, working on a point of sale till system written in React and Redux. That was in 2018 or so. Then you come back in 2021, three years later, and it's like, oh great, I get to see the same problem again. (That’s when Hugo joined Tesco as principal software engineer.) Weirdly with the same tech, because it was started about the same time. I can see all the things we did differently, some of them are better in this place.

When my time at that betting company came to an end I knew that I wanted to do something a little more ethical. Then I saw this role available at Tesco.

And I was thinking about where am I actually effective as an engineer? Typically, I think that I do a better job working on products that I'm actually a user for.

✍️ Author’s Note: This is also encoded in the Full Context mentality. I’ve dedicated two chapters of the book to help people understand the customer’s perspective of the software products we create because we can only do our best work when we have that kind of understanding under our belt.

And I actually was a customer of Tesco. I do use the Till software. And I have opinions about what is and is not good Till software, as opposed to working on some internal tooling for some bank, right? Or like building an insurance product or anything where you're out of touch with the domain. Also, the fact that I had previous experience working on point of sale, React, e-commerce systems, I was like, I can bring a lot of value to this specific role because I've worked on this problem twice before. I know what an approach to it looks like. And so I can actually apply that to this problem space. And then Tesco was daft enough to hire me. So here we are.

🛒 Tesco

- Helping millions of people as a software engineer

Joe: It’s really interesting how your story naturally progressed from a birthday gift of a couple megabytes of hosting space to working at the scale of Tesco in a very high impact position. And I can relate to your motivation for joining this company. I also considered the ethical aspect when I was planning my next move. For me it’s tremendously motivating to know that you help people get something that they really need and that we are working on something *real* instead of *virtual*.

Hugo: Well, that's the selfish side of it, right? The reason I took the role at a gambling company was because the problems were really interesting. You're talking about real-time processing of millions of events. Take for example the Grand National in the UK, it’s a massive event where the same amount of activity happens in the system on that one day as on the rest of the year. You get these really interesting big problems of scale and throughput, that's a fun problem to solve.

But at the end of the day, you're like, yeah, but it is gambling. I go back and forth. Am I making the world a worse place? For some people? Yes. For most people? Broadly, I feel neutral, verging towards unethical. It's not as bad as working for a company that does arms manufacturing. Or tobacco companies. Well, there's no societal benefit to smoking. People enjoy it, but it's not good for you.

On the other hand, I had other opportunities where I could have gone to work for a healthcare startup that was doing healthcare in Africa or something like that. That would be more morally good than what I’m doing. But I feel like Tesco is towards the better end of the spectrum, all things considered.

And there's not a lot of companies where you can have the level of scale and impact and also feel good about it while having the chance to make major individual contributions.

If you're going to work at Google or Meta, you're going to be one of 5,000, 10,000 engineers, there's a very small number of people that have outsized impact. Engineers working on the React team at Meta have more impact than your typical Meta developer. But most people at Meta don't work on React. And I don't know what they've been doing for the last year because it hasn't been releasing updates to React. So maybe nobody works on React at Meta anymore. Who can say?

Joe: Yeah, I don't know either, but I would be surprised if there was no work going on behind the scenes. What I know with 100% certainty is that many interesting things are going on at Tesco Technology. What do you like about them the most?

Hugo: The good side of it is you can affect positively, literally, millions of people. And then also, if you're not careful, millions of people can have a bad day because of your mistakes. But you want to have stakes, right? It makes it meaningful. At Tesco, you feel like what you're doing is actually having a positive impact on society, broadly speaking.

Joe: Yeah, I agree. What I found fascinating in addition to that is the scale of the organization itself and the opportunities that come along with it.

Hugo: This is another thing that attracted me to Tesco. I'm at a point in my career now where I don't want another 18 months and then pivot, 18 months and then pivot cycle. I want to work on something that I get to see the consequences of my decisions in five years' time. And I think that Tesco is the kind of place where you can have that long a career.

✍️ Author’s Note: Most definitely, we have a couple of colleagues who are here for 10 or even 20+ years. Make of that what you will, but for me their depth of familiarity with the domain and the organization is super impressive. They can leverage these assets to easily create seemingly 100x impact.

I have done some smaller greenfield projects from scratch, in some cases, they were 100% my code and nobody else’s. I've been proud of those things, and I thought they were good software. But I've written it and then, I don't see the report from someone three years later that has to maintain that thing as to whether or not they were able to pick up what I did. I want that person's opinion as to my software, right?

Joe: That’s the kind of input you can only get while sticking around for a long time in a stable environment, at a place like Tesco for example. You will plateau in certain aspects of your professional development if you are always jumping around every 18 months as you said.

Hugo: Some of the stuff I'm proud of, like the decisions we've made recently, are things like not only saying it's not time to do a rewrite, but actually having a migration path from what we have today to a better version of it in two years' time, that’s the roadmap I was putting out for this project. It's just an interesting evolution in thinking, being more cognizant of the fact that not everything needs to be disposable.

Joe: I'm in a similar phase myself. I choose Tesco among other reasons to have the chance to learn from the long-term consequences of my decisions.

Hugo: You have a bit more flexibility. You don't have just six months of runway where everything is boom or bust. At Tesco people are rightfully upset when you lose the business money. It's not inconsequential. The situation with our cloud logging is a perfect example. At a time you realize, oh, we're spending X amount of money, and we've been doing that for six months, and we're going to be doing that for the next six months if we're not careful.

Joe: Well this sounds interesting. Why is that?

Hugo: It's externalities, where, as a developer, I just think console.log, right? Of course I'm going to write my logs. But it doesn't occur to me that this log line will get written 1,000 times a minute on 1,000 servers every single day. And that's costing us 10 gigabytes of data a day, which every month is costing us £1,000. One log line is £1,000 of cost a month. An engineer can easily write that line without realizing those consequences. (The numbers are of course made up, just close enough to give you a sense of the actual scale.)

That's money that could be better spent elsewhere. That could be some extra engineers joining the team. Or savings are passed on to our customers in a lot of cases. So this stuff does matter. But like, nobody's getting fired because you were two weeks late or put in some extra logging. And the project will most likely live on for the next five years, and who knows how much longer.

The business problem (the need to collect payment from customers) will be there, even if the specific implementation of what you're doing isn't there anymore. And that's the interesting part, it’s you get to work on the same problem for a long period of time.

⚛️ React

- The experience of working with React for a decade

Joe: That’s what provides the chance to learn from long term consequences and also to become an expert of a business domain. Moving on to the more front-endy topics I planned, one of the things you mentioned is that you have worked with React since at least 2018? When was the first time you used it? What were your first impressions?

Hugo: I've been following it along since its inception. I was there in 2013, straight off the back of the F8 Facebook conference. I was like, let's use this thing. I was, apparently, one of the few people who thought that JSX seemed fine. Some years down the road the bulk of the community got over that initial hump too.

At that time people were excited about React. The pitch that it was "just the view layer" helped, I think. When you're working on existing projects and want one page of our application to be this fancy interactive page, but keep the rest of the app server rendered, React felt like a quite natural fit there. That was what everybody was building. That's how I picked it up.

Then it just turned out that the tooling only seems to get better and better. Fast forward to today and the level of tooling we have is just extremely good. The types of problems that you can solve, even with relatively little ability, is much wider. Newcomers can get a multiplicative advantage, a level up over what you could do 10 years ago.

Joe: How does it feel to work with React after a decade of using it?

Hugo: What's interesting about working in React over a longer period of time, is that one of React's greatest strengths is also one of its biggest weaknesses, which is historically how not opinionated it has been about how you build a React application. And what that has resulted in, at least in the apps that I've worked on, is that unless they were started by the same person and worked on by the same teams, typically every React app you work on is its own thing. I see very little commonality between different React apps. And I think that's also more true for React and the JavaScript ecosystem in general, than it has been for other ecosystems, because there's just more churn in the space.

React today is, in many ways, quite different to the React I learned a long time ago. Hooks are very different to the component lifecycle. And the ecosystem of what you do in React is very different today. But fundamentally, the mental model is the same. Your application as a function of state is kind of still there.

I think they latched onto a really good idea. There's that Guillermo Rauch tweet that says, React is such a good idea, we're going to be thinking about the implications for the next decade. I remember thinking, it's a little bit high, but broadly, he’s probably right. And lo and behold, here we are almost 10 years later from when he wrote that. And we are still seeing the implications of the React programming model all this time later.

Joe: Adopting a library very early comes with a huge risk but has unique benefits as well. What were the positive effects of adopting React early on?

Hugo: There was no guarantee that React was going to be like the big thing it is. But by getting in very early, I had the advantage of, when React becomes big and companies start looking for React expertise, that I've been doing it as long as anybody outside of Facebook can be doing React. Five years ago I had five years experience, which was quite rare. I have now 10 years experience, which is still quite rare.

And so the advantage that has afforded is exposure to more of the types of problems that teams working with React have faced, such that now, when we have our internal issues on the team, and someone's like, oh, I've got this problem with React, odds are I've probably seen it before.

Not because I'm some kind of React expert that knows everything about React. It's as you expose yourself to something for long enough, the same problems tend to resurface.

✍️ Author’s Note: This is where we will stop for this post. Let me know how you liked it in the comments and stay tuned because:

Part II is out now, take a look!

Hey Full Context Developer,

We need to talk about Legend State! It’s a trending new state library for React and React Native apps that might fundamentally change how React’s component lifecycle works by drastically simplifying it using fine-grained reactivity. This might become the single most significant evolution of the React ecosystem this year. (More about this towards the end.) (Also support for more frameworks is likely to come in the future.)

Intro to the newsletter: Hey I’m Joe 👋, senior frontend developer and this is a short, more focused issue of the High Impact Frontend series. The goal of the whole publication is to cut through the noise of non-stop frontend tech buzz and bring you only the most impactful news that can create outsized, positive impact and change what you work with, the way you do development or even the course of your career.

I use the Full Context approach, my way to identify and explain the level of impact a tool or a piece of information can make and the hype-value scoring system. My goal is to offer a complete picture of when, how and who can realize that impact so you can easily find the most valuable news for you. You can find more details about this in a dedicated post.

My absolutely top secret, hidden agenda behind all this is to teach developers how to connect the technical part of our work with its business and real-life outcomes, so I can help you to make better choices and create better software for everyone.

If you think this work is worth supporting please consider upgrading to a paying subscription. Your financial support would make it possible to put in even more effort and produce higher quality content. Thank you if you consider joining the core Full Context Developers’ team this way!

Subscribe now

I’ve decided to write this post as soon as I learned about LS because it has some really cool and interesting properties that also has the potential to easily overhype the library. (Starting with its name, which is kind of cool, not gonna lie. And the fact that it gives you signals for 4 KBs which is another trendy topic nowadays.) To quote its own introduction from GitHub:

This lib is so performant it claims to be the fastest React state library out there. Furthermore it’s optimized for arrays to the level that it even beats vanilla JS on the "swap" and "replace all rows" tests in the de-facto krausest/js-framework-benchmark.

And damn, that’s quite something! However I want to focus on the utility of this library from the Full Context perspective. Let’s jump straight into that.

Is This Really Legen …Wait For It… dary?

As most of you following already know, my goal is to offer a well balanced view of the benefits of the technology in review. To do that, I use the CPU-DB impact factors. (Customer Experience, Productivity, Utilization, Direct Costs, Business Opportunities).

I want to provide you with that type of analysis for Legend State so you will be able to decide whether it will deliver legendary results for your use case or not.

As the web performance experts say: “Fast is cash” and Legend State is fast, so is it going to increase the revenue a lot?

That's the question every one of us is trying to figure out right now. If it will lead to the type of speed improvements that shave off 100s of milliseconds from your important performance metrics it will become a no-brainer for lots of projects. But will you really achieve that by introducing it? And even if yes, what’s the price you have to pay for it?

The Name is Important: A State Library

I really like that the author is honest about the goal and scope of the project by calling it a state library and not a state management solution. This is actually one of my biggest worries about adopting it. What you currently get are super optimized primitives to handle reactive state. But it doesn’t come with a baked-in, enforced pattern to manage that state application wide.

It’s a tradeoff with pros and cons. You can roll your own flavor of state management, but for large scale, long-term projects where consistency and maintainability are crucial this might not cut it. If you check out the docs you will find a section called Patterns that show you some possible styles of handling application state with it. Jack Harringon’s YouTube video covering it also shows some extra patterns in practice.

If you are looking to create a new open-source project this is also a great opportunity. I think there’s huge potential in a higher level library that actually enforces a single pattern of handling application state, built over Legend State. (Legend State Manager, or… Legendary State?)

The Issues

With LS you can just go and directly get and set state all across the app, however you will miss the benefits of the centralized handling of state transitions when taking that route. This pattern can easily lead to a lot of issues:

• Duplicating the logic of updating the same piece of state across different parts of the app.

• Duplicating the logic of accessing and deriving new state from the same pieces of base state aka selectors.

• Introducing subtle bugs or divergence each time you reimplement the same state manipulation.

• It lacks an easy way to find or modify code that works with the same part of the state on the same way.

• It also lacks the ability to clearly show the shape of the whole application state as it can be ad-hoc defined at places of usage.

• Similarly there’s no definitive place to look for the possible state transitions.

All of these can lead to a huge mess down the line. However there’s nothing stopping you from implementing guardrails and establishing conventions to prevent these issues yourself. What I want to emphasize is that you need to do it consciously without much official guidance.

The Radical Rethinking of the React Lifecycle

I can’t deep link to it, but there’s a paragraph in the lib’s intro post called: Replacing global state AND all of the React hooks. If you are a React dev, you need to check it out. When adopting Legend State you can drastically rethink and reduce the complexity of the React component lifecycle. That is literally mind blowing! Read the linked post for the exact details. In a nutshell, this lib will eliminate re-renders, so you don’t have to care about anything related to subsequent rendering, all you have to take care of is when the (observed) state of the component changes. However you will have the library provided tools for that. If you give it a thought that’s a massive shift in the mental model of what happens at React runtime and a massive simplification! I still don’t fully comprehend its implications but I will look into it further. Would you like me to follow up on that?

CPU-DB: The Full Context Perspective

• Customer Experience: Legend State is small, only 4kbs of JS payload so you can save some initial bundle size by using it instead of some larger state management package (looking at you Redux). Its state updates are crazy fast and it can even hack the React render lifecycle to speed up rendering performance even more. These are not by default impactful improvements so I would precisely measure and validate if the project can meaningfully benefit from the high rendering performance it can provide. Most applications working on the standard React way are actually fine perf wise. Or can be optimized with the built-in optimization tools just fine. I can totally get why any frontend dev can get super enthusiastic about huge performance improvements but please don’t jump ship without considering the ROI of any tech choice.
  ➡️ Potential Impact: System Category
  

• Productivity: If adopting Legend State can really reduce the complexity of working with React hooks by eliminating the need to think about useMemo, useCallback, useEffect or useState (as the linked article says) while also making most of the component lifecycle irrelevant, we can gain a meaningful productivity improvement. If it can save us from the effort of handling all the weird edge cases and potential issues stemming from them, that difference can actually add up to something noticeable. On the other hand, if you don’t enforce good patterns for managing application state, the issues mentioned can easily negate any productivity gains.
  ➡️ Potential Impact: Group Category
  

• Utilization: This is always affected by changes in productivity. When that's improved your utilization goes down, which results in extra capacity and the chance to get more done under the same time as earlier.
  ➡️ Potential Impact: Group Category
  

• Direct Costs: No direct costs are involved besides the bang for your engineering hours as productivity dips at the beginning of adoption and hopefully improves as time goes on. This is where I have to point out that early adoption of any technology can actually become really costly through the productivity killing unforeseen issues that only arise as a tool gets more widely adopted and used. That’s why my recommendation for non-trivial projects is to only choose Legend State now if you can validate its usefulness and viability and there’s capacity and budget to stick with the decision even if you find some weird use cases that take time and community effort to support properly. (For example: SSR is just being explored.)
  ➡️ Potential Impact: Organization Category
  

• Business Opportunities: Performance improvements in general has the effect of bringing a broader audience to your websites and it’s the same with Legend State. With faster sites, more and more people fall into the category where performance issues won’t make them exit the journey before they convert so the reach of the product will increase. Which is a classic example of gaining new business opportunities.
  ➡️ Potential Impact: Organization Category

Should You Use It?

I recently read about the Innovation Point Principle from Addy Osmany (ex core jQuery, now Head of Chrome Developer Experience @Google) in a LinkedIn post. I highly recommend taking his advice when thinking about adopting new and shiny tech including LS. The principle is super aligned with the Full Context perspective of our work and it’s coming from a huge industry expert. Can’t love it more. But back to the lib…

I personally would only go all in with Legend State on low-risk projects. That typically means, side projects, internal tooling, PoCs, or any application that won’t be developed by more than ~ 3 people for a long time.

However I believe this is a tool that has great potential and interesting benefits so I definitely recommend experimenting with it if you can!

That’s all I can say about Legend State right now, but I’m looking forward to exploring it further in the future if you are interested. Let me know!

🏆 Final Score 🏆

📊 16 Points: Hype 4 x Value 4

Personal Update

While writing this post last week, I was on vacation with my family but something very interesting happened on Tuesday that I want to share with you all! I’ve interviewed Hugo Jobling for the newsletter about his experience using Remix in production. Hugo is an early (paying) adopter of the framework and also my colleague at Tesco working as a Principal Frontend Engineer. I had a chat with him about his experience with the framework and how it helped him to deliver multiple projects (one live in more than 2000 Tesco stores). I will share the details and many more interesting ideas about frontend development from our conversation. It’s going to be super insightful! Really looking forward to delivering it to you all soon.

I also wanted to say huge thanks for all the new subscribers, the rate of signups is actually accelerating, there’s 151 of you already following. That’s super awesome and I’m doing my best to deliver you an ever improving, interesting and valuable newsletter. Let me know if I can do anything more to make that a reality for you!

See you in the next one Full Context Devs!

Best,
Joe @fullctxdev

➡️ Thank you for reading Full Context Development. If you liked this post feel free to share it and subscribe to the newsletter if you don’t want to miss future posts.

Share

Subscribe now

Hey Full Context Developers & Company

I’m really sorry I’ve kept silent for a long while. There were multiple reasons (like switching jobs, now I’m at Tesco, sadly some health issues) but the biggest one was the giant effort I put into the preparation of (… drum roll)

For a long time I have been a huge fan of web performance, React and Next.js. All 3 of them are super interesting and awesome tools for delivering full context value. Long story short, while there are tons of resources covering web performance, there’s none that’s covering the whole field yet laser focused on Next.js and its basis, React. That’s why I decided to connect all of these topics to deliver a unified guide, here on Substack, that will help anyone to gain comprehensive knowledge of the field and the self-confidence that’s coming with it! I believe it will be truly helpful and absolutely thrilling for all of you passionate frontend engineers!

I will be covering a ton of advanced performance optimization techniques and the basics necessary to understand them. I’m personally stoked by the unique blend of practical tips, real life case studies, technical details and code examples I’ve managed to put together. (Hope that doesn’t sound weird, I mean, it’s not crazy to be excited for what I’ve done, right?) All these, tied to their effects on user experience and business results.

That’s one of the cool things about web performance. It’s strongly connected to the profitability of products so it’s super easy to see the relationship between the optimization work and its effects over the Full Context. As the perf gurus say: “Fast is cash” and I will show why later.

With this post I want to share an overview of what’s in the making because, I believe, if you are interested in any of these topics this will get you super excited. (Ordered quite randomly). Just one more thing before that. I will resume writing about the news too!

• Elementary and advanced React performance optimization techniques

• Using web workers with hooks, Redux or simply by themselves to speed up processing-heavy tasks.

• Introduction to core Web Vitals, their practical importance and how React and Next.js can affect them.

• Performance Scoring, Performance Budgets and Performance Comparison best practices.

• Deep dive Into the usage of React Developer Tools for performance optimization

• Case Studies, Code Examples and Pro Tips

• The ultimate guide to Controlling the client-side browser cache (including cache invalidation strategies for single page web applications)

• Surprising ways to use Storybook for performance aware design (and more optimization related work)

• Introduction to performance measurement and analysis using Chrome Dev Tools, Google Lighthouse and WebPageTest

• The RAIL model in the context of React and Next.js

• Strategies for cache management using Service Workers: cache first, network first, cache with network fallback

• Next.js specific web performance optimization tools and techniques

You can already check out a much more complete and comprehensive list in the full Table of Contents, up on the website and read the first complete chapters including a free premium one: Lazy Loading in React and Next.js.

How to access it

The format I’m going to use - and I think the process as well - is a little unconventional. I will incrementally release chapters here on Substack and once I manage to release a good amount of in-depth posts some of the performance guides will be paywalled behind the subscription. Ultimately this will become premium content for the publication.

Exactly when and how, I don’t know yet. But until I get there I’ve decided to enable paid subscription on the publication with the lowest price allowed by the platform, while keeping it completely optional. I’m doing this because I would like to give everyone a chance who wants to support my work on the guides to do so. If you decide to keep up a paid subscription that would be 1) super awesome and mind blowing 2) a great way to ensure I can work on producing a high quality, polished product that will help you all with everyday pains or just with learning fun and interesting stuff. I also plan to offer more premium community features so we can engage and shape the material together.

As the work continues, I will surely update and refine already published content. Don’t worry, if there are substantial changes or improvements I will notify all subscribers! Oh yeah, one more important thing, I won’t be completing chapters in any order set upfront but as it makes the most sense to me and our community.

So this is the plan! Many things are in the works already, I have the draft version for every chapter in the table of contents and some more. The journey itself will be an interesting one to follow. I hope it will teach you all a lot of interesting and useful performance hacks and proper optimization techniques too! See you around web performance ninjas and full context developers! Reading the guides will make you a better one of both!

Best,
Joe

✍️ Quick notes:

• As the guide is currently work-in-progress the table of contents will be likely changed multiple times to reflect structural or topical changes as I refine the work.

• Please read the Announcement Post to learn about how I plan to deliver the guide. TLDR; It’s free here on Substack, but later I plan to compile it into a standalone book.

• The ordering of the chapters is not final.

The Ultimate Guide to High Web Performance React and Next.js Applications

1. Introduction: The Ultimate Guide to High Web Performance React and Next.js Applications

   • What it Takes to Become a Badass Frontend Ninja Master

   • Performance is a State of Mind

   • The Call to Adventure
     

2. The Importance of Web Performance in Modern Web Development

   • About The Impact of Web Performance on Multiple Dimensions

   • The Unique Challenges of Modern Web Applications

   • Special Considerations for React.js and Next.js Performance
     

3. Learnings From The Fastest Next.js App of The Galaxy

   • Inspecting The Champion of All Times

   • The One True Goal of Performance Optimization

   • Key Takeaways

4. React Performance Optimization Tools and Techniques

   • Generic Optimizations: VDOM, State Updates, Component Lifecycle

   • Reduce Forced Synchronous Layouts

   • Throttle or Debounce Event Handlers - Infinite Scroll and Search Use Cases

   • Lazy Loading Components

   • Optimizing State Management

   • React.Profiler API

5. How to Use The React Developer Tools for Performance Optimization

   • Inspecting Components

   • Profiling Component Performance, Break on Update

   • Component Filtering

   • Highlighting Updates

   • Comparing Profiling Sessions (Render durations, Commit frequency, Component flame graph)

6. Introduction to Core Web Vitals With React and Next.js

   • First Contentful Paint (FCP)

   • Largest Contentful Paint (LCP)

   • Cumulative Layout Shift (CLS)

   • Time to Interactive (TTI)

   • You Can’t Optimize What You Can’t Measure: Performance Scoring

7. Implementing Critical Render Path Optimization With React and Next.js

   • What’s a Critical Rendering Path?

   • Finding the Critical Rendering Path of Your Page(s)

   • RRR: Remove, Reorder, Reduce

   • Responsive Design and the Critical Rendering Path - A Next.js API Approach

8. Top 6 Next.js Performance Optimization Techniques

   • How to Choose a Rendering Strategy (SSR, SSG, ISR, CSR, RSC)

   • Implementing Custom Cache Controls

   • Effective Use of Built-in Optimization Tools, next/image, next/script, next/link

   • Code Splitting And Dynamic Imports

   • Optimizing API Routes

   • Bundle Analysis And Eliminating Duplicates

9. All That’s There to Know About Lazy Loading in React and Next.js Apps

   • Lazy Loading: What is it And How it Works

   • The DPS of Lazy Loading

   • Implementing Lazy Loading in React

   • Lazy Loading Is The Second Step in a Combo Move: It Starts With Code Splitting

   • What to Lazy Load and When?

   • Identifying The Target

   • Lazy Loading With Next.js

   • More Tools in Next’s Arsenal With Lazy Loading Powers

   • Final Warning: When Not to Lazy Load

   • Challenge: Share The Diff

10. Utilizing Service Workers to The Max

    • Intro to Service Workers

    • The Service Worker’s Lifecycle: Writing and Registering Your First Worker

    • The Cache API: How to Cache And Server Static Assets And More

    • Offline Behavior & Background Sync

    • The Push API

    • Case Studies About The Business Benefits of Implementing PWAs

    • Updating and Debugging Service Workers

    • Customizing Service Workers in CRA and Next.js

    • Workbox

11. The Snappiest Static Assets On The Planet

    • Font Optimization Techniques

    • Ideal Image Delivery

    • HTML, CSS, JS And Their React + Next.js Specific Concerns

    • Resource Compression

12. The Ultimate Guide to The Client-Side Browser Cache

    • Exploring The 11 Parameters of The Cache-Control Header

    • How to Use Last-Modified

    • How to Use ETag

    • Cache Invalidation Strategies for Single Page Applications

13. How to Use Storybook for Web Performance Optimization

    • Storybook as a Performance Benchmarking Tool

    • Performance-Aware Component Design

    • Guide to Measuring Performance and Enforcing Performance Budgets.

    • Performance Monitoring: Integrating Storybook Into The CI Pipeline
      

14. The RAIL Model, the React and the Next.js

    • Learn The Basics of The RAIL Model And Its User-Centric Approach to Web Performance Optimization

    • Response - What to NOT do in The Render Method

    • Animation - How to Implement Them Efficiently With React & Family

    • Idle - How to Free Up The Main Thread From The Burdens of React and Next.js

    • Load - Next.js Rendering Strategies, Lazy Loading, Caching And More
      

15. Uncommon Usages of Native Web APIs for Performance Optimizations + React Examples

    • Intersection Observer

    • Resize Observer

    • Navigation and Resource Timing API

    • requestAnimationFrame
      

16. Overview of Web Workers and Their Use for Faster Page Rendering

    • How to Work With Web Workers

    • Web Workers and React

    • Usage With Redux, Hooks and Images

    • Interesting Use Cases: Offloading Data Manipulation, Image Processing, Background Data Syncing, Background Indexing for Fast Search
      

17. What is a Performance Culture and How to Build One?

    • The Importance of Systemic Performance Awareness For The Business

    • How to Communicate Performance Concerns to Business Stakeholders

    • Translate Business Objectives into Performance Metrics

    • How to Monitor and Evaluate Progress

    • Reporting the Financial Consequences of Web Performance Optimizations
      

18. How to Use Google Lighthouse For Advanced Performance Measurements

    • Installing Google Lighthouse

    • Running a Lighthouse Audit

    • Analyzing Lighthouse Reports: Performance Metrics, Opportunities, Diagnostics

    • Continuous Performance Monitoring

    • Sharing and Comparing Lighthouse Reports
      

19. How to Use WebPageTest For Advanced Performance Measurements

    • A Recap of WebPageTest's Key Metrics Including SpeedIndex

    • Analyzing WebPageTest Results: Waterfall Charts, Filmstrip View, Custom Metrics

    • Continuous Performance Monitoring with WebPageTest

    • The Waterfall Charts' Compare Feature

    • Best Practices and Tips for Effective Profile Comparison

Table of Contents

1. Lazy Loading What is it and How it Works

2. React: Implementing Lazy Loading

   1. 14 Pro Tips

3. The Combo: Code Splitting And Lazy Loading

4. What to Lazy Load and When

   1. Lots of Images or Other Media

   2. Huge Bundle Size

   3. 3rd Party Scripts

5. Generic Strategies For Identifying The Best Targets

6. Next.js: Implementing Lazy Loading

   1. 5 Pro Tips

7. More Next.js Tools for Optimizing Loading: next/image, next/script, next/font

8. When NOT to Lazy Load

Hey Frontend Ninjas,

In this chapter you are going to acquire one of the secret, ultimate techniques of performance grandmasters used to divide and conquer (pun definitely intended) slow loading websites since the dawn of the web era.

But before we start the training, a word of warning: lazy loading isn't for the faint of heart! It's an incredibly powerful technique for improving network performance and enhancing the user experience but it can also mess up your React application’s loading behavior if not done right. That’s exactly why I will teach you what lazy loading is, what are its effects, its typical use cases, how to identify where it’s best applied, where it’s best avoided and of course how to implement it perfectly with plain React and the tools coming with Next.js. Let’s jump right into it!

Lazy Loading: What is it And How it Works

Lazy loading is a technique that allows you to defer the loading of resources, such as images, scripts or React components until they're actually needed. This concept is based on the idea of "just-in-time" delivery of content: instead of loading all resources upfront, you only load what's necessary for the moment, and fetch additional resources as required for user interactions. The result is a faster loading time and more efficient use of network resources. An ideal outcome! 🚀 Combined with code splitting, this will become one of the most frequently used tools in your performance tuning toolbox! No wonder, it helps to temporarily increase how much your application resembles the ideal website. (Details are coming in Chapter 3: Learnings From The Fastest Website of The Universe)

The DPS of Lazy Loading

So that’s lazy loading in a nutshell, but why is it so useful? Let’s take a look at some real-life results:

• By implementing lazy loading ClearTax improved their initial load time ~50%.

• Quran.com shaved off 50kb from their entry chunk by lazy loading non-critical components.

• Max Rozen halved the TTI on one of his previous projects by moving 200kb of code from the main bundle to a lazy loaded chunk.

Those are some massive gains! As we discussed in the introduction chapter, these could translate to serious financial gains on the right projects. The potential is tremendous so let’s get to the implementation details!

Implementing Lazy Loading in React

Ever since v.16.6, React has a built-in solution to execute this attack. A bit later I will also show you the legacy solutions and why some of them might still be relevant today. With this simple approach implementing lazy loading is not difficult at all.

You can lazy load components using React.lazy().

This function takes another function as its argument, which should return a dynamic import() statement for the module you wish to lazy load. Here’s a minimal example:

import React, { lazy, Suspense } from 'react';

const SneakAttack = lazy(() => import('./DelayedComponent')); 

function LightningFastApp() { 
  return (
    <div>
      <Suspense fallback={<div>Camouflage...</div>}>
        <SneakAttack />
      </Suspense>
    </div>
  );
}

export default LightningFastApp;

Let’s break down what’s happening here.

1. We are importing the basic moves from ‘react‘ to build up the combo.

2. We define the custom component (DelayedComponent) we want to load in the background, escaping the line of sight of the users. (Well, not exactly in this example, but in real life situations)

3. We create a simple but lightning fast top-level component to house the SneakAttack we are about to deliver.

4. We wrap the SneakAttack in camouflage while we are preparing the ambush. Meaning, we simply provide fallback content to be displayed while the loading part of lazy loading is in progress.

5. We tell React to deliver our SneakAttack by rendering it as a component. That will initiate the fetching of the DelayedComponent and replace the fallback with it once arrived over the network or from cache.

You might have noticed that this example really doesn’t make much sense. All it does is delaying the rendering of DelayedComponent by one render cycle (+ loading time). So this way it likely just worsens performance. You can check out a more meaningful implementation in the official docs where the loading only happens after a user actually tries to access a feature. However, even this version is good enough to discuss some important tips!

💡 Pro Tips (lots of them…)

• Always Use Suspense: Suspense works with React.lazy by default, offering you an easy way to provide some content to the users while the resource requested is in transition. Choosing the right placeholder is an art in and of itself, I will share some tips about it down below.

• Pitfall With The Target of Importing: React.lazy - out of the box - only works with the default export of a module. If you want to lazy load a component exported by name, there’s a workaround: re export it from another file as the default export. (Read the old docs for an example). Alternatively you can use this approach:

  const LazyNamedComponent = React.lazy(() =>
    import('./Named.js').then(module => ({ default: module.Named }))
  );

  Or with a bit more up to date syntax:

  const LazyNamedComponent = React.lazy(async () =>
     await (import('./Named.js')).Named);

• Pitfall With The Place of Importing: Make sure to import the lazy loaded component outside of any component’s code at the top level of the current module (file). If you move it inside one, a rerender can re-run the import and you will lose the current state of the already mounted lazy-loaded component whenever that happens.

• Pitfall With Mixing Import Types: If you happen to load a component with the regular (non-dynamic) import syntax as well as dynamically, the latter will be disregarded and the code will be packed into the main bundle. Keep this in mind to avoid unpleasant surprises on the network tab! 🙈

• Pitfall With Import Path: You can not use variables or string templates in the import path. It has to be a direct import with a simple string. You will read about a possible workaround just a bit further down in this list in SSR before React 18.

• Pitfall With Tree Shaking: As dynamic imports can’t be analyzed at build time, to help bundlers with tree-shaking unused code we need to follow the official workaround and reexport our named components as a default export from a standalone module. This way bundlers can weed them out when necessary.

• Pitfall With Deep Linking: (Specifically links with an id at the end eg: www.fast.site/#speed.) I can tell you from first hand experience, if you want to have deep links and lazy loading at the same time… you don’t get to eat your cake and have it too. At least the browsers are not going to scroll to your content marked with the id in the URL as it’s initially not in the DOM and they don’t care that it appears later. There’s a workaround though! If you want to emulate that behavior just check the URL with JavaScript once the component is loaded and trigger the scroll programmatically when it matches.

• Timing Concerns: Just as much as lazy loading can improve the user experience by enabling a faster initial load it can also destroy it if you don’t time the starting right. Ensure that loading is triggered as soon as necessary to minimize or completely eliminate the visible loading of the lazily loaded content. I mean, who likes those web shops with infinite loading product lists. slowly crawling for the next batch whenever you hit the bottom of the screen? I don’t for sure.

• Avoid Layout Shifts: CLS is a metric in Web Vitals, meaning besides impacting user experience it also impacts search engine ranking so it’s crucial to minimize it. When there’s something on the initial view of a page (not just above the fold!) that you are lazy loading, you face the challenge of having to properly size the placeholder content so that it matches the size of what will be displayed later. It’s necessary to avoid janky shifting of the layout (more on this at web.dev) leading to a higher CLS value.

• Use Skeletons Instead of Spinners: The current best practice is to use low resolution / low detail mock content as placeholders. The next minor challenge with this approach for the performance maximalists is finding the right balance between detail and payload.

• Avoiding Fallbacks With The startTransition API: Sometimes it makes sense to prevent displaying fallback content while the lazy loading is in progress. A good example is a tab switcher with lazy loaded tabs. It’s a better user experience to see the old tab and have it interactive until the new one is ready than watching a flash of the fallback placeholder whenever the user clicks on another tab. Check the official method documented in the old React docs (nope, I couldn’t find it in the new) how to pull it off with the help of startTransition.

• SSR and React 18: React.lazy and SSR are not used to play nicely together before v18. But that’s now in the past. You can read more about the details in one of React’s GitHub discussions on architecture. In a nutshell lazy now enables you to segment the UI into separately renderable parts so you can stream some high priority content sooner. This naturally means first class support for lazy loaded components on the server.

• SSR Before React 18: In the age of old (or current projects pre-upgrade) we used to use either Loadable Component’s SSR support (intro here) or React Loadable’s (read more here). It’s worth noting that React Loadable is not in active development anymore but some projects still use it just all right (even with the officially incompatible Bable & Webpack versions) . Loadable Components is the de-facto successor and it has other merits (docs a bit outdated about SSR) that might warrant adopting it even with React 18 including the option for truly dynamic importing as you can use variables or string templates to define the import path with it.

• Route Based Lazy Loading: With React.lazy you can lazy load anything not just routes. However you might actually want to lazy load routes in a plain React app. React Router supports that use case out of the box with the lazy prop and dynamic imports. Read the details here.

Lazy Loading Is The Second Step in a Combo Move: It Starts With Code Splitting

We jumped straight to the finishing move but it’s true, in order to execute the lazy loading attack you first need to prepare something that you will load lazily.

How can we do that? That’s where code splitting joins the battle! In the world of native ES module support in-browser you could simply write and host a module yourself… but come on, that’s so 1990s. Today, virtually everyone works with a bundler like Webpack, Vite or Turbopack. Those tools will take care of splitting your modules according to what you want to lazy load. Webpack for example uses the presence of a dynamic import as the indicator to where to split the application to multiple files. In the end it will output pieces of JS code called “chunks“ that your app will be able to download and use separately.

💡 Pro Tips

• Keep an Eye on The Size: Next.js will automatically display the size of all the output chunks at build time which makes it easy to manually check how we are doing. For monitoring and enforcing performance budgets on assets sizes you can read a comprehensive guide here. (Later on I will also cover this topic in detail.)

• Without Next: Vite can do that same reporting for you by default. In Webpack land there are tons of useful plugins for this same purpose. Although a bit old, this is still a very cool article describing how to set them up for some serious performance wizardry.

What to Lazy Load and When?

Now that we’ve learned a few things about what lazy loading is and how to implement it in our React apps let’s focus on our enemies for a bit. You need to know about their weaknesses in order to choose a super effective attack against them! This section will include strategies and generic advice on when lazy loading can best help in improving performance.

Weakness #1: Lots of Images or Other Media

Imagine you're building an e-commerce website that showcases a wide range of products. Each product has multiple high-resolution images, making the site extremely image-heavy. Loading all these images upfront would lead to slow load times and a poor user experience.

By implementing lazy loading for images, you can ensure that only the images visible on the user's screen are loaded, while the rest are fetched on-demand as the user scrolls or clicks around. This saves bandwidth for the users and significantly improves the initial load time and overall performance of your website. And nothing restricts us to only images, we can deal with videos or even audio in the same way.

💡 Pro Tips

• Progressive Image Loading: One of the best ways to deliver a good user experience while lazy loading images is to inline a very low resolution version of the image, render it blurred, initiate the fetching of the original and replace it with the full image once it’s loaded. Using a placeholder with the correct aspect ratios also helps with preventing a CLS increase. We will cover this technique in much more detail in Chapter 11: The Snappiest Static Assets on The Planet. In the meanwhile you can take a look at how Medium implemented this pattern or check out some of the most popular tools for creating those placeholders: LQIP and SQIP (used by yours truly on fullcontextdevelopment.com/blog).

• Modern Formats: Another thing you can do to improve either the lazy or normal loading speed of images is using modern image formats like WebP or AVIF. These formats provide better compression and quality compared to traditional formats like JPEG or PNG.

• CDN: Consider using an image focused CDN that can help you optimize and serve those visual assets as fast as possible. (Looking for a sponsor here 🥺)

Weakness #2: Huge Bundle Sizes

For large-scale applications with numerous components and features loading everything at once can be resource-intensive and slow. Many SPAs fall victim to the growing main bundle size syndrome, when slowly but surely the production build size spirals out of control.

A typical example is the good-old admin dashboard with lots of charts and diagrams, but any client-side-logic-heavy application can easily start to develop the symptoms. To resolve it you can lazy-load individual widgets or even full views of the app so they're only fetched when the user interacts with them.

💡 Pro Tips

• CRP Optimization: One of the most frequently used techniques to help with this problem is called Critical (Render) Path Optimization. In a nutshell, it’s about packing above-the-fold content into a separate bundle/chunk than the rest of the page so the users first download only the “critical“ or minimal part needed to interact with the site meaningfully. We will spend a whole chapter on this topic in: Chapter 7 Implementing Critical Render Path Optimization With React and Next.js. That’s how important this technique is!

• Other Assets: You can read a really nice generic introduction to lazy loading on MDN that also discusses how to use this technique with fonts, images and even iframes. It mentions techniques for reducing the render blocking time of CSS and introduces one of my favorite tools, the Intersection Observer API too.

• Use The Intersection Observer API: It’s a very effective weapon widely used on the web for killing slow page load times! The basic idea is to only initiate fetching a component’s chunk once the observer tells us it would become visible on the screen. It’s even better if we time it just a bit earlier than that so it will already be there once the users scroll to its position. I’ve used this technique a lot in my own projects and I plan to show some as examples later but for now I will link you to a nice tutorial about its implementation combined with React.lazy.

Weakness #3: 3rd Party Scripts

Very common performance hogs that lazy loading can effectively beat are the 3rd party scripts. They are often loaded immediately as the HTML is just being rendered for the first time. They sometimes even get bundled into the prod build of the application! 🤯 But in reality, they are often not needed immediately for the site to function as intended. It opens up the opportunity to lazy load them.

Good examples are 3rd party chat or comment widgets, captcha services or the code of any external services. In some cases even analytics or cookie consent code can be deferred! Eliminating these from the initial render of the app can often significantly improve the performance characteristics of a site. A real life example shared by MediaVine is how they improved their initial ad load time by 200% with lazy loading ads!

💡 Pro Tips

• Lazy Loading Scripts: The tools of the trade here are the HTML attributes called async and defer of the script tag and the rel attribute of the link tag with the preconnect and dns-prefetch values. Here’s an awesome article on web.dev showing exactly how to use them for some serious speed improvements. Key takeaway from there: use async for highest priority scripts and defer for less critical dependencies. But there are some exceptions, check the article.

• Lazy Loading Anything: You can lazy load just about anything that an ES module can hold. It naturally includes npm packages too. You can load them at any place or time simply by (await import(‘name‘)).default-ing them. The Next.js docs have a nice example of how to put it to good use. In the next section I will also share some strategies about how to utilize this for the best possible speed improvements.

Going forward, whenever a wild slow website appears with any of these weaknesses, you will know how to deal a super effective blow to them! In my experience this is really valuable knowledge so you already acquired some good skills! Let’s continue!

Identifying The Target 🕵️

Now that you can easily recognize the general patterns where lazy loading can help, we can also look at the generic approach to find good targets for this technique. Here’s what you should be looking for:

• Components that aren't immediately needed on the initial view. Good examples would be modals, heavy dropdown menus or any element of the UI that appears on interaction.

• Components that have a significant impact on loading time. As usual, doing a performance profile and analyzing the network/render waterfall is the best starting point. Some typical offenders you might find are large data tables, huge charts or not-always-used npm packages (like date handling… moment.js anyone?).

• Components that are always conditionally rendered.

• Components that are only present in certain routes of the app yet are put into the main bundle somehow. (mistakes happen)

• Infrequently used features are also great targets for lazy loading. You can improve the UX for the majority of the users if you lazy load the least used parts of the app. The best way to identify them is going empirical. Use analytics or monitoring/logging data to see the interaction patterns of your site and look for those less frequently used features. ☢️ Make wise judgements. The least frequently used parts can still have critical importance.

• Imports that are only needed when/after the user starts an interaction. If there are imports in a module that fit the description, you can either defer their loading until the user’s first attempt to use them or manually prefetch them even sooner so they wouldn’t have to wait.

👉 Infinite scroll is also a kind of lazy loading pattern but I’m sure you will know when you need it without any special speed improvement goals.

🧠 Performance Mindset

I found it really helpful in developing a performance mindset to pick up the habit of considering what to lazy load in the design phase of work. Be on the lookout for the above cases and you might avoid the need to “optimize performance” in the future, instead you could “simply“ keep it high all along. That’s the best thing you can do for your users and company profits too!

Lazy Loading With Next.js

You have already learned a ton about lazy loading in general and in combination with React. Now let’s go deeper and take a look at the unique tools that Next.js offers for implementing this technique!

Next takes the DX of lazy loading to a whole new level with its automatic code splitting and dynamic imports. By default, Next.js will split your codebase at the page level, ensuring that users only download the code required for the current URL. That’s a nice little favor from the framework authors, saving us all some time and effort.

👉 Now with React Server Components (RSC) it can automatically save you from including JS in the output of SSR when the code is only used for rendering but not needed for client-side interactivity.

To further optimize your Next.js application, you can use dynamic from next/dynamic to lazy-load individual components. It gives us the same level of control over loading behavior as React.lazy and a bit more!

Here's a cookie cutter, basic example of how to use it:

import dynamic from 'next/dynamic';

const LazyLoadedByNextJS = dynamic(() => import('./MyComponent'), { 
  loading: () => <div>Loading placeholder</div>,
  ssr: false,
});

function App() {
  return (
    <div className="App">
      <LazyLoadedComponent />
    </div>
  );
}

export default App;

It kind of follows the same pattern as the “native“ React solution. There’s not much difference between these two now in the v18 era as dynamic uses Suspense and React.lazy internally. Its only significant, added feature is that you can prevent the lazy loaded component from rendering in SSG and SSR mode by passing the ssr: false config option to the dynamic call. Otherwise the component would be loaded and rendered in those situations too. (Of course only if the UI logic is set up that way.)

When do you need that ssr: false? Most frequently, in case of rendering stuff that:

• Relies on browser-only APIs, like WebGL or the DOM.

• Displaying real-time data like a chat widget or stock price chart where you might not want to show outdated information on the initial load.

💡 Next.js Pro Tips

• App and Pages: There’s no need to worry, next/dynamic works the same way in both folders.

• Loading Placeholder: As you saw in the example, you can provide the placeholder component as a config option to the call.

• Importing Default vs Named Exports: next/dynamic has the same issue with named exports as React.lazy (no wonder considering it’s using that.) As a work around you can do this:

  const NamedLazyLoadedComponent = dynamic(() =>
    import('./NamedComponent').then((module) => module.Named)
  )

• Client and Server Components: Server components are code split to their own chunks by default and can be streaming-rendered. Lazy loading is only relevant when working with client components. If you try to lazy load a server component only it’s child client components will be lazy loaded (if there’s any).

• The Place of Calling Dynamic: Calling dynamic has to be in the top level scope of the module (file) in order to work. It means you can’t write it inside functions or React components.

That’s how you do generic lazy loading with Next.js but it has some additional tools that can be used to implement this method in specialized cases.

More Tools in Next’s Arsenal With Lazy Loading Powers

Next/Image: The developers of Next.js have upgraded the img tag with special capabilities and made it available through the next/image component. Some of those has lots to do with lazy loading. They designed it in a way to only load images when they enter the viewport. You can optionally provide a blurred placeholder with the blurDataURL prop or if you are directly importing an image with a supported format the blurred version will be auto generated for you at build time when you use the placeholder prop.

Another neat, performance aware feature is the many built-in ways the component takes care of CLS as it will always reserve the right size for the image, even before it’s loaded. In addition, you can “mark“ an image as priority. This is best used for the LCP (largest contentful paint) image on each page so that it will be prioritized for the earliest possible load. Make sure to utilize this component to the max. It’s a very powerful and useful optimization tool that can do much more than what’s related to lazy loading!

Next/Font: Well, this one is not directly related to lazy loading fonts, just to loading them, but I might as well mention it here. next/font allows you to control when and where the different font files are loaded depending on where you use it. It also depends on whether you are rocking the pages or the app folder.

In the case of pages, fonts requested with next/font will be preloaded on that single route and fonts requested in the custom app will be preloaded globally.

Working within the app directory you have more options. Requesting a font inside a page works the same way, however you can also request them in a layout that will preload the font for every route wrapped by it and non-surprisingly if you request one in the root layout it will be preloaded globally.

The nice thing about next/font is that it does a lot more to ensure your app won’t suffer from any related performance issues. Most notably it can load fonts while ensuring zero layout shifts by using the size-adjust CSS property. A must use if you are dealing with fonts in a Next.js application.

Next/Script: You can use next/script to control the timing of load and the scope of 3rd party scripts. Again, it can do more to optimize app performance than what’s related to lazy loading so make sure to check out the docs if you are interested. (I will cover those areas in other chapters later.)

What’s relevant here are the different loading strategies it offers, which makes it a very clean and easy to use tool for precisely controlling script loading. The most relevant strategy is called lazyOnload. It delays the loading of the script to the first time the browser’s main thread becomes idle.

Another interesting strategy is called worker which moves the loading of the script off-main-thread to a web worker using Partytown. It’s not compatible with the app folder as of July 2023. But when you are in a position enabling its use, this opens up interesting optimization possibilities. Mostly if the script is doing quite independent stuff from the rest of the application like analytics, A/B testing, or metrics collection.

🧠 Performance Mindset

These are the options offered by the framework for influence loading behavior. Remember, when you are reaching out for: React components, libraries, images, fonts or scripts you can and likely should use some of these tools on a Next.js based project.

Final Warning: When Not to Lazy Load

Before you go out and naively try to:

You need to realize, as with all design decisions there are tradeoffs to be made here. I will explain what you need to keep in mind when deciding for or against lazy loading something.

👉 If you want to see an easy to follow, step by step example of the core issues with naively lazy loading everything check out this excellent article from the authors of Qwik. Highly recommended. As well as the framework itself. It’s so innovative I’m sure it will drive lots of changes in other frameworks too.

1. Lazy loading only works properly with client side rendering. If you SSR a lazy loaded component you might come out worse in the end than without lazy loading or server side rendering. The JS for the lazy loaded component will be fetched eagerly on the client, as it’s needed for the hydration of the initial HTML. That means we created another unnecessary network request, that’s pure overhead in the process of reaching interactivity. If you had it loaded normally, its code would have been part of the main bundle and be available at this point. However if the lazy loaded component is purely CSR, this whole situation won’t happen. Issue solved.

2. Lazy loading is only useful for components not present in the current render tree in SSR mode. It usually comes down to two cases. One is lazy loading the next route and the other one is conditional rendering of a lazy loaded component. The reason is the same as before. If the code split chunk of the lazy loaded component is eagerly fetched for hydrating the initial SSR’ed HTML we end up shooting ourselves in the foot. However if the component is not present in it, we can still reap the proper benefits of lazy loading and in these two cases that’s surely what will happen.

3. You should never lazy load content needed for SEO. There’s just no telling whether the crawler will surely wait for the loading to finish or not. If you SSR the lazy loaded component to circumvent this, then we are back to problem #1.

4. Many lazy loaded components on the same view lead to hard to answer bundling questions. If multiple lazy loaded components are requested for the same URL, it might make sense to put them into the same chunk depending on when they will be requested. I’m sure you already feel the combinatorial explosion building up in your head. What would be best paired with what when the app navigates from A to B or from C to A. What about things that are fetched on user interaction. What about prefetching? Not every bundler is capable of handling this question properly so now we developers are responsible to think about this concern too.

5. Each code split chunk has some overhead. You need to be mindful that every chunk contains some additional JS code. The extra size can add up with each new chunk and their loading incurs network overhead too. All these can lead to situations where too many, small, lazy loaded chunks negate every performance benefit they provide otherwise. Evaluating the costs & benefits of a certain chunking setup is tricky, but luckily we don’t have to pioneer the solution. Here’s a guide on Hackernoon how to measure and fine tune chunk sizes and their performance impact.

That’s all the advice I have for you, student of the way of ancient performance grandmasters. Now you know how to lazy load, when to lazy and what to lazy load. Use it well and see you in the next one!

Challenge: Share The Diff

I would like to ask you to take what you learned here and put it to practice. Use the Lighthouse Diff Tool to record how you made a difference by applying lazy loading. If you share your results and a little background story here in the comments I will highlight the best 3 of those in the article!

Hey Web Devs,

Welcome to the first chapter of the ultimate web performance guide! I’m super excited to start this journey with you! This is the basic tutorial that the first time gamer needs to learn how to play the performance game. If you are a pro feel free to press the skip button, but I put in here some really interesting case studies and stats from big companies and big projects to make a solid and not-boring case for the importance of performance. With all that out of the way, let’s dive right into the world of performance optimization.

1.1. The Basic Definition of Web Performance

Web performance is a measure of a web application's speed, efficiency, and overall ability to load, render, and respond to user interactions. In future chapters we are going to cover each of those areas in depth but for now this simple definition is a good starting point.

📋 Case Study: What constitutes "fast"? We will define that later, now it’s enough to say that in a 2017 study made by Akamai researchers found that even a 100-millisecond delay in loading time can decrease conversion rates by 7% so even small performance changes can have huge financial consequences.

📚 Future Reference: We will learn how to quantify performance in the chapter: “Optimizing Core Web Vitals With React and Next.js“ and how to measure and analyze it in multiple chapters about the usage of 4 tools: “How to Use The React Developer Tools for Performance Optimization“ & “Google Lighthouse For Advanced Performance Measurements“ & “WebPageTest For Advanced Performance Measurements“ & “How to Use The Chrome Dev Tools Performance Panel“.

1.2. User Experience and Web Performance

First and foremost, web performance is all about creating a positive user experience and a key part of that experience is speed. When your site loads quickly, users can find what they're looking for without staring at “the loading screen” / “spinner hell“. And as we all know, happy users are more likely to stick around, recommend your site to others, and even make purchases.

📋 Case Study: In 2016 the Financial Times ran an experiment where they artificially delayed their page load times and found that a 1-second delay in page rendering could potentially cost them up to 4.9 million users per year.

📚 Future Reference: We will learn how to identify the user experience impact of our React/Next.js app’s speed in the chapters: “The RAIL Model, the React and the Next.js“ and “What is a Performance Culture and How to Build One?“

1.3. Web Performance and SEO

Web performance isn't just about retaining users on your site; it's also about attracting them in the first place. This is where Search Engine Optimization (SEO) comes in. Google, the most widely used search engine, includes site speed (and as of today, Core Web Vitals) as one of the many factors influencing search result rankings.

Improving your site's performance can increase your visibility on search engine results pages (SERPs), drive more organic traffic to your site, and enhance user engagement and conversion. Conversely, a slow-loading site can cause your SERP rankings to drop, reducing your site's visibility and impacting your site's ability to attract new users.

📋 Case Study: Pinterest managed to improve their site speed and witnessed a 15% increase in search engine traffic and a 15% increase in sign-ups.

📚 Future Reference: SEO is vaguely related to a couple of topics covered in “The RAIL Model, the React and the Next.js“, “Optimizing Core Web Vitals With React and Next.js“ and

1.4. Web Performance and Business Success

The impact of web performance extends beyond user experience and SEO. It directly affects business metrics like conversion rates, customer retention, and overall revenue. This is the key to the special attention this field enjoys. As the Akamai study showed, a one-second delay in page load time can lead to a 7% loss in conversions. That means an e-commerce site making $100,000 per day could potentially lose $2.5 million in sales every year from that small delay.

📋 Case Studies: Rakouten 24 a Japanese online-store giant (as reported on web.dev) have achieved amazing results by improving web performance: an increased revenue per visitor by 53.37% and conversion rate growth by 33.13%. A more recent Portent study showed that websites that load faster than 1 second have 3 times the conversion rate compared to sites that load in 5 seconds.

📚 Future Reference: The chapter “What is a Performance Culture and How to Build One?“ has extensive coverage of topics like how to communicate performance concerns to business stakeholders. There I show you how to define the connections between performance and business metrics, company KPIs and OKRs.

1.5. Web Performance and Accessibility

Web performance also plays a role in making the web accessible to everyone. Not all users have access to high-speed internet or high-powered devices. For many, slow connections and low-end devices are the norm. By optimizing performance, you ensure that your website is usable and accessible to these users as well.

Performance optimizations can also lead to improved accessibility in other ways. Using proper, semantic, accessible HTML tags can reduce cluttered DOM structures or weighty JavaScript solutions, or optimizing your site's images also gives you an opportunity to provide alternative text for them, which is beneficial for users who rely on screen readers.

📋 Case Studies: While I’m not aware of studies about how performance optimization improves accessibility there are indeed talks on YouTube or blog posts drawing the connection between these two areas.

📚 Future Reference: The tools and techniques related to this aspect are broad and general, spread over the whole material. Ultimately all our efforts will help to improve the Accessibility of our sites.

1.6. Web Performance and Sustainability

If you feel strongly about sustainability and environmental impact, web performance might just become a new favorite of yours! The energy consumed by servers, network infrastructure, data transfer and the devices we use all contribute to carbon emissions.

The more performant a website or application, the less processing power and energy the user's device needs to render and run the site or app. By making your websites more efficient, you're effectively reducing the energy usage on millions of devices, which can have a considerable cumulative impact. Reducing the data transmitted over those optic-fiber cables also has positive effects in this sense.

📋 References: If the internet were a country it would be the 6th largest polluter. No wonder there’s a green / sustainable web movement. You can learn more about it at places like The Green Web Foundation or the Website Carbon - where you can also calculate the CO2 emission of your website. Or you can grab a popular book on this topic: Sustainable Web Design. Perhaps take some quick tips from Fershad Irani, a web sustainability consultant.

📚 Future Reference: As with accessibility, most parts of the guide contribute to achieving a more sustainable version of any website through the overall performance improvements.

1.7 The Unique Challenges of Modern Web Applications

Modern web applications are super exciting to build! We get more support from the frameworks than ever before in web development history to create awesome apps fast, but they also come with their unique set of performance challenges.

As we increase the complexity of our projects, the size of JavaScript bundles often grows as well and it’s not always straightforward to even know what goes into them. These large bundles then take longer to download, parse, and execute, which can significantly impact performance, especially on mobile devices or slower network connections. There are many options to fix this problem but it’s not always obvious which approach would bring the best results.

On the flipside of frameworks we need to make more choices than ever before. Whether to use runtime or build time CSS tools? Or to use any at all? How to solve the issue of cache invalidation? How to import images? How to configure the bundler? Or which one to use? What’s the appropriate rendering strategy?

Having a deep understanding of every factor is an enormous challenge but they are all important decisions to be made that can impact web performance. I will give you answers or strategies to come up with your own answers for all these questions and more using a web performance mindset.

1.8. Special Considerations for React.js and Next.js Performance

React's component-based architecture makes it easy to build scalable and maintainable applications. However, inefficient rendering of components can lead to wasted computations and sluggish UI. Most of you surely know that every time the state of a React component changes, the component re-renders. If not managed properly, this can lead to unnecessary renders and under certain conditions, noticeably slow down your applications.

And our concerns are far from over! Hooks themselves are a performance tradeoff (you know invoking extra functions every render) and there’s no one-size-fits-all solution when it comes to their use. The ubiquitous question of what’s the right place to store state in a React app also has performance implications. Then there are questions about the state itself. Should it be mutable or immutable for example. Did you know that’s a performance tradeoff too?

Similarly, Next.js brings server-side rendering, static site generation and their different flavors to the React ecosystem, which are fantastic tools for performance and SEO, but also add complexity and potential pitfalls. What if SSR goes on for too long? What if SSG content gets out of date? What if your hosting provider doesn’t even support the latest features of Next?

Good infrastructure, efficient data fetching, caching strategies, streaming support and the appropriate usage of the different rendering strategies can play a crucial role in delivering a performant user experience powered by Next.js.

For all these reasons and more, it’s crucial to have deep familiarity with the tools and techniques available in the React ecosystem to max out the positive impact of speed on our projects.

If you feel like you’re up to the challenge let’s get started for real in the next chapter!

While that opening statement is not necessarily true, that’s how I always felt about web performance. For me, performance optimization is the most challenging and exciting part of frontend engineering work and in this series I want to help you master this skill with a special focus on React.js and Next.js apps.

I believe web developers can benefit immensely from this expertise on multiple levels. Performance is one of the top goals that drives the creation of the newest and most innovative frontend technologies. Some of the best developers of our time are dedicated to relentlessly pushing the boundaries of what’s possible in web and browser performance. It’s a world full of exciting challenges, surprising discoveries to be made and there’s always something new in the making. It’s just a lot of fun to be involved with.

But that’s not all! Web performance optimization is about so much more! I’m 100% sure you already have a pretty good understanding about the why. We all abandoned websites because they were loading or reacting frustratingly slowly and for businesses that translates to lost revenue, sometimes lots of lost revenue. It’s not a surprising fact that big companies are willing to go far to prevent those losses from happening.

However, for us developers, the story is a bit different. I believe most of us want to create web experiences that we can be proud of and that’s exactly what I want to help you to do! I will teach you all the intricacies of developing, shipping and maintaining fast (and furious) React or Next.js web apps, capable of serving millions of daily users with a top-notch user experience that you can proudly reference on your CV, LinkedIn or your social media channel of choice (and get tons of likes or whatever).

I will cut open the internals of the Browser platform, React.js and Next.js to teach you the ultimate techniques of web performance optimization. It’s going to be super insightful, practical, results oriented, full of examples, case studies and useful tips.

And there’s a final truth behind all this, that I will teach throughout the whole material.

To get performance right long term, It should permeate every aspect of our work so I will teach you the everyday habits and the mindset necessary to do so.

What’s Included?

We will analyze React and Next.js to the deepest level and learn all the foundational and advanced tools and techniques to fine-tune their performance characteristics. The material also covers all the necessary, framework independent topics like: the RAIL model, controlling the browser cache - header configuration and invalidation strategies, utilizing web- and service workers and other native browser APIs like the Navigation and Resource Timing APIs, Intersection and Resize Observers and different animation techniques.

You will learn about the most efficient use of the popular performance measurement tools: Chrome Dev Tools, Lighthouse, WebPageTest, React Development Tools, Storybook (yes, that Storybook) and more.

The guide covers how to build a performance culture in an organization, including development process best practices for measuring, tracking, monitoring, maintaining and continuously improving the performance of a project. It also covers human factors for example with an intro to communication techniques used to reach alignment on performance goals with business stakeholders.

And the list is far from over. I will equip you with the whole set of tools and techniques required to develop and maintain (mostly but not exclusively) React based websites that serve millions of daily users while offering a world class user experience. If that doesn't sound exciting for a frontend engineer I don't know what does!

Take a look at the whole list of topics in the Table of Contents if you haven’t done so and start your web performance journey straight away! It's gonna be lit devs!

Hey Full Context Developers,

Welcome to the next High Impact Frontend daily post. We are exploring some recent news about React and Next.js today.

About the system: If you need introduction to my scoring or impact analysis systems, check out any of the recent weekly releases (for example this), and the generic introduction post.

Why React Re-Renders

🏆 News of the Day 🏆

📊 16 Points: Hype 4 x Value 4

There are only two ways for improving the performance of a React application, by eliminating unnecessary renders and minimizing total payload size. That’s why understanding the rendering behavior of React is an important - and tricky - task.

The full name of the article is: The Interactive Guide to Rendering in React and it fully lives up to that. It’s one of the best illustrated and most thorough material about this topic I ever found. And I mean it, not trying to hype it up.

Here are some (and far from all) of the covered topics:

• What is rendering?

• When exactly does React re-render a component?

• Batching: how React calculates state

• Why we can't just assume that a component only re-renders when its props change.

It’s funny that after reading like 80% of the article with resolve to learn how to eliminate every little unnecessary re-render it also tells us this:

React is very good at rendering. If you have a performance problem, the reality is it's rarely because of too many renders and if it is because of too many renders, you're most likely doing something wrong.

Well, I guess it’s good to know at least for interviews then?

Who should care?

➡️ Every React developer, but especially those who are building Level 2 and above web-complexity projects where the user perceived performance directly affects business results.

Which Impact Factors can this affect?

➡️ This is all about Customer Experience as the result of performance optimization is experience optimization. If you are struggling with this topic it can improve Productivity a little bit as well.

Best case impact:

Customer Experience - System | Productivity - Unit

Eliminate Flickering From React Apps

📊 16 Points: Hype 4 x Value 4

I hate it when Cumulative Layout Shift ruins my first experience of a website and so does you! I hate it even more when I’m the one creating such a site.

I had some tough times figuring out how to eliminate or reduce that flickering and this article succinctly called: Say no to "flickering" UI: useLayoutEffect, painting and browsers story gives us the knowledge and tools required to do just that!

The main topics include:

• How to change elements based on DOM measurements

• What is the problem with useEffect

• How useLayoutEffect fixes it

• What is browser painting

• How SSR plays a role

Who should care?

➡️ Every React developer regardless of the web-complexity level of their projects but especially those who work on products where a smooth user experience directly affects business results.

Which Impact Factors can this affect?

➡️ It seem this article and the previous one are in a similar category. This one too is all about Customer Experience as it’s about directly improving the UX of websites and apps. If you are struggling with a similar task, it can improve Productivity a little bit as well.

Best case impact:

Customer Experience - System | Productivity - Unit

Securing Your Next.js 13 Application

📊 12 Points: Hype 4 x Value 3

To be honest, now that I’ve been playing a lot with ChatGPT I can’t help but feel like this article is AI generated. (What’s your impression?) Nonetheless, it’s a nice introduction to securing a site using HTTP Headers and mitigating Cross Site Request Forgery.

You get Next.js specific code examples and a short introduction to each component like:

• Content-Security-Policy

• Referrer-Policy

• Strict-Transport-Security

• X-CSRF-Token based mitigation

Who should care?

➡️ Mostly developers using Next.js but it’s not too framework specific so if you are interested in these security topics you can take away something. The same can be said about projects of course depending on the criticality of security needs.

Which Impact Factors can this affect?

➡️ Security is a “silent“ contributor to Customer Experience. It’s generally unnoticed, and if you are lucky you never get to experience the level of “improvement" it offers in this regard. However when things hit the fan because of a breach, that’s the time the drastic contribution of security measures can really be felt. If you are struggling with a similar task, it can even improve Productivity by a little bit.

Best case impact:

Customer Experience - System | Productivity - Unit

Wrapping Up

If you enjoyed this High Impact Frontend daily post and/or found it valuable please consider sharing it with your friends and colleagues. It’s a huge help to keep this newsletter running! (Not financially, but through the motivation it gives me. 😎)

See you in the next one!
Joe @fullctxdev

Hey Full Context Developers,

Welcome to the first daily issue of the High Impact Frontend Newsletter. I will try a new approach to keep the momentum going. (Which was down recently.) The plain is to publish smaller pieces of content on a near-daily basis and send out a properly ranked compilation as the weekly newsletter.

About the system: If you need introduction to my scoring or impact analysis systems, check out any of the recent weekly releases (for example this), and the generic introduction post. I added the web complexity scale to the very end for reference.

Special note: I will only publish these daily posts on the Substack website starting with the next one. This goes out as an email too, but only this time to let you all know what’s happening. Hope you will like this format and follow along on the site!

Full Context Development

Crafting the Next.js Website

🏆 News of the Day 🏆

📊 16 Points: Hype 4 x Value 4

I honestly felt bad for covering so little front-of-the-frontend stuff recently. You know the kind of news that’s not about frameworks, meta-frameworks, SPAs or MPAs but pure HTML, CSS and JS/TS. There are lots of interesting things going on in that part of our field with the potential of high impact and today I will finally talk about a lot of those.

The first and most impactful of such news comes from Rauno Freiberg. A detailed article about his experience building the new Next.js website. 🤩

I don’t know about you but for me Vercel together with Next.js are one of the most interesting spaces in the current frontend landscape. They are relentlessly pushing the boundaries of frontend technology forward. They gather some of the most innovative and influential technologists of our field under the same company. They engage with the largest players of the Web like Google, Meta and Microsoft. So I keep a close eye on what they are up to and usually whatever comes out of their secret, underground lab is world class in quality, definitely worthy of attention. (I guess you could call me a fan)

With all that in mind, when I saw this article I got really excited and it didn’t let me down. Rauno offers us a look into the fine details of crafting a technically excellent frontend experience, it just blew my mind. You can learn about:

• Dynamic & responsive grid lines around elements

• Blinking switchboard effect that’s consistent across browsers and avoids unnecessary re-paints

• Consistent focus states

• A nifty trick to create beautiful quotation marks

• Explicit accessibility labeling

• How to use data attributes for styling

• Gradient tracing

• Smooth border fade-out

It’s the kind of front-of-the-frontend stuff I was talking about and between you and me, this is the level of expertise that makes me secretly jealous. Hopefully in another 10 years I will have mastered some part of the profession to this level.

What can we take away from the article?

➡️ For Vercel the impact of such a well crafted website is of course tremendous. Customer Experience is impacted through the user experience improvements, which is a huge driving factor of increased engagement. In this case that can translate to increased framework adoption, which increases revenue for Vercel in the end. Cross browser compatibility and accessibility are some of the key factors of creating new Business Opportunities as frontend engineers. This is very important to keep in mind and push for to deliver business value! They increase the addressable market by allowing a wider audience to engage with the website and become part of the user base.

➡️ For us this is a source of technical insights that can help to get similar tasks done more efficiently, increasing our Productivity and that always has the potential to help us with career advancement.

Who should care?

➡️ The most likely projects where these benefits can fully manifest are in the Level 1 and Level 2 web complexity categories. More specifically the user facing, conversion oriented websites, landing pages or engagement based platforms like web-shops, news sites or any other kind of content focused businesses. Some techniques like the consistent focus states and accessibility labeling are applicable more generally.

Best case impact:

Customer Experience - System | Productivity - Group | Business Opportunity - Organization

Web Workers For Practical Multithreading

📊 12 Points: Hype 3 x Value 4

Next front-of-the-frontend news focuses on JavaScript with a surprisingly practical take on Web Workers. I’ve used them a couple of times in production, in particular with Comlink to offload expensive Redux state management stuff, and looked into Partytown to speed up 3rd party code loading, but the kind of generic applications this article covers never appeared on my radar. The main topics include:

• Offloading CPU intensive work

• Handling network requests

• Parallel computation instead of sequential main-thread processing

You get code examples for each of these cases, a thorough exploration of the limitations and considerations of using web workers and strategies for mitigating those issues.

I will be looking for situations where these techniques can bring benefits to the projects I’m working on. It’s awesome to learn while writing the newsletter.

Question: Have you ever used web workers to achieve similar goals? If yes, I would love to hear your story in the comments down below. (I’m doing my best to create some engagement! Please talk to me 😭. Damn, I suck at this…)

What can we take away from the article?

➡️ By offloading appropriate work to web workers, we can make our applications more responsive. The RAIL model immediately comes to mind, these techniques can help to meet those budgets resulting in better Customer Experience. Depending on the situation it can mean life and death for a project. Where I used the off thread redux worker approach, if we couldn’t pull that off, the app would have been dysfunctional freezing for roughly 1 second in every 2 seconds. Even in less dramatic situations the gains can be massive by improving site loading speed and other metrics.

Who should care?

➡️ The Level 2 & 3 web complexity projects. Here again the performance sensitive, user facing, conversion oriented websites, landing pages or engagement based platforms like web-shops, news sites or any other kind of content focused businesses are best suited to reap benefits.

Best case impact:

Customer Experience - System

Maneuvering JavaScript’s Event Loop

📊 12 Points: Hype 3 x Value 4

Last front-of-the-frontend news is about JavaScript again from Alex MacArthur. You can learn the ins and outs of function execution order in the JS engines and the tools we have to manually place our code to certain points of it. It’s a topic that I rarely see covered. The main techniques it discusses are:

• The good old setTimeout

• MessageChannel

• queueMicrotask - With practical examples I never saw before !!!

• requestAnimationFrame

• requestIdleCallback

Everything has code examples here as well and nice diagrams too. I took away some new insights from here. What I missed from the article is a mention of how Observer callbacks behave. I know for a fact that the IntersectionObserver and the MutationObserver classes put stuff on the microtask queue.

Question: I’m really curious here as well, do you have experience with using the more esoteric methods in practical situations? Let us know!

What can we take away from the article?

➡️ This is a tricky topic. Real life situations where these tools come up are usually sources of confusion and are a pain to maintain. But that’s exactly why we all need to understand their details, in my experience these are unavoidable on the long run. As most of these technical articles this one comes down to increasing our Productivity and improving Customer Experience with all the benefits these provide.

Who should care?

➡️ The Level 2 & 3 web complexity projects. Here again the performance sensitive, user facing, conversion oriented websites, landing pages or engagement based platforms like web-shops, news sites or any other kind of content focused businesses are best suited to reap benefits.

Best case impact:

Productivity - Group | Customer Experience - Group

Wrapping Up

If you enjoyed this High Impact Frontend daily post and/or found it valuable please consider sharing it with your friends and colleagues. It’s a huge help to keep this newsletter running! (Not financially, but through the motivation it gives me. 😎)

See you in the next one!
Joe @fullctxdev

The Web Complexity Scale:

Hey Full Context Developers,

Welcome to another issue of High Impact Frontend. The goal of this publication is to cut through the noise of non-stop Frontend Tech buzz and bring you only the most impactful news that can create outsized, positive impact and change what you work with, the way you do development or even the meaning of your life. — Well, that last one is a bit of a stretch but I like to make these kinds of jokes …and I often get into uncomfortable situations because of it. 😅 🤷

I use the Full Context approach, my way to identify and explain the level of impact a tool or a piece of information can make. My goal is to offer a complete picture of when, how and who can realize that impact so you can easily find the most valuable news for you. You can find more details about this system in a dedicated post.

My absolutely top secret, hidden agenda behind all this is to teach developers how to connect the technical part of our work with its business and real-life outcomes, so I can help you to make better choices and create better software for everyone.

Summary

I feel very bad about it but I missed another week again, however the upside is that I had a lot more news to choose from and I found some mind blowing pieces. Here’s the overview:

• Call for stories!

• On-demand / Ephemeral / Just-in-time UIs driven by AI or a backend

  • And a tool to generate AWS services using an LLM

• Two ways to rethink the modern web

  • And one covert way to diss its creators

• Insights from Dropbox, transforming their web architecture to last the next decade.

  • And a large-scale demo implementation of the Clean Architecture using SvelteKit

• New frontend frameworks from Big Tech companies.

  • A survey of framework popularity on Netlify

• Code for writing new code in either TypeScript or JavaScript.

• A Vercel and Builder.io news special

• Clean code horrible performance the original video from the author Casey and and interview with The Primeagen.

  • Also a long written chat between Casey and Uncle Bob, the father of Clean Code.

• Quick news

  • The most common mistakes when using React

  • AWS infra setup to host Generative AI

  • Jampack - a static asset optimizer

  • Hidden telemetry in modern frontend frameworks

  • And more, a lot more…

• Newsletter Community Report.

I’m looking for stories, you can share yours!

I want to take the newsletter to a new level. In addition to reviewing recent developments of the frontend field I plan to share interesting, real-life stories in line with the High Impact & Full Context approach. If you have a personal story where a web technology related change brought significant business or organizational impact to a project please share it with me. I’m happy to introduce you to the readers and link back to your social profiles and personal website. Read more about the details here.

If you know about a good post or video fitting into this theme please send them my way, I will attribute everyone individually who shares some material. And if you know-somebody-who-knows-a-story feel free to refer them to me, we can build our own MLM pyramid scheme if you guys are into that.

The Scoring System

This is the Hype & Value scale I use to filter and categorize the news themselves. Evaluating their impact is a later step. The two values are multiplied to create the final score. Why? Because Hype increases the visibility of any news so it multiplies their impact whether that’s positive or negative. I will review some of the articles in batches as many of them are about the same or very similar topics.

High Scoring News (15+)

🏆 News of the Week 🏆

On-Demand / Ephemeral UI (AI or Server driven)

📊 15 Points: Hype 5 x Value 3

I came across multiple articles about the topic of On-Demand UI. While pretty much an exploratory area right now, it has huge potential to bring drastic changes to both how we create and how we use software. Here are the sources, then I will explain what this is about, and why it won the News of the Week title.

• ConjureUI - Generating throw away UIs with ChatGPT to get your tasks done and be gone. Impressive demo but nothing more.

• Malleable Software in the Age of LLMs - An in-depth, very insightful article that explores how new AI capabilities will change the life of users and developers alike. A bit optimistic in general but far from unrealistic.

• Server Driven UI, Personalization, Runtime Bundling - A non-AI technique to support just-in-time customization of UIs across multiple platforms using an abstract UI model and client renderers.

• e2b (EnglishToBits) - AI-powered “IDE“ to transform tech specs into working backend and frontend software. Here’s a demo of creating Just-in-time UIs.

So there are a couple of things going on here. Ephemeral / On-Demand UI manifests as users describing the kind of application they want with a text prompt, the AI generates it for them, they use it for the task at hand and move on. This is a very interesting idea. We only have demos and I don’t know how I would feel about always describing the app I want to use or to copy & paste the prompt from an “app_store.txt”. Conversational workflows are not the best for many common use cases. However this kind of app generation has the potential to become the building block of more intuitive, higher level tools.

Real time customization / personalization on deeper levels than what we use today is another theme that could be powered by AI or is already implemented using a server driven approach. The idea is to optimize application UI-s to the personal needs and characteristics of the individual user dynamically as they are using the application. However the version of this idea discussed in the Server Driven UI article goes beyond what we are capable of today.

➡️ If or once we get production grade solutions, these techniques can potentially improve developer Productivity and Customer Experience by a large margin. If they free up significant development capacity that’s called decreased Utilization in the Full Context system’s terms. Also if these techniques prove to be feasible they will open up gigantic Business Opportunities and can lead to significant decreases in Direct Costs. Their scope at this point is hard to predict, but that’s exactly because the potential here is mind blowing. This makes it the News of the Week.

Related Tool:

Eventual.ai: In the domain of backend services this app brings the future we just explored to today. Their motto is: “Business Requirements in → Cloud Service out“. You have a chat with their AI and it designs and deploys an AWS service configuration to solve your business case. Would be pretty interesting to test drive.

Two Ways to Rethink the Modern Web

📚 Recommended Read 📚

📊 20 Points: Hype 4 x Value 5

If you are going to open any links from this volume, I strongly recommend the 2 articles coming right now! I think of the previous section as the exciting, but only potential future. In nice contrast this part will show the definitely implementable future that gives it extra value on multiple levels.

First, because these are iterative improvements, they have a long history to look back at, evaluate and build upon. And they do just that with wisdom and certainty, showing a path forward that would benefit all of us as humans and developers.

Second, because there’s code you can already use if you want to try to implement this future and regardless of references from these articles I planned to include some of them in their own right in this issue. So without further ado:

• Web of the People - Includes some heavy - and I believe justified - criticism of the modern tech giants and the effects of their tools over society but goes way beyond that and offers technical next steps to heal the damage done and create a future where these can’t be repeated. Really eye opening on many levels. (Also somewhat dissing the current AI boom) → The philosophical way

• Rethinking the Modern Web - Sheds some light on the often non-perceived absurdity of the ways we did web development for the last 10ish years and shows the new tectonic shift that’s already happening just not in full swing yet. It talks about React, CSS-in-JS, compilers and everything you would expect but the conclusions it comes to is not what you would guess! → The technological way

➡️ The ideas covered here are so broad in scope they have the potential to influence every Impact Factor up to the highest levels possible. This is the challenge with the systemic topics, until they become something more fine grained and concrete I can’t exactly judge their impact.

Related Diss:

Common API design flaws - Jake Archibald: I absolutely love how Jake is covertly mocking the authors of both the HTML/JS standards and React simply by talking truth.

Large-Scale, Long-Term Frontend Architecture Migration At Dropbox

🚀 Highest Technical Impact 🚀

📊 16 Points: Hype 4 x Value 4

Our awesome colleagues at Dropbox presented us with a beast of a case study. It’s about the journey of revamping their core web application architecture, complete with problem statements, pros/cons and before/after analyses. Simply put, it’s bloody good.

Dropbox.tech - How Edison is helping us build a faster, more powerful Dropbox on the web

I found it beyond insightful. The Dropbox devz walk us through the history of their web architecture evolution, highlighting how the different decisions made along the way played out through such a large scale system and organization. They gather the challenges that arose as the consequences of those decisions and the changing technological landscape and it’s complete with their way of finding and implementing a solution that lays the foundations for their next decade!!! of development.

In real life I never encountered this kind of long-term thinking put into technical strategy and working software, yet. (Hope I will do it one day though) It’s not a wonder with the short length frontend hype cycle and industry average tenure, for sure. I don’t want to moralize about these factors, the point I want to make is that the rarity of this approach makes it even more valuable.

➡️ The impact of this strategic initiative is extremely large for Dropbox but how can it benefit you? The possible lessons you can take away from here can help you in any kind of higher level decision making. Those tend to have influence over a lot of impact factors most notably Customer Experience, Productivity, Direct Costs but usually Business Opportunities as well. One thing is for sure, you can only become a better developer by reading it.

Related Article:

Clean Frontend Architecture with SvelteKit - A precise introduction to and implementation of the hexagonal architecture in a frontend application with proper use-case driven design and a TDD approach using SvelteKit and TypeScript. Every bell and whistle is there to tickle your coder taste buds, hmmm a delicious piece.

Average Scoring News (6+)

New Frontend Frameworks

📊 9 Points: Hype 3 x Value 3

Big tech companies have a new hobby nowadays besides keep laying us all off. They decided to have a piece of the frontend framework cake for themselves. But I get it. The internal pressure to take action must have been crazy high. I mean, I can’t even imagine how could all the Microsoft or ByteDance developers put up with the shame of working at a place that does not even have its own open source frontend framework. Now I guess they feel much more confident when talking with their old classmates working at Google and Meta… (No offense meant, this is just a joke. How would I ever dare to insult the dream audience of my newsletter? …Oh, are you working at Amazon? Can I take a selfie with you?)

• Fast, a framework from Microsoft quoting their description: “FAST is a collection of technologies built on Web Components and modern Web Standards, designed to help you efficiently tackle some of the most common challenges in website and application design and development.“

• Modern.js more than a framework because apparently that’s not even attention worthy nowadays. Imagine the devz at ByteDance having a discussion like: - Dude, I came up with a crazy idea to create a new frontend framework. - Hah, don’t kid me, if that’s all you can do don’t even get started mate. Look at Next.js, Nuxt.js, Angular, SvelteKit and all the cool projects. You ain’t have no chance, unless you ship - at the minimum - your own package manager, build tool and docs site generator. - Hold my beer. And that’s how I think Modern.js got born over a weekend-long solo hackathon. Or probably not…

• Enhance, an HTML-first framework mentioned in the Rethinking the Modern Web article as a good step forward.

• Framework popularity on Netlify a slightly related but very interesting read.

“Clean“ Code Horrible Performance

📊 12 Points: Hype 3 x Value 4

A video by Casey Muratori got popular a while ago where he questions the status quo about Clean Code using a C++ developer’s performance focused mindset. I saw him talking about some earlier version of the same idea before and always thought that his approach is pretty much Full Context.

He is taking measurable characteristics of code and software to evaluate the technical choice of implementation style in terms of its impact. Of course, performance is not the only factor that we should care about in general but the approach itself is sound!

• The original YouTube video by Casey

• A much shorter interview with The Primeagen who is one of my favorite programmer content creators. The interview is filled to the brim with programming wisdom and summarizes the main points of the full video pretty well.

• The Final Quest of Programming: Ideas on how to analyze and quantify the effects of coding related decisions over business outcomes. - A chapter from my own book.

• unclebob/cmuratori-discussion An hours-long GitHub “chat” between Casey and Uncle Bob - the author of Clean Code.

Code for Writing More Code

📊 9 Points: Hype 3 x Value 3

If simply writing code doesn’t deliver the high any more, you might want to go meta and start to write code that writes code for you. No, I’m not talking about AI here, it’s old school hand written stuff, supported by two recent tools:

• TS-writer a template string template engine designated to generate TypeScript code at runtime

• Magicast for programmatically modifying JavaScript and TypeScript source codes with a simplified, elegant and familiar syntax powered by recast and babel.

The Vercel and Builder.io Special Report

📊 12 Points: Hype 4 x Value 3

These two companies just keep on giving, and there’s no decline of content in sight from either. Here are the news of the last two weeks I loved the most.

• Improved infrastructure security with Vercel Secure Compute Secure isolation and protected integration of serverless functions with other private networks

• Vercel platform support for streaming rendering from the Edge and Next.js v13 offers out of the box tools to utilize it.

• Builder.io: Building AI-powered apps is way easier than you think

• Builder.io: AI Shell A CLI that converts natural language to shell commands.

• Builder.io: GPT-Assistant An experiment to give an autonomous GPT agent access to a browser and have it accomplish task

• Builder.io: Generate Figma Designs With AI

Other Links With Possibly High Impact

• LambdaPi: GPT-Driven Serverless Code Plugin - a serverless runtime environment tailored for code produced by LLMs. Automatic API generation from your code, support for multiple programming languages, and integrated file and database storage solutions.

• New Official Amazon Tools for Building Generative AI Products on AWS

• Jampack - Optimizes static websites for best user experience and best Core Web Vitals scores. Yes, it works even with the output of Astro and Next.js

• Hidden Telemetry in Modern Frontend Frameworks - a hall of shame and hall of revelation.

• Building a faster CI pipeline with Turborepo and pnpm

• 6 CSS snippets every front-end developer should know in 2023 - these are really modern and useful techniques

• Improving React Testing Library Tests

• The Most Common Mistakes When Using React - I’m guilty of many too

• Chrome Ships WebGPU

• Streaming lexical scope In this ElectricUI demo

• React useExceljs

• JavaScript Algorithms and Data Structures

Newsletter Community Report

Here I share what’s going on behind the scenes of Full Context Development. I hope it can help you feel like a part of our awesome community. I don’t have the formulas figured out, I experiment and refine things frequently so we are all in this newsletter stuff together. That makes me even more genuinely happy to share the joys and tears of my work with anyone interested.

The last issue became our most liked and shared post on LinkedIn so far which is by far the most significant source of traffic for us. It also drove a huge (relative to previous) number of new subscribers! Even Miskov Hevery (Creator of Angular and Qwik) reposted it himself. I’m super happy to see that the momentum is building around our little community. Thank you all for participating and contributing to it.

Reporting on the subscriber count. We are still a teeny-weeny newsletter but if this post follows the trend of the previous ones we will likely hit the 100 subscribers in a couple of days!!! I’m super grateful and happy for all of you who already dedicated some of your precious attention to my writing and serving your interest will always come before chasing arbitrary numbers. Still, I feel incredibly excited to reach this milestone.

Typo report: I always made at least one embarrassing typo in every issue so far. Last time it was in the hero image: Fronted Mastery. I felt cringe any time I looked at a social preview. But the best one so far was when I renamed the Hono framework in the headline. While nearly falling asleep in the morning for some reason I put it as Hokai. I don’t know more that 3 words in Japanese and it’s not one of them. I only realized the mistake after sending the email. I was looking up the meaning of the word panicking if I put some completely inappropriate out there. Luckily it means collapse or meltdown. Once I read the news the next day about the Silicon Valley Bank collapse I seriously thought about whether I became a prophet.

Wrapping Up

If you enjoyed this volume of the High Impact Frontend Newsletter and/or found it valuable please consider sharing it with your friends and colleagues. It’s a huge help!

Do you know how YouTubers call out their audience in-video for not subscribing? If you read it in an email I have no grounds to do anything like that, BUT. I know how many of you shared this stuff, and the numbers break my heart. So please, it’s simple, it’s easy and it helps me a lot to run this channel… umm newsletter so please if you haven’t done that, click on “Share” and smash the notification bell, … I mean like button. You all who already did are simply the best! I need to find a way to invite you to a VIP Subscriber club somehow. Those who didn’t, don’t worry, the party is open, join us, you know what to do!

See you in the next one!
Joe @fullctxde

Hey Full Context Developers,

To make up for the missed volume of last week I will include the most interesting stuff of that period in this issue. There’s a lot to look at so here’s the overview:

• Get to the next level even as a Senior FE dev with Frontend Mastery. (Not to be confused with Frontend Masters the course website)

• Gain better insight into the arts of Local-First web application development

• Boost your time-to-market with Vercel AI templates

• The Qwik framework hit the first release candidate version, claims to be production ready.

• Hands down tutorials into implementing Monitoring and Observability in React web and React Native mobile apps.

• In the Quick News section there’s just so much cool stuff it’s hard to list:

  • Lost of useful and/or insightful React posts

  • The coolest recently published tools, for example Cicada, that enables writing CI/CD pipelines in TypeScript.

  • A lot of the recent, awesome Builder.io articles

  • And more, a lot more…

• The Interesting Links has links to articles like:

  • 4,600 npm Packages All about John Wick

  • Static Types in Pure JavaScript With Zod and JSDocs

  • And many more

• Newsletter Community Report

I know, yes, I changed the name again, sorry. (This newsletter was previously known as Weekly Frontend Hype) I’m still iterating as I refine my own vision for the newsletter. We will hit 1.0 eventually with no more breaking changes.

Why the switch this time? After a chat with Jack Herrington on LinkedIn I realized I need to communicate what I want to deliver to you more clearly. It’s still the same thing, showcasing the highest impact news of the last week. (Now it’s weeks, more on that at the end).

But what’s the impact I talk about? In the Full Context view, it’s anything that makes a project or a product more successful. Here it means news about frontend tools or ideas that help you become a developer with high impact. (Prioritized by that)

If you are new around here or just wonder what this “Full Context“ stuff really means, you can read about it in a dedicated post. It takes around 10 minutes to go through so I recommend doing that after finishing the newsletter.

The Scoring System

For reference here’s the Hype & Value scale I use to score the impact of the news. The two values are multiplied to create the final value. Now onto the main part!

High Scoring News (15+)

Frontend Mastery - Rethinking React Best Practices

📊 15 Points: Hype 3 x Value 5

This article came out recently from Frontend Mastery about the current state of React. It’s super insightful about the current phase of frontend framework evolution in general and clearly explains many of the underlying concepts of the recent trends.

Besides that, it offers the perfect opportunity for me to bring some attention to this website in general. Why? Because I believe this is one of, if not the best website for senior frontend engineers to gain deep and systemic insights into our areas of focus that can still take us to new levels. (At least it surely did that with me) 👨‍💻🥷📈

Every post is extremely well written, they just reek of professionalism and battle tested, deep understanding. Check them out, I highly recommend them all.

➡️ The article concludes with a very Full Context-y quote from John Carmack (see my related definition) which further solidifies its position as the News of the Week 🏆. Congrats Frontend Mastery!

The impact of the article is hard to judge. As a learning material the benefits depend on your level of React knowledge and the decisions you might face. In the right circumstances it could boost Productivity up to the Organization level.

To be completely honest I gave a Value of 5 considering the whole website not only this article, but hey, as the author I can do at least that much to highlight something super valuable but relatively less known.

Related News:

Speaking of very Full Context-y stuff, I came across an article making a very solid Business Case for SvelteKit which is a good example of using this perspective by connecting technical choices to measurable business results.

The Cool Frontend Arts of Local First

📊 15 Points: Hype 3 x Value 5

The Evil Martians wrote an article about the 3 big “local-first” tasks: storage, synchronization, and conflict resolution. Local first web development is becoming a much larger thing recently (see their movement defining website) and this post gives a nice introduction to the topic. We can also learn the key concepts behind the 3 major topics and see some examples. It strikes a good balance between being easy to follow and offering deep technical insights.

The value of this topic comes from the fact that a local first approach is essential for many live collaboration applications AND every app that wants to offer offline support which is key for a superior, app-like experience nowadays.

If you want to understand the challenges involved in this problem space and get recommendations for some ready-made solutions, definitely give this one a read.

➡️ What you learn here can help you increase Productivity up to the Organization category and Customer Experience up to even the System level.

Average Scoring News (6+)

Vercel AI Templates

📊 12 Points: Hype 4 x Value 3

As I have previously said Vercel just can’t stop shipping awesome stuff. This time they prepared out of the box application templates specifically tailored for AI projects. You can kick start stuff like:

• GPT Chatbot

• Dall-E Art Generator

• AI Code Translator

• … and more

If you are trying to be an early entrant to the AI boom with a similar app these can provide real value.

➡️ Productivity improvements up to the Organization category. They can provide you with better Business Opportunities by reducing time-to-market. In the best case scenario that’s impact in the Organization category.

Related News:

On dev.to an article about Jema.ai got popular. It’s titled: Build AI Template Engine to create amazing content with Next.js and ChatGPT. Pretty hype.

Vercel rolled out an advance integration of Remix with their Edge infrastructure enabling features like: Streaming SSR, API Routes, Advanced Caching and Data Mutations.

An optimistic and well rounded take on the future of Web Developers in light of Chat GPT and LLM tech from Josh W Comeau.

Monitoring and Open Telemetry for React (Native)

📊 10 Points: Hype 2 x Value 5

Monitoring and Observability are not the sexiest of frontend development challenges, but their impact on the business is so massive, they can make or break millions of revenue.

That’s why this topic got such a high Value score. It’s actually not a single article but a whole bunch of recent ones.

1. Implementing Open Telemetry in React with SigNoz

2. Enabling Open Telemetry in React Applications by Redhat

3. Monitoring React Native Applications with New Relic

They are pretty technical and platform specific and honestly, I don’t expect them to be the favorite news of this volume. No wonder as observability is usually a one-off FE task.

➡️ The articles can give you a head start in setting up these tools, improving Productivity up to the Group category. From a generic perspective properly implemented observability has massive influence over Customer Experience in the most critical situations that can absolutely hit the System impact category. It affects Direct Costs and even Business Opportunities. (Think not losing customers, reputation and revenue because of a sensitive incident)

The Qwik Framework Hitting First Release Candidate Version

📊 12 Points: Hype 4 x Value 3

This is the most exciting piece of news for me these last weeks. Qwik is driving recent innovation in the FE space with its approach to zero-hydration SSR called resumability among many others. I can’t wait for it to reach higher market adoption and this step is an important milestone towards that goal.

But why? I like that they position themself in business terms that answers this question pretty nicely:

“Companies that deploy Qwik apps increase their competitive advantage in terms of conversions, customer happiness, and SEO ranking.”

Qwik offers peak web performance and a great developer experience and you know we frontend developers just like a good, new framework as normal people would a good, new Netflix series. (Not to imply we are not normal people!)

➡️ Productivity and Customer Experience are the main game here. This framework can increase Productivity up to the Organization category and Customer Experience to the System level. The lower Value is due to the fact it didn’t hit 1.0 yet so it’s still harder to push for adoption than ideal.

Low Scoring News (5-)

It just makes sense to expect news from the low category after seeing the high and average sections. But it actually doesn’t. Sure there are many low scoring news out there, but why should you care about them if their impact is so low? I won’t waste your time with irrelevant news. Is this a good approach? Or should I change it somehow? Let me know in the comments or in a reply email if you have an opinion!

Quick News

Builder.io Is The Next Vercel

📊 9 Points: Hype 3 x Value 3

At least in terms of pumping out top-notch content non-stop. I found a couple of very interesting and informative articles recently. In no particular order:

• The Future of AI-driven Design and Development, Today

• Web APIs for smooth resource intensive apps

• A Complete Visual Guide to Understanding the Node.js Event Loop

• Visualizing nextTick and Promise Queues in Node.js Event Loop
  

Lots of Useful React Content

📊 9 Points: Hype 3 x Value 3

It’s an interesting bunch, some opinion pieces and lots of practical and very visual articles about best practices in React. They can deliver real value.

• React prop drilling refactor pattern, visualized on Twitter

• Mastering the Compound Components Pattern

• The Visual Map of React API

• What the React Team has been working on

• Official tutorial: You might not need an effect

• Meaningful React Criticism

• Bright VS Code's syntax highlighting with an RSC, no impact on bundle-size

Cool Tools

📊 8 Points: Hype 2 x Value 4

I came across a couple of exciting new tools the last two weeks. There’s a good chance some of them will be relevant to what you are doing.

• Cicada Build Write CI/CD pipelines in TypeScript

• Termino.js A JavaScript component for making web based terminal animations, games & apps on any website

• Maestro The self described: “simplest and most effective mobile UI testing framework”. (That works with web apps/sites too!). It has two built-in features that would have saved me from a lot of pain if other E2E testing tool had them: tolerance to flakiness and tolerance to delays. It just makes me want to try it immediately.

• Refine A React based rapid web app development toolkit, with support for nearly anything you might need but possibly for much more.

The Vite Scene

📊 12 Points: Hype 4 x Value 3

Vite is just steamrolling with no signs of stopping. Take a look at the latest content:

• Ionic V7 just got released and now it boasts improved Vite support. In addition it uses Vite by default for new Ionic React and Ionic Vue applications.

• In Praise of Vite a post that showcases the strengths of Vite in practice.

• A Petition to the React Team on GitHub to add Vite to the docs on the same level as the SSR frameworks. (I guess the React people really want you to use those shiny RSCs)

Node.js and The Edge Are Converging

📊 9 Points: Hype 3 x Value 3

It seems Edge vendors are in lock-step in releasing the same feature. I planned to add the article from Cloudflare as a separate item, but 1 day before sending out this issue Vercel released their own version of the same feature. Vercel just can’t stop.

• Node.js Compatibility for Cloudflare Workers

• Improved Node.js compatibility for Edge Middleware and Edge Functions on the Vercel platform

Interesting links

• Static Types in Pure JavaScript With Zod and JSDocs

• There Are 4,600 npm Packages All about John Wick

• A Visual Guide to Some of TypeScript’s Utility Types

• With or without the JS framework - a very insightful read explaining the whole context of the modern frontend frameworks and common misconceptions around them. I highly recommend it

• How to build zero-CLS A/B tests with Next.js and Vercel Edge Config - surprise surprise… another article from Vercel.

• Alternatives to Using Async/Await With a forEach Loop

• Take Stock of Your Application With Static Code Analysis Tools - kind of basic but depending on your prior knowledge it can be insightful

• Jack Herrington’s YouTube video about handing State in React

📧 📈 📋 Newsletter Community Report

This is the part not about the news, but the newsletter. I share what’s going on behind the scenes, with the hope you will feel like we are all doing this together as a community of super awesome developers. That’s good for you, good for us so why not? And I’m also genuinely happy to share the joys and tears of my work with anyone interested.

These past weeks were very busy for me, and against my best efforts I couldn’t keep up with the weekly release cycle. I feel really bad about that as I’m truly serious about bringing you up to date content wrapped in the Full Context perspective. Please be graceful with me, I’m writing this newsletter in the very early morning hours in the little free time I have besides a full time job, family with two small kids (3.5 and 1.5 years old, cute little girls) and the occasional extra things I need to handle. Thank You! 🙏🏻

The previous issue became the most viewed post so far both on LinkedIn and on Substack. I’m pretty happy about that and I’m trying hard to make that trend continue!

Wrapping Up

I’m more than happy that you got to the end! It feels so strange and also amazing that someone actually makes it here! If you enjoyed the article and/or found it valuable please consider sharing it with your friends and colleagues.

Do you know how YouTubers call out their audience in-video for not subscribing? If you read it in an email I have no grounds to do anything like that, BUT. I know how many of you shared this stuff, and the numbers break my heart. So please, it’s simple, it’s easy and it helps me a lot to run this channel… umm newsletter so please if you haven’t done that, click on “Share” and smash the notification bell, … I mean like button. I love you all who already did, you are simply the best! Those who didn’t, don’t worry, the party is open, join us, you know what to do!

See you in the next one!
Joe @fullctxdev

Hey Full Context Developer,

This volume will be more snappy. It’s still the collection of the most impactful news I encountered last week ranked by the value they can provide to you as a developer. But it’s organized in a different manner this time. I’m trying to figure out the best format for highlighting the usefulness of the stuff in an easy to process way. Let me know if you like this version better.

But first here’s the overview:

• There will be lots of Svelte goodies

• Modern tooling to make working on email not-that-big-of-a-pain.

• We will attend the funeral of CRA (create-react-app)

• Get some industry insight into how Vercel (the company behind Next.js) ported over BBC’s frontend from plain React to Next.js,

• I will share some coding tools with amazing capabilities like Console Ninja

• Newsletter Community Report

• Full Context System Upgrade

• And more…

About The System Upgrade

I replaced the usage of Impact Points with Impact Categories to demonstrate the scale of the impact the stuff can make. There are simply 4 categories: Unit, Group, Organization and System. Read the details at the end.

If you are new around here or just wonder what this “Full Context“ stuff really means, you can read about it in a dedicated post. It takes around 10 minutes to go through so I recommend doing that after finishing the newsletter.

Enough intro, just give me the news already

I hear you, one last thing before that. For reference here’s the Hype & Value scale I use to rank and group the news. The two values are multiplied to create the final score. Now let’s jump right into it.

High Scoring News (15+)

Modern Email Tooling With React

🔎 15 Points: Hype 3 x Value 5

Brail - This is a freakin’ awesome tool if you have to author emails. For me, emails are one of the most painful web development tasks I ever had to do. That’s where Brail comes to the rescue.

It defines itself as a “Full-Stack Email Development Toolkit“ built over tRPC and Next.js. It has devtools, linting, theming, templates, responsive design support and offers end-to-end type safety using TypeScript. The benefits and details are too many to list. Head over to their site if you are interested.

➡️ This is undoubtedly the Tool of the Week 🏆. Brail can bring the most outsized impact by solving a massive pain in the … Its Productivity Impact can reach the Organizational category and the Customer Experience Impact can even be Systemic if email is core to the business. If you can replace existing 3rd party email authoring software with it, there’s a possibility to impact Direct Costs likely in the Group category and Utilization can be affected again in the Group category by freeing up developer capacity.

Alternative: There’s a very similar tool simply called React Email offering mostly the same benefits, check it out too! It also has a guide for styling your emails with Tailwind.

SvelteKit Is On a Feature Spree

🔎 16 Points: Hype 4 x Value 4

The Svelte team has been pumping out new features since the version 1.0 release. In a recap blog post they shared the major additions. If you use this framework you can gain substantial benefits from them.

You can now Stream Non-essential Data for each route to unblocking a render-performance bottleneck.

You have access to Snapshots, that among many things can save the users from having to restart filling in forms after an accidental back navigation.

There are Vercel specific changes to enable making much better use of the platform capabilities including Incremental Static Regeneration (ISR).

In other news they introduced Zero-configuration type-safety for the loader functions Next.js and Remix style.

➡️ These all have compounding Productivity and Customer Experience Impact by increasing both development efficiency, the perceived speed of the website and lowering user frustration. Both of them will cap out in the Group category. Customer Experience might even reach Organizational levels. The Vercel config enables adjusting Direct Costs more granularly around the Unit or even Group impact categories.

Related: A Svelte UI Library just hit 1.0 called Skeleton. Check it out, it looks great and uses Tailwind.

Mixed Score News (6+)

Full-Stack Toolkit for Cloudflare Workers

🔎 12 Points: Hype 3 x Value 4

Superflare - “is an experimental full-stack toolkit for Cloudflare Workers. It features a relational ORM for D1 databases, utilities for R2 storage, and lots more.” - from their website. It offers out-of-the-box support for Remix and soon Next.js.

The Cloudflare Workers platform is an awesome serverless and edge infrastructure solution like a leaner and cheaper AWS alternative with unique capabilities.

If you are looking for a place to host an edge rendered web app or broadly speaking cloud infrastructure options, check this one out.

➡️ The CF Workers platform itself has the potential to affect every Impact Factor up to the highest categories. Superflare specifically can stack more Productivity Impact over it in the Organization Category and indirectly improve Customer Experience.

Console Ninja

🔎 9 Points: Hype 3 x Value 3

Console Ninja is a nifty little VS Code extension that will pipe browser console output straight into you editor, in the line of the specific console.log calls. And it will display error logs in similar fashion at the line that’s failed. Check it out in action in Jack H’s short.

➡️ Isn’t it the type of Productivity improvement we all love? At least I surely do. It’s not big, likely Unit Category but still so cool.

Ditching CRA for Vite

🔎 12 Points: Hype 3 x Value 4

This blog post by Luke Twomey is making the rounds, discussing what are advantages and disadvantages of replacing create-react-app with Vite, how to go about it and showing some real world examples.

➡️ Making that move can increase you development efficiency leading to Productivity improvements up to the Group category. That can always have Customer Experience Impact, but it’s often negligible.

The Funeral of CRA

🔎 8 Points: Hype 4 x Value 2

The new official React docs are out and there’s something missing that YouTuber programmer Theo covered and sad his farewells. Jack Herrington also made a short about it.

It’s interesting how people make a huge issue out of something relatively inconsequential. I get the points they make, for the whole ecosystem it might make some difference but I think the whole discussion is fueled by hype more than anything.

➡️ How can it affect your everyday work? There’s nothing it can add that would make a practical difference but hey, the videos were fun to watch.

Migrating the BBC Website From Plain React to Next.js

🔎 9 Points: Hype 3 x Value 3

Vercel published a step by step case study of how they ported over BBC’s open source website to Next.js.

This is an article I found really valuable, as proper write ups of these industrial scale rewrites are hard to come by. Yet migration to Next.js is a frequent adoption path. In those cases, it can offer really valuable insights.

➡️ Adopting Next.js can increase the Productivity, Utilization, Customer Experience, Business Opportunities and Direct Costs Impact of the team/company. Gaining insight into it offers fractional shares of the whole package.

Unevaluated News

Zero Infrastructure Node.js Background Jobs

🔎 6 Points: Hype 2 x Value 3

Defer.run offers something I can’t really put my fingers on. It’s like serverless functions but it’s not request/response handlers but background tasks. The tool looks solid. I’m really interested in how it can be best utilized

Rspack the Next New Rust-based Bundler

🔎 9 Points: Hype 3 x Value 3

Rspack is developed by ByteDance, the creators of TikTok. It’s the same stuff like Vercel’s Turbopack but it offers full Webpack compatibility, which can be a game changer among the new bundlers besides the insane compilation speed improvements.

Million.js the 70% Faster React Renderer

🔎 6 Points: Hype 2 x Value 3

Million is a custom VDOM renderer that can drastically speed up the UI of React apps. However its marketing feels a bit like false advertising as the type of components that it can render are quite limited and possibly not even that useful.

Interesting links

• History of reactivity

• Utangling state in React

• Where did hooks come from?

• Fine tuning refs with useImperativeHandler

• Create and download text files using JavaScript

📧 📈 📋 Newsletter Community Report

(This is the part not about the news, but the news-letter. I share what’s going on behind the scenes, with the hope you will feel like we are all doing this together as a community of super awesome developers. That’s good for you, good for us so why not? And I’m also genuinely happy to share the joys and tears of my work with anyone interested.)

The most exciting thing that happened to the newsletter last week was that Sébastien Lorber put us into his This Week In React - Substack publication’s Recommendations section. That’s a real honor for me, thanks Seb!

Otherwise, last week’s issue brought the least number of new subscribers so far. I honestly thought the last one was quite good. It might be due to a number of factors, my first guess is the release day. It went out on a Saturday. I will release this one on a Monday missing the weekly mark. Sorry if I let you down with that. I still think of all this as an open-beta version of the Newsletter where lots of changes are normal.

The New System

I have been thinking hard and long about the Impact Point system that I use to show the size of impact the tools can make. I believe it’s too abstract to easily grasp the scale it represents so I came up with a simplified version. Let me introduce Impact Categories.

The ultimate goal is still the same, I want to show you how the ideas or (mainly frontend) tools & technologies can influence business results (read: profit). The 5 key areas that connect tech to the bottom line are unchanged: Business opportunities, Customer experience, Productivity, Utilization and Direct costs aka CPU-DB. But from now on I will use the following categories to show the scale of influence across these 5 dimensions:

• Unit - An elementary part: a person, a single metric, a user

• Group - A group of units: a team, a user type / persona, a quarterly target

• Organization - Groups working together for common goals: a department, a user group, a market segment, strategic goals

• System - The whole of the related dimension: the whole market, the whole company, the whole budget, every user in the customer lifecycle, every developer

This is just to give you a rough idea. I will update the introductory post with the details once I get the time.

Wrapping Up

I’m more than happy that you got to the end! It feels so strange and also amazing that someone actually makes it here! If you enjoyed the article and/or found it valuable please consider sharing it with your friends and colleagues.

Do you know how YouTubers call out their audience in-video for not subscribing? If you read it in an email I have no grounds to do anything like that, BUT. I know how many of you shared this stuff, and the numbers break my heart. So please, it’s simple, it’s easy and it helps me a lot to run this channel… umm newsletter so please if you haven’t done that, click on “Share” and smash the notification bell, … I mean like button. I love you all who already did, you are simply the best! Those who didn’t, don’t worry, the party is open, join us, you know what to do!

See you in the next one!
Joe @fullctxdev

Hey Full Context Developer,

I love all the cool stuff that I managed to dig up this week and I’m pretty sure you will like it too. 🤞 The most interesting topics bring up serious questions about the value provided by cutting edge tech and I will get to the bottom of some real drama that’s going on on Twitter. As always, from the Full Context Perspective.

Couple of Side Notes

• I’m not sure at this point about its worth but the last issue raked in some high profile likes, like from Malte Ubl CTO of Vercel, the same YouTuber Jack Harrington of previous issues, and developers from a couple of big tech companies signed up to the newsletter . THIS IS CRAZY for me! 😵🤩😱

• Sorry for messing around with the email sender, newsletter name, etc… It’s early days and I’m trying to figure out the best way to present what I do here. If you have some preference let me know though.

Overview

➡️ ChatGPT got a foothold in writing frontend code, that’s old news by now. I will take a look at the value provided by the current tools built around it. We will explore an even more interesting development, an attempt to replace the whole role of the backend with an LLM like ChatGPT.

➡️ Tech Twitter is as active as ever, churning out interesting discussions. A lot has been going on about RSCs (React Server Components) and SCs in general as other frameworks have already started to adopt the concept. Lots of people voiced a critical opinion. Dan Abramov struggles to clearly explain them. Turns out, there’s a surprising way they can improve the productivity of developers. What are the implications of all of this?

➡️ The article “Were React Hooks a Mistake?“ is making strides and I found it a really valuable read. It sums up the recent discussions of framework authors about signals and then it quickly transitions to the mental models of component types in React. Specifically how class components and function components with hooks differ in fundamental yet often not-understood ways and why that makes Signals all the more attractive for developers.
As a developer using React day to day I took away some very valuable learnings from here!

➡️ A new edge-native router/framework appeared on the radar called Hono (means flame🔥 in Japanese). It entered the same category as tRPC. The best part of it is Hono Stack helping you to build type-safe server-client communication embedded into your favorite frontend framework. (FFF?) But who needs it to begin with?

➡️ I will introduce the A Life Engineered YouTube channel. I don’t want to only talk about the drama and the hot stuff (see what I did there Hono? 😆) so I will show a really good example of something ranking high on the hype & value scale because its value focus. I learned an awful lot from it and so will you if you are not watching it already.

➡️ I’ve found a real hype destroyer💥. The Great Gaslighting of the JS Age is an article that hit too close to home with me. I had very similar thoughts for a while. Give it a read if you want to get deeper insight into how all the fuzz, marketing, and hype around JS frameworks starting around 2010 hurt the wider web ecosystem and to uncover some of its hypocrisies.

➡️ And there’s a bunch of smaller, interesting news at the end.

Let’s jump right into it.

If you are new or just wonder what this “Full Context“ stuff really means, you can read about it in a dedicated post. It takes around 10 minutes to go through so I recommend doing that afterwards.

🔗 The headings below are links to the covered topic 🔗

#1 🤖 ChatGPT for the BE & FE

In short: No, ChatGPT is not going to replace any of our jobs, at least not in the foreseeable future. I will give you some tips on how to beat it!

There are a lot of intriguing tools and videos showing the capabilities of Open AI to “replace“ frontend developers. I honestly laughed at most of them. There are some impressive ones though. But the current level of sophistication doesn’t go far beyond generating boilerplate code, … if you get the prompts right. Or to recreate the examples from StackOverflow and all the tutorials and introduction books on the net with slight tweaks.

You can get that much easier and faster if you:

• Use a purpose made library. Who needs to generate those algorithms when there are much more optimized ones an import away?

• Download a proper boilerplate repo where stuff is not in a single file but you have proper folder structure, actual dependencies are set up for you and so on. No fuss with prompting for much less.

• Download a website template/theme from Themeforest or any other marketplace. You get premade, better quality and incomparably more extensive websites, sometimes even for free.

• Download a proper UI Kit or Component Library. You get a 1000x higher quality code, that’s actually maintained, gets security fixes, and you can ask other people about your issues as they face the same things as you! Unlike what ChatGPT custom generates for you.

The examples of it explaining and commenting code all seem to lack the complexity of a real product. ChatGPT doesn’t have the domain knowledge or the understanding about how the subsystems and modules come together. And I think you can’t really feed your production codebase into it and even if you could, I have my doubts of it being able to handle it. In the end, its knowledge of tech lags behind years and frankly, only real-time knowledge would suffice to hand over generating production code to any AI.

Don’t get me wrong I can totally see a future where AI tools are much more useful, but we are not living in that future yet. However following the progress is amazing in itself.

What about the Back End?

That story I linked in the section header is really fascinating. People put together a system that kind of auto generates a CRUD API using the LLM as the BE and the DB. That’s nice but I still believe there’s an endless number of CRUD SaaS products offering the same features with a much larger set of additional functionalities for less effort. I can’t see an LLM do distributed systems, datalake/warehouse, NoSQL, instrumentation or any of the more intricate types of BE/DB work. What does the future hold? I’m eager to see, but a bit skeptical.
Sorry, if I don’t sound enthusiastic about this AI topic, now I’m really doing what I advertise: “fighting the hype“.

More interesting stuff built over ChatGPT that you might actually use:

• VisualStudio Code Integration

• Adrenaline a SaaS (CGPTaaS) to debug and fix your code

• Code GPT the most feature rich VSCode extension for CGPT

• JavaScript to TypeScript transformer

From the Full Context Perspective

ChatGPT is the perfect example of Level 5 Hype not paired with equal Value. It already has some use for pre-generating repetitive, basic code or doing refactoring, but I didn’t see any mature use case yet. Let me know if I missed some!

In its current form ChatGPT already enabled the creation of new businesses that otherwise couldn’t exist. This is the staple of a 1000 Impact Points of Business Opportunity. If it matures it has the potential to multiply this effect and this score further.

However until it can be made more context aware (like a specific codebase) and be retrained in real time on new data I think it will only be around Level 3 Value or Level 4 in rare cases for software engineers.

#2 🥱 Twitter Drama around RSCs

I wanted to be shorter this week, but writing less is my worst enemy. So I will try to put up a battle now. Here’s a bunch of links where Twitter Tech people discuss React Server Components (scroll down just a bit on that page).

Some are doubtful of its usefulness. I call them the “It’s PHP“ group. Some think RSC is the obvious next step in framework evolution. Let’s call them members of “the Dan cult”. Sorry both camps, the truth is in the middle, RSCs are useful but they are no silver bullet either.

The practical value of server components lies in a couple of factors best described in the Next.js docs. Here’s the gist of it:

✅ You can fetch data directly inside the components with support for async/await syntax. The buzzword here is colocation of data and UI. Like what Remix or the new Next.js router does.
✅ Directly access server resources including API keys, security tokens etc. It makes writing UI that directly depends on those resources more streamlined,
✅ Keep large dependencies on the server, shrinking client bundle size => increased web performance. Which is always nice, but the kinds of components that can be defined as an RSC are limited.

What are its benefits and who can take advantage of them?
RSCs can have a visible impact on a projects’ business outcomes only if the generated revenue is directly correlated with the web performance. Its effect on bundle size can make some difference and the rendered components don’t need rehydration to further improving web performance.

Regardless of that, RSCs have the potential to make your life as a developer easier in a mind bending way.

Assuming you are working on a React application that has a Node.js backend to execute those RSCs.

So what’s that way? You might not need APIs anymore! You can fetch and await data directly in the RSC that needs it. That means writing DB queries or calling 3rd party APIs without holding back! Once they are resolved the component will render static html and send it to the client but!!! you can pass that data down through props to client only components. No need for manual serialization, no need to do anything. It will just magically be available to be used in the browser. Well, that can make a real difference in architecting BE APIs and systems. Watch Theo’s full video on this topic for examples.

For the right project RSC can be influential and the hype is definitely strong so it gets a solid 4 X 4 score.

#3 📡 From Signals to Hooks

The article still rides the waves of signals hype. But it takes a plot twist. Btw, I really love the somewhat clickbaity title of the post: Were React Hooks a Mistake?

No they were not!

But the premise of the article is that developers are subconsciously attracted to Signals because their mental model is much closer to how React Class Components work than to how Function Components do in combination with hooks. Give it a read to explore the details.

Nothing it talks about will bring a directly measurable difference in business outcomes but it will help you to understand how React works on a deeper level. Especially useful if you just started to use the framework.

It scores a nice 3 x 3. Which is the ideal balance every tech news should have.

#4 🔥 Hono Edge + Hono Stack

Are you familiar with tRPC? Then you already know what this is all about. If not, here’s a short summary:

Hono is a small, simple, and ultrafast web framework for the Edge for full stack TypeScript developers. It runs in all common Edge runtimes + Node.js. Comes with the fastest router out there and its secret weapon is guaranteed type safety between server APIs and client code, using Zod and static typing to create exportable type definitions for each endpoint that the official hono client can reuse.

So what are the benefits?

We need to talk about the Edge ⚔️ here. I really like Gergely Orosz’s (my fellow Hungarian) recent summary about what it is. (There’s no direct link to that section so please just scroll down a bit from there.)

Now that we all are on the same page, I can just say that only those projects need Edge infrastructure which operates in a large enough geographical region to include multiple edge endpoints and have low latency needs like online games, or any website which wants to maximize perceived web performance to increase customer engagement. In this case Hono has the potential to improve that metric. By how much, depends on the starting situation.

If there’s a need for very high network throughput it might make a visible difference based on their own benchmarks. But we all know how benchmarks work, we need to do our own.

All these can improve Customer Experience in the range of 10s to 100s of Impact Points.

You get improved DX and productivity thanks to the type safety guaranties. But keep in mind, to get that you need to have a monorepo for the BE and FE or export the types as an internal npm module.

This would bring Productivity benefits in the 100 Impact Points range.

Who should consider adoption: Your run-of-the-mill website/app likely won’t benefit from Edge infra, and for the ones who do, betting on early tech is probably too risky of a move, as there are more mature alternatives with lower but not orders-of-magnitude lower performance. Any less critical project, operating on global or continental scale can consider Hono in my opinion.

I give it a well balanced 3 x 3 score.

#5 👨‍🔬 A Life Engineered

It’s a YouTube channel I follow, run by Steve Huynh an L7 Principal Engineer (top 1%) at Amazon with 17 years spent at that company. His views, advice, the topics he covers (for some reason I even feel like the way he speaks) all show distilled wisdom, wide experience and delivers constant value. (I’m not sponsored believe me)

I just wanted to share something with you that can bring immense benefits for any software engineer regardless of specialization.

How much impact can it make? The Full Context System has a part about the motivation of engineers. While that’s focused on the effects of technical decisions, it’s very much directly translatable to how the message of these videos can influence us in positive ways. What you learn here can help us to become at least a 100 Productivity IPs more efficient at our work, career growth and through helping us to help other engineers.

Check it out if you want to learn from all his experience and growth at Amazon.

On the hype value scale it “sadly” gets a 3 x 5, it could really do with more visibility.

#6 📣 The Great Gaslighting of the JS Age

I assume you read the short introduction to this article at the beginning. I don’t want to spoil anything. Thinking about it again, I even wonder why did I include it in the newsletter? Obviously it doesn’t offer much evaluate-able business value even though it has a positive message that would be a nice takeaway for all of us. I think the main reason is that it takes such an objective and big picture view of the last decade of the JS/web world it resonated with the approach I’m trying to use. Give it a read if you are interested.

There’s no score for this one.

Short news

Tech news that I found interesting or funny this week

• Jack Harrington invited Jason Lengstrof for a React Will it re-render? challenge.

• Declarative Setup, Imperative Update: The Key to High-Performance UI Components in React

• Applying for a new job with React and NodeJS and AI

• More Elegant Destructuring with JavaScript Generators

• Vercel: Framework Defined Infrastructure

• Header Overrides feature in Chrome DevTools: You can specify response headers locally without access to the server.

• Speculative module fetching in Qwik

Outro

I’m super happy that you read (or scrolled ) till the end! I feel speechless that people actually do that! If you enjoyed the article and/or found it valuable please consider sharing it with your friends and colleagues.

I’m at a very early stage of building this Substack publication so even the smallest extra visibility can make a huge difference. My wholehearted thanks if you help with that!

See you in the next one!
Joe @fullctxdev

Hey Full Context Developer,

This week has been more quiet on the hype front but I found some very interesting technical stuff to show you. And I mean absolutely fascinating things for those who are interested in the bleeding edge of frontend tools.

Before I forget, this is what happened after publishing the first issue of the Tech Hype Report last week! My mind is still blown! 🤯🤯🤯

Overview

We will look into the future that Electric Clojure can bring about with its industry changing, paradigm shifting new ideas. It got me more excited than anything in the last year. And there are other news in the mix trying to bridge that network chasm.

The rest of the lineup is just as strong! The folks behind Next.js are relentlessly churning out improvements and there’s quite a few significant ones in the latest v13.2 bunch.

Mitosis, Zag and TanStack/Bling are tools I haven’t heard about before, that all bring cross framework frontend development to unprecedented heights.

I have a whole bunch of smaller tech news to share like running RSCs in ReactNative with Expo, running SolidJs components in React apps and a shoutout to Jack’s latest videos. Let’s jump right into it.

If you are new or just wonder what this “Full Context“ stuff really is, you can read about it in a dedicated post. It takes around 10 minutes to go through so I recommend doing that afterwards.

🔗 The headings below are links to the covered topic 🔗

#1 Electric Clojure ⚡ and The 2 Chasms

I'm not gonna lie, I can only understand about 69.420 % of all the fancy terms inhibiting that tweet and the repo readme. I guess that means you should probably be closer to 100% but don’t let the missing percentage set you off. Here’s my best attempt to translate it to regular English.

Electric is a programming language (== reactive signals Clojure DSL). And its compiler can spit out full stack web apps where you don’t have to manage the BE / FE communication at all, it’s auto generated for ya.

It has some other fancy and nice QoL innovations, but this one is by far the most significant. If this can become mainstream it will change how we think about web applications forever and close that network chasm that the Remix team also aims to tackle.

From the Full Context perspective

But there’s a gigantic if. IF it will become mainstream. Clojure is already an obstacle for that and the pain Electric solves has to be large enough to close another chasm the chasm of tech adoption. I’m super hopeful that it will happen, I even got the urge to pick up the tutorial book on ClojureScript that I never finished… for the 3rd time. However I didn’t experience how much of a help Electric offers by removing the network part. If it’s similar to how GC removed the need for memory management that would be huge.

But what’s the price you need to pay for that? Until it reaches early majority adoption it’s a lot! Small job market == higher risks for both talent and employer, 100% vendor lock in, very little security and community support, no standards compliance and the list goes on. For now, I can only recommend using it for pet projects, disposable prototypes or some hyper niche products. (For what I can’t come up with an example)

But let’s imagine Electric delivers on the promises. It will remove a whole category of tasks and issues from web development, freeing up massive amounts of engineering capacity, which in turn will bring significant business benefits. Probably in the multiple 1000s of Productivity Impact Points. This is why other bleeding edge frameworks are trying to tackle the same problem, like Nullstack. (Which honestly has the best art and mascot out of all the popular FE frameworks right now.)

I’m looking forward to see how this project grows but as of today, for the regular company and developer:

Electric Clojure offers a 3 x 2 = 6 HV score on the Full Context Hype Value scale. But it has the potential to reach a 5 x 5 score in the future!
(Yes, I tweaked the formula since the last issue based on feedback)

#2 Next.js v13.2 💣Business as Usual

This release just proved my conspiracy theory. I don't know what kind of drug they use at Vercel but they definitely pump something into their developers and turn them into super soldier-coders as they ship with inhumane speed.

This minor version casually shipped:

• An entirely new caching architecture on Vercel

• The accompanying Next.js Cache, an evolution of ISR

• Compatibility with Webpack loaders in Turbopack

• Custom route handlers for the app directory

• Statically typed links

• And more, check the announcement link in the section heading…

I would love to walk you through all of them as I’m really excited for a lot of these features, but it’s not the main point of the newsletter. I will link some great resources about the technical details after the score. Take a look if you are interested!

From the Full Context perspective

The improvements to the caching mechanisms in Next.js and Vercel will impact businesses significantly.

• Improve customer experience by increasing the render performance of even dynamic, personalized or behind authentication pages. It was previously impossible to achieve similar levels of performance without custom solutions requiring much effort and capacity from development.

• Further reduce infrastructure costs. The reason is that the fine grained caching enables us to move such SSR pages to ISR that was previously unsuited for this change. This can significantly reduce the number of server side operations and even 1st or 3rd party API calls resulting in less resource consumption and lower costs.

• Speed up redeployment of sites with 1000’s of static pages since the page generation can use the existing cache improving delivery speed.

• Increasing the productivity of software engineers by speeding up local development. It’s less impactful than the previous points but still relevant.

The Webpack ←→ Turbopack compatibility can enable moving additional projects to the new bundler. Turbopack’s main benefit is its speed, resulting in higher delivery performance for projects that bring along all the derived perks like a faster feedback loop and increased customer engagement with the product.

Statically typed links can reduce the human error factor in creating dead links. In the worst case those links can totally destroy the user experience or even cause financial losses. (Think, one dev messing up the signup link)

But there’s a catch again.

All these features are in either Alfa or Beta status. So with that in mind I can’t recommend using them in mature, established products. It can probably be fine in newer, smaller products, I think about hipster geek startups or indi hacker projects.

I will sum up the rest of the stable and new stuff in v13.2 as a pack of productivity improvements that make common tasks more efficient and pleasant to get done.

Only scoring the stable functionality, the situation is a bit less impressive.

Next.js v13.2 gets a 4 x 3 = 12 HV score on the Full Context Hype Value scale. With the non-stable features it would reach a 4 x 5 score which is massive!

I really love Vercel and Next.js from the Full Context perspective, most of their releases and strategic goals align well with solving real world pains using cutting edge technology. Keep it coming guys!

Resources:

• Introduction to the caching architecture from Malte Ubl here on LinkedIn

• A neat tweet thread describing the significance of the Next.js cache

• Another tweet thread about all the new features but I especially like this one about the Custom Route Handlers.

#3 Mitosis, Zag, Bling 🗺️ - Clues about the new frontiers of frontend development

These technologies made an appearance on the sidelines in recent weeks. There’s one thing in common between these tools, they are all built to abstract away the differences between frontend frameworks.

The promise of Mitosis is that if you write your components using its syntax it can transform them into components of any of the supported frameworks. And that’s a really long list.

Zag tackles a different aspect of cross framework FE development, component-logic. Meaning state definition and manipulation. A simple example is controlling the state of a checkbox or really any value displayed in a component.

But this reminds me of something 🤔 … standards?

(Even though Mitosis authors disagree there are situations when it can simply become one more tool on top of those already in-use)

TanStack/Bling defines itself as:

Framework agnostic transpilation utilities for client/server RPCs, env isolation, islands, module splitting, and more

Which honestly is a bit hard to wrap my head around. The best lead I found is in the authors’ description of the upcoming TanStack Start library:

Type-safe, SSR-friendly meta-framework for building modern React & Preact applications, powered by TanStack Router, Astro & Bling.

Sounds like the Webpack of the future. The reason I’m really interested in this project is the recent emergence of the new silent revolution of web development which centers around module extraction by build tools.

It’s interesting to notice that this article is also coming from Builder.io. All of these new ideas are coming together. Multiple vendors we already touched in this volume are involved. Remix, Astro, TanStack, NullStack, Electric Clojure, and a lot of tools that are coming from Builder.io like the Qwik framework and Mitosis. All the goals these frameworks and tools progress towards are converging and defining the next frontier of frontend development for the coming 2 - 3 years.

1. Bridging the network gap, by unifying/colocating server and client code enabled by module/function/clojure extraction behind the scenes or by a purpose built programming language. And Qwik has also joined the fight.

2. Removing hydration and reducing JS payload as much as possible with resumability (Qwik), super fine grained caching (Next), islands architecture (Astro), Server Components (React) or any other means.

3. Abstracting away the FE framework level from component development like what Astro, Mitosis or Zag are attempting.

4. Speeding up or entirely eliminating (Deno + Fesh) the build processes. It’s something I only covered in previous volumes.

These are all very interesting trends

From the Full Context Perspective

Abstractions over FE frameworks can make life significantly better for:

1. Multi-framework design system maintainers

2. Micro frontend teams using diverse stacks but a single design system

3. Web SDK developers who ship components for multiple frameworks

4. Builder.io employees 😉

In these use cases Mitosis and Zag will influence Productivity, Customer Experience, Utilization and even Business Opportunities heavily. These have so many implications it’s best if you check them out yourself on the Business Impact chart. For the rest of us, these are just interesting but irrelevant technologies. And I will go with the most common case for the results here.

I will leave out Bling and the related tools from this scoring.

Mitosis and Zag get a 3 x 2 = 6 HV score on the Full Context Hype Value scale. But for the right teams it can be a 3 x 5 score!

Short news

These are all technical news that can or has the potential to make a positive impact for certain projects.

• Evan Bacon showcases how React Server Components can be used in React Native through Expo.

• Marko shipped TypeScript support

• Ryan Carniato gets Solid.js components work inside React in his livestream

• Jack Harrington is still riding the wave of the Signals hype with quite a “solid” video about how to use them in Qwick, React and Solid. 3 x 3 Jack!

Outro

I’m super happy that you read (or scrolled ) till the end! I feel speechless that people actually do that! If you enjoyed the article and/or found it valuable please consider sharing it with your friends and colleagues.

I’m at a very early stage of building this Substack publication so even the smallest extra visibility can make a huge difference. My wholehearted thanks if you help with that!

See you in the next one! - Which will definitely be much smaller in scope but at least this good or even better in quality. I spend like 20 hours working on this in the late evenings and early mornings this week.

Joe @fullctxdev

Hey Full Context Developer,

Maybe you are new around here, or perhaps you already read some of my previous posts yet still wonder what exactly "Full Context Development” means. Regardless of how long you have been following along, this post will serve as a simple introduction to what this is all about, my vision and mission for this newsletter and how all this can improve your life. Let’s start with the core question.

What is Full Context Development?

It’s two things:

• A mindset - a specific way of looking at role of a software engineer

• A toolset - a system that helps you to analyze the impact of technical decisions using that mindset

I came up with them while working on my online book of the same name. These are what I use to analyze the tech tools, form my opinions and hopefully provide more objective, valuable insights that go beyond the hype. You can read more about them a few paragraphs later. (After the sign up CTA)

What about this newsletter?

I love programming, I love to lose myself in discovering interesting, new tools and approaches to development that push the boundaries of what technology can achieve today. But…

I also see that there are huge financial incentives in the industry to hype up the tech we create. Open source technologies are no exception nor tech content creators who stream, teach, write about or promote these. (Quite hypocritically it holds true for me just as well)

As a former lead frontend developer I had to learn how to look at all my decisions with the perspective of serving the customers and solving real, human problems. I tried to document and refine that perspective in my book and after its financial failure (and recovering from it to some extent) I decided to share what I learned in a much more interesting and engaging format. (Yes, that book is boring as hell)

With this newsletter I want to go against the mainstream tech hype and sound another voice, show another perspective, one that takes a more objective approach, focusing on if and how all the new stuff can be used to solve or even to eliminate real human problems.

I want to provide you with a weekly collection of short overviews about the trending tools or other material I report on with this focus. All that so you can:

• 🔥 Have fun while I burn those who baselessly hype things up

• 🧭 Learn how to make better, impact focused technical decisions

My hope and mission is to enable every programmer to enjoy the hype, which is quite enjoyable for sure, without succumbing to fake promises, overblown significance or dead end decisions by teaching you the Full Context way of evaluating tech stuff. So basically I want to be the tie & mast.

But I also have a much larger vision

Which sounds quite impossible or just waaay too ambitious. But that’s how a vision should be. It makes me feel uncomfortably vulnerable to share this as who knows how much of it will I manage to realize, if any, but.

I want to teach every programmer how to make the best tech decisions possible.

So many software engineers are asking for advice all the time: What’s the best tool to use? What’s the best approach to take? I want to create an easy to follow and practical guideline for everyone to answer those questions in their given context. I wish that the Full Context system would be the perfect tool for that, but it certainly isn’t, hopefully just not yet.

I have been working in this field for nearly 9 years but my experience is still lacking to really pull this off. I don’t know a lot about making the best tech decisions. But I will continue on the road to get there. I will learn in the public and I hope to learn from you as well. Please share your ideas and insights with me. Am I wrong? Tweet me. Am I missing something? Drop a comment down below. Do you know of a better way? Message me on LinkedIn!

Together, I'm convinced, it's possible to build the future where every programmer has a tool that makes making the best tech decisions easy.

This newsletter is a small step towards that goal. Sadly this step is all I can take right now as a full time employee, husband and father of two adorable little girls. (Even now as I’m writing this the clock is at 2:59 AM)

But I’m sure if this is the right thing to aim for a road will open up. And I can’t wait to see what that will be!

Now that the inspirational stuff is over we can get back to the original topic. What that mentality and toolkit really is about.

I hope everything that follows won’t be a prerequisite to enjoying the newsletter but knowing about the main concepts will definitely help to get the most out of it. So let’s cut the chase and go straight to the heart of it:

The meaning of Full Context Development is to take responsibility for every effect of the tech choices we make.

This stems from my view about the real job of a developer. Here’s a part of my summary from the book:

And we can do that best when we know and think about all the effects of our decisions, even those that go beyond code or software. That’s what I call the Full Context mindset.

The Full Context system is a way that helps you to do exactly that in a well defined manner, while hiding entire layers of business complexity from you.

These will help you to put your everyday decisions into the full context of your job. The result should be better alignment with the real goals of the products we create and the companies we work for. Or your own company. Or your clients’ companies. In turn it will increase your impact and boost your chances of career progression.

The most compact description of that system is in this part of my Next.js review. Take a look if you have the drive to dig into more details.

In short, and without much explanation the Full Context system maps how the 5 Impact Factors (CPU-DB) are connected to the 4 Pillars of Business Value (RIP-CAR) and gives you a method to roughly quantify a tech decision’s impact on them using Impact Points. (See in the first link).

However for the newsletter I replaced the usage of Impact Points with Impact Categories. I believe the point system is too abstract to easily grasp the scale it represents so I came up with a simplified version.

The ultimate goal is still the same, I want to show you how the ideas or (mainly frontend) tools & technologies can influence business results (read: profit). The 5 key areas that connect tech to the bottom line are unchanged: CPU-DB. But now I’m using the following categories to show the scale of influence across these 5 dimensions:

• Unit - An elementary part: a person, a single metric, a user

• Group - A group of units: a team, a user type / persona, a quarterly target

• Organization - Groups working together for common goals: a department, a user group, a market segment, strategic goals

• System - The whole of the related dimension: the whole market, the whole company, the whole budget, every user in the customer lifecycle, every developer

This is just to give you a rough idea. I want to add further details in a dedicated post.

I also have an interactive tool to visualize these connections at the very end of the Code to Money roadmap.

To put it simply, Full Context Developer === Gigachad Software Engineer

In conclusion

I hope I answered more questions than those I created with this post. If you still have some and care to ask, feel free to reach out here in the comments, or Twitter, or LinkedIn. That would make my day! You can even…

I’m super happy that you read (or scrolled ) till the end! I feel speechless that people actually do that! If you enjoyed this post and/or found it valuable please consider sharing it with your friends and colleagues.

I’m at a very early stage of building this Substack publication so even the smallest extra visibility can make a huge difference. My wholehearted thanks if you help with that!

See you in the next one!
Joe @fullctxdev

Hey Full Context Developer,

I’m back for a quick overview of the recent FE tech news using our own perspective to fight the hype. Let’s find out what happened this week that can make a difference for the projects we work on, for our users and us software engineers.

The headings are links to the covered topic

#1 Next.js 13 vs Next.js 12 vs Astro 2 performance test

A video by Jack Herrington (heading is a link) comparing the speed of the same web apps implemented in all 3 frameworks/versions. It got lots of love from the community and I also enjoyed it so please Jack no hard feelings but:

It has it all:

• Hot topic of the day FE tools ✅

• Everyone’s favorite obsession: Performance ✅

• Battle of technologies with a possible clear winner triggering tribal instincts ✅ (I know the conclusions were balanced)

• It only missed the celebrity component. ❌
  Like Dan Abramov implementing the Next v13 version sharing behind the scenes info about the future of RSCs.

The 100k views wouldn’t have been out of reach. Keep it up Jack! - In all honesty it was a really well done comparison. But…

From the Full Context Perspective

The video compares the TTI and the supporting/correlating info about the size of transferred data. While TTI is a factor in achieving a good Customer Experience (link from my book on how tech and CX are related to business outcomes) but it’s far from the only or the most significant component of it.

I will be strict, the video as a whole has no added value to increase the impact of the products we are working on.

In smaller products it’s unlikely that the shown level of difference in TTI will create a bottleneck while developers on huge projects wouldn’t rely on the default output of these frameworks. These small app measurements are sadly irrelevant for that case,

That’s why Jack’s advice at the end is absolutely correct, do your own measurements for your own situation.

But then what’s the value we can take away from this comparison?

The performance comparison gets a 4 / 10 HV score.

#2 Signals, Signals, everywhere

Misko Hevery (author of Angular.js and Qwik) released a very interesting, deeply technical article about signals as reactivity primitives in modern FE frameworks. At the same time Sarah Drasner announced that Angular will introduce the use of signals. Andrew Clark teased the idea that React might add them as a compiler target, or a low level API for library authors.

Signals are not a new concept, Vue, Preact, Solid, and Qwik all use them, it even existed in Knockout. But recent implementations improve on the DX side significantly.

This is the type of news that I really appreciate. It shows us how to achieve a goal more effectively through a technical tool, - reactive state updates with high rendering performance - while also creating just enough hype to raise attention.

From the Full Context Perspective

This can be a couple hundred Impact Point worth of Productivity improvement depending on the circumstances that can manifest in a visible value increase.

The signal technology gets a 8 / 10 HV score.

#3 Node.js runtimes, in the browser

CodeSandbox and StackBlitz both announced the next version of their in-browser Node.js implementation, respectively Sandpack 2.0 and the WebContainers API. Here’s a summary of both:

WebContainers

WebContainers are a micro-operating system based on WebAssembly designed to allow spinning up Node.js servers locally inside a browser tab

SandPack

Sandpack 2.0 introduces Nodebox, a new technology that implements its very own abstraction of Node.js in-browser. Nodebox brings a new set of possibilities allowing Sandpack to run almost any JavaScript application you can imagine in any browser.

These are cool things, but their use-cases are limited. They can mostly be used to create… cool things. Web IDEs, interactive coding tutorials, no-code/low-code environments or to compile and run Next.js, Vite and Astro projects completely client side.

These are legitimate technology advancements, totally newsworthy and congratulations to everyone who pulled it off, it’s tremendous work!

From the Full Context Perspective

This is the stuff that manifests the purest form of Business Opportunity. An innovation that creates new markets, that enables the creation of products previously impossible to build. The thing is, if the product you are working on belongs to a different category, the effect of these innovations on your life and on the business’ is 0.

The Node.js in-browser tech gets a 7 / 10 HV score.

#4 Shopify’s Hydrogen, uses Remix

This news is delivered without much buzz and I also won’t say too much about it.

Shopify devs rewrote Hydrogen using Remix. They enjoy all the benefits of Remix now. Well they bought the Remix company so they’ve got to do something with ‘em, right? The real question is the pros vs cons of using Remix over pure React and its ecosystem. I tried to form a well balanced, opinion on that last year. It’s not all songs and birds but there are a ton of major benefits. I’m interested in following how it will pay out for Shopify.

From the Full Context Perspective

I would have loved to see some measurements of how the Remix implementation did in terms of Real User Metrics or other benchmarks vs the v1 Hydrogen. That would have given us a sense of the impact of the rewrite on business value. Without that I will be optimistic with this one an give

Hydrogen v2. a 7 / 10 HV score.

I’m super happy that you read (or scrolled ) till the end! I feel speechless that people actually do that! If you enjoyed the article and/or found it valuable please consider sharing it with your friends and colleagues.

I’m at a very early stage of building this Substack publication so even the smallest extra visibility can make a huge difference. My wholehearted thanks if you help with that!

See you in the next one!
Joe @fullctxdev

Couple of different authors wrote recently about their workflows and tools to deliver modern frontend projects using the latest browser standards to avoid the added complexity of build tools.

• Julia Evans - Writing Javascript without a build system

• Kofi Gumbs - Modern SPAs without bundlers, CDNs, or NodeJS

• Brandon Foley of Vue.mjs, - Simple, Modern JavaScript

I highly recommend checking them if you are interested in the technical details. What I will focus on here is how and when this approach can bring value, when to avoid it and what it teaches about the often overlooked benefits of bundlers.

Now before you get overly excited let me answer the question you might have: Awesome, can I go bundlerless right away? No, most likely not!
Julia makes a solid case for what’s the right situation for this approach:

easily make changes to old tiny websites

The old part is not strictly necessary in the equation. She and the other articles name the same main motivation for adopting this approach: bundlers are too much hassle to set up and sometimes it’s hard to get old projects to build correctly.

I completely agree with the problem and the example situation. In general I think this can be a beneficial choice for

• small scale projects that don’t require heavy JavaScript based functionality,

• that will be maintained by one or two person

• won’t require a lot of updates

• and won’t utilize other non-browser-standard tools (pre and post processors, build optimizers)

• doesn’t meant to build reusable components

• you already know or don’t want to learn modern tools

It makes sense. The lack of extra tooling is justified because it wouldn’t be used really anyways. However what if the project starts to grow? When you want to automate more complex tasks like pre and post processing or build optimizations you would walk down the road of the FE tooling evolution of the last 14 years on your own. Adding a task runner? Build tools? Filesystem watcher? It won’t be easy, pleasant, or even justified. Your choices for building design system and reusable components are also much more limited.

So if your project is to grow even a bit larger than the above, this approach will only make your life unnecessarily harder.

Is it possible to go bundlerless now? Yes, surely it is, it’s even more performant and convenient that before thanks to new browser features.
But it doesn’t scale.

What about bundlers?

The overlooked benefit of bundlers - even with all the pain to set them up - is exactly that, scalability!

Bundlers unify the way teams handle the tooling and tasks around building, optimizing and delivering FE projects.

They enable organizations to predictably replicate the configuration of the tooling across time and projects. All of these are huge-huge benefits which we take for granted nowadays, maybe even forgot to appreciate.

Now’s the time to use the Full Context System to get a relative sense of the impact this approach makes. If you are not familiar with it, you can read a short summary in one of my older blog posts here.

In summary:

Who should go bundlerless? Small one person projects, tiny landing/static pages unlikely to change, maybe even minor projects of web-dev studios.

The impact in the optimal case is still small as the scale of the work is small and I neglect the fact that by using JavaScript instead of TypeScript you already miss out on a couple of DX improvements:

1. Business Opportunity - Increased time to value

2. Productivity - Time saved at the project start

Who should avoid the bundlerless approach? Anybody else really.

The impact of adopting it in an unfitting, large environment can be devastating:

1. Business Opportunity - Wasted time means a smaller chance for building successful products and business relationships

2. Productivity - Reinventing the wheel, a huge and complex wheel can ruin the productivity of the developers

3. Utilization - Time spent elsewhere instead of delivering value, and sitting on available but not adopted solutions means bad utilization of both mental and financial resources.

4. Customer Experience - You will miss out on the cutting edge performance optimizations that even Vite recommends to use by not bundling your code. Meaning your users will also get a subpar experience.

5. Costs - Low productivity, utilization and missed business opportunities will affect the financial results way more significantly and negatively, than the little you save on the surface level, build-vs-buy cost reduction.

What about TypeScript?

I don’t think it’s possible to pull off the same stunt with TypeScript sadly. You need a compile step to turn TS into actually usable JS either way. Or… wait a minute! Deno! I would love to do a full context analysis of Deno in a follow up post as it offers an interesting set of pros and cons with possibly huge business implications. Let me know if you are interested!

I’m super happy that you read (or scrolled) till the end! If you enjoyed the article and/or found it valuable please consider sharing it with your friends and colleagues.

I’m at a very early stage of building this Substack publication so even the smallest extra visibility can make a huge difference. My wholehearted thanks if you help with that!

See you in the next one!
Joe @fullctxdev