@alexdln

Facets as a Formatting Engine

Wed, 22 Apr 2026 10:06:00 GMT

Formatting is an important tool for emphasizing your point. We use it to highlight key parts of our work every day, including when developing services. WYSIWYG editors, HTML tags, Markdown symbols. These are convenient tools that let users see text exactly as we intended to convey it. Under the hood, however, this is often markup embedded directly within the text itself. What we see isn’t the same as what we store. But there’s another way - not through markup inside the text, but through a layer on top of it. One example is Facets - a formatting approach in atproto. Everything is a facet (except plain text) I started thinking about this back when I was developing atsky.app (an appview for Bluesky). One of the first improvements was polls, which were displayed only in atsky, while Bluesky showed the post as usual. Later, this same approach became the basis for displaying code and mathematical expressions. However, in Bluesky, such elements are still not displayed directly - instead, the user sees a link saying “code not supported, open in Atsky.” https://bsky.app/profile/alexdln.com/post/3mbybcmnh522o It was an interesting experience, but the possibilities I saw in it were far more intriguing. And I asked myself - just how much can be done with them? And as you’ve already gathered from the title - quite a lot. This article will be dedicated to that journey and the results obtained. Formatting First, a little about the problem facets solve - formatting. Formatting is the process of giving data (such as text) structure, semantics, and/or visual representation according to specified rules. The main formatting methods in development are HTML and Markdown. Both add structure through inline markup, using key expressions to define formatting boundaries within the text itself.

Hello World!

But if we don’t understand this language, it looks like strange, incorrect text to us. To address the issue of accessibility, some atproto standards, such as standard.site, recommend storing textContent separately, thereby allowing any user or service to read the record’s content, while the content blocks themselves, with all formatting, are typically stored within the “content” key. { "$type": "site.standard.document", "site": "at://did:plc:abc123/site.standard.publication/3lwafzkjqm25s", "path": "/blog/getting-started", "title": "Getting Started with Standard.site", "description": "Learn how to use Standard.site lexicons in your project", "textContent": "Full text of the article...", "content": { "$type": "com.example.blog", "blocks": ["..."] }, "publishedAt": "2024-01-20T14:30:00.000Z" } An alternative formatting method is the so-called annotation layer. This approach involves defining formatting boundaries not within the text itself, but in a separate data layer. One example is the facets feature in atproto. { "features": [ { "$type": "app.bsky.richtext.facet#link", "uri": "" } ], "index": { "byteEnd": 10, "byteStart": 16 } } Currently, atproto itself uses them only in links within Bluesky. Writing-focused services like pckt.blog, leaflet.pub, and offprint.app also use them for standard formatting elements - bold, italics, underlining, etc. How it works As mentioned earlier, facets are an annotation layer that stores formatting instructions in a separate layer without altering the text. Let’s break down what a facet consists of: range - the text range where formatting begins and ends. This range is specified in bytes. RichText sequentially passes through each facet and applies features to the specified range. "index": { "byteEnd": 10, "byteStart": 16 } features - a set of formatting instructions themselves - type (bold, italic, link) and additional data for a specific type (f.e. link URL). This is an array that formally allows you to specify multiple formatting types within a given range. "features": [ { "$type": "app.bsky.richtext.facet#link", "uri": "" } ] And if you look at these two parts, you can see that they allow for embedding any data. Here’s an example of how the math works in atsky.app [{ "features": [ { "$type": "app.bsky.richtext.facet#link", "uri": "" } ], "index": { "byteEnd": 98, "byteStart": 56 } }, { "features": [ { "$type": "app.bsky.richtext.facet#code.latex", "code": "T(n) = a \\cdot n + b \\cdot \\log n + c" } ], "index": { "byteEnd": 98, "byteStart": 56 } }] You can see overlapping facets, and this is a common feature of current implementations: if formatting has already been applied to this range, subsequent ones are ignored (since it is more likely that it was specified as a second feature within the first facet). Therefore, in bluesky the code is ignored, and in atsky the link is ignored. Post on Atsky - https://atsky.app/profile/alexdln.com/post/3mbybcmnh522o Post on Bluesky - https://bsky.app/profile/alexdln.com/post/3mbybcmnh522o It is important to note that facets operate specifically in bytes. In the most basic version, their implementation would look something like this: if (!facets.length) return text; return facets.reduce((acc, facet, index) => { const nextFacetStart = facets[index + 1] ? bytePositionToCharPosition(text, facets[index + 1].index.byteStart) : undefined; acc.push( {text.substring( bytePositionToCharPosition(text, facet.index.byteStart), bytePositionToCharPosition(text, facet.index.byteEnd), )} , {text.substring(bytePositionToCharPosition(text, facet.index.byteEnd), nextFacetStart)} , ); return acc; }, [ text.substring(0, bytePositionToCharPosition(text, facets[0].index.byteStart)), ]); Flexibility In the example above, another clear benefit of this approach is its high cross-platform compatibility. If you support only the link - you process only the link, if you support the full set of features - you process all specified facets, if you’re unfamiliar with the system or just starting to build a tool - you simply display the text. The service author has access to the content regardless of language, tools, environment, or runtime. You can start with text and gradually add support for more elements. Iterative development where you can get results immediately and then gradually improve them. One of the many things we love about atproto. Scalability As mentioned earlier, the only standardized use of facets in atproto itself right now is links in bluesky. This is perhaps the most underrated feature in the entire protocol. It’s a powerful tool for inline formatting, but as you’ve seen from the code and links, it’s also suitable for other elements. More precisely, for absolutely any element. One example of its use is articles. Current services store text separately and formatting in special blocks { "content": { "$type": "com.example.blog", "blocks": [{ "$type": "com.example.blog.blockquote", "content": "Everything is a facet (except plain text)" }] }, "textContent": "Everything is a facet (except plain text)" } But if you look at this block, you’ll notice that its content is essentially no different from the facet mentioned above. So let’s implement it as a facet { "facets": [{ "features": [ { "$type": "com.example.richtext.facet#blockquote" } ], "index": { "byteEnd": 0, "byteStart": 41 } }, "textContent": "Everything is a facet (except plain text)" } And this is a perfectly valid facet, all that’s left is to integrate it if you want to support it. This way, we avoid duplicating text, and the main logic of the analysis is shifted to the rendering engine. Types and lexicon After a series of experiments and comparisons, I concluded that a facet can be used not only to display an expanded post on a social network, but also to generate literally any text. To make this possible, I created a lexicon, which you can view on pdsls. Here are its types as of this writing: net.atview.richtext.facet#b, net.atview.richtext.facet#i, net.atview.richtext.facet#u, net.atview.richtext.facet#code, net.atview.richtext.facet#strikethrough, net.atview.richtext.facet#highlight, net.atview.richtext.facet#link, net.atview.richtext.facet#mention, net.atview.richtext.facet#h2, net.atview.richtext.facet#h3, net.atview.richtext.facet#h4, net.atview.richtext.facet#h5, net.atview.richtext.facet#h6, net.atview.richtext.facet#blockquote, net.atview.richtext.facet#codeBlock, net.atview.richtext.facet#media, net.atview.richtext.facet#bskyPost, net.atview.richtext.facet#ul, net.atview.richtext.facet#ol, net.atview.richtext.facet#website, net.atview.richtext.facet#horizontalRule, net.atview.richtext.facet#iframe, net.atview.richtext.facet#math, net.atview.richtext.facet#hardBreak If you’re reading this article in its original form (at alexdln.com/blog/facets), you can inspect its data by clicking the button below or on pdsls. This article is written using the lexicon and approaches described above, as well as some interesting sugar from other implementations. For example, two line breaks in the text create a new block, similar to markdown engines. Of course, this is an experiment, not a final proposal. This approach adds significant complexity to the rendering tools themselves, whereas current implementations are easier to integrate. Nevertheless, I hope you found at least some of these ideas interesting.

Open Social Software. npmx

Thu, 02 Apr 2026 10:44:00 GMT

It’s been a month since the release of npmx.dev. We had a wonderful release week with many informative and in-depth articles not only about the experience of participating but also about the technical foundation. Thank you to everyone who is helping us on this journey, and a big thanks to everyone who supported us and shared their kind words. If you missed it, read and discover all these wonderful stories in my previous article or in the official release. At the same time, we’ve just celebrated reaching 3,000 stars, made a number of major releases, and the team gave a really great presentation at atmosphereconf But it seems I still hadn’t actually answered so many questions - just teased at the end of the previous article. I think it’s time to formulate the answers and finally gather them all in one place. Prehistory But to make the answer clearer, it’s worth going back a bit. By the time I joined, it was already a well-organized community that welcomed everyone with warmth and helped us build together. It was an intense and enjoyable time, and together we solved all the problems fairly quickly and completed most of our plans. Then we started talking more about the future, architecture, and details - how to make the service fully-fledged, stable and friendly for everyone. We thought a lot about accessibility, design, security, performance, copywriting, and, of course, the community. This became a turning point when the code took a back seat. Yes, it happened in less than a month, but it was inevitable. After all, behind technology there is never just code, but people and an idea. At the same time, there was a post online where we were all discussing the OSS community’s attitude toward non-developers. I’m not one of those who thinks there’s a big difference in attitude. In most cases, the community is either friendly to everyone or largely closed off within a specific circle. And it’s rare to find a place where code is welcome but ideas and other forms of contribution are not. Hostages of Habits Yet in our daily lives, this difference does exist - it’s the infrastructure. When we talk about representing contributors at the service level, perhaps the first thing that comes to mind is the list of contributors on GitHub. It’s also, in a way, the last. Everything else is, at best, isolated efforts by individual projects to make the contributions of other participants visible. But despite these rare attempts, the approach itself doesn’t really change, and this has become an established habit. But why is there so much focus on this? Don’t get me wrong - code is a very important part of OSS - its value is hard to overstate. But the main value lies in the community, in the people. If we look at projects, the most valuable thing we’re building isn’t individual features - that’s a matter of hours, days, or sometimes even weeks. The most valuable thing is peers. As we build features, the project will continue to grow, but it will gradually approach a plateau. Each new task will contribute less and less to this creation. Peers, on the other hand, are about exponential growth. But when these peers consist only of developers or another specific group, we very quickly hit the inevitable glass ceiling. A great tool made for oneself and tailored to oneself. Going beyond this zone has always interested me - first as part of work projects, and now [even more so] as an npmx.dev member. Not a universal experience “But why go beyond these boundaries if it already works for a million people - it’s a tool for developers, and that’s enough for us”. And behind this lies the same principle as in any other area of our lives. When working with a specific group, we end up in a bubble from which we cease to understand other bubbles. It’s about design - just because we like it doesn’t mean it aligns with the user experience; It’s about accessibility, because just because we can see it and control it doesn’t mean others will “see” it too; It’s about performance, because when it works fast for us it doesn’t mean other users will consistently get the same experience; It’s about our representation, because what’s obvious to us might be a blind spot even for experienced engineers; It’s about copyright, illustrations, security, stability, emotions. It’s about us. After all, we are human - unique and so different. And it is precisely this diversity that shapes our future. An Open Community It’s hard to call me an optimist, but I know for sure that we’re moving forward toward a bright future. That’s why one of the tasks that I - and many at npmx - set for ourselves as a key goal is to make collaboration among all of us easier, more convenient, and friendlier for everyone. With this in mind, I participate in many discussions, and it’s largely this mindset that guided the design of npmx and parts of my vision. And yes, we have a design - you may have even seen it mentioned at atmosphereconf. We work hard to be an open community, but we’re still limited by our services. However, in recent years, aside from AI, there’s been - in my opinion - an even more important shift that’s worth stepping back from for a moment. At protocol A decentralized protocol focused on ownership. Your data is owned by you, while additional infrastructure interacts with each user’s data and acts as an intermediary at the general level when necessary. It solves the problem of connecting users. And that is exactly what we were working on. Any service, any user, any infrastructure can connect to this data and take exactly what they need, displaying it however they want and own this actions the way they want. This vision resonates with many of us, and in fact, it solves exactly what I described above. That’s why we’re built on it - not on specific, off-the-shelf tools but on the protocol and the vision. This site, by the way, is also powered by atproto, and the article you're reading now is stored in my pds in site.standard.document lexicon Social Layer We loosely refer to this level of functionality as the social layer. It’s where all user and package interactions take place - projects, profiles, likes, saves, shares. This already makes up a large part of the project, but in essence, we’re just getting started in this direction. One of the first such updates was likes, and to my delight, the wonderful Svelte has been and remains the leader all this time (now it's already 191). Nowadays, in our daily lives, we interact with dozens of services just to get basic information - to check stars and downloads, read documentation, view source code, look at vulnerabilities and issues, follow authors, join Discord, check releases, read the author’s articles… This list goes on and on. And it’s even longer for the project author who shares all of this with their beloved community. The true magic of OSS lies in the people who do this, day in and day out. Thank you for that! You’re making magic happen, and we can’t do it for other, but we can help make it easier. Npmx has already brought together npm view, GitHub stats, Social Layer, e18e and many more in one place. Integrations with an even longer list of services are coming soon But even this still largely keeps us in our bubble. Contribution as a layer Thinking about how to break out of this bubble, I’ve been talking a lot with people both inside and outside the community in search of details and solutions, including in discussions on the post mentioned earlier We have many people ready to join us on the OSS journey, but sometimes there simply isn’t room for them. Some contributions simply go unnoticed, except for our personal appreciation for these people. We try to speak up about what our community does and value it a lot (endlessly). But we want to show this even more, including at an automated level. That’s why another idea I hope we can implement is “contribution interactions”. Imagine a social network with users, posts, comments, and embeds. But instead of social media accounts - you have tech profiles, instead of posts - releases and articles, instead of comments - ideas and tasks, and instead of likes - contributor recognition and reactions. Every PR is an important contribution to the project, but equally important contributions include tasks, designs, suggestions, ideas, bug reports, and even posts expressing disagreement. One of the main ideas is to make this visible. In that very same unified space that has already become home to all our daily services, a new layer will appear to strengthen the connections between these areas. After all, to be a contributor, you don’t necessarily have to be on GitHub - it’s enough to love the idea just as much as we do. And our task is to find a way to say thank you in return. To everyone, everywhere. After all, behind every technology there are always ideas and people. A few other updates npmx stays true to its values, remaining not only the service I love so much, but also a warm, welcoming community that I’m so happy and proud to be a part of. Made by wonderful alfon.dev We conducted some research with the team and shared the results on April 1st! Charts, as well as many other details, have become even more accessible Comparing packages has become much more convenient A wonderful version page has appeared And much, much more… We’re building this project for people, together. Join us on this great journey. Site • Discord • Bluesky • GitHub

The month. npmx

Tue, 03 Mar 2026 13:25:00 GMT

npmx - a fast, modern browser for the npm registry. You've definitely heard about this project, and it’s probably got you just as excited as it has me. We've had a month of exciting and invaluable experience, and we've got some crazy plans ahead. I'm Alex, a project maintainer and one of the many who have been lucky enough to witness the formation of npmx from the front lines. This is an article reflecting on the project, warm stories, wonderful people, and, of course, a look into the future. I hope I can convey this marvelous experience and give you the opportunity to feel it with me. The moment London, winter, one of the longest seasons of rain and complete absence of sun. January is considered the most depressing month here. At this time, AI is taking over the world, and many large OSS projects are either declining or being bought by corporations. I work on my small projects day after day to distract myself from this race and relax. During breaks, I share solutions on bluesky and scroll through my feed. Everything happens in the same way on a daily basis - days that have been repeating for years - but on that day, one detail seemed unusual. More and more people, whom I always read with such interest, began to talk about a certain project for npm. No details, no links, no information on Google. Nothing, but it was enough to grab my attention. Although I am an introvert, it is people who have always inspired me to move forward. And I saw many people who are important to me in this stream (and I will see hundreds more, but more on that later). Acquaintance This went on for several days - I continued to finish my projects robindoc.com & atsky.app, London remained cloudy, the world of development became increasingly alien to me, and time and again I came across a project that had already piqued my interest. It was no longer just about people. The idea of building a project focused on developers in OSS today seemed bold, crazy. Did I see only a browser for npm in these posts? No, definitely not, but I'm getting ahead of myself again. And now I finally found a link. And it was a match. The idea, the design, the views, the values. Later, we joked that npmx was suspiciously similar to my projects by vibe. But these values are a reflection of all of us, and that's why npmx attracted so many wonderful people. At that moment, I was surfing the site with interest, enjoying the speed and design, and... Of course, I started looking at myself and my packages. Looking at the documentation, statistics, vulnerabilities, versions, metadata, release channels - so much new information was gathered on one page in a convenient interface. Well, almost convenient - the release channels didn't really work out. My long versions in the experimental channel of some packages broke the interface. Out of habit, I open devtools, quickly find the cause, and decide to write about it so that I don't get caught up in it in the future. To my great delight, I find a panel with all the links in the footer. Contributions Both Discord and GitHub are invaluable parts of this project that are difficult to talk about separately. But first, a little about the code. I already mentioned that this project attracted me because of the people behind it. And here I omitted an important detail - despite the fact that I have spent almost all of my career working with React & Next, most of my subscriptions are to wonderful authors from other ecosystems — Svelte, OCaml, Astro, Vue. What am I getting at? npmx turned out to be written in Vue & Nuxt, an ecosystem I'm practically unfamiliar with. But the bug I found was simple, and my interest was strong. So, without thinking twice, I forked it, read the contributing guide, searched, fixed, checked, PR, merged, and released. Did I go through the steps too quickly? Actually, that's exactly how it went. I think installing the dependencies took longer than the rest of the cycle. My interest was piqued once again. The whole process was unexpectedly simple. Once you open the project, you immediately stop noticing that this technology is new to you. You just feel it, and that's how it all works. And if you do miss something, the tooling is already set up to check every part, from stability to accessibility. And if there are still gaps after that, you will be reviewed by some of the most experienced people in this ecosystem, who do so honestly, warmly, and wholeheartedly, trying to teach and help you. Collaborations And here we return to a familiar topic - people. I have mentioned this factor many times and will mention it many more later. It is the people behind the project that make it special. More than 200 people, many of whom I had the pleasure of working with to come up with ideas, make corrections, check things, and just communicate. This is a place where time flows differently. Where up to 100 people participate in decision-making, backing up their arguments with experience and sources. Where ideas are born on the fly and immediately find executors. Where assumptions are backed up by advice from experts in a11y, SEO, performance, etc. Where translations for many languages are added with a single message asking a question. Where everyone works on different things, but still on the same. We heatedly discussed button designs, decided on the cursor, tested the search functionality, worked out the accessibility of every detail, and suggested ideas for graphs (and watched in amazement as Alec Lloyd Probert solved them quickly and elegantly). This list could go on forever, and each of these stories deserves its own article. This is a place where friends gather. We can't say how long we will continue to develop npmx, but these connections will remain with us for many years to come. And I am happy to play my part in this. Maintainer Almost a week had passed, and I continued to complete task after task that bothered me. At the same time, without me even noticing, the whole project became familiar and dear to me, as if I had been working on it for the last few years. We consulted, reviewed, found mistakes, corrected, and made some bugs. But day after day, the project continued to grow exponentially. "How quickly other people’s kids grow", joked I to myself. It was growth that I would not have believed possible, but here it was an exception - there were amazing people behind this project. Meanwhile, I had practically completed my internal pool of tasks, as had many other participants in the story. Conversations about problems were replaced by discussions about plans, architecture, and standards. Conversations without a source of truth, without managers, without customers, without needs. Built around one goal - to give the web environment and OSS a new life. And, to my infinite happiness, we agreed on the vision for the next steps. And against this backdrop, I was invited to join the maintainers team. I had already grown to love this project and, of course, was very grateful and happy to receive such an invitation. But for me, it's more than just a role, perhaps even more important than on everyday job. I came to the project because of the people, and for the same reason I fell in love with it. Every member of an open community can either empower others or destroy their interest at all. Will I be able to maintain my enthusiasm for a long time, and how long will I be able to be an active member of this community... I had a warm and honest conversation with the project stewards, and we agreed on almost everything, as we did with all the participants in the story before. And most importantly, first and foremost, we are simply making our everyday experience better, together and for everyone. We agreed that I will stay here as long as I can, and, as it seems now, the energy of this community will keep me warm for a long time to come. Marathon Meanwhile, the project continued to move forward. More and more ideas, more and more communication, more and more issues and PRs. We were accelerating at an incredible pace, working more and more every day. During breakfast, you discuss an idea in Discord, then reviews, issues, plans, *cut*, and suddenly it's 3 a.m., and you're still actively discussing the next PR. On each of these nights, we successfully gained milliseconds and literally every micro-reaction. And the next morning, during breakfast, you go into the chat, see the discussion of the idea, *cut*... An incredible pace, exponential growth every day, dozens of ideas, hundreds of issues per day, thousands of messages. At the same time, every day new experienced and strong participants arrive, ready to solve problems from the very first minute. A pace that any startup dreams of, a team that any corporation would envy. Yes, I am once again bringing you back to people, because behind all this magic there were already almost 500 people. Each of whom not only sincerely loves the project, but also the people around us. This is what distinguishes it from corporations and startups. So the next step, unexpected and strange to many outsiders, was taken - we announced a vacation. Vacation One week, complete blocking of channels and repositories, disabling discussions and stopping updates, canceling invitations to Discord, pausing posts and technical ideas. And all this in a project that was already used by tens of thousands of people. But it was much more than just a desire to rest. We cannot create a wonderful experience for users if we don't make the experience better for each other. It seems that this philosophy was taken from nuxt and vite, but here we gave it a completely new and warm format. In the remaining days, we fixed bugs, checked stability, reviewed PRs, and prepared to go out and touch the grass. Then we all got together, celebrated another wonderful day, and went to rest with anticipation of our plans. For me, this was the first time in my entire career that I wasn't programming because I wanted to (rather than because of illness or relocation). And I did what I always loved to do - take leisurely walks with my camera through the green corners of London. At the same time, it was a great opportunity to tackle some long-standing projects - articles, design, and social media. We simply lived and did what we enjoyed, letting go of the usual programming race for a while. Touching the grass wasn't a strict rule, and we touched the snow, trees, and our beloved pets. Sometimes the rule was completely disregarded, so we touched the grass like this: At the same time, we discussed tastes, countries, shops, cheeses, pizza, places, hobbies, plans, and jokes. Practically strangers to each other, from different corners of the earth - with similar questions, tastes, and problems - we turned these evenings into heartfelt online gatherings. And then we celebrated 2,000 stars. The vacation was coming to an end, and a big release was ahead of us. March 3rd, the day when we would openly talk about ourselves and our future for the first time. A month of the project's life was already behind us, a month of wonderful experiences and warm stories. But behind these stories, I left out another, equally important detail - ideas and meaning. And when to talk about greatness if not after a vacation? Reasons "A fast, modern browser" is a phrase you've heard many times before. After all, speed and ease of surfing are important factors, and you'll feel it every fraction of a second you spend on the site. I love this phrase - it's very concise and says a lot, but still not everything. Behind this project are ideas and visions that we have gathered over years of interacting with services. Everyone has their own experience and priorities, which makes it difficult to choose a single vector. The service is growing in many directions at once: accessibility, community features, data-focused tools, ownership, speed, and so on. But if we simplify it all into one rule, it would probably be "everything you need for development, fast and for everyone." Fortunately, we know how to achieve this. Most of us have created tools and services before, many for the atproto ecosystem and with a focus on user experience. These are hundreds of experts, each in their own field, who came to npmx to work on a project they love and value. Not just as a service, but as a tool we use every day. Npmx is much more than a browser - it is a service focused on people. Its goal is to provide quick and high-quality choices, where metrics are based on the opinions of other participants, and where the interface is designed for quick search results rather than retention. I enjoy working on ideas, optimizations, and design in this system. There are still many opportunities ahead, and we are just getting ready to take action. The Future And now we have gone through this wonderful month together. I am finishing this part literally in the last moments before the launch of the service, and perhaps you have even noticed how feeling of this article has changed. Looking back on those January days, I realize how much has changed. Not only with me and the project, but with the entire ecosystem. Community support, OSS activation, changes in npm, and independent interfaces for services. Today, we casually talk about a new service with a convenient interface for GitHub, but just a couple of weeks ago, we were jokingly discussing the post "when githubX". "Bold", I would have said then, and "inevitable", I say without a doubt today. All we needed was people. And luckily, we stumbled upon that wonderful series of posts. We spent this month together building connections, ideas, and architecture. It takes a lot of time, but we are close to completing the strongest foundation. And we are getting ready to build even more amazing opportunities. With a focus on people, their experience, their convenience, and their connections. Just as we found value in each other, any project can become the center of a network of wonderful connections. We build in open source, but the most valuable stuff happens in our chats and conversations with each other. Join us ❤️ Site • Discord • Bluesky • GitHub

Next.js v15 — What’s new under the hood

Thu, 17 Oct 2024 12:16:00 GMT

Hello! This is another article about next.js. And finally, about the new version! Each release is a set of new, interesting, and controversial features. This version will be no exception. However, new version is interesting not so much for its new functionality, but for the change in priorities and organization in next.js. And yes, as you may have guessed from the title, a significant part of this release is valuable for reflecting on previous mistakes. I’ve been working with next.js since around version 8. All this time I’ve been watching its development with interest (sometimes not without disappointment). Recently, I’ve published a series of articles about struggling with the new App Router — “Next.js App Router. A path to the future or a wrong turn”, “Next.js caching. A gift or a curse”, “More libraries for the god of libraries or how I rethought i18n”. All of these were a result of very weak development of ideas and capabilities in previous versions of next.js. And because of this, my interest in the new version has only grown. Along with that, there’s a desire to understand the vector of changes in the framework. In this article, I won’t dwell on what App Router or server components are — these are described in detail in previous articles. We’ll focus only on the new version and only on the new changes. Note: The article reflects the most interesting changes from the author’s perspective. They differ from the official list, as the author selected them from commits and PRs in the framework. Next.js v15 Release First, a bit about changes in the internal development processes of next.js. For the first time, the framework team has published a release candidate (RC version). Obviously, they did this due to the React.js team’s decision to publish React v19 RC. Usually, the next.js team in their stable releases calmly uses react from the “Canary” release branch (this branch is considered stable and recommended for use by frameworks). This time, however, they decided to do things differently (spoiler alert — not in vain). The plan for both teams was simple — publish a pre-release version, let the community check for issues, and in a couple of weeks publish a full release. It’s been over six months since the release candidate of React.js was released, but the stable version still hasn’t been published. The delay in releasing the stable version of React.js has impacted next.js’s plans as well. Therefore, contrary to tradition, they published a total of 15 additional patch versions while already working on the 15th version (usually 3–5 patches and then a release). What’s noteworthy here is that these patch versions didn’t include all accumulated changes, but only addressed critical issues, which also deviates from next.js’s usual processes. The basic release process in next.js is that everything merges into the canary branch, and then, at some point, this branch is published as a stable release.However, as a result, the next.js team decided to decouple from the React.js release and publish a stable version of the framework before the stable version of React.js is released. Documentation Versioning Another very useful organizational change. Finally, it’s possible to view different versions of the documentation. Here’s why this is so important: Firstly, updating next.js can often be quite a challenging task due to major changes. In fact, this is why there are still over 2 million downloads for version 12 and over 4 million for version 13 monthly (to be fair, version 14 has over 20 million downloads). Consequently, users of previous versions need documentation specific to their version, as the new one might be rewritten for a half. Another problem is that Next.js essentially uses a single channel. Documentation changes are also made to it. Therefore, descriptions of changes from canary versions immediately appeared in the main documentation. Now they are displayed under the “canary” section. React usage At the beginning, I mentioned that Next.js is currently using the RC version of React.js. But in reality, this is not quite true, or rather not entirely true. In fact, Next.js is currently using two React.js configurations: the 19th canary version for App Router and the 18th version for Pages Router. Interestingly, at one moment they wanted to include the 19th version for Pages Router as well, but then rolled back these changes. Now, full support for React.js version 19 is promised after the release of its stable version. Along with this, the new version will have several useful improvements for server actions functions (yes, the React team renamed them): I suppose I’ll include Next.js’s new feature in this section as well — the Form component. Overall, it’s the familiar form from react-dom, but with some improvements. This component is primarily needed if successful form submission involves navigating to another page. For the next page, the loading.tsx and layout.tsx abstractions will be pre-loaded. import Form from 'next/form' export default function Page() { return ( ; ) } Developer Experience (DX) When talking about Next.js, we can’t ignore the developer experience. In addition to the standard “Faster, Higher, Stronger” (which we’ll also discuss, but a bit later), several useful improvements have been released. Long-awaited support for the latest ESLint. Next.js didn’t support ESLint v9 until now. This is despite the fact that both eslint itself (v8) and some of its subdependencies are already marked as deprecated. This resulted in an unpleasant situation where projects were essentially forced to keep deprecated packages. The error interface has been slightly improved (which in Next.js is already clear and convenient): A “Static Indicator” has been added — an element in the corner of the page showing that the page has been built in static mode. Overall, it’s a minor thing, but it’s amusing that they included it in the key changes as something new. The indicator for a “pre-built” page has been around since roughly version 8 (2019) and here, essentially, they’ve just slightly updated it and adapted it for the App Router. A directory with debugging information has also been added — .next/diagnostics. It will contain information about the build process and all errors that occur. It's not yet clear if this will be useful in daily use, but it will certainly be used when troubleshooting issues with Vercel devrels (yes, they sometimes help to solve problems). Changes in the Build Process After discussing DX, it’s worth talking about the build process. And along with it, Turbopack. Turbopack And the biggest news in this area. Turbopack is now fully completed for development mode! “100% of existing tests passed without errors with Turbopack” Now the Turbo team is working on the production version, gradually going through the tests and refining them (currently about 96% complete) Turbopack also adds new capabilities: const nextConfig = { experimental: { turbo: { treeShaking: true, memoryLimit: 1024 * 1024 * 512 // in bytes / 512MB }, }, } These and other improvements in Turbopack “reduced memory usage by 25–30%” and also “accelerated the build of heavy pages by 30–50%”. Other Significant style issues have been fixed. In version 14, situations often arose where the order of styles was broken during navigation, causing style A to become higher than style B, than vice versa. This changed their priority and consequently, elements looked different. The next long-awaited improvement. Now the configuration file can be written in TypeScript — next.config.ts import type { NextConfig } from 'next'; const nextConfig: NextConfig = { /* config options here */ }; export default nextConfig; Another interesting update is retrying attempts for static page builds. This means if a page fails at build time (for example, due to internet problems) — it will try to build again. const nextConfig = { experimental: { staticGenerationRetryCount: 3, }, } And to conclude this section, a functionality highly desired by the community — the ability to specify the path to additional files for building. With this option, you can, for example, specify that files are located not in the app directory, but in directories like modules/main, modules/invoices. However, at the moment, they have only added it for internal team purposes. And in this version, they definitely won’t present it. Going forward, it will either be used for Vercel needs, or they will test it and present it in the next release. Changes in the Framework API The most painful part of Next.js updates — API changes. And in this version, there are also breaking updates. Several internal framework APIs have become asynchronous — cookies, headers, params and searchParams (so-called Dynamic APIs). import { cookies } from 'next/headers'; export async function AdminPanel() { const cookieStore = await cookies(); const token = cookieStore.get('token'); // ... } It’s a major change, but the Next.js team promises that all this functionality can be updated automatically by calling their codemod: npx @next/codemod@canary next-async-request-api .Another change, but probably not relevant to many. The keys geo and ip have been removed from NextRequest (used in middleware and API routes). Essentially, this functionality only worked in Vercel, while in other places developers made their own methods. For Vercel, this functionality will be moved to the @vercel/functions package And a few more updates: const nextConfig = { images: { localPatterns: [ { pathname: '/assets/images/**', search: 'v=1', }, ], }, } Caching In my personal opinion, this is where the most important changes for Next.js have occurred. And the biggest news is — Caching is now disabled by default! I won’t go into detail about caching problems, this was largely covered in the article “Next.js Caching. Gift or Curse”.Let’s go through all the main changes in caching: const nextConfig = { experimental: { staleTimes: { dynamic: 30 // defaults to 0 }, }, } const nextConfig = { experimental: { serverComponentsHmrCache: false, // defaults to true }, } That’s regarding the “historical misunderstandings”. New APIs will also appear in Next.js. Namely, the so-called Dynamic I/O. It hasn't been written about anywhere yet, so the following will be the author's guesses based on the changes. Dynamic I/O appears to be an advanced mode of dynamic building. Something like PPR (Partial Prerendering), or more precisely, its complement. In short, Partial Prerendering is a page building mode where most elements are built at build time and cached, while individual elements are built for each request. So, dynamic I/O [probably] finalizes the architecture for this logic. It expands caching capabilities so that it can be enabled and disabled precisely depending on the mode and place of use (whether in a "dynamic" block or not). const nextConfig = { experimental: { dynamicIO: true, // defaults to false }, } Along with this, the "use cache" directive is added. It will be available in nodejs and edge runtimes and, apparently, in all server segments and abstractions. By specifying this directive at the top of a function or a module exporting a function - its result will be cached. The directive will only be available when dynamicIO is enabled. async function loadAndFormatData(page) { "use cache" ... } Also, specifically for use cache, methods cacheLife and cacheTag are added export { unstable_cacheLife } from 'next/cache' export { unstable_cacheTag } from 'next/cache' async function loadAndFormatData(page) { "use cache" unstable_cacheLife('frequent'); // or unstable_cacheTag(page, 'pages'); ... } cacheTag will be used for revalidation using revalidateTag, and cacheLife will set the cache lifetime. For the cacheLife value, you'll need to use one of the preset values. Several options will be available out of the box ("seconds", "minutes", "hours", "days", "weeks", "max"), additional ones can be specified in next.config.js: const nextConfig = { experimental: { cacheLife?: { [profile: string]: { // How long the client can cache a value without checking with the server. stale?: number // How frequently you want the cache to refresh on the server. // Stale values may be served while revalidating. revalidate?: number // In the worst case scenario, where you haven't had traffic in a while, // how stale can a value be until you prefer deopting to dynamic. // Must be longer than revalidate. expire?: number } } } } Partial Prerendering (PPR) Probably the main feature of the next release. As mentioned earlier, PPR is a page building mode where most elements are assembled at build time and cached, while individual elements are assembled for each request. At the same time, the pre-built part is immediately sent to the client, while the rest is loaded dynamically. The functionality itself was introduced six months ago in the release candidate as an experimental API. This API will remain in this state, and we will likely see it as stable only in version 16 (which is good, as major functionality often transitioned to stable within six months to a year). Regarding the changes. As mentioned earlier, it primarily updated the working principles. However, from the perspective of using PPR, this hardly affected anything. At the same time, it received several improvements: Previously, there was just a flag in the config, but now to enable PPR, you need to specify ‘incremental’. This is apparently done to make the logic more transparent — content can be cached by developers even in PPR, and to update it, you need to call revalidate methods. const nextConfig = { experimental: { ppr: 'incremental', }, } Also, previously PPR was launched for the entire project, but now it needs to be enabled for each segment (layout or page): export const experimental_ppr = true Another change is Partial Fallback Prerendering (PFPR). It’s precisely due to this improvement that the pre-built part is immediately sent to the client, while the rest is loaded dynamically. In place of dynamic elements, a callback component is shown during this time. import { Suspense } from "react" import { StaticComponent, DynamicComponent } from "@/app/ui" export const experimental_ppr = true export default function Page() { return { <> }; } Instrumentation Instrumentation is marked as a stable API. The instrumentation file allows users to hook into the lifecycle of the Next.js server. It works across the entire application (including all segments of Pages Router and App Router). Currently, instrumentation supports the following hooks: register - called once when initializing the Next.js server. It can be used for integration with observability libraries (OpenTelemetry, datadog) or for project-specific tasks. onRequestError - a new hook that is called for all server errors. It can be used for integrations with error tracking libraries (Sentry). export async function onRequestError(err, request, context) { await fetch('https://...', { method: 'POST', body: JSON.stringify({ message: err.message, request, context }), headers: { 'Content-Type': 'application/json' }, }); } export async function register() { // init your favorite observability provider SDK } Interceptor Interceptor, also known as route-level middleware. It’s something like a full-fledged [already existing] middleware, but unlike the latter: Moreover, when creating an interceptor file, all pages below in the tree become dynamic. import { auth } from '@/auth'; import { redirect } from 'next/navigation'; const signInPathname = '/dashboard/sign-in'; export default async function intercept(request: NextRequest): Promise { // This will also seed React's cache, so that the session is already // available when the `auth` function is called in server components. const session = await auth(); if (!session && request.nextUrl.pathname !== signInPathname) { redirect(signInPathname); } } // lib/auth.ts import { cache } from 'react'; export const auth = cache(async () => { // read session cookie from `cookies()` // use session cookie to read user from database }) Speaking of Vercel, middleware will now be effective as a primary simple check at the CDN level (thus, for example, immediately returning redirects if the request is not allowed), while interceptors will work on the server, performing full-fledged checks and complex operations. In self-hosting, however, such a division will apparently be less effective (since both abstractions work on the server). It may be sufficient to use only interceptors. Conclusions Overwriting fetch, aggressive caching, numerous bugs, and ignoring community requests. The Next.js team made erroneous decisions, rushed releases, and held onto their views despite community feedback. It took almost a year to recognize the problems. And only now, finally, there’s a sense that the framework is once again addressing community issues. On the other hand, there are other frameworks. A year ago, at the React.js presentation, it seemed that all frameworks would soon be on par with Next.js. React started mentioning Next.js less frequently as the main tool, frameworks were showcasing upcoming build systems, support for server components and functions, and a series of global changes and integrations. Time has passed, and essentially, none of them have reached that point yet. Of course, final conclusions can only be drawn after some time, but for now, it feels like the changes in React.js, instead of the expected leveling of frameworks, have led to even greater dominance of Next.js and a wider divergence between frameworks (since the implementation of server components and actions was left to the discretion of the frameworks). At the same time, OpenAI switched to Remix (“due to its greater stability and convenience”): And apparently they started before significant changes in Next.js In general, in the next stateofjs and stackoverflow surveys, we are likely to see significant reshuffling. Credits Code examples or their foundations are taken from next.js documentation, as well as from commits, PRs, and the next.js core; Postscript If you need a tool for generating documentation based on MD files — take a look at robindoc.com, if you work with next.js — you might find something useful in the solutions at nimpl.tech.

Website Performance. Big Basic Checklist

Fri, 13 Sep 2024 08:13:00 GMT

A fast website is something very obvious and simple: the site loads quickly and does not freeze. “If you make people wait 3 seconds, you start losing users” is a rule that probably every web developer has heard. But this rule is only the tip of the iceberg, both when it comes to the reasons customers are lost and when it comes to real outcomes. This article is a comprehensive collection of information about performance: from the history of the first analysis tools and the reasons they appeared, to modern problems and universal ways to improve a website. Performance factors First, what does a fast website mean? Site speed is a combination of factors. Some of them are easy to measure, including in a “lab” environment, while others work only at the level of the user’s perception. And perhaps the three‑second rule today can no longer be called the main and only correct one. Most users now have fast enough internet to load even a very heavy page in a couple of seconds. Further optimizations of load speed are done mostly for the remaining 20% of customers. But there are factors that affect 100% of customers. These are factors of how the site is perceived and how it feels to interact with it. And if you try to identify the main principle of a fast website today, it is this: “the user should not feel the site working.” To achieve that, you need to consider not only site speed metrics, but also the user experience. User experience You have probably run into situations where you search for an answer, open a site, start reading, and ads keep loading nonstop on the sides. Or you open a landing page for a tool to see how it is used, and it stutters because of animations. Or you click a button and nothing happens. These are very common cases that almost every third site is guilty of. But there are less obvious cases too. Site feedback Imagine two blogs. In both, you go to the second page of an article list. In the first case, nothing happens. One second, two seconds, you click again. Another second, and here is the long‑awaited navigation to the new page. Next time you do this, you will very likely click again after just a second. After that, repeated clicks will happen immediately. The reason is simple: the interface gives no feedback that the action was successful. A kind of “CTRL+C effect.” In the second blog, right after the navigation it shows skeleton placeholders for the articles. That same one or two seconds of waiting feels different. The user understands that loading is in progress and the articles are about to appear. But what happens with the same scenario on a 5G connection? The first site will load and show new articles after about 200 ms of a blank screen. The second site will immediately show a skeleton, and after 200 ms it will replace the skeletons with the actual articles. During those 200 ms the interface changes several times, with jumps and flicker. So an overly fast response significantly worsened the user experience. This happens with all metrics: improving one can lead to worsening another. Every optimization is analysis, checks, tests, and searching for the best solution for a specific case. In this case, the optimal solution is to show a loader or skeletons with a small delay, usually around 150 to 300 ms. After a second, you can show an additional message like “This page is taking longer than usual, please wait.” This kind of solution is used, for example, in Jira and Notion. Usually users do not notice these tricks (and that is exactly the key factor of a fast site, as mentioned before). Another possible solution is a progress bar. In this case a line appears right away showing the loading percentage. The percentage can be symbolic, moving in steps (started the action: 10%, sent the request: 20%, received a response: 90%). You can see this approach, for example, in GitHub. Showing content The other side of the same situation is that the user should see something as early as possible. This applies both to the initial page load and to everything that happens after. For example, if a page has a popup with cards for related tasks, you should not wait until all tasks are loaded and only then open the popup. The user may not even need that list. It is much better to show the popup right away with the data you already have and indicate that the tasks are still loading (using the approaches mentioned above). Some services show a full-screen loader during the basic page load. LinkedIn does this while the main blocks load, then it shows the page and loads a few more blocks. This can be good for perceived experience, but it can hurt metrics because it causes UI transitions, extra logic, and delays. For example, the LCP metric, which will be discussed later, will be counted when the largest element is loaded, which in this case will happen only after the loader is hidden. Animations Animations sit on a very fine line when it comes to user experience. They are a powerful tool for showing beauty, modernity, and a sense of momentum. And it is true that a site without well-crafted states, effects, and animations often cannot compete. With states and micro-effects, things are simple: a short, smooth response to every interactive user action. Full animations are more complex. An overabundance often leads to the page freezing or stuttering, especially on a user’s first visit (and since animations are used mostly on marketing landing pages, that is a large part of the audience). You need to find a balance in both quantity and complexity. For especially complex animations, a much more efficient solution is often to use video. There are also cases of deliberately worsening the user experience. For example, full-screen transitions on scroll. Instead of quickly scrolling to the relevant part (pricing, description, the form itself, and so on), the user spins the wheel for 10 seconds and watches animations they do not need. A similar situation happens with videos or animations that autoplay as you scroll. Users often do not need those videos. Each scroll step should reveal useful information that stays anchored in place. Image display Another basic and controversial example is progressive image loading, where an image is shown first in very low quality with blur, and the full version loads in the background. This is how, for example, Cloudflare Mirage or Next.js Image works. This approach is controversial for a few reasons: So, with the right optimizations, this can improve user experience because the user sees thumbnails quickly. But, all else being equal, it will likely worsen speed metrics, because it clogs the pipeline with extra requests (or increases page weight if those images are inlined) and runs inside client logic. Another common mistake is setting loading="lazy" on a large image in the first section. It will load after all scripts, sprites, CSS files, other non-lazy images, and so on. But the user should see that image immediately, which means it should be much higher in the queue. I intentionally do not mention image preloading (meta preload) here. It is usually better to load images via picture with multiple formats. With preload, you either have to pick a preferred format or preload all possible variants (which also harms other metrics). Late image loading affects metrics, especially LCP. Incorrectly configured images can also worsen CLS. That brings us to the main set of metrics: Web Vitals. Web Vitals Web Vitals is a set of metrics that Google considers key to user comfort. Currently, they include: All of these metrics have different weights. You can see the weight and the potential benefit of improving each one in a special calculator. The list changes constantly. For example, in 2017 there was First Meaningful Paint instead of FCP, Perceptual Speed Index instead of Speed Index, and Estimated Input Latency (which was later replaced by First Input Delay and is now being replaced by INP). Web Vitals metrics are part of the Lighthouse analyzer. Lighthouse, in turn, is part of the PageSpeed Insights service, which is part of the Google PageSpeed toolkit. The latter was introduced by Google back in 2010. Today this is the main set of metrics for analyzing site performance in Google and on the web overall. But in the first years after release, they were not very popular. Everything changed when Google updated its search ranking policy. Why Web Vitals appeared If you find a first-generation website today, its contents will usually arrive extremely quickly, even though those sites had no optimizations (not even response compression). For example, netside.net has a total resource weight of 117 KB (114 KB transferred). For comparison, the average Wikipedia page is about 750 KB (250 KB transferred), and react.dev/reference/react is about 2.1 MB (915 KB transferred). At the same time, both Wikipedia and the React documentation load in roughly the same time as netside on fast connections, but on slow connections they take 2 to 3 times longer for the full content to appear (8 seconds versus 3 seconds). The internet got much faster, and as a result people largely stopped paying attention to page weight. Today, an apparently simple text page can load tens of megabytes of data. Services that are identical in complexity, with medium-sized HTML, simple styling, and basic logic, can still differ dramatically in size and metrics. While some teams built huge products and optimized them to load in a couple of seconds, others simply scaled sites to tens or hundreds of megabytes. jQuery, Angular, and later Vue and React accelerated this trend to extreme levels. As a result, users increasingly landed on sites that took longer than 3 seconds to load. Without waiting for the content, they would go back to search and try other sites. At some point Google noticed this. After being disappointed a few times, users could close the search engine or switch to another one (where results were ranked differently). In 2020, the Web Vitals metric set was fully introduced, Lighthouse was rebranded, and a new era of optimization began. Metrics returned to the web with renewed force. Impact of metrics on business In 2020, not only the metrics themselves were introduced, but also updated tools for analyzing and optimizing them. Lighthouse did not just show a page’s results. It provided clear, concrete metrics, instructions, and documentation for possible optimizations. Today, metrics play an important role in search results. Slow sites risk more than just the three-second rule. They can also lose organic traffic as they drop in rankings. But why? Google, of course, does not disclose all ranking rules, and it often says it does not know them in full. Still, it is known that a position in search results is the sum of many factors. Some factors are higher priority than others. Content quality, relevance to the query, and a site’s overall “weight” are among the most important. But Web Vitals metrics are also one of the ranking factors. At the same time, an even bigger factor is how real users behave. That is why, in Google, many metrics are assessed using real user data rather than purely in a lab. If people visit a site and consistently stay on it (instead of immediately returning to search), that is a good signal. So if a site is slow, it not only loses points on metrics. It also risks losing overall effectiveness. Some sites can have very poor performance metrics while still being highly effective. Such sites can rank above sites with good metrics but worse user effectiveness, because this factor matters more. Overall, this started an era of chasing metrics and endless attempts to trick Google. For example, for a while it was popular to show crawlers a screenshot of the first screen. Agencies often used this approach. The image loaded much faster than all of the site’s resources, so the metrics were immediately counted. It is possible that approaches like this are exactly why performance is now analyzed using real user data. Today, if Google sees suspicious differences between what bots and real users receive, it can react harshly. This often means removing pages from search results and blocking them in Google’s services. Of course, slow sites also affect the business itself. Tasks take longer to complete, navigation is slower, and various unpleasant effects appear. Overall, it is simply less comfortable for people to use such a site. A few more resources on how optimizing metrics can help a business: How The Economic Times met Core Web Vitals thresholds and increased overall bounce rate by 43% How redBus improved Interaction to Next Paint (INP) and increased sales by 7% How Renault reduced bounce rate and improved conversions by measuring and optimizing Largest Contentful Paint BBC found that they lose an additional 10% of users for every extra second a website takes to load Vodafone: improving LCP by 31% increased sales by 8% Rakuten 24: investing in Core Web Vitals increased revenue per visitor by 53.37% and conversion rate by 33.13% Metrics for dynamic sites Over time, a number of single-page application (SPA) libraries and frameworks started being used to build marketing websites. As a result, a large share of content ended up outside the reach of search engines. Google reacted again. Googlebot began not only scanning sites immediately, but also letting dynamic content render. This meant apps could fully compete for rankings. This means the question of metrics also affected these tools. Frameworks started competing not only on simplicity and features, but also on speed. But they did not do a great job at it. Splitting logic, lazy loading, style optimization, and deferred rendering can, in the case of marketing landing pages, only get you closer to native sites. An SPA can apply many internal optimizations only after all client logic has loaded. That makes sense for web applications, because it brings a large benefit for long browsing sessions and repeat visits. But for landing pages, optimizations for a user’s first visit are often much more important. Today, React Server Components are changing this. Combined with many built-in optimizations in React and Next.js, they make it possible to get comparable metrics out of the box and provide a lot of potential for marketing use cases. But that is a topic for separate articles. Data collection and analysis Overall, metrics are important, metrics are useful, and metrics need to be improved. But before improving them, you need to collect data about them. Lighthouse The first tool on this list is the already mentioned Lighthouse. Lighthouse is the main tool for working with Web Vitals in lab conditions. It lets you collect the metrics themselves, look at additional factors (such as accessibility or best practices), find weak spots, and review recommendations for improvements. You can test a site in Lighthouse both locally and via the PageSpeed Insights service, on the recommended device. If you need a quick check for the main issues, it is enough to run the local version (Developer Tools → Lighthouse → Analyze Page Load). If you need a full analysis, trend tracking, and more stable results, use PageSpeed Insights. The service will show all the needed information, but specifically on the recommended device. Also, if the site is popular enough, the service will show average user metrics. Developer tools Besides Lighthouse, DevTools has a number of other useful tabs, but the most helpful for optimization are probably Performance and Network. Performance Performance lets you record a page profile, including resource loading, script execution, and rendering. In this tab you can immediately see FCP and LCP. You can check request queues, analyze long scripts and animations, see delays, and find overloaded moments. Network In the Network tab you can see all network requests, including loading resources (images, scripts, styles) and REST requests. This helps identify which resources slow down loading. Here you can see the load time of each resource (including request latency), the request waterfall, queues, drops, request order, size, and caching. Search Console You can get a bit of additional information about real user metrics from Search Console. Google Analytics This may be an unexpected service on the list, but it is one of the most effective for analyzing real user results (Real User Monitoring, or RUM). GA can collect any data by simply enabling the needed options in settings, sending additional metrics manually, or connecting a ready-made preset in GTM (Google Tag Manager). For Web Vitals there is also a ready-made preset. Once connected, GA will start receiving all the metrics data you need. All that is left is to build charts and start tracking trends. Third-party services DebugBear DebugBear lets you automatically collect and analyze metrics through several tools, including Lighthouse, run multi-run analysis (to get more accurate metrics), and track and compare metrics and requests over long periods of time. SpeedCurve SpeedCurve lets you analyze real user metrics, test from different browsers and locations, check performance in CI/CD, analyze INP, and more. GTmetrix GTmetrix lets you analyze under different conditions, replay video recordings, test different scenarios, and analyze request waterfalls. Site24x7 Site24x7 lets you monitor all server components, from site load speed to network and Kubernetes monitoring, from more than 130 locations worldwide. Pingdom Pingdom lets you monitor a service, including availability and response time analysis. You can configure outage alerts and analyze from many locations. It can also monitor specific user scenarios. Uptrends Uptrends offers availability, performance, and infrastructure monitoring. It includes analysis from different locations, detailed reports, scenario testing, and API monitoring. WebPageTest WebPageTest lets you analyze a site and then validate optimizations using dynamic tests. The service can also be used to pre-check planned changes (for example, adding third-party analytics). Metrics optimization So, we have learned what metrics exist and how to analyze them. That means it is time to move on to optimizing them. Image optimization This is the improvement already mentioned in the context of user experience. Images often take up a significant share, not only of the page content, but also of its weight, meaning transferred traffic. That means it is worth reducing their weight. There are several approaches. Image compression The first and most obvious solution is to compress the image. There are many services and tools that can reduce image size, sometimes significantly, without a visible loss of quality. Overall, there are many solutions, and that deserves a separate article. In general, there are a few paths: Resizing images If an image is used in a 400x200 block, it does not need to be 1920x1080. No screen will show that level of detail in such a small block. It is better to use an image that is no more than 2x the display size. This margin is useful, for example, for retina displays. - + Lazy loading The idea of lazy loading is to defer downloading files until they are needed. For images, that is until they are visible. First, it is worth using the native browser attribute loading="lazy". It gives the desired result on fast connections. On slow connections, all images can still be queued immediately, so that when scrolling the page the user does not encounter blank spaces. But those images go to the bottom of the pipeline, letting the user load the most important files first, and only then load images. It is important that this attribute should not be used for critical images, such as a large image in the first section, meaning LCP. Using modern formats Among modern formats, webp and avif are worth mentioning. Both have good support today, and it is likely broader than what your website supports. At the same time, it is hard to say which format is optimal. For each image, the compression ratio and quality trade-offs differ. For example, for illustrations, png can often weigh less than a modern webp. For text, avif works well. For raster images with transparency, webp often works well. On average, choosing the right format can reduce image weight by more than 50%. Serving different images If someone visits from a mobile device, they do not need images intended for desktop, neither in size nor in quality. On mobile devices there is much less space for an image and often lower display capabilities. The most convenient way to serve different images depending on conditions is to use the tag. It lets you specify which image to show for which screen size and type. A nice bonus is that picture can include multiple formats. For example, webp as the primary one and png as a fallback for the rare case when webp is not supported or is disabled for some reason. Serving different images in CSS For CSS background images, handling screen size is simple: define media queries and set background-image to the right variant. But format selection is harder. For these cases, you can add a blocking script at the start of the page that adds the required classes to the whole document, such as .img-webp and .img-2x, and then set images in CSS based on those classes. .example-block { background-image: url("/example_400x225.png"); } .webp .example-block { background-image: url("/example_400x225.webp"); } Sprites For large images, the main goal is to reduce weight. For small images, the main goal is to reduce the number of requests. Small images and icons often weigh so little that transfer time is not the main issue. Instead, much of the time goes into connection start and subsequent delays. At the same time, a page often contains dozens or hundreds of icons. All of them can overload the pipeline and prevent important information from loading. The best solution in this case is to combine all icons into a single file, a sprite. This can be an SVG or a PNG. With SVG, an svg sprite is created as a single svg file, where each icon is defined as a separate tag. Then it is used via the use tag.

Critical icons, if any, can be split into an additional sprite and inlined into the HTML. With PNG, or another raster format, you create classes that crop a specific icon out of a larger image, a CSS sprite. This approach is often used by maps. .icon { background: url("/sprite.png"); height: 20px; width: 20px; } .icon-check { background-position: 20px 0px; } .icon-close { background-position: 40px 0px; } Inlining images Another possible optimization for small images is to inline them. This is useful when small images are used once and only on a single page. If the image repeats, it is better to include it in a sprite. This is usually implemented via additional loaders and special file naming. Video optimization The main improvement for video is deferred loading. But unlike images, it often follows a more progressive path: In some sections, YouTube shows GIF previews on hover, and on click navigates to the full player. Static compression A key optimization is configuring compression. Compression is especially useful for JS, HTML, and CSS files. It can reduce transfer size by around 50% to 70%, more or less depending on compression level, file size, and content. You can compress files during the build, generating brotli or gzip versions. It is better to prefer brotli, because it is about 20% more effective than gzip. More often, compression is delegated to a CDN or the server, in many cases nginx. But with incorrect configuration, such as missing caching, this can increase server response time. Style optimization How styles are delivered There are three ways to deliver styles to a page: Inline inflates the document, and that is critical, so it is not suitable as the main approach in most cases. External allows caching. But if every page has unique styles and the visitor only comes once, that benefit disappears. Embedded is most effective when each page has unique styles and you use streaming. Optimizing style application When rendering a page, changing DOM elements, or changing an element state, such as hover or focus, the browser recalculates styles. In some situations, this can cause visible slowdowns. As basic optimizations, remove unused styles and move rarely used media into separate bundles with conditions. Optimizing selectors This is a less obvious optimization. Evaluating some selectors can be an expensive operation. For example, if you have a selector like body.test-a .block[data-test=a], when the body class changes the browser needs to match all .block elements on the page. More about optimizing and debugging selectors can be found here: https://developer.chrome.com/docs/devtools/performance/selector-stats?hl=en#analyze-stats. Deferred rendering In addition to lazy loading sections or deferring rendering via JavaScript, you can use a standard CSS mechanism. The content-visibility property lets you tell the browser an element's visibility on the page. By default, all elements are rendered immediately and are fully available. But if you override this property, the browser can optimize rendering. With auto, the element will be prepared and rendered as needed. With hidden, it will remain hidden until you change the value. .map { content-visibility: auto; contain-intrinsic-size: 1000px; } The contain-intrinsic-size property lets you reserve height for the element. This is similar to height for an img with loading="lazy". It is important to note that if you set hidden, the element will not be available to bots or for in-page search. Font optimization Fonts are often a weak spot for a website because they are both critical and fairly heavy resources. Optimizing the glyph set First, review the fonts used on the page. Are all font families, weights, and variants really needed. After keeping only what is necessary, or switching to variable fonts, you can move on to optimizing how fonts are loaded. @font-face { font-family: "Inter"; src: url("Inter-Regular-webfont.woff2") format("woff2"); unicode-range: U+0025-00FF; } Loading strategy There are two main approaches to font loading: Which approach to choose depends on the situation, since both have pros and cons. In some cases, teams also use background font loading and apply those fonts only on subsequent visits. Preloading Another possible improvement is preloading fonts. This moves the font earlier in the loading pipeline than other resources. This step, like many others, can have negative side effects. For example, secondary fonts can take up the network pipeline, while the hero image from the first section ends up at the bottom of the initial request queue (so it is important to limit the number of fonts and preload only critical ones). Faster server response Because resources load like a train, one after another, server latency has a compounding effect. For example, if server latency is 60 ms and the hero image from the first section is loaded via JavaScript, it will load 120 ms later than it would with 20 ms latency (40 ms latency for the HTML, then 40 ms for the script, then 40 ms for the image). At the same time, latency stretches the entire pipeline and, as mentioned earlier, this is especially important for small files. To reduce latency, the following can help: Caching The best way to optimize requests is to avoid requests. One way to do that is caching. When all parts of the page are already downloaded and stored, the browser only needs to render the page (which takes relatively little time). Caching can dramatically speed up repeat page loads and navigation to subsequent pages (since some resources are shared). Caching usually relies on: The Cache-Control header. It lets you set how long the browser can cache a response. This should only be used together with a hash in the filename. Otherwise, the user may be unable to get updated resources (which can lead to unexpected artifacts). The Etag and Last-Modified headers. They let browsers detect whether content has changed and only download the file if it has. Otherwise, the browser uses the cached version. This approach requires an additional request to the server, which adds latency. For that reason, Cache-Control should be the default choice, and Etag or Last-Modified should be used for special cases. Other Reducing layout shifts Another important improvement that affects how fast a site feels is reducing layout shifts (CLS). They can happen, for example, when a user loads a page [and may have even started using it], and then additional elements load and shift the entire UI. These can be banners, images, dynamic widgets, and so on. For most cases, the main solution is to reserve the most accurate amount of space for the block. For example, for a banner above the header you can fix a minimum height of 60 px on desktop and 120 px on mobile. For images, use built-in mechanisms: Avoiding render-blocking elements Some elements can completely stop rendering and further processing of the page. These are called render-blocking. Until they load and or execute, loading of required resources and showing the page content is blocked. These elements commonly include: Postscript Beyond the list above, there are dozens or hundreds of other optimizations. Every framework, every library, and every integration has its own issues and its own impact on metrics. As mentioned earlier, every optimization is analysis, checks, tests, and searching for the best solution for a specific case. Validate ideas and continuously track trends. The best thing you can do is fix losses in time.

Vercel Edge — what is it and how is it

Sun, 14 Jul 2024 19:26:00 GMT

Edge runtime. One of the main functionality of Vercel — the company that developed and maintains next.js. However, its influence on the edge runtime has gone far beyond its frameworks and utilities. The edge runtime works in the recently acquired by Vercel Svelte, in nuxt, and in more than 30 other frontend frameworks. This article will focus on the edge runtime — what it is, how it is used in Vercel, what features it adds to next.js, expected changes and what solutions I made to expand these features. Vercel Edge Network Simply put, the edge runtime is a content delivery network (CDN/distributed infrastructure), i.e., multiple points around the world. Thus, the user interacts not with a single server (which may be located in the company’s office on the other side of the world), but with the nearest network point. At the same time, these are not copies of the application, but separate functionalities that can work between the client and the server. In other words, these are mini-servers with their own features (which will be described later). This system allows users to access not your far server right away, but a nearby point. Decisions on A/B tests are made at this point, authorization checks are performed, requests are cached, errors are returned, and much more. After this, if necessary, the request will go to the server for the required information. Otherwise, the user receives an error or, for example, a redirect in the shortest time. Of course, this concept itself is not Vercel’s achievement. CloudFlare, Google Cloud CDN, and many other solutions can do this as well. However, Vercel, with its influence on frameworks, has taken this to a new level, deploying not just an intermediate router at the CDN level but creating mini-applications capable of even rendering pages at the nearest point to the user. And most importantly, this can be done simply by adding familiar JS files to the project. Edge runtime in next.js In next.js, perhaps the main functionality of this environment is the middleware file. Any segment (API or page) can also be executed in the edge runtime. But before describing them, a little bit about the next.js server. Next.js is a full-stack framework. That is, it contains both the client application and the server. When running next.js (next start) - it is the server that starts and is responsible for serving pages, working with the API, caching, rewrites, etc. It all works in the following order: When it is determined that the current request reaches is the segment (not, for example, a redirect), its processing begins (this is either the return of a statically assembled segment, reading from the cache, or its execution and return of the result). In Vercel, likely, this entire cycle can run in the edge runtime. However, points 3, 5, and 7 are particularly interesting here. The middleware in its basic implementation looks like this: import { NextResponse, type NextRequest } from 'next/server'; export function middleware(request: NextRequest) { return NextResponse.redirect(new URL('/home', request.url)); } In it, for example, you can: You can read more about the areas of application in the next.js middleware documentation. The same can be done in segments (i.e., API and pages). To make a segment work in the edge runtime, you need to export from the segment file: export const runtime = 'edge'; Thus, the segment will be executed in the edge runtime, not on the server itself. However, it is important to make an important caveat here. Everything described above is not a full-fledged edge runtime by itself. In Edge Network, this will be distributed only when the service is deployed in Vercel. Also, in addition to all these capabilities, the edge runtime has several limitations. For example, despite the fact that when running the application outside of Vercel, the edge runtime is part of the server — it will not be possible to interact with this server. And this is done because it was developed specifically for the Vercel Edge Network. Edge runtime concept in Vercel As mentioned, the edge runtime can be called mini-applications. They are mini because they run on node.js V8 (which runs, for example, Google Chrome and Electron). This is their key detail, on which not only the features of the previous section depend but also the restrictions. Namely, in the edge runtime, you cannot: The full list of supported APIs and restrictions can be found on the next.js documentation page. Thus, Vercel Edge Network can be responsible for, for example: The edge runtime acts as the first stage of segment processing and is most effective in situations where all processing can take place inside the edge container. For example, for redirects or returning cached data. The entire processing process in Vercel usually works in the following order: After the build, Vercel sends the new edge runtime code (which now compiles to machine code) to the servers, and they immediately start working with the new code. Vercel itself uses the edge runtime for all applications and all requests. That is, after connecting the domain, Vercel immediately configures that this domain is also available on these points around the world. The next time a user visits the page, the provider will ask the network where this domain is located, and in response, it will get available locations, choose the nearest point, and go to it. These Edge points always have caching logic, and if there are rewrites, redirects, middleware, or segments in the edge runtime in the project — after the build, it will send all of this to the edge servers. Then the edge runtime will process it: check rewrites and redirects -> pass through middleware -> check if it is cached -> if the segment is in the edge runtime — execute it there, if not — send the request to the original server (but Vercel does not document these orders and internals of the Edge runtime anywhere, but this is how I see it). In summary, it is beneficial to use the Edge runtime when all processing can be done within the Edge environment (The request will be Client -> Edge). If you need to access the main server (for example, a database connected within the project, or to read files for some reason) — it is not advantageous. The request will still be Client -> Edge -> Server. And since you still need to access the server — it is better to do all the processing there — it has all the cache, the database is nearby, the whole system is nearby, and overall, it has more capabilities. Expected changes in the edge runtime Despite the fact that the edge runtime is one of the key features of Vercel as a hosting, the team is actively revising it. Not only its application but also its necessity as a whole. Recently, Vercel VP Lee Robinson in his tweet shared that Vercel [as a company] stopped using the edge runtime in all its services and returned to the nodejs runtime. The team also expects that the experimental partial pre-render (PPR) will be so effective that edge runtime generation will lose its value. And it was PPR along with advanced caching that pushed the edge runtime into the background. Previously, the entire page was rendered either on the server or in the edge runtime. The edge runtime won precisely because of its closer location. Now, pages are mostly pre-generated. Then, upon request, individual dynamic parts are rendered and cached. The cache, in turn, is unique for each point in the edge runtime, whereas on the server it is the same for all users. And, of course, the server has access to the environment, database, and file system. Therefore, if the page needs this data, the nodejs runtime wins significantly (gathering everything in one environment is faster than making requests to the server from the edge environment each time). Vercel is likely to introduce new priorities in its pricing, restructuring them around partial pre-render. Perhaps with these changes, tweets with bills of tens of thousands of dollars will become fewer (but this is not certain). In addition, the Next.js team recently shared a tweet about middleware revision. It is very likely that, like the segments, it will be given an execution environment choice. Again, considering that outside Vercel middleware works as part of the server, this is a very logical decision. It is also possible that with these changes, a separate middleware for API routes will be added. Expanding the Edge runtime I am the author of several packages for next.js nimpl.dev. I have already mentioned getters with information about the current page in the article “Next.js App Router. Experience of use. Path to the future or a wrong turn”, translation library in “More libraries to the god of libraries or how I rethought i18n [next.js v14]”, caching packages in “Caching in next.js. Gift or curse”. But in this family, there are also packages specifically built for the edge runtime — router and middleware-chain. @nimpl/router As mentioned, the edge runtime works best if it can handle the entire request in a self-contained mini-application. In all other cases, this is an unnecessary step since the request will still go to the server but via a longer path. One of these tasks is routing. Routing also includes rewrites, redirects, basePath, and i18n from next.config.js. Their main problem is that they are set only once — in the configuration file — for the entire application, and also, i18n is full of bugs. Therefore, including in the App Router, there is no information about the i18n option, and the documentation recommends using middleware for this case. But such a separation means that redirects from the config and i18n routing from middleware are processed separately. This can cause double redirects (first a redirect from the config will be performed, then a redirect from the middleware) and various unexpected artifacts can appear. To avoid this, all this functionality should be gathered in one place. And, as the documentation recommends for i18n, this place should be middleware. import { createMiddleware } from '@nimpl/router'; export const middleware = createMiddleware({ redirects: [ { source: '/old', destination: '/', permanent: false, }, ], rewrites: [ { source: '/home', destination: '/', locale: false, }, ], basePath: '/doc', i18n: { defaultLocale: 'en', locales: ['en', 'de'], }, }); Familiar Next.js redirects, rewrites, basePath, and i18n settings but at the edge runtime level. Documentation for the @nimpl/router package. @nimpl/middleware-chain Working with ready-made solutions or creating my own, time and time again I encountered the problem of combining them in one middleware. That is when you need to connect two or more ready-made middleware to one project. The problem is that middleware in next.js is not the same as in express or koa — it immediately returns the final result. Therefore, each package just creates the final middleware. For example, in next-intl, it looks like this: import createMiddleware from 'next-intl/middleware'; export default createMiddleware({ locales: ['en', 'de'], defaultLocale: 'en', }); I am not the first to encounter this problem, and ready-made solutions can be found on npm. They all work through their own APIs — made in the style of express or in their own vision. They are useful, well-implemented, and convenient. But only in cases where you can update each used middleware. However, there are many situations where you need to add already existing solutions. Usually, in the issues of these solutions, you can find “add support for adding package chain A”, “work with package chain B”. It is for such situations that @nimpl/middleware-chain is created. This package allows you to create a chain of native next.js middleware without any modifications (that is, you can add any ready-made middleware to the chain). import { default as authMiddleware } from "next-auth/middleware"; import createMiddleware from "next-intl/middleware"; import { chain } from "@nimpl/middleware-chain"; const intlMiddleware = createMiddleware({ locales: ["en", "dk"], defaultLocale: "en", }); export default chain([ intlMiddleware, authMiddleware, ]); The chain processes each middleware sequentially. During processing, all modifications are collected until the chain is completed or until any element in the chain returns FinalNextResponse. export default chain([ intlMiddleware, (req) => { if (req.summary.type === "redirect") return FinalNextResponse.next(); }, authMiddleware, ]); This is not Koa or Express, this is a package for next.js, in its unique style and format of its API. Documentation for the @nimpl/middleware-chain package. And to end, let me leave a few links here.My Medium with other useful articles | nimpl.dev with package documentation | github with star buttonThe dot map used as the background for images at the beginning of the article is made by mocrovector from freepik.

Measure twice and release once. A/B tests of static sites

Tue, 04 Jun 2024 18:31:00 GMT

A release starts with an idea. When that perfect idea comes in the brainstorming, the idea that will appeal to all users and attract new customers. The idea is presented to a team of managers, marketers and is unconditionally supported by everyone. The technical task is elaborated and the task is given to the developers. They grumble, asking to make an unnecessary updates, set clearly inflated deadlines, but eventually do the task. The task is testing and going to the end users. At this point, the life cycle of the idea is complete. Now all that remains is to wait for a mass of fresh analytics and celebrate… Some losses are allowed in the first week — there is little data, users are getting used to the updates, other improvements are being rolled out, a high influence of outliers. However, by the second week, it becomes evident that the idea not only did not attract new clients but also made some users use this product less. The idea, which has gone through dozens of discussions and received hundreds of enthusiastic comments, has failed. The Hypothesis Failed The introduction turned out to be voluminous. But I wanted to start this article with the long journey of the hypothesis. Because it broke at the very beginning — it was supported only by people similar to its author. But these people are not the most suitable target audience, and maybe even their rare exceptions. That’s why when changing existing functionality, they do not rely on the thoughts of the author and the team. To make the right choice, they conduct research, analyze existing product and market analytics, compare with competitors. But often behind all these methods goes the only reliable way to test the hypothesis on the business audience. This (attention!) — is to test it specifically on the business audience. But not on all of it. This method is called A/B testing. And all the further narration will be devoted to it. A/B Testing As we found out above — A/B test is testing a hypothesis on the very audience of the business. This test is due to the comparison of one functionality (option A) and another (option B). Sometimes A/B tests are conducted alternately — that is, they first measure option A, and then, the next week they measure option B. This variant will not be described in the article because it does not represent anything interesting in technical terms (and here will be nothing about data collection and analysis).A/B testing can take place for checking changes — in which case option A remains the current functionality, as well as for checking several implementations of a new idea — in this case, both options contain new functionality and they are compared relative to each other. Despite the name, there can be any number of options. The main thing is that the audience allows it. That is, it should be possible to collect enough data for each option, excluding outliers and interference. So, suppose a decision is made to make a critical change to the website or application. At this moment, the seriousness of this change is assessed and a decision is made to implement it through an A/B test. At the same time, depending on the risks, they decide how to distribute the traffic. Often the test starts with showing the new option only to 10% of users. Then, if the changes did not lead to a sharp deterioration in metrics on these 10% — it is extended to half of the users, so that the comparison would be full-fledged. Based on the results of this test, make a decision — to leave the new option or return the previous one. At the same time, of course, according to the results of testing, it is possible to return the idea for revision and then launch the updated test. This can be repeated dozens of times until the necessary change leads to business metrics growth. A/B Test Rules A/B Test Scheme Now, having sorted out what, why, and how is conducted, we can finally move on to the most interesting — the technical part. And it is worth starting with the basic scheme of the application’s work: Client — server — client A very simple communication scheme. The client addressed to the necessary address, the server processed this request and response to the client. With the advent of A/B tests, this scheme begins to work a little differently. Now, doing identical requests at the same time and under the same conditions, different answers are expected — those very option A or option B. In practice, this is usually performed by a layer — either at the CDN level, a regular middleware on the server, or other intermediate tools, such as nginx (module for conducting A/B tests in nginx). Further, for the simplicity of the story, just middleware will be used. In fact, A/B tests can be conducted entirely on the client side. This is how Google Optimizer worked (but in September 2023 it was deactivated). The main problem with this approach was that the user who got option b was redirected to another page. This, in turn, made option B less comfortable for the user and gave out the testing. This approach can be schematically described like this: Implementation of A/B tests Below will be described the solution on next.js, but it can be repeated on any other technology that can change cookies and make rewrites (or return a specific page). In next.js, this is done by middleware, which runs in the so-called edge-runtime, i.e., at the CDN level. In fact, outside of Vercel (a platform for deploying applications, owning next.js), it’s just a part of the server that works before processing routes. The first and simplest method of testing is to show one of the options without any conditions: import { NextResponse, NextRequest } from 'next/server' export function middleware(request: NextRequest) { if (request.nextUrl.pathname === '/home') { if (rollVariant() === 1) { return NextResponse.rewrite(new URL('/home-animated', request.url)); } else { return NextResponse.rewrite(new URL('/home', request.url)); } } } The user has entered the /home page, in the middleware a random option is selected. If the user gets option B — the home-animated page is returned, otherwise the standard home. It is more convenient to make the options of the interface test separate pages — a new option — a new page. root --app ----about ------page.tsx ----home ------page.tsx ----home-animated ------page.tsx How to choose which option to show to the user? Just roll the dice! If less than half — variant a, otherwise — variant b. const rollVariant = () => Math.random() < 0.5 ? 1 : 0; Now, depending on the rolled value, the user will receive from the server either a standard page or home-animated. For the same time and invisibly for the user. However, with each entry, the user will get a random option. To prevent this from happening, you can write to the database that the client has become a participant in the A/B test. In the case of anonymous tests, test information can be saved in cookies and read from them in the future. So, if the client already has a cookie recorded — you can skip the steps with the request check and option selection, and immediately issue the necessary page. import { NextResponse, NextRequest } from 'next/server' export function middleware(request: NextRequest) { if (request.nextUrl.pathname === '/home') { const prevVariant = request.cookies.get('ab_variant'); const variant = prevVariant ?? rollVariant(); let next: NextResponse; if (variant === 1) { next = NextResponse.rewrite(new URL('/home-animated', request.url)); } else { next = NextResponse.rewrite(new URL('/home', request.url)); } next.cookies.set('ab_variant', variant.toString()); return next; } } Of course, these data need to be analyzed. Here are two options — send data from the server, in parallel with issuing the result to the user, or already on the client, having previously transferred the test results from the server. For the latter, you can use the previously created cookies. Further, it may be necessary to launch A/B tests only on a specific group. This can be a certain share of users, users of specific browsers, users from specific companies, or anything else. That is, it is necessary to check the user for a match and depending on the result, either include him in the test or not: import { NextResponse, NextRequest } from 'next/server' export function middleware(request: NextRequest) { if (request.nextUrl.pathname === '/home' && request.nextUrl.searchParams.has('utm_campaign')) { // ... } } Also, it may be necessary for only new users to participate. But, formally this is the same task as described above. This is a group of users who were not on the site before. In the case of anonymous users, it can be determined, for example, by the absence of cookies of the test, acceptance of policies, or analytics. Of course, one test will not be enough and it will be necessary to run dozens, if not hundreds, of tests in parallel. The same logic will be used for this, but it will now be checked according to an array of instructions of the launched tests until the first suitable one. Of course, every company will have different conditions, different requirements, and different orders. The basic example described above is a possible implementation, from which everyone can decide exactly what is needed and how. Nevertheless, it was decided to try to implement a universal package for conducting A/B tests in next.js — @nimpl/ab-tests. @nimpl/ab-tests The first thing to note is that the package meets all of the above, including all the rules. At the same time, it has a number of pleasant possibilities, executed in a familiar API for next.js developers. The operation of the package can be described as follows: The main advantage of the package is the principle of finding a suitable test. Each test may include the keys has and missing. Those familiar with next.js know these keys from working with rewrites and redirects. For example, a test can be described as follows: { id: 'some-id', source: '/en-(?de|fr|it)', has: [ { type: 'query', key: 'ref', value: 'utm_(?moogle|daybook)', } ], variants: [ { weight: 0.5, destination: '/en-:country/:ref' }, { weight: 0.5, destination: '/en-:country/:ref/new' } ], } This test will be performed for all users who come to the page with English locales and the label utm_*. Then the user will see either the base page for this company or a new one. Each test also contains other keys, such as: id - the identifier of the test, which will be written in the cookie; source - another familiar key from next.js - the path on which the test is conducted; variants - a list of options, which can be any number. Each variant describes a weight — a weight and a destination (again, a familiar key from next.js). The main rule is that the total weight equals one. Additional part The development of the package did not end there. During the work on the package, it was decided to test its operation in several projects. However, adding a simple middleware turned out to be a real adventure. The problem is that the projects already had middleware — one with next-intl, one with next-auth. Surprisingly, none of the projects had previously had the task of supporting two external middleware (only together with the internal ones). As a result of the search, it was not possible to find any solutions. All existing solutions work due to their own APIs — made in the style of express.js or even in their own vision. They are useful, well implemented, and convenient. But only in those cases when you can update every used middleware for them. The situation here is quite different. It is necessary for each middleware to work as an original middleware from next.js. In general, another new solution was needed. I took it upon myself. So @nimpl/middleware-chain appeared: import { default as authMiddleware } from "next-auth/middleware"; import createMiddleware from "next-intl/middleware"; import { chain } from "@nimpl/middleware-chain"; const intlMiddleware = createMiddleware({ locales: ["en", "dk"], defaultLocale: "en", }); export default chain([ intlMiddleware, authMiddleware, ]); A small and neat insert. You can check out these and other packages for next.js at nimpl.dev.

React Conf 2024. React v19 RC

Thu, 16 May 2024 19:13:00 GMT

The first day of React.js Conf just concluded. This much-anticipated conference took place almost 3 years after the previous one. The React updates were just as eagerly awaited. The conference began with these updates and this article will be dedicated to them. And yes, as you saw from the preview — version 19 has moved into the release candidate status. The full release is promised within two weeks. Overall, as a next.js developer, most of it was familiar to me. Dozens of articles on the hub have already talked about almost every part of this update, and I partially touched on the updates introduced in next.js. It can be said that the main directions of this update were achieving “High UX at high DX”. Maximum performance with maximally simple code. At the same time, there was almost no mention of server components in part of the updates, only indirectly. And so, let’s move on to the conference itself. As usual in such conferences, everything starts with a description of growth. React downloads reached One Billion per year. The growth of the tool is inevitably linked to the growth of the community. Therefore, Stackoverflow statistics were also shown — 40% of developers use react in web development, 36% are learning it. Also of interest, React functionality has become possible to a greater extent only within frameworks, so now React.js has started recommending specific ones. The slide showed remix, redwoodjs, next.js, and expo. Interestingly, there is no react router in this list. Yes! React Router can now be added to this list. The first conference report was about him from Ryan Florence. Now with react router, you can not only do SPA but also SSR and SSG. This is now possible in conjunction with Vite. Hooks are available for working with data and server components. But for now, let’s return to the changes in React.js. The problem of coordinating elements and expanding the application was described next. JSX solved the problem of coordinating elements in UI development. Then they added Suspense, which solved the problem of coordinating elements when loading elements (what to do during loading and what to show to the user at this time). In React 19, the following were also added: The style loading of the component is now tracked by suspense. That is, you can display the loader not only while the component is rendering, but also while its specific styles are being prepared. With the advent of server components, React took on more responsibility in terms of server rendering, as a result, hydration takes on even more logic and potential problems. The React.js team improved hydration errors. In addition to significant changes in working with the construction of a real tree, the logic of interaction with forms has been updated in React.js. First of all, the form component was included in react-dom, which means significant changes over the element. And first of all, this change concerns the change of the “action” attribute — as an alternative to submitting a form through onSubmit or a native attribute. Adding action itself looks just like onSubmit, but instead of an event, it immediately takes FormData. Also, for form fields and buttons, the formAction prop has been added, which works in an identical manner. Perhaps the basic advantage of using action instead of onSubmit is that with client actions, if the user calls form submission immediately (even before loading the form logic) — its submission will be postponed and will be performed as soon as the logic is ready. In server actions, the submission will occur immediately because it does not require client js. But, in addition to the basic difference, there are significant changes in interaction with form submission — these are new hooks. useOptimistic, useFormStatus and useActionState. Sam Selikoff shared examples of working with them in his presentation “React unpacked: A Roadmap to React 19”. For example, this is what replacing onSubmit with action + useActionState looks like: Then you can add optimistic render: And again, let’s return from the report to the key changes. A relatively small change was shown next, but very, very valuable. In React.js 19, you can pass ref to a functional component as props. Right away. Without forwardRef. Also, when passing ref to components, you can return a callback on unmount. The final key change was the React Compiler. An advanced loader with memoization out of the box. Together with him, React will automatically set up memoization in the application. Lauren Tan elaborated on this in her presentation “React Compiler Case Studies”. So, to understand how to set up memoization, React analyzes the relationships from the place that triggers the rerender to the endpoints: Based on these relationships, the compiler can imagine a full graph of dependencies: And then, depending on these connections, set up memoization with the necessary dependencies. In this case, since songs do not change — filteredSongs should remain the same (they will be memoized with a dependency on songs), and if the song is changed by setSong, NowPlaying should be rerendered (it will be memoized with a dependency on song). “Maximum performance with maximally simple code”. A great solution, however, it will be interesting to see how memoizations will be set up in practice — where developers should write them, and where it is worth not complicating and leaving this logic to the compiler.You can install the compiler right now on all major frameworks and build systems that support babel. It is already being used in Instagram, Facebook, and Bluesky (the company where Dan Abramov now works). Also, to increase reliability and quality of compilation, you can install an eslint plugin, which will indicate all problems with code optimization. In general, the plugin can be used independently of the compiler. npm install eslint-plugin-react-compiler You can also use a command-line utility that will check the application for possible optimization by the compiler npx react-compiler-healthcheck Another innovation was shared by Lydia Hallie — the use function. Yes, it’s not a mistake — it’s not a hook. The key difference between use and hooks is that use can be used within conditions Use itself can take either a promise or a context. It’s hard to imagine a situation where you can’t be sure what argument will be passed to use — a promise or context and why not just make two independent functions. In conclusion, I will note the amazing reports, presentations, examples, and performances in general. The React.js team was really able to show the possibilities of all improvements (next.js team forgive me but they didn’t even come close). Also, from a pleasant difference, I note that the React.js team refused to include in the core the rewrite of the fetch API and rolled back already finished changes. The general list of changes looks like this: UPD: Seems like I can leave some advertising here.If you’re using next.js — you might want to check out the solutions from nimpl.tech, you might find some of them useful (like for example the getter getPathname for server components or the package for configuration config set up for all next.js environments) UPD2: There are still entries here, so I’ll leave another update.I just submitted a PR for the addition of getPageContext functionality in next.js (for non-next.js readers — the huge pain of working with contexts in server components [because there simply isn’t one and there are no alternatives]). Leave a reaction if you’re familiar with this pain.

Caching in next.js. Gift or Curse

Tue, 19 Mar 2024 20:19:00 GMT

In version 13, the next.js team introduced a new approach to application design — the so-called App Router. In version 14, it was made stable and primary for new applications. The App Router significantly expands the functionality of next.js — partial pre-rendering, templates, parallel and interceptable routes, server components, and much more. However, despite all these improvements, not everyone has decided to switch to the App Router. And there are reasons for that. I briefly discussed the advantages and problems of the new router in the article “Next.js App Router. Experience of use. The path to the future or the wrong turn”. Further, the conversation will not be about new abstractions or their features. In fact, the key and most controversial change is caching. This article will explain what, why, and how the most popular frontend framework, Next.js, caches. What does next.js cache? On the next.js website, you can find excellent documentation on the caching process. First, a brief overview of the main points from the article. Any request in next.js triggered through fetch will be memoized and cached. The same will happen with pages and the cache function. How this works under the hood will be discussed in the following sections. The general page building process works as follows: That is: the user goes to the page, a request for a route is sent to the server, the server starts rendering the route, sending the necessary requests along the way. Then all this is executed and cached. In addition to the cache in the scheme, there is also memoization. It is needed for recurring requests — so that they are not sent several times, but are subscribed to the first one. Caching on the server is done using the so-called Data Cache. You can remove data from it by calling the revalidatePath and revalidateTag functions. The first one will update the cache for the page, the second one for the tag specified in the requests. Data is also cached on the client side — inside the client router. Not mentioned in the article — next.js also caches rewrites and redirects. That is, if the user was once redirected from the / page to the /login on the server - now he will continue to be redirected there. This will be cached in the client router until the client cache is cleared. You can clear the cache on the client using router.refresh or by calling revalidatePath and revalidateTag in server actions. 'use server' import { revalidateTag } from 'next/cache' export default async function submit() { await addPost() revalidateTag('posts') } Why is caching needed in next.js? The fetch from next.js is a wrapper over the native node.js fetch. The wrapper is configured to connect with the so-called Data Cache. This is done so that each request can be processed as described in the schemes above. The next.js team is most often criticized by the community for this replacement of the native API. Later in next.js, the ability to disable caching of a request was added with the cache: "no-store" option. But even with this option, it will continue to be memoized. As a result, one of the key APIs for development has ceased to be controlled by the developer. Nevertheless, there were reasons for this step. And it is unlikely that the initial reason was optimization. For optimization, it would been enough to create a new function for requests — a separate API, of which there are hundreds in next.js. I followed a similar path when developing the next-translation package (as I wrote in a previous article). Then an interesting problem arose — too many requests were going to the server (not triggered through fetch). Looking into the reasons and reading the next.js source code, it became clear that the application is now being built in several independent threads. Strange, why they didn’t talk about this in the latest releases. Each thread lives as an independent process, as a result, it was not possible to make normal caching for the entire application inside the package. The same problem arose before the next.js team — each integration, each package, each user now began to send several times more requests, and the previously configured caching systems stopped working correctly. And as a solution — the remodeling of fetch and hiding this feature under the hood. How does Data Cache work? The saving of loaded or generated data occurs in the so-called cacheHandler. Out of the box, next.js has 2 options for cacheHandlers — FileSystem and Fetch. This cacheHandler will be used both for caching requests and for caching pages. FileSystem is used by default, saves data to the file system, additionally memoizing in-memory. FileSystem copes well with its task, but it has one drawback — it works as part of the application. From this it follows that if the application is created in several replicas — each of them will have an independent cacheHandler. This problem is especially felt when the application works in ISR mode. You need to get into each replica and revalidate the cache in each of them. At the same time, check that they will load the same data. Also, if 2 replicas work with one folder — conflicts can arise in the file system during recording. Probably for this reason, you can find Fetch variant in the framework code. It saves the cache to a remote server. However, this cacheHandler is only used when publishing the application in Vercel, as it saves data on Vercel servers. As a result, the out-of-the-box solution does not cover all needs — FileSystem is not suitable if there are several replicas, and Fetch if the application is not deployed in Vercel. An important feature is that next.js allows you to write your own cacheHandler. To do this, you need to pass to the application configuration the path to the file with the class (CacheHandler), in which the get, set and revalidateTag methods will be described: // cache-handler.js module.exports = class CacheHandler { constructor(options) { this.options = options } async get(key) { // ... } async set(key, data, ctx) { // ... } async revalidateTag(tag) { // ... } } And connect it in the application configuration: module.exports = { cacheHandler: require.resolve('./cache-handler.js'), cacheMaxMemorySize: 0, // disable default in-memory caching } One of these cacheHandlers is cache-handler-redis, which the next.js team referred to in the last release. Key points Next.js caches a large part of the processes. Caching occurs in several stages — caching transitions and pages in the client router, memoization of the request, caching on the server of requests and pages. Quite often, applications are launched in several replicas. Replicas need a common cache, especially this is acute when the application works in ISR mode. The application itself is assembled in several threads that do not have access to each other. The cacheHandler is responsible for caching. Next.js has two out-of-the-box options — working with the file system and working with a remote server, but the latter is only available within Vercel. You can write your own cacheHandler. Caching refinement Let’s go back to the next-translation package. To solve the problem of unnecessary requests, I came up with an interesting way out — to raise an additional server and process requests going through it — as a result, all requests go from one place, which means caching can be configured in it. This is a principle similar to FetchCacheHandler and the approach in Vercel in general — when during the build the data is cached on the vercel server, and since the server is nearby, this works quickly. However, caching is too much responsibility for a translation library. The next task was to overhaul the caching logic to combine the next.js API, libraries, and solve common problems. As a result, another library was created — next-impl-cache-adapter. Cache management As already mentioned, for a common cache between instances (replicas, copies) — the cache must be separate from each instance of the application. next-impl-cache-adapter solves this by creating a separate service. This service is a server in which the desired cacheHandler works. Each application instance will process requests through this server. At the same time, the server does not need to be restarted with each build. Outdated data will be automatically deleted during the launch of a new version of the application.Server code: // @ts-check const createServer = require('next-impl-cache-adapter/src/create-server'); const CacheHandler = require('next-impl-cache-in-memory'); const server = createServer(new CacheHandler({})); server.listen('4000', () => { console.log('Server is running at '); }); In this example, the server is passed next-impl-cache-in-memory — this is a basic cacheHandler that saves data in-memory. A special adapter for working with the cache is configured in the application itself: // cache-handler.js // @ts-check const AppAdapter = require('next-impl-cache-adapter'); const CacheHandler = require('next-impl-cache-in-memory'); class CustomCacheHandler extends AppAdapter { /** @param {any} options */ constructor(options) { super({ CacheHandler, buildId: process.env.BUILD_ID || 'base_id', cacheUrl: 'http://localhost:4000', cacheMode: 'remote', options, }) } } module.exports = CustomCacheHandler; The created adapter is connected in the next.js configuration: // next.config.js module.exports = { cacheHandler: require.resolve('./cache-handler.js'), cacheMaxMemorySize: 0, // disable default in-memory caching } The package supports three caching options: local, remote and isomorphic. localStandard solution. The cache is processed next to the application. It is convenient to use in development mode and on stages where the application is launched in one instance. remoteThe entire cache will be written and read on the created remote server. Convenient to use for applications launched in several replicas. isomorphicThe cache operates next to the application, but also saves data to a remote server. Convenient to use during assembly, preparing the cache for the moment of launching application instances, but without spending resources on loading the cache from a remote server. As a cacheHandler, it can be any cacheHandler supported by next.js. And vice versa, cacheHandlers from the package can be directly connected in next.js. Conclusions The App Router introduced a lot of very useful updates, but lost in convenience, predictability, and versatility. First of all, due to caching. After all, this is a task in which there is no and cannot be a universal solution. The ability to disable caching for a request and write your own cacheHandler solves most of the problems. However, memoization and caching in the client router remain out of control. The next.js team itself is in no hurry to develop solutions for specific tasks. For this reason, since the release of the stable App Router, I continue to work on the implementation of packages that solve next.js problems. Along the way, telling about them in articles. Let’s make the web not only faster, but also clearer. Links next-impl-cache — solutions for setting up caching in next.js. next-impl-getters — implementation of server getters and contexts in React Server Components without switching to SSR. next-impl-config — adding support for configuration for each possible next.js environment (build, server, client, and edge). next-classnames-minifier — compression of classes to characters (.a, .b, …, .a1). next-translation — i18n library, developed with consideration of server components and maximum optimization.

History of Vercel 2020-Present (7/7). Zeit is now Vercel

Wed, 28 Feb 2024 20:35:00 GMT

In April 2020, tech company Zeit announced a major rebranding. This new turn allowed Guillermo Rauch to return to big business, but at the same time, it became the most controversial decision in the eyes of the community. Nonetheless, this decision had objective reasons. Zeit could be labeled a failure in terms of investments — essentially, it was not perceived as a startup and that was the main problem. Some of the investors in the future company Vercel — CRV — said they were “delighted to resume business with Guillermo, after he returned to the path of entrepreneurship and founded Vercel”. The decision, so critically perceived by the community, turned out to be extremely effective for attracting investors. Immediately after the rebranding, now the company Vercel, announced the collection of $21 million. Soon the company received another $40 million, then $102 million — then Vercel was valued at $1.1 billion, becoming Guillermo’s first unicorn. In this, the final part of the series, we will talk about the extreme, the most important, and successful project of Guillermo — the company Vercel. Rebranding First, it’s worth dwelling on what the company zeit represented. And to describe this is quite difficult — speaking Zeit implied directly the company itself, and often spoke about Zeit Now — for example, in one interview Guillermo was asked a question, starting with “Your products zeit and zeit now”. The new company was supposed to unify these products. And today, saying “Vercel”, implies both the concept of Zeit and Zeit Now. “Our product consists of two parts: NextJS and a platform distributed around the world, and the business is based on the scalability of this platform” — Guillermo Rauch. The decision to rebrand caused a surge of emotions in the community — a lot of negative comments, requests to return everything back and/or not to sell the company (it is difficult to understand why many considered this rebranding a sale). In addition to this, there are more interesting reasons for the rebranding. So, Guillermo noted that the old name sounded differently in different languages and not everywhere it was easy to write what was heard — “The new name was analyzed in five languages by five linguists from different languages of the world”. The new name — Vercel — was devised by the company Lexicon. According to them: “Zeit needed a name that would reflect the efficiency, superiority, and power of their platform. They also needed the name to be short, spread worldwide, and easy for developers to type command”. The business model as a whole remained unchanged. “Although anyone can access the library for free, the company’s business model is based on selling software as a service (SaaS) to companies” — Guillermo Rauch. Investments As mentioned earlier, the rebranding quickly paid off. Immediately after it, Vercel announced a successful round A — $21 million. Investors were: Accel, mentioned CRV, Naval Ravikant, Nat Friedman, Jordan Walke and others. Accel fund member — Daniel Levine — is a member of the Vercel board of directors. The company went for the next round only after 8 months, in December 2020, and was able to raise $40 million. The biggest investor in this round was Google Ventures. Also, new investors were Greenoaks Capital, Bedrock Capital and Geodesic Capital. Bedrock founder Geoff Lewis is also a member of the Vercel board of directors. The next round took place in June 2021. The company raised $102 million, received a valuation of $1.1 billion, thus becoming a unicorn company. The main investor was the company Bedrock Capital. All previous investors were retained and several new ones were added (8VC, Flex Capital, GGV, Latacora, Salesforce Ventures, and Tiger Global). The last round took place in November 2021, during which Vercel raised $150 million. The main investor was GGV Capital, also all the previous investors supported the company (including Accel, Bedrock, and Google Ventures). Private investments are also interesting. Guillermo, after leaving Automattic, became an investor himself and began investing mainly in emerging tech companies. Some of his seed investments were companies auth0 and scale, which soon became unicorns (Auth0 became the fifth with Argentine roots, that is, shortly before Vercel). Soon after, their co-founders (Auth0 — Matias Woloski, scale — Alexandr Wang) — invested in Vercel. The complete list of Vercel investors can be found on the company’s website. Total investments in Vercel amounted to $313 million. This allowed the company not only to actively develop and attract people but also to make some acquisitions. Purchases and Important Actions One of the most important and valuable actions of the company was the attraction of Rich Harris, the creator of svelte. This happened in November 2021, 2 weeks before the completion of the last round of investments (and possibly played a significant role in the success of the round). So far, the company has made 2 major acquisitions: the company Splitbee and the utility turborepo. The cost of both purchases is not named. First, Vercel bought turborepo, in December 2021 — a utility created by Jared Palmer (he is also the creator of Formik and TSDX). “Turborepo is a high-performance build system for JavaScript and TypeScript codebases”. The main features of the utility are parallel assembly of applications in a monorepo and caching processes (including remote ones). Jared himself joined the Vercel team after purchasing the utility, his main task was to speed up the assembly in Vercel. The next purchase took place almost a year later, in October 2022. The company Splitbee was purchased — a platform for collecting real-time analytics, created only in 2020. The co-founders of the company joined the Vercel team, their main task was to develop analytics tools within Vercel (in the service you can buy analytics collection, the price starts from $10 per project). Open-Source Development “Supporting open-source projects is an integral part of our mission “Make the Internet Faster””. Despite several purchases — the main improvements come through integrating third-party services. For example, there is integration with Check.ly, which takes a URL and runs automatic end-to-end tests, simulating web browsers for this interface. Another interesting integration is made with Sanity CMS, together with them Vercel adds the possibility of editing the site on the site itself (next-preview.now.sh). In total, Vercel has about 100 integrations (Mongo DB, Contenful, Wix, Shopify, AWS, Sentry, Slack, Auth0, etc.). Vercel owns such frameworks and libraries as Next.js, Hyper, SWR, pkg, turbo, satori, serve, styled-jsx, ai, and other less popular utilities. Also, team members are authors of many libraries. Next itself after the rebranding became 10 times more popular (from half a million to 5 million downloads weekly). Vercel is also a sponsor of Nuxt, Astro, webpack, Babel, NextAuth, Parcel, and Unified and other open-source projects. Team Today the company has more than 200 employees, only an office in San Francisco, but most of the team works remotely from all over the world. This situation has been in the company from the very beginning, as its parent, Zeit, was founded by an Argentine, a Finn, and a Japanese, who often worked from different places. “From the very beginning, we were a remote company. We worked together from San Francisco, Argentina, Brazil, Finland, Japan, and Germany. We were fortunate to use remote work before covid forced us” — Guillermo Rauch. In hiring, the company adheres to the policy of Guillermo’s first projects — they attract active participants in open-source. Vercel is also worked on by the creator of Webpack and Turbopack Tobias Koppers, creator of Svelte Rich Harris, React developers — Sebastian Markbåge, Andrew Clark, and Josh Story. Most of them are hired by the company with the expectation of continuing work on their projects. So, Sebastian still heads the main React team, but also helps support the development of React in Vercel. Guillermo himself, in addition to Vercel, is involved in investing. In April 2022, he received a second citizenship — American.

History of Vercel 2015–2020 (6/7). Zeit and Next.js

Wed, 21 Feb 2024 20:38:00 GMT

After leaving Automattic in 2015, Guillermo founded a new company — Zeit. Co-founders were Tony Kovanen and Naoyuki Kanezawa. The main task of the company was to provide developers and teams with the ability to easily develop, preview, and deploy their applications. “One of my dreams is that the next Facebook or Snapchat will be created by someone who didn’t have to go through all this training, develop these connections, and hire these bright people. It could be a girl from Africa or a boy from Bangladesh” — Guillermo Rauch. This part will discuss the most uncertain period in the history of Vercel — the time when the company was becoming known to the community and fading from investors’ view. Zeit first became known thanks to its product Now — a tool for deploying applications with a single command from the terminal, allowing developers to easily assemble their projects and instantly share them. Now The utility’s purpose was simple: You type “now” in the command line and get a new server. This concept is basically inherited by Vercel and even described in its main slogan “Develop. Preview. Ship”. After entering the command, within a second, a new instance of the application is created and published on the Internet. You can share the link to the published application immediately, even before the build is completed — initially, the build process will be displayed on it, and then the application itself. Guillermo described the procedure as follows: An application for PC — “Now Desktop” was also created for the utility. The utility itself supported the publication of static sites, next.js applications, as well as applications on go, php, node.js, python, rust, and other options. Next, a global DNS solution — “Zeit World” was created. HyperTerm The Now utility had its page on the company’s website. At the very beginning of this page, there was a demo of its work in the terminal. And what is interesting here is not so much an example of work, but the fact that the terminal was added not as a gif, but written in pure html, css, and js. Guillermo liked the demo result, as it looked like the simplest terminal. Then he thought about a new project — Hyper.app. The development of the first version took about two weeks. The terminal, like most other company projects, was published in open access and immediately after a quick presentation attracted the attention of developers — they began to actively participate in the development of the utility and soon more than 100 plugins were written for the terminal. HyperTerm itself was created on Electron. This allowed you to open the developer console at any time and make various changes. You can also install ready-made plugins, many of which are collected in a special list. The terminal is still highly popular (gihub, website). Next.js In 2016, Zeit released Next.js — a framework for creating Jamstack-style websites. The framework page lists the authors: Tim Neutkens, Naoyuki Kanezawa, Guillermo Rauch, Arunoda Susiripala, Tony Kovanen, Dan Zajdband. All but Dan worked at Zeit. Dan is familiar with Guillermo from JSConf Argentina, and probably as a developer of The Lift company (which used cloudUp, Guillermo’s second startup). Next.js was initially released as an open source project on GitHub on October 25, 2016. The framework offers out-of-the-box server-side rendering, static site generation, API routes, and more. The goal was to provide critical features that React lacks — primarily in terms of speed and SEO optimization. “We work for those who do front-end design to make e-commerce sites, media and everything else better… Everything should look good, sites should load quickly” — Guillermo Rauch Today, Next.js is used by Uber, Amazon, Open AI, and thousands of other companies. Being a framework for React, Next.js has become an important part of the ecosystem — “NextJS takes it to a new level. And now many ideas from NextJS inspire React itself”. Zeit Platform Despite the fact that applications were published through the Now utility — it was just a part of the Zeit platform. After entering the platform, you could publish up to 3 applications for free through Now. However, you could not link domains in the free tariff. This was a paid feature, the price started from $15, and, for example, support cost from $750 to $2000. Also, you could buy domains directly in the platform. The pricing policy was changed in December 2018 and, most importantly, limits on the number of applications and linked domains were removed, and for many categories, the price was calculated based on the resources spent over the limits. It lasted until the end of 2019, when it was changed again and fixed tariffs from $20 appeared. Co-founders Guillermo Rauch In addition to the utilities mentioned in the article, Guillermo participated a lot in conferences and presented Now and Next.js. Also during this period, he was a mentor for the “Open Source Engineering” course organized by Stanford. Tony Kovanen Tony worked with Guillermo at Automattic and mainly worked on the Jetpack plugin. He left Automattic with Guillermo and became a co-founder of Zeit. In it, he will hold the position of CTO. At Zeit, Tony participated in the development of next.js and Now. He worked until 2017, after which he will move to Gatsby. Now Tony is working on the Based.io platform. Naoyuki Kanezawa Naoyuki was one of the main developers of Socket.IO and Engine.IO (created by Guillermo). Now Naoyuki remains part of the Vercel team in the position of Infrastructure/Backend Developer. Team From the team it is worth noting: Tim Neutkens, creator of Micro and MDX; Arunoda Susiripala, creator of React Storybook; Igor Klopov, creator of Pkg; Nathan Rajlich, creator of node-gyp; Javi Velasco, creator of React Toolbox. Nicolas Garro / Evil Rabbit, Founding Designer and Brand Architect. Zeit Day Also, the Zeit company organized one-day conferences — “Zeit day”, the first of which took place in 2017. Investments Zeit can be called a failure in terms of investments — in essence, the company was not perceived as a startup and this was its main problem. So, one of the investors in the future Vercel company — CRV — said when investing in the latter that they are “glad to resume business with Guillermo, after he returned to the path of entrepreneurship and founded Vercel”. Actually, this was one of the main reasons for the rebranding that happened. And soon Vercel will become Guillermo’s first unicorn (and the sixth unicorn with Argentine roots).

History of Vercel 2013–2015 (5/7). Automattic

Wed, 14 Feb 2024 20:41:00 GMT

Automattic. A company that played a massive role in shaping the modern internet and deserves a separate series of articles. However, it will only be touched on superficially here. In May 2003, Matt Mullenweg, together with Michael Little, founded a new platform for publishing blogs. It was not the first such platform; the most popular at the time was b2/cafelog. Indeed, Matt and Michael were the developers of that platform, but they decided to create their own product. The new platform developed rapidly and quickly gained a large audience. This part will discuss what Guillermo Rauch and the Learnboost team did after Automattic acquired them. Automattic On May 27, 2003, Matt announced the availability of the first version of the new platform and named it “WordPress”. The main task of Automattic itself (besides developing WordPress) became hosting and supporting websites written in WordPress. The main principle of monetization was that any user could create a site on WordPress, publish it for free, and then, if necessary, pay for additional features. Automattic raised 6 million in Series A and B funding rounds from investors including True Ventures, Polaris Venture Partners, The New York Times, and others. In May 2013, Tiger Global invested 50 million dollars in purchasing shares from Automattic’s early investors. By that time, about 20% of websites were running on WordPress. Automattic actively purchased interesting products, primarily due to the people working on them. In 2013, they met with Guillermo and Tian Lu. Sale of CloudUp On September 25, 2013, after the meeting, Automattic announced the purchase of CloudUp, along with the company LearnBoost and all related libraries (including socket and mongoose). This was Automattic’s 12th acquisition (after Lean Domain Search, Poster, Simperium, CodeGarage, After the Deadline, Blo.gs, PollDaddy, IntenseDebate, BuddyPress, Gravatar and Plinky). The CloudUp team set about updating the editor and tools related to media in WordPress. Matt himself (the founder of WordPress) admitted that CloudUp was significantly better than the WordPress media library. The editor was planned to implement real-time editing for simultaneous work on texts by several people. Life at Automattic The LearnBoost and Automattic teams had a similar view on open development — they participated in conferences, created and supported open-source projects. “Automattic and us share a history and vision: we have a distributed workforce, we passionately care about creating a better web and we support our open-source roots” — Tian Lu (co-founder of CloudUp). The team took on the tasks set for them, but they did not plan to stop working on CloudUp — they created new projects, packages, and talked about the imminent expansion of the service. They also continued to work on open-source projects. Thus, in 2014, the first stable version of socket.io was introduced. Nevertheless, the story of the CloudUp service itself ended there. The site remains unchanged and continues to lie on the internet with a field for applying to join the testing. The Team’s Future Tian Lu After the company’s acquisition, Tian remained the general manager of Cloudup, overseeing the creation of a new technology stack and a completely new editor. Also, in 2013, Tian will create his company Tsukemen. As a co-founder of two startups, Tian raised nearly 5 million dollars from CRV, Bessemer, RRE, and other investors before a successful exit. Now, Tian is a Vice President of Product at Blockchain.com, responsible for product strategy and design. He joined the Blockchain.com team through the acquisition of his company Tsukemen. Nathan Rajlich Since 2013, Nathan has been working at the WordPress company on editors. In 2014, he spoke at a conference in Buenos Aires on the topic of “Writing a webmodule” — about writing npm modules intended for use in browsers [speech]. Until 2016, he worked at Cloudup and Automattic. He currently works at Vercel. Tj Holowaychuk In 2014, while already working at segment.com as a backend developer, he will participate in the development of YAL. In 2014, TJ will write the article “Farewell Node.js” (goodbye node.js) with an official farewell to node.js and a transition to the Go language. However, he continues to support his projects on js (primarily koa). In 2014, TJ will sell express to StrongLoop (but that’s a whole other story). This was not just a departure from Node.js, but also a partial departure from programming and open-source. The following are TJ’s words: “No, I have no intentions, my new goal is to live better. After all, open-source doesn’t pay the bills, so it’s better to focus on other things or if you just like a project, that’s cool. Now I spend most of my time enjoying other things, I code for 2–3 hours a day if I don’t like something. Time is your real currency! Money is good, but don’t waste time. If you really like the project you’re working on, then do it, but don’t neglect other areas of your life (or people).” In 2016, TJ will create the Apex company, and Guillermo — the Now utility and the Zeit company. Guillermo Rauch Guillermo also worked on the development of WordPress, for example, he redesigned the video platform — VideoPress. For this, he “used the Virtual DOM approach and wrote a very simple version of React,” making it interactive and convenient. He added features such as searching for a moment by frames and embedding video functionality. Guillermo left WordPress on October 13, 2015, and founded a new company — Zeit.

More libraries to the library god or how I remade i18n [next.js v14]

Tue, 13 Feb 2024 20:45:00 GMT

There are dozens of amazing libraries made for internationalization, such as i18n, react-intl, next-intl. They all do an excellent job of adding translations to an application or website. Most of them are tested, debugged, and consistently supported. But they are all outdated. After all, during this time, the react ecosystem has been developing. The latest version of next.js has major updates from react.js — cache, taint, new hooks, and, of course, server components. The React.js team will likely introduce these changes in May. In this article, I will talk about key changes, personal experience, problems with existing solutions, necessary updates, solutions I came up with, and, of course, answer the questions of “why” and most importantly — “why”? Changes The first thing to start with is how the changes in React.js made translation libraries obsolete. Despite the fact that the latest stable version of React.js was released almost two years ago, it has 2 other channels — canary and experimental, where canary is also considered a stable channel and is recommended for use by libraries. This is the channel that Next.js uses. Next.js launched server components without additional flags inside the so-called App Router — a new directory as an alternative to pages, which uses its conventions and different sugar (about changes and problems which I wrote in a recent articlearticle). Server components definitely solve a number of problems and are a new milestone for optimizations. Including for translations. Without server components, translations were stored both in the compiled HTML and as a large object in the client script. Now you can get ready-made HTML, which doesn’t need anything on the client. Next.js paid special attention to this feature. Personal experience You can add translations (according to the Next.js documentationNext.js documentation) as follows: // app/[lang]/dictionaries.js import 'server-only' const dictionaries = { en: () => import('./dictionaries/en.json').then((module) => module.default), nl: () => import('./dictionaries/nl.json').then((module) => module.default), } export const getDictionary = async (locale) => dictionaries[locale]() // app/[lang]/page.js import { getDictionary } from './dictionaries' export default async function Page({ params: { lang } }) { const dict = await getDictionary(lang) // en return // Add to Cart } This solution is described as ready and fully optimized. It works entirely on the server, and the client already receives ready-made HTML. However, the Next.js team missed one important detail — how to pass the language deep into server components. A big problem with server components is that contexts are not available in them. The Next.js team explains the absence of these functions by the fact that Layout is not re-rendered, and everything that depends on props should be client-side. Perhaps translation libraries were most affected by this. As a temporary solution, they suggest determining the language in the middleware and adding it to cookies. Then when building the page, read it in the necessary places. But reading cookies means enabling server rendering, which is not suitable for everyone. In general, the main problem with existing solutions is that most of them are not made for server components. Components and functions were developed for runtime, using hooks and synchronicity. Another inconvenience was caching in Next.js. Namely — it works fully only for GET requests, and if the weight of translations is more than the limit of 2MB — they will not be cached. Implementation Goals and tasks: To my surprise, there is not a single library that would satisfy all these requirements. The first thing you need is functionality. In the standard version, this is a hook that returns the function t and the Trans component for more complex translations. However, such functionality is needed in server components, and they have many of their own features. Functionality The main functionality is divided into two versions — for client components and for server ones and includes: useTranslation, getTranslation - which return the function t inside the DOM and the language; import getTranslation from 'next-translation/getTranslation' export default function ServerComponent() { const { t } = getTranslation() return (

{t('intro.title')}

) } 'use client'; import useTranslation from 'next-translation/useTranslation' export default function ClientComponent() { const { t } = useTranslation() return (

{t('intro.title')}

) } The interface turned out to be quite familiar, the functions support namespace and query. It is recommended to use it by default, as it is simple to use and in logic. Returns a ready-made string. For more complex translations, you should use the ClientTranslation and ServerTranslation components. They can replace pseudo-components with real ones. import ServerTranslation from 'next-tranlation/ServerTranslation'; export default function ServerComponent() { return( }} /> ) } "use client"; import ClientTranslation from 'next-tranlation/ClientTranslation'; export default function ClientTranslation() { return( }} /> ) } There are also cases when translations need to be added outside the react tree. For this, you can use createTranslation anywhere. import createTranslation from 'next-translation/createTranslation' // ... export async function generateMetadata({ params }: { params: { lang: string } }) { const { t } = await createTranslation(params.lang); return { title: t('homePage.meta.title'), } } Page setup Now about setting up the page. To work with translations, you need to know the language. However, in server components, you cannot use context. For this, an alternative to createContext was made for server components in the next-impl-getters package - createServerContext and getServerContext. In the package for this, you need to create a NextTranslationProvider. It is recommended to do this at the page level to avoid problems with Layout re-rendering. import NextTranlationProvider from 'next-translation/NextTranlationProvider' export default function HomePage({ params }: { params: { lang: string } }) { return ( {/* ... */} ) } It is also necessary to indicate which translations are needed specifically on the client and to pass only them there. To do this, you can pass an array of client keys or groups to NextTranslationProvider using the clientTerms prop. Also, sometimes situations arise when a component needs different translations or different blocks are rendered depending on conditions. In such cases, different translations need to be passed to the client. Condition options can be wrapped in NextTranslationTransmitter and client terms are passed to it. import NextTranslationTransmitter from 'next-tranlation/NextTranslationTransmitter'; import ClientComponent from './ClientComponent'; const ServerComponent: React.FC = () => ( ) As a result, only those terms that were specified above in NextTranslationProvider or NextTranslationTransmitter will be passed to client components. Package setup Before working with translations, they need to be loaded. For this, you need to create a configuration file in the root of the project. Its minimum configuration is the load function, which will return current translations and an array of languages with permissible languages. The load function is called in server components, and the necessary keys will be passed to the client. A very important point was the absence of unnecessary requests, that is, full caching is needed. Here it is worth digressing a little. Starting from the latest version, Next.js builds the application in parallel in several processes. If each process lived with its own cache — requests would be sent from each. Probably, to avoid this, the Next.js team redesigned fetch — now it works with a common cache. The package solves the problem in the same way — it creates a common cache and works from each process already with it. For this to work, you need to use withNextTranslation in next.config.js. Conclusion The solution turned out to be truly tailored to next.js — taking into account all its capabilities and problems. It also includes all the optimization capabilities provided by server components. The package is fully optimized for next.js, their concepts and views, which I fully share. I faced the problem of translations and I had to make my own solution, which would work exactly as expected. Despite the significant advantage in optimizations, the package is still inferior to large libraries in terms of translation capabilities. There is a lot of work ahead. P.S. I will be grateful if you describe what you lacked in existing solutions or what functionality you consider most important.

History of Vercel (4/7). 2013. Cloudup. Drag. Drop. Stream.

Wed, 07 Feb 2024 20:56:00 GMT

Cloudup is a clear and fast file-sharing service for files, videos, links, music, documents, code, text, and so on, which is both user-friendly and recipient-friendly. Drag. Drop. Stream. “We created Cloudup because we were disappointed with sharing services that took too much time for conversion, storage, management, and uploading — we just wanted to share anything, anytime.” — CloudUp team. In this part, I want to talk about the history and reasons for creating the service and what came out of it. Reasons The LearnBoost educational platform, Guillermo Rauch’s first startup, had already become popular and secured its place in the market by this time. It was a simple, convenient and fast service that solved all problems related to education. However, the interests and needs of teachers did not end there — they wanted to share their work, publish lesson plans, share photos from lessons in blogs, and talk about their work on social networks. The LearnBoost development team also shared a large amount of information — images, videos, documents, presentations — for personal or work purposes. Different tools were used for each task. LearnBoost users needed a tool that would allow them to share files with all network users. In existing solutions, you had to log in to view the file. Another disadvantage was the lack of cross-browser compatibility. CloudUp Video Presentation — https://cloudup.com/cYiu8eWgvxt Competition CloudUp was not the first to enter the market in this area. By that time, there were already startups in the data storage sphere (WeTransfers and YouSendIts), big players (Google Drive and Dropbox), and even social networks (Facebook, Twitter) were quite good at this task. Nevertheless, the goal of CloudUp was slightly different — not just to store files, but also to share them. But there were competitors at that time also — DropLr, CloudApp, Ge.tt. The most advanced service at that time was Dropbox, but its main task was (and remains to this day) data storage, not file sharing and distribution. On June 20, 2013, Guillermo and Tian Lu announced the creation of a new file-sharing service — CloudUp. From the LearnBoost team, TJ, Meredith, and Nathan also participated in the development of cloudup. Tasks The main goal was to make the sharing of images, links, videos, code, documents, and everything else — simple and beautiful, both for service users and for those with whom these users share. To do this, the following tasks needed to be solved: Functionality Drag. Drop. Stream. Three simple steps for files to take a huge path from the user’s device to viewers. The service absorbed all the experience accumulated by the team, was built on modern technologies (many of which were created and developed by the LearnBoost team itself), a minimalist design was created for it. But this was not enough to stand out among the existing giants and become a market leader. The service needed to stand out, improve all existing solutions, and create new ones. Cross-platform and cross-browser compatibility Google Chrome only surpassed IE in popularity in 2012. By the time of the CloudUp launch (June 2013), cross-browser compatibility was a big and important task. In addition to directly supporting all browsers, the service also solved the problem of file format support. The service converted documents into PDF, performed video transcoding, and compressed images for devices with weak internet connections. Grouping and preview Existing alternatives displayed folders in a “list” format, CloudUp did so in a “tile” format and called this not folders, but streams. Streams differed from folders not only in their display style but also in their content. In the “folders” of competitors, files were stored as a list, with basic icons. Streams, on the other hand, contained tiles with files that allowed you to see all the content in preview mode, be it a document, photo, file, or video. Thus, in these streams, you could easily and quickly find the necessary files. This worked with a really long list of files, whether they were simple documents, raw photos, or even psd, eps, and AI files, preview was available for everything. Also, directly from the service, you could view the meta-information about the file, such as weight, extension, creation date, resolution, and much more. Editing and security Each stream was assigned a unique identifier that could not be forged or predicted, so the only way to view a specific stream was to get a link. For additional stream protection, it could be password-protected. At any time, the file could be edited, replaced, password added or removed, or deleted. Speed One of the main features of LearnBoost was real-time operation. The company that created the first library for these purposes — socket.io was a leader in this area. The next startup was no exception, all files were uploaded and available in real time. As soon as the user started uploading files, a link would be immediately available to him, which he could share with his friends. The upload did not occur as a whole file, but as a stream, which was a significant advantage, primarily for video. Also, the product followed the ideas of web 2.0, that is, it was a single-page application. https://cloudup.com/blog/the-need-for-speed Application Along with the presentation of the service, an application for it was immediately presented. Initially only for OSX, but in the near future, apps for other platforms were planned. In addition to the main functionality, the application could also: And these promises were kept. Almost immediately after the launch, a Windows application was presented. The application could also track screenshots and automatically upload them. Result On June 20, 2013, the service launched pre-registration. The service offered users 1000 files up to 200MB each for free. In early September, the service launched in beta testing and sent out 10,000 invitations. In just a few weeks, users uploaded over 300,000 files, the total volume of which was almost 1,500 GB. CloudUp quickly and confidently entered the market for cloud solutions, but to secure a strong position in it, the team had to do a lot of work. The service had a huge and unique functionality, which favorably distinguished it from competitors, but this was not enough for establishment. The next step was to consider monetization. The free tariff provided for the upload of up to 1000 files, which was enough for an ordinary user. For business, special tariffs, applications for all platforms, and collaborative work on files in real time were needed. The company continuously improved its applications, the performance of the service, supported file formats, thereby gradually closing all market needs. The first company to fully switch to CloudUp for internal purposes was The Lift, on August 12, 2013 (one and a half months later). theLift was engaged in product development from concept to product, from software development to the creation of marketing materials. The company’s headquarters were located in Southern California, and there was also an office in Buenos Aires. The second company was Sawhorse. Sawhorse is a full-service production company helping startups and large companies share their stories through video and post-production campaigns. This, perhaps, was the first company well familiar with the product and the team, as they made the introductory video for CloudUp. Also, CloudUp launched a “scaling program” — a referral program, so that users could invite their friends to the service.

History of Vercel (3/7). 2009–2013. LearnBoost. Team that has become a leader in open source

Wed, 31 Jan 2024 21:00:00 GMT

…one of the most technologically advanced companies… socket, stylus, mongoose, n, express… Nathan Rajlich, Aaron Heckmann, TJ… LearnBoost is an online tool that efficiently manages classrooms. The company addressed the problems of every participant in the learning process, supplementing this with quality, convenience, and speed, gaining significant advantages in these characteristics compared to existing competitors at that time. This part will talk about how the educational platform became one of the most tech-savvy companies and how it was able to attract, without exaggeration, the best js developers to its ranks. Technical Vector LearnBoost was introduced to the public in 2010, but its development began the previous year, 2009. Learnboost began to be designed according to the standard structure of the time — one language for the backend and js for the frontend — there were simply no other options at that time. An alternative to this approach appeared a little later, when Ryan Dahl created Node js. In 2009, Guillermo was on an IRC forum with Ryan Dahl, who talked about version 0.1, warning that the tool was still not ready. However, the idea to make universal rendering and simplify the development of asynchronous services attracted listeners, and Guillermo was no exception. In the end, they decided to build everything in one language. “Why not?”. Although there were many reasons against it. The problem was that these were completely new technologies, approaches, databases. They had shortcomings and vulnerabilities, so the team created their alternatives based on existing solutions or created them from scratch and opened the source code (the licenses of most open-source products allow you to clone and edit the code, but the resulting project must be promoted under the same license, including with a clause about open source code). In addition to third-party tools, there were problems with node.js itself, as it was too raw at that time. Around Node.js, a large community quickly formed, but it could not cope with the flow of tasks and difficulties. Thus, one of the first contributors to node.js will write an article in the future about how he can no longer fight it [article]. Ryan Dahl, at the release of version 0.1, predicted the unreadiness of the tool. The LearnBoost team had to make many changes — “from small utilities to patches and HTTP servers” — in the Node.js repository. Team and open-source One of the main advantages of open-source, which Guillermo saw, was the opportunity to communicate with the smartest people on the planet — to work together on libraries, fix and develop the ecosystem. Such acquaintances give not just a pleasant experience of communication, but also a sufficient number of talented programmers who can be attracted to your project. The first major open-source project in Guillermo’s history was Socket.io, which ranked 3rd in 2012 in terms of the number of stars on github, overtaking express js. Most libraries were developed and evolved primarily for the company’s needs. For example, in 2010, the team was tasked with styling their products, but none of the existing alternatives suited them, so they created their solution. The created preprocessor was named “Stylus”. Together they developed tobi, Cluster, knox S3 Node Amazon S3 Client, node-canvas and many others. LearnBoost was not just one of the most promising startups, but also one of the most technologically advanced. In 2011, they were in second place in terms of the number of subscribers to open-source, overtaking github, twitter, mongo and only losing to facebook. The number of subscribers is often directly proportional to the number of contributors, which gives a huge advantage in the speed of development, as more than 50 repositories on Github, including Mongoose and Socket.io, were developed by the community. The company has reached a high level in the community, and there is a great merit in its policy. But to a much greater extent, this is the merit of the people who stood behind the company for many years — both the authors of these libraries and other participants in the process, creating a comfortable environment for development and all the necessary conditions. Rafael Corrales. Co-founder He graduated from the Georgia Institute of Technology. From a young age, he understood that he wanted to do business, whether as a co-founder or as an investor. Therefore, after the institute, he entered Harvard Business School. By the time the company was founded, he was studying in the second year. He ran a personal blog and actively managed social networks. “In addition to this, keep in mind that this is a game consisting of several rounds, if you think about it. Being a guy who is over 20, even if LearnBoost fails, and of course I hope it won’t, I’m going to be at the startup table in one form or another, presumably for the next 20, 30 years.” (Mixenergy interview from November 5, 2010). Rafael actively communicated with angels and investors, attracting them to the project, and also continued to develop in the field of business in general. In 2012, alongside supporting learnboost, he became an advisor in the company Instacart. And on March 1, 2013, Rafael will move from the section of co-founders of the company Learnboost to the section of a member of the board of directors. On April 1, 2013, Rafael became a member of Charles River Ventures, one of LearnBoost’s investors, and since then Rafael has been in the status of an angel and will participate in this role in future startups by Guillermo. Thianh Lu. Co-founder, product manager / designer. Thianh Lu has a Bachelor of Business Administration in Finance and Marketing from the University of Massachusetts Amherst, graduated from the Eisenberg School of Management in 2002 and received a Master of Business Administration in Finance and Entrepreneurship from the Carroll School of Management at Boston College in 2008. He started his career at Zecco (online broker), where he developed a design platform for trading options. There was no full-time designer in the company and therefore all the design work was done by Thian. Meredith Ely/Bordoni. Community and Marketing Manager Before coming to LearnBoost, Meredith also worked in education. For the previous 4 years, she worked at Stanford University, Kappa Kappa Gamma, and Teach For America. Meredith oversaw the development and support of clients, content, event planning, sales, and also engaged in marketing, telling about LearnBoost and its free opportunities to teachers and schools. In 2010, she began hosting Ed-Tech Meetup — a movement that brings together teachers, technologists, and entrepreneurs for communication, experience sharing, learning, as well as creating a closer feedback loop between teachers and innovators in education. She actively engaged and developed this event and by 2012 the number of Ed-Tech Meetup participants was more than 2000 people. She coordinated, organized and conducted dozens of events to bring together innovators and people from the education sector. In 2012, she will hand over the management of the event to the EdSurge company. Today, Ed-Tech Meetup is the largest event in the US in the field of technologies for education. Rafael, Thian, and Meredith created a unique look for the company and excellent conditions in which the development team was able to create an excellent product and leave a huge mark in the history of open-source. Guillermo Rauch. Co-founder, Developer By the time the company was founded, Guillermo already had experience in developing open-source libraries. He developed several plugins for WordPress and was on the list of main developers for the MooTools library. The establishment of the company was not the final point in this vector. The company was based on a completely new technology — Node.js, for which there were virtually no ready and high-quality solutions. In addition to this, the company had quite modernist desires, such as speed and interactivity of the service. For this, they needed real-time. WebSockets at that time were still in the stage of protocol refinement, and a more or less stable version would only be developed in the following, 2011 year.In 2010, Guillermo gave a presentation at JSConfEU on socket.io, which by that time already had 1000 stars on github. Although Websockets existed by then, they had very limited support and modest functionality, so an overlay was needed on this API, similar to it, but solving the problems of cross-browser and cross-platform. Guillermo demonstrated the possibility of “real-time collaboration” [presentation]. The demo used on the presentation also used express, AJAX, jade (now pug) and mongoose. In 2011, a library was written to launch a server with sockets — engine.io. The first version of socket.io was used by MSOffice in 2012 to add real-time collaboration support (presentation). Guillermo actively traveled to conferences and talked about the libraries created. Primarily about socket.io. He even organized conferences, for example, in Argentina, in 2012. The project needed a database. Therefore, initially support was developed for a MySQL database (https://github.com/rauchg/node.dbslayer.js) in node.js. Introduced in 2009, MongoDB attracted the attention of the company and soon it was chosen for the LearnBoost project. The company stuck to the idea of “everything in js” and the next library developed by the team was “Mongoose”. At the end of 2011, Guillermo developed the juice library, which allowed creating elements with inline styles (written in the