We've taken it too far

It has led us to the point where developers avoid writing custom code at all costs and instead spend months researching libraries. Yes, you read that right, months. True story 🤯 Funnily enough, the library that they picked, nurtured, and made half of the app reliant on got abandoned not more than a few months later.

In the meantime, their main competitor developed an in-house solution, released it to production, and started marketing around it. In theory, picking a library ought to give you a head start. In reality, though, that's often not the case.

I believe the mindless chanting of "do not reinvent the wheel" turned many workplaces and projects into toxic environments. Developers are afraid of putting themselves on the spot, being judged, and possibly failing. They'd rather shift the center of gravity and all attention toward the libraries and their authors.

The time-saving fallacy

„But isn't that good?” you may ask. Great question; I'm glad you asked. The answer is: it depends. Using libraries is supposed to save you a ton of time. Unfortunately, once the library is picked, the developers usually need to spend countless hours trying to bend it to their needs. The library does 90% of the job, which is great, but the remaining 10% requires the developers to become MacGyvers and implement a quick and dirty duct tape solution.

Not to mention the time and money costs of relying on external dependencies: bugs that go unfixed for years, projects that are abandoned, and breaking changes in releases. Maintaining a codebase with more than a few external dependencies seems daunting.

The external dependencies

I am not immune. Just recently, we were faced with the task of implementing a search engine for yournextstore.com. I tried one library, which kind of worked. Then I tried another, which was significantly faster but lacked one of the features that we needed. Oh, and it had 1231 features we didn't need.

It took us a month of meandering to ask ourselves: How hard would it be to implement search on our own? I wrote down the requirements: full-text in-memory search with prefix search, suffix search, and scoring, but no fuzzing. I started coding. It was done in less than a day. It worked 10x to 20x faster than the library we picked previously.

The "don't get me wrong" paragraph

Don't get me wrong. I'm not trying to convince you to abandon all dependencies and rewrite everything internally. It's all about the balance.

If you've decided to build your own framework, I suggest you reconsider. It's unlikely you'll match the quality and velocity of other popular solutions, and you'll make the learning curve cliff-like for new hires.

But a tooltip? A datagrid? A carousel? Even a simple search engine? Those are the examples where going completely custom really shines. Not only are those problems actually easy to solve, thanks to the modern Open Web. But by zeroing in on your specific use cases, you'll be able to trim tens or hundreds of kilobytes off of the bundle compared to the libraries.

Not every problem needs a pre-made solution. Sometimes, rolling your own can save you headaches down the line. Reinventing the wheel isn’t always bad. In fact, it might just be the best decision you make.

Please, by all means, sometimes do reinvent the wheel.

The Link Component in the Pages Router

The Link component from next/link accepts an optional prop prefetch. Back in Next.js 12 or now in Pages Router, prefetch took only two values: true or false (and it was true by default when omitted). However, these values don't really mean what you might think they do.

• true – the route is prefetched when the link enters the viewport

• false – the route is not prefetched when the link enters the viewport; however, the route will be prefetched on hover

That last behavior was commonly perceived as confusing because the semantics of the false value didn't obviously convey the mechanics. Also, it was impossible to disable the prefetching completely.

The Link Component in the App Router

This changed with the introduction of App Router in Next.js 13. However, the exact mechanisms of the automatic prefetching were modified between Next 13 and Next 15, and finally, a third possibility was introduced. The workings of Link are now also different, depending on whether it points to a static or dynamic page. The prefetch prop is (still) optional and takes the following values:

• true – the full route is prefetched when the link enters the viewport, both for static and dynamic pages

• false – prefetching is completely disabled

• null – new default value – the behavior depends on whether the route is static or dynamic:

  • static – the full route will be prefetched when the link enters the viewport

  • dynamic – only a partial route down to the nearest segment with a loading.tsx boundary will be prefetched; if there's no such route, nothing is prefetched

Now, prefetching is more powerful and adjustable. However, it still lacks some flexibility. Let's fix that!

SuperLink: Wrapper for Link

We can extend the capabilities of the Link and control prefetching by introducing a custom component that wraps around the Link.

The plan is to wrap around it, override prefetch, and programmatically prefetch on certain interactions. My idea is to do it when a user hovers over the element. Often, the time between hover and click is long enough for the prefetch to complete, and then navigating to the route is instantaneous. When we're done with that, we'll also consider other ways of interacting with the web app, and improve accessibility of our solution. Let's get to it!

Implementing SuperLink with onMouseEnter

Let's start by wrapping around next/link. We're using React 19, so we don't need the whole forwardRef shenanigans, and we can simply accept ref as props via ComponentPropsWithRef:

"use client";

import Link from "next/link";
import { type ComponentPropsWithRef } from "react";

export const SuperLink = (props: ComponentPropsWithRef<typeof Link>) => {
  return <Link {...props} />;
};

Now, let's override the prefetch prop and use router to programmatically prefetch instead. We'll also need to handle the fact that href can be a string or a URLObject:

"use client";

import Link from "next/link";
import { useRouter } from "next/navigation";
import { type ComponentPropsWithRef } from "react";

export const SuperLink = (props: ComponentPropsWithRef<typeof Link>) => {
  const router = useRouter();
  const strHref = typeof props.href === "string" ? props.href : props.href.href;
  return (
    <Link
      {...props}
      prefetch={false}
      onMouseEnter={(e) => {
        if (strHref) {
          void router.prefetch(strHref);
        }
        return props.onMouseEnter?.(e);
      }}
    />
  );
};

Now, prefetching happens on mouseenter, which should be enough to make the navigation smoother than no prefetching at all. It also works for both static and dynamic routes.

Unnecessary requests

Some people on Twitter𝕏 argue that this is a poor choice because moving your cursors across the page will trigger multiple prefetches. It's true. However, with justprefetch={true}, even more requests will be made. So, I'd say our current implementation is an improvement anyway. On rare occasions, you might want to change the event or condition for which the prefetch is called. It's a tradeoff.

Accessibility

Our current solution completely ignores users navigating the application with keyboards and touch screens. We should improve it and work on accessibility, too!

Will adding handlers for onPointerEnter, onTouchStart and onFocus do the job? I'm no accessibility expert, but it certainly seems to be working:

"use client";

import Link from "next/link";
import { useRouter } from "next/navigation";
import { type ComponentPropsWithRef } from "react";

export const SuperLink = (props: ComponentPropsWithRef<typeof Link>) => {
  const router = useRouter();
  const strHref = typeof props.href === "string" ? props.href : props.href.href;

  const conditionalPrefetch = () => {
    if (strHref) {
      void router.prefetch(strHref);
    }
  };

  return (
    <Link
      {...props}
      prefetch={false}
      onMouseEnter={(e) => {
        conditionalPrefetch();
        return props.onMouseEnter?.(e);
      }}
      onPointerEnter={(e) => {
        conditionalPrefetch();
        return props.onPointerEnter?.(e);
      }}
      onTouchStart={(e) => {
        conditionalPrefetch();
        return props.onTouchStart?.(e);
      }}
      onFocus={(e) => {
        conditionalPrefetch();
        return props.onFocus?.(e);
      }}
    />
  );
};

Now, again, you might argue that calling prefetch on focus will trigger many unnecessary requests. To get to the third link on the page with your keyboard, you need to also focus the first and second ones, and, in effect, you'll prefetch them, too. I agree this is not optimal and can be improved. Looking forward to your suggestions on how.

Prefetch on Fast Internet Only

Here's another idea: only trigger prefetch when the user has a stable and fast internet connection. How can we do that? Using navigator.connection. Let's try that.

I've omitted the rest of the code for brevity, but here's the gist of the idea:

"use client";

import Link from "next/link";
import { useRouter } from "next/navigation";
import { type ComponentPropsWithRef } from "react";

export const SuperLink = (props: ComponentPropsWithRef<typeof Link>) => {
  const router = useRouter();
  const strHref = typeof props.href === "string" ? props.href : props.href.href;
  return (
    <Link
      {...props}
      prefetch={false}
      onMouseEnter={(e) => {
        const hasFastInternet =
          !navigator.connection || navigator.connection.effectiveType === "4g";
        if (strHref && hasFastInternet) {
          void router.prefetch(strHref);
        }
        return props.onMouseEnter?.(e);
      }}
    />
  );
};

Summary

It's not ideal, but remember the Pareto rule: We've done 80% of the job in 20% of the time. I'm open to suggestions on how this can be improved. Maybe with a debounce of some sort? Post your code in the comments!

Classic tests

Typically, regardless of framework, language, or kind of testing, a test consists of three main parts:

1. Conditions / Assumptions (Given)

2. Changes / Actions (When)

3. Observations / Assertions (Then)

The exact names depend on the testing paradigm and community, but the notion is the same: We make assumptions, then perform operations, and finally verify whether the code behaves expectedly.

The problem with tests

Having said all that, I would argue that there's a problem with how tests are usually created: all three steps need to be handled by humans. And humans make mistakes.

Another issue is that this approach to testing requires us to think of every possible scenario. Every step that can be taken in the app, every possible value of variables, and their combination… It's a lot to handle for our minds. And as the number of features in the codebase increases, the complexity of testing grows exponentially. Testing everything is infeasible.

And while there are techniques that help us deal with this complexity, how many times have you released to prod without any bugs? Let me take a guess: 0 times.

Property-based testing

Now, here's a silly idea: what if inputs to tests and actions taken in tests were created automatically by a machine? That's exactly where property-based testing comes into play!

This idea, like a lot of good ideas, comes from functional programming (Haskell, Quickcheck). Later, it was refined in Elixir. But the same concept exists in multiple different languages: C++, Rust, Python, TypeScript… I'll focus on the latter.

Property-based testing is a concept where:

• inputs are randomized

• inputs are constrained

• we think of properties

• we have no specific assertions

• we test properties

The simplest example

Let's take a quick look at the simplest example. It's repeated in probably thousands of articles about property-based testing. We have a function sort that takes a list of numbers, sorts it, and returns. Ignore the fact that most languages have such a function in their standard library.

We could easily write unit tests for our sort. For example:

1. Given a list (3, 5, 1)

2. When it's sorted

3. The result is (1, 3, 5)

Or in code:

it("sorts numbers", () => {
  const input = [3, 5, 1];
  const result = sort(input);
  expect(result).toEqual([1, 3, 5]);
});

We could add a few more tests for edge cases, too: sorted list, empty list, list where all elements are equal… However, unit testing is often called example-based testing. We only test cases we think of, so our test is only as good as our imagination.

QA Engineer walks into a bar, and they order a beer. Order 0 beers. Order 999999 beers. Order -1 beers. Order a lizard. Order a ueicbksjdhd.
✅ Unit tests pass
A real customer walks into the bar and asks where the bathroom is.
The bar goes up in flames.

Now, property-based testing takes a different approach. We think of properties and tell the framework: "Our sorting function behaves such that given any list of numbers…". Let's list a few properties:

1. When a list is sorted, each element is greater or equal to the previous one.

2. The lengths of the original list and the sorted list are equal.

3. Each element from the original list is also in the sorted list.

We do not think of specific cases. Instead, we think of properties that can be applied to any list of numbers. It's way more difficult to think about tests this way, but it's also more beneficial. When we're done designing the properties, the framework will generate hundreds or thousands of tests for us.

Enter fast-check

The framework for property-based testing in TypeScript is called fast-check. What does the above example look like in code?

import assert from "node:assert";
import { it } from "node:test";
import fc from "fast-check";

it("When a list is sorted, each element is greater or equal to the previous one.", () =>
  fc.assert(
    fc.property(fc.array(fc.integer()), (arr) => {
      const sorted = sort(arr);
      assert(sorted.every((v, i) => i === 0 || v >= sorted[i - 1]));
    })
  ));

What this code does is tell fast-check that we're testing a property that requires a list of integers (fc.array(fc.integer())). Fast-check will generate hundreds of randomized inputs on which our assertion will be run.

Shrinking and counterexamples

But the truly interesting thing happens when one of our tests fails. I've introduced a bug to my sorting function to demonstrate this. We get an error message saying Error: Property failed after 6 tests, then an undecipherable string (seed and path), and finally Counterexample: [[23,22]] / Shrunk 526 time(s). What does all that mean?

Fast-check generated a bunch of random arrays and found a case where the test failed. The arrays generated could've been huge. Wouldn't it be nice if Fast-check could somehow produce a minimal reproducible example instead? This is exactly what's going on here! The framework started looking for a smaller input for which the test fails. This process is called shrinking.

Fast-check started with a large array, shrunk it 526 times, and produced a counterexample: an array of just two elements [23, 22]. Isn't that just wonderful?

Fixing bugs

You might be tempted to fix the bug, run the tests again, and move on with your life. But how do you actually know that the bug is fixed? Inputs generated by fast-check are randomized, so there's the off chance of not generating a failing case anymore!

Therefore, the first thing you must do whenever you discover a bug with fast-check is to write a unit test for that specific scenario. That's where another feature of fast-check comes in handy: examples. After a slight refactoring:

it("When a list is sorted, each element is greater or equal to the previous one.", () => {
  const eachGreaterThanPreviousProperty = fc.property(
    fc.array(fc.integer()),
    (arr) => {
      const sorted = sort(arr);
      assert(sorted.every((v, i) => i === 0 || v >= sorted[i - 1]));
    }
  );

  fc.assert(eachGreaterThanPreviousProperty, { examples: [[[23, 22]]] });
  fc.assert(eachGreaterThanPreviousProperty);
});

Summary

I highly recommend playing with fast-check and trying to write a few tests with it. However, in practice, property-based unit tests often become more complex than the underlying tested implementation itself. I treat it as a fun exercise to change the way we reason about the problem.

The next step? Property-based end-to-end testing. This is where the framework really shines, and the cost vs. benefit ratio is much more profitable. I'll focus on that topic in my next article, so follow my blog if you don't want to miss it!

XY Problem: A Scenario

I've been helping many people on various forums, chats, and discord servers for years, and I encounter the XY Problem almost daily. What does it typically look like?

• Q: How can I use library Y to do X?

• A1: (usually, there are ten different suggestions, each more complex than the last)

• Q: Unfortunately, it doesn't work (then more problems arise)

• A2: Why do you want to use library Y? It would be easier to achieve X this way.

• Q: Thanks! It works.

Problem XY: The Mechanism

1. The user wants to solve problem X.

2. The user needs to figure out how to solve X but believes solving Y might be the key.

3. The user doesn't know how to solve Y, either.

4. The user asks for help with Y.

5. Others attempt to assist but need clarification on the focus on Y.

6. After much discussion and time lost, it's finally understood that the user is trying to solve the problem X, and Y is unrelated or unsuitable.

Problem XY: Examples

First Example

A user wants to get the file extension based on its name. Instead of asking this directly, they begin by trying to solve a problem that doesn't exist:

• Q: How can I get the last three characters from a file name?

• A1: filename.slice(-3);

• Q: Thanks! But unfortunately, this doesn't work for jpeg files 😢

• A2: Are you trying to get the file extension?

• Q: Yes.

• A2: filename.split('.').pop()

Example 2

A user is converting CSV to JSON using a specific library but isn't happy with the data format – it comes out as an array of rows, not an array of objects. Instead of asking how to use the library for CSV parsing, the user thinks they should change an array of arrays into an array of objects and asks only about that. They're focusing on a problem that doesn't exist:

• Q: I have several arrays and want to turn each into an object using keys from the first array. For example, [['a', 'b'], [1,2], [3,4]] into [{a: 1, b: 2}, {a: 3, b: 4}]

• A1: That may be tricky. You could use the lodash library, which has a function for this.

• A2: Maybe Object.fromEntries(…) could work?

• A3: You can use a simple loop for this; try this: (code example provided)

• Q: Thanks, but that seems too complicated. I thought converting CSV to JSON was straightforward, but I keep hitting snags…

• A4: Hold on. Are you converting CSV to JSON? What library are you using?

• Q: PapaParser

• A4: PapaParser has a headers: true option, giving you the objects you're looking for instead of an array of arrays. You don't need to do anything manually.

Where does it come from?

Several factors contribute to the XY Problem. First, the person asking the question is often too invested. They've spent so much time trying to solve problem Y that stepping back to consider problem X seems daunting. They might insist, "I already have the whole system; I just need this one small part," but as the CSV example shows, they might have built more than necessary.

Another reason is the desire to do things correctly. It might sound surprising, but our idealistic views on solving problems can blind us to simpler solutions.

Additionally, questioners sometimes feel guilty. They hesitate to ask about the broader issue X, opting instead to focus on solution Y. They believe this approach saves the time of those helping them, showing up with a specific problem in search of a specific solution, either out of politeness or guilt.

The XY Problem isn't just a tech issue; it's universal, affecting all areas of life, including medicine. Often, people visit doctors with a self-diagnosis, asking about that instead of explaining their actual symptoms.

The Issue of Understanding and Compassion in Replies

Some argue that what I've described isn't the heart of the XY Problem. They think the real issue lies with the person responding, not the one asking the question. I don't entirely agree, but it's worth mentioning. The XY Problem can lead to a lack of compassion and understanding in those who answer.

Imagine you're asking about a problem you believe is important. A few people attempt to help, but then someone tells you, "You don't actually have problem Y. What you're really asking about is X." How does that make you feel? This lack of compassion from the person answering might make you defensive. You might want to say, "I know what I'm talking about." That could be true, or maybe not, but the conversation will continue with feelings of guilt ("I'm wrong, they're right") or defensiveness ("they're wrong, I know what I was asking").

Another example occurs when the person responding sees themselves as an expert, disregards what the other person is looking for, and instead pushes their preferred solution. For instance, in programming, if you inquire about loops, someone will likely insist you have an XY problem, and you should instead try making your code more functional. It's not the XY Problem I mentioned earlier in the article — it's the responder's narcissism.

It's beneficial to offer different solutions when you want to help someone and think they might need help understanding their needs or are making errors. However, it's important to remember that the person asking is occasionally right.

The article Two Attitudes in Psychiatry further explores this contrast.

How to Ask Questions?

Eric S. Raymond, in his publication How To Ask Questions The Smart Way, discusses the XY problem with an example:

• Q: How can I use X to do Y?

• A: If what you want is to do Y, you should ask that question without pre-supposing the use of a method that may not be appropriate. Questions of this form often indicate a person who is not merely ignorant about X, but confused about what problem Y they are solving and too fixated on the details of their particular situation. It is generally best to ignore such people until they define their problem better.

My advice? Provide more context in your question.

Instead of asking, "How can I get the last three characters from a file name?" you should ask, "How can I get the last three characters from a file name? I need the file extension."

Instead of saying, "I have several arrays, and I want to convert each of them into an object whose keys come from the first array," you should clarify by saying, "I have several arrays, and I want to convert each of them into an object whose keys come from the first array. These arrays come from parsing CSV files using the PapaParse library."

Adding more detail can make things much easier for you and others. Often, there's a better, faster, and easier solution to your problems.

What are polymorphic components?

You've probably heard of them. Seen them. Used them. Maybe even tried building one. Simplifying, polymorphic components render as different elements based on props passed to them. A typical example is LinkButton that takes an as prop and can either be a button or a:

<LinkButton
    as="a"
    href="/"
/>

<LinkButton
    as="button"
    onClick={(e) => {
        console.log(e);
    }}
/>

Mind how the as prop influences other props as well. In this case, when passing as="a", you'll also need to add href. And when passing as="button", href will be forbidden. Looks nice.

Polymorphic components in TypeScript

Implementing polymorphic components in TypeScript requires a wee bit of trickery. You can read all about it in this excellent piece by Matt Pocock: Polymorphic Link/Button Components in React & TypeScript. Doesn't look so bad! But…

Accidental and true duplication

In "Clean Architecture" by Robert C. Martin, the author mentions a concept that deeply resonated with me. There are two kinds of duplications: true (bad) duplication and false (accidental) duplication.

True duplication is when the same code or logic is repeated in multiple places.

Accidental duplication is when the same code or logic is repeated in multiple places.

Just by looking at the code in situ, it's impossible to say which kind of duplication we're dealing with. That's why it's so tricky. Only when the codebase starts evolving will we see that accidentally similar pieces of code are changing in a different manner and for various reasons. In contrast, truly duplicated code always changes in the exact same way at the same time. That's why it's so important not to avoid duplication at all costs. I suggest waiting and observing which pieces of code will benefit from deduplicating.

What does it have to do with anything? My experience tells me that polymorphic components are mostly used to deduplicate accidentally similar pieces of code.

Diverging polymorphic components

Consider the LinkButton example above. What happens when we need to add disabled state support for both a and button? The underlying implementations will differ significantly. In the case of a button, it'll be as simple as adding a disabled attribute to the HTML element. However, for a to be "disabled", we'll need to add an onClick handler whose sole responsibility is to preventDefault. Moreover, the aria-disabled attribute should be added as well. That forces us to write dirty conditional code. Not only will it cause trouble with maintenance in the future, but it'll be instantly annoying when it comes to getting the types right. Try it for yourself!

Even worse, we're mixing responsibilities! There's no clear separation between the UI and logic. We can't simply reuse LinkButton's looks for other elements without modifying it.

What happens when we use the same pattern for more complex cases if it's a pain in such a simple scenario? Think of <Container as=…> or <Card as=…> – commonly found in different codebases. Yikes.

Enter asChild

The asChild pattern solves all the mentioned problems. It clearly separates responsibilities. Components built with asChild in mind are easily reusable for their looks regardless of the component's role. Let's see it in action:

<UIButton asChild>
    <a href="/">Go back home</a>
</UIButton>

<UIButton asChild>
    <button onClick={…}>Do something</button>
</UIButton>

Smooth, right?

The UIButton component is completely agnostic of the element inside – an a, button, div or any other. Moreover, no additional HTML tags are rendered.

asChild and Slot Implemented

Often, the asChild is optional. When you omit it, a default element is rendered instead of relying on the child. See Radix, for example. However, it stems from my experience that it's a good practice to make the child element required. I never render the default element and always expect the developers to use children. In this case, the asChild prop is not really required. It's just a pattern. A clear way of indicating that a given component needs to be used in a certain way and doesn't render anything on its own.

Either way, the true magic happens inside the Slot component:

import clsx from "clsx";
import { isValidElement, cloneElement, Children, type HTMLAttributes, type ReactElement } from "react";

export const Slot = ({
    children,
    ...props
}: HTMLAttributes<HTMLElement> & {
    children: ReactElement;
}) => {
    if (isValidElement<HTMLAttributes<HTMLElement>>(children)) {
        return cloneElement(children, {
            ...props,
            ...children.props,
            className: clsx(children.props.className, props.className),
        });
    }
    throw new TypeError(`Single element child is required in Slot`);
};

What's going on here? Let's go through the code step by step. We declare a Slot component that takes all props that any element could take. Additionally, we require children of type ReactElement – meaning that exactly one element needs to be passed to it.

Then, we do a runtime validation of whether the provided children is, in fact, a valid React element. If it is, we clone that element, merge props passed to Slot and the element, and return it. We also take extra care of the className using the clsx library. You might want to use tailwind-merge instead if that's your jam.

Then, the Slot is reused in different UI… components in the following manner:

import { clsx } from "clsx";
import { type ReactElement, type ButtonHTMLAttributes } from "react";
import { Slot } from "./Slot";

interface UIButtonProps
    extends ButtonHTMLAttributes<HTMLButtonElement> {
    asChild: true;
    children: ReactElement;
}

export const UIButton = ({
    asChild: _,
    ...props
}: UIButtonProps) => {
    return (
        <Slot
            {...props}
            className={clsx(
                "your classes to make it look nice",
                props.className,
            )}
        />
    );
};

We ignore the asChild and pass all remaining props to Slot. We also add classes responsible for how the element is supposed to look and merge them with the parent class names. And this is it!

Summary

No conditional logic, straightforward separation of concerns, easy maintenance. There's now only a single reason to modify the UI… components: when we need to change how they look.

The added benefit is how simple it has become to build a Storybook with such components. No need to mock any logic or providers. Just use the UI… components with bare-bone elements, and you're done!

I can't imagine building interfaces without the asChild pattern anymore. Do you like it? Let me know in the comments.

Serendipity is the luck some people have in creating interesting or valuable things by chance.

How could three people who barely knew each other and were from different cities pull off a conference in two months?

Kongres Next.js conference is over. We've welcomed nearly 250 people and had 14 excellent talks in Warsaw on February 2, 2024. You can find the agenda here and read our Transparency Report about tickets, speakers, costs and income.

I also invite you to read Aleksandra's recap of the event, where she uniquely pinpoints all the good and bad things about the event. But my article is slightly different; I wanted to tell a story about trust, friendship, collaboration, and randomness.

Zaiste

So, serendipity. The origin story behind Kongres Next.js goes back a few years back when a Twitter user DM'ed me and praised one of the Open Source projects I was working on. That user was Jakub "Zaiste" Neander. We didn't know each other. To be honest, I've never even heard of him, despite his quite popular tech YouTube channel Zaiste Programming.

At that time, I was at my peak popularity in Poland after just releasing a book about TypeScript. I got tons of messages from people daily, and frankly, I was a bit tired of it. Yet, for some reason, I was in a perfect mood that day, so I quickly replied to Zaiste. What I thought was yet another irrelevant message from a fan turned out to become a collaboration that would go on for years. It was just completely random. Or was it?

Aleksandra

Being deeply involved in the TypeScript community, I quickly learned about Aleksandra Sikora. First, I found her blog. Then, I found her public initiatives. Without any exaggeration, Aleksandra is one of the most influential people involved in TypeScript on the Globe. I was astonished at how well Aleksandra was known worldwide, yet not at all in Poland. She was, to me, what Ariana Grande is to teenagers: an untouchable star.

However, one day, I just randomly reached out to her. I can only fantasize how many messages she gets every day from random geeks like me, so you can imagine my surprise when she replied almost instantly. And was she friendly and approachable! My hit-or-miss one-in-a-thousand DM eventuated into her being my guest in Breakfast with Programming (pol. Śniadanie z Programowaniem) YouTube talk show. Later, we met IRL during a TypeScript Wrocław meetup that the company I was working for was sponsoring (what are the odds?!). We quickly became not only colleagues but, I guess, friends.

Meetup Next.js

Jakub and I started collaborating on a Next.js cohort-based online course. We've produced and sold four homemade editions, and when Next.js 13 was released, we decided to go full professional: start from scratch, focus on App Router, rerecord everything, and work with a well-qualified video-producing company, Brave Courses.

A bit of context: Zaiste has 10 new ideas every second, to most of which I instantly say bluntly "NO". One day, he just randomly said, "Let's start this edition of the course with a meetup". My thoughts were, "No, this is stupid, it's not enough time, it doesn't make sense, I'd rather not", so I indifferently answered, "Yeah, let's do that", hoping he'd just forget about it in a few hours. Well, spoiler alert, he didn't.

It was almost the end of November 2023, and we were meeting with some friends in Warsaw. I randomly remembered attending a conference in a small and cosy cinema in 2016. We called them. It was available to rent on the day Zaiste wanted to organise the meetup, and it was surprisingly affordable. We've booked it immediately and got the balls rolling. How random?

Kongres Next.js

The clock was ticking; we had just around 60 days to organise and prepare everything with the holiday season in the middle. We were brainstorming about good speakers we could've invited, and I instantly thought of Aleksandra. She rejected my request to speak at the event, but she offered so much more: she'd help us organise it and reach out to many renowned speakers from Europe that she personally knew. We also changed the idea from a local meetup to something way more ambitious: an international conference.

To make matters even more complex, the conference was supposed to happen in Warsaw, as we thought it was the best tech hub in Poland, but none of us live there – we all had about a 4-hour drive to the venue.

We've built the website in a few hours, guessed proper ticket prices, integrated Stripe… Not more than two days later, we were ready to start the presale, and Aleksandra officially joined the conference board. Everything that happened during the next two months was either by sheer luck, through our friends' help, or by YOLO'ing it.

5 days before the event, I thought, "Oh no, we forgot about the badges 😱". So Ola and I designed them in Figma in one hour. I ordered some recycled paper, and my wife printed and cut them to the proper sizes.

3 days before the event, I thought, "Wait, we don't have lanyards for the badges 🫠". Panicking, I made a few calls and found a company in Warsaw that would deliver 300 eco-paper lanyards to our hotel the day before the conference.

Trust and friendship

I'm talking a lot about what I've done; what did Jakub and Aleksandra do? Well, a lot of other things! Took care of speakers, venue, lunch… But the most beautiful aspect of our cooperation was our complete trust in each other. Despite my anxiety and being a total control freak, I felt I didn't need to check on them, ask every other day whether things have progressed, and that they're doing the best they can. I didn't even need to know precisely what they were up to because I could've blindly trusted them. Each of us was able to make calls independently, and we consulted on more significant decisions. Without any pretentiousness, I think it was the most perfect teamwork I have ever experienced.

Summary

How did the event go? Not without problems, obviously. But all in all, it was great. The atmosphere of coziness, unbelievable meetup vibes, 14 incredible talks, fantastic networking, and a lively after-party.

Is there a moral to this story? It's truly shocking how many random things had to coincide for this event to happen. So, I guess the moral of this story is that the best things in life happen by accident. Serendipity.

Event Density and Time Perception

When I discussed this with several people, they claimed that as children, they had many more interesting and new experiences, while today, life seems dull. This idea is fascinating, but it doesn't entirely reveal why childhood events would impact our perception of time in later years!

Many people also suggest that the time we perceive is relative to the time we've experienced. For example, a year perceived by a 4-year-old child is a whopping 25% of their entire life, while for an adult, it would be less than 5%.

Mathematical Model of Relative Time

Let's rephrase the above statement to facilitate writing it as an equation: The perceived speed of time passing decreases with age.

In scientific publications, I discovered a proposal that this relationship was proportional to the absolute passage of time (objectively measured, e.g., in years) [Doob (1971), Janet (1877)]. However, according to our assumptions, we experience relative time, not objective time! Let's attempt to express this mathematically.

Assume that objective time is denoted by O, and subjective time (perceived by us, relative) is represented as S.

dO and dS are infinitesimal time periods – dS signifies the passage of time dO as experienced by us.

As previously mentioned, the perceived passage of time decreases with the amount of time lived (also subjective!), so dS decreases as S increases. Consequently:

$$dS = dO\frac{K}{S}$$

where K is some constant that we'll get rid of shortly. Additionally, we assume that at the moment of birth, both O and S are equal to 0:

$$O_0=S_0=0$$

The remaining task is to transform the equation and perform integration:

$$\begin{aligned} dS &= dO \cdot \frac{K}{S} \\\\ SdS &= K dO \\\\ \int_0^S SdS &= K \int_0^O dO \\\\ \frac{1}{2} S^2 &= KO \\\\ S^2 &= 2KO \\\\ S = \sqrt{2KO} &\ \ \ \ \ S \geq 0;\ \ O \geq 0 \\\\ \\\\ dS &= dO \frac{K}{S} \\\\ dS &= dO \frac{K}{\sqrt{2KO}} \\\\ dS &= dO \frac{\sqrt{K^2}}{\sqrt{2KO}} \\\\ dS &= dO \sqrt{\frac{K^2}{2KO}} \\\\ dS &= \sqrt{\frac{K}{2O}}\ dO \\\\ \end{aligned}$$

Now, let's assume the same time period dO is perceived at two different moments in life, O1 and O2, and determine the proportion between the relative perceptions:

$$\begin{aligned} dS &= \sqrt{\frac{K}{2O}} dO \\\\ \\\\ dS_1 &= \sqrt{\frac{K}{2O_1}} dO \\\\ dS_2 &= \sqrt{\frac{K}{2O_2}} dO \\\\ \\\\ \frac{dS_1}{dS_2} &= \frac{\sqrt{\frac{K}{2O_1}} dO}{\sqrt{\frac{K}{2O_2}} dO} \\\\ \frac{dS_1}{dS_2} &= \frac{\sqrt{\frac{K}{2O_1}}}{\sqrt{\frac{K}{2O_2}}} \\\\ \frac{dS_1}{dS_2} &= \sqrt{\frac{O_2}{O_1}} \\\\ \end{aligned}$$

Isn't it fascinating that, for an average person, their subjective perception of the same time period shifts in a way that's inversely proportional to the square root of their life's length?

Application

Now let's consider how the perception of a year in one's life changes for two people who are 10 and 40 years old. By substituting into the derived formula, we obtain:

$$\sqrt{\frac{40}{10}} = \sqrt{4} = 2$$

This means that for a 40-year-old, a year will pass twice as fast as a 10-year-old!

Relative perception of time

We can also take it a step further – let's consider what part of our life (relatively) we have already experienced. If we go back to one of the equations for a moment…

$$S = \sqrt{2KO} \ \ \ \ \ S \geq 0;\ \ O \geq 0$$

Let's denote the moment of death as Sd and Od (perceived relatively and objectively, respectively), substitute into the equation above, and divide by the same equation:

$$\begin{aligned} S_d &= \sqrt{2KO_d} \\\\ S &= \sqrt{2KO} \\\\ \\ \frac{S}{S_d} &= \frac{\sqrt{2KO}}{\sqrt{2KO_d}} \\\\ \frac{S}{S_d} &= \sqrt{\frac{O}{O_d}} \end{aligned}$$

To simplify the calculations, let's first assume that a person lives for 100 years (Od=100), and the person being analyzed is 25 years old (O=25):

$$\sqrt{\frac{25}{100}} = \frac{5}{10} = 0,5$$

This means that 25-year-olds have already experienced 50% of their life, at least in their perception, even though they still have 75% of their life measured in objective years ahead of them.

Now let's analyze me. Assuming that the average life expectancy in Europe is 80 years, and I am 31, then:

$$\sqrt{\frac{31}{80}} = 62\%$$

Well, most of my life is already behind me 🙃

Relative time vs. objective time

Fortunately, as rightly pointed out, the subjective time we have left will never be less than half of the objective time until death. Let's try to prove it!

If the relative and objective times until death are given by the equations:

$$\begin{aligned} 1 - \sqrt{\frac{O}{O_d}} \\\\ 1 - \frac{O}{O_d} \end{aligned}$$

Let's start with the two previously discussed examples:

$$\begin{aligned} 1 - \sqrt{\frac{25}{100}} &= 0.5 \\\\ 1 - \frac{25}{100} &= 0.75 \end{aligned}$$

If we divide one by the other, it turns out that the result is greater than half:

$$\begin{aligned} \frac{0.5}{0.75} &= 0.\overline{6} \end{aligned}$$

Similarly, for the second example:

$$\begin{aligned} 1 - \sqrt{\frac{31}{80}} &\approx 0.3775050201 \\\\ 1 - \frac{31}{80} &= 0.6125 \\\\ \frac{0.4193027447}{0.6627906977} &\approx 0.6163347267 \end{aligned}$$

The theorem seems to hold true. Let's try to generalize:

$$\begin{aligned} \frac{1 - \sqrt{\frac{AGE}{DEATH}}}{1 - \frac{AGE}{DEATH}} \geq \frac{1}{2} \end{aligned}$$

AGE is the variable here, and DEATH is the constant. In that case, we can substitute:

$$\begin{aligned} x = \frac{AGE}{DEATH}\ \ \ \ \ 0 \leq x \leq 1 \end{aligned}$$

$$\frac{1 - \sqrt{x}}{1 - x} > 1/2 \ \ \ \ \ \ \ \ \ \cdot \frac{1 + \sqrt{x}}{1 + \sqrt{x}}$$

$$\frac{(1 - \sqrt{x})(1 + \sqrt{x})}{(1 - x)(1 + \sqrt{x})}$$

$$\frac{1 - x}{(1-x)(1+\sqrt{x})}$$

$$\frac{1}{1 + \sqrt{x}}$$

$$\frac{1}{1 + \sqrt{x}} \geq 1/2$$

$$1 + \sqrt{x} \leq 2$$

$$\sqrt{x} \leq 1$$

$$0 \leq x \leq 1$$

$$\therefore\ \ \ 0 \leq \sqrt{x} \leq 1$$

$$\blacksquare\ QED$$

Summary

Interestingly, the above theories and calculations have also been preliminarily confirmed experimentally [Robert Lemlich – Subjective acceleration of time with aging, 1975]. How much of your life have you already experienced in relative units?

Did you enjoy this post? Let us know in the comments.

What are Optimistic Updates?

The term "optimistic updates" refers to an application behaviour in which we don't need to wait for asynchronous operations to complete before seeing their results. It's a little trick – the operation is performed in the background while the interface is updated immediately.

Optimistic Updates and UX

Let's assume we're building a social media platform. When a user likes a post, they have to wait a second or two for the server to confirm that the like was successful. This results in a poor user experience (UX). Can we improve it somehow?

Yes! We can apply Optimistic Updates and immediately update the like counter after the user clicks the button. In the background, we'll send the request to the server. It makes the post appear as if the server operation was immediately successful without waiting for its completion.

Optimistic Updates, when they're successful

Additionally, when the server update is ultimately successful, we could also inform the user about it. Depending on the specific use case, app, and design, we can do it in several ways:

• While the asynchronous operation is in progress, we display a tiny spinner (animation). Either near the "like" button or, for example, in the lower right corner of the screen. When the operation is successful, the spinner simply disappears.

• We perform an optimistic update, but the view slightly differs from the final one. For instance, the like counter increases immediately, but it's slightly greyed out until the response from the server arrives.

• After the server query is completed, we display a message to the user. We can do this in different manners, depending on the importance of the operation being performed. Toasts are often used in this case.

Optimistic Updates, when they fail

Most user actions will be successful. However, we cannot completely ignore the possibility that liking a post might fail for some reason. It could be a temporary loss of the Internet connection or an intermittent server outage. What then?

A lot depends on the seriousness of the situation and the operation being performed by the user. Going back to the example of likes, we can simply undo the optimistic update and decrease the like counter. However, for more important actions like sending an email or deleting a document, we should consider displaying a notification and informing the user about the consequences or the need to take action.

React.js Implementation

useOptimistic in React.js and Next.js 14

In early May 2023, the React team released experimental support for the built-in hook called useOptimisticState, which was later renamed to a simpler useOptimistic. Its use cases include implementing, well, optimistic updates, but not just that. Essentially, useOptimistic allows for the implementation of any "pending" state, that doesn't necessarily have to be related to sending requests to a server.

Today, the hook is available in canary and experimental React releases as well as Next.js 13 and 14. This is where we'll be using it.

Let's get started with Next.js 14

We're beginning by creating a new project in Next.js 14:

pnpm create next-app use-optimistic

Now we just need to answer a few simple questions and we're good to go!

Naïve Implementation

Let's start with a naïve implementation. Let's assume that there are three functions used for operating on likes:

1. getLikes()

2. like()

3. dislike()

In the main component, we fetch the number of likes and information on whether we have already liked the current post or not:

const { likes, isLiked } = await getLikes();

Next, we pass this information to the LikesCounter component:

<LikesCounter
  likes={likes}
  isLiked={isLiked}
  onLiked={async () => {
    "use server";
    revalidatePath("/");
  }}
/>

The simplest implementation of this component is just a basic form with a button:

<form action={async () => {
  if (isLiked) {
    await dislike();
  } else {
    await like();
  }
  await onLiked();
}}>
<button type="submit" aria-label={isLiked ? "Dislike" : "Like"}>
  {likes}
</button>

Unfortunately, as anticipated, this doesn't work very well. After clicking the button, it takes a few seconds before the counter updates. Moreover, we should also handle an intermediate state – waiting for the response from the API – and during this time, ignore further button clicks.

Implementation with useOptimistic

useOptimistic is a hook that takes two arguments: the initial state (e.g. from the server) and a reducer – a function that takes the state and an action and returns a new state. useOptimistic returns a tuple with the optimistic state and a function to update it.

An example usage looks like this:

const [optimisticLikes, setOptimisticLikes] = useOptimistic(
  likes,
  (likes, action: "LIKE" | "DISLIKE") => {
    if (action === "LIKE") {
      return likes + 1;
    } else {
      return likes - 1;
    }
  },
);

Now we need to modify the function for updating likes. Before liking a post, we call setOptimisticLikes("LIKE"), and if it was already liked, we use setOptimisticLikes("DISLIKE"). Additionally, instead of likes, we use optimisticLikes for displaying. The entire code listing is shown below, although it's worth noting that not everything works as it should just yet…

<form action={async () => {
  if (isLiked) {
    setOptimisticLikes("DISLIKE");
    await dislike();
  } else {
    setOptimisticLikes("LIKE");
    await like();
  }
  await onLiked();
}}>
<button type="submit" aria-label={isLiked ? "Dislike" : "Like"}>
  {optimisticLikes}
</button>

Rapidly clicking the button now causes the counter to decrease: 20, 19, 18, 17, 16, 15, 14… Additionally, we never update the value of isLiked. We need to modify our state and reducer slightly to fix that:

const [optimisticState, setOptimisticLikes] = useOptimistic(
  { likes, isLiked },
  (state, action: "LIKE" | "DISLIKE") => {
    if (action === "LIKE") {
      return { likes: state.likes + 1, isLiked: true };
    } else {
      return { likes: state.likes - 1, isLiked: false };
    }
  },
);

Now, instead of a simple state, we have an object with two properties: isLiked and likes – which correspond to those coming from the server. Another important change is updating isLiked and using it in the components below:

<form action={async () => {
  if (optimisticState.isLiked) {
    setOptimisticLikes("DISLIKE");
    await dislike();
  } else {
    setOptimisticLikes("LIKE");
    await like();
  }
  await onLiked();
}}>
  <button
    type="submit"
    aria-label={optimisticState.isLiked ? "Dislike" : "Like"}>
    {optimisticState.likes}
  </button>
</form>

Now, quickly clicking the button causes the counter to toggle up and down – just as we would expect!

Actions Queueing

You might now be wondering, "If I click the button quickly 10 times, what will be the final state on the server side?" Don't worry, React.js and Next got you covered and take care of the correctness for you. Consecutive clicks cause an immediate interface change (optimistically), but the server requests are queued and sent one by one. There's no risk that rapid button clicking will result in requests being sent out of order.

We can observe this behaviour precisely in the Network tab in devtools. We see a beautiful waterfall of requests – they are not executed in parallel but one after another.

State rebasing

An interesting and yet underrated behaviour of useOptimistic is recalculating (rebasing) of the optimistic state when the source state changes. Imagine a scenario: a post has 20 likes, and we like it. The counter optimistically changes to 21 immediately. However, while our request is being executed to the server, an update to the number of likes arrives: it turns out there are now 44. What should the optimistic interface display?

In many simple implementations, it would show 44. However, I expect 45 (the number from the server + our like "in flight"). Fortunately, React.js saves the day again and takes care of this for us. We don't even have to do anything!

Summary

Undoubtedly, many of you have implemented optimistic updates on your own, but the complexity of this problem and the numerous edge cases to consider make it a challenging task. Fortunately, useOptimistic is built into React.js and significantly simplifies the implementation of applications that adhere to good UX principles.

Sources

1. https://github.com/HyperFunctor/optimistic-updates

2. https://kongresnextjs.pl/

3. https://www.nextjsmasters.pl/

4. https://github.com/facebook/react/pull/26740

5. https://github.com/facebook/react/pull/26772

6. https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions-and-mutations#optimistic-updates

Organizing Conferences

Organizing meetings and conferences is no easy task. There are countless details to remember! Even if you do everything 100% right, a lot depends on others – suppliers, service providers, sponsors…

In this post, I have gathered a summary of my experiences from the past 5 years. The entry is as practical as possible – it serves as a simple checklist for conference organizers. What should you keep in mind and consider when organizing events?

General

• You need at least six months to organize any event of this size.

• Consider the purpose of your conference. Are you focusing on networking or knowledge?

• Make sure that every participant at the conference feels comfortable.

• Implement and enforce a Code of Conduct. It's more important than you might think.

• The Code of Conduct must include specific steps you will take in case of violations, as well as a clear and straightforward way to report issues.

• At times, it can be difficult to identify all the issues, and groupthink may prove to be quite detrimental. Choose co-organizers who are different from you, and who will sometimes disagree with you. This way, you'll identify problems that you might not have noticed otherwise.

Finances

• Operate with net amounts only – everywhere and always. Some services have different VAT rates, so if you work with gross amounts, you might end up at a loss.

• It's ideal to issue all invoices for sponsors within the same accounting period (month or quarter) as the conference. By doing so, you won't pay huge income tax, as you'll spend the money before the next accounting period, simplifying your financial management.

• To confirm agreements, send sponsors pro forma invoices. These resemble invoices but are not actual invoices :)

• Begin collecting contacts and quotes from various companies early: print houses, videographers, photographers — so you won't be caught off guard by prices later on.

• Avoid promising things you don't have the funds for yet. For instance, only announce a second night's accommodation for speakers, breakfast, or complimentary alcohol at the after-party when you're certain you can afford it.

• A website is crucial – the sooner it's up and running, the better – even without highly detailed information.

• You can attract sponsors even before taking any other steps, based on the strength of your brand (in my case – meet.js or Type of Web).

• You can sell the first batch of tickets even before the agenda is made available.

• Always gather at least one counteroffer before making a purchase. Frequently, you'll discover that another company offers a lower price, and you'll also generate great ideas and learn what you truly want during discussions with different providers.

• Keep in mind - it never hurts to ask for a discount. Negotiate as much as possible.

• If you have specific expectations, make sure to clearly communicate them. Rather than relying on verbal communication, put your expectations in writing, such as in an email, or ideally, in a contract.

• Avoid making arrangements over the phone, as words can be fleeting and easily forgotten or misinterpreted. After each conversation, send an email summarizing the agreements.

Printouts

• Badges

  • Order personalized badges with participants' names.

  • Ask about the printing deadline. Typically, you should provide the print house with a list of participants at least a week before the conference.

  • Don't forget about badges for speakers, assistants, and organizers.

  • Print some blank badges for last-minute guests to write their names on.

  • The agenda on the back side should be upside down to make it easier to read.

  • Verify whether the badges will be pre-inserted into their holders. This is a lot of work, so plan accordingly.

• Lanyards

  • Order extra lanyards to ensure you can freely distribute them to attendees without any stress.

• Bags and T-shirts

  • Bags are fantastic because they can hold flyers and sponsor gadgets.

  • Although conference T-shirts may not be widely worn, they are a pleasant and affordable addition – worth considering.

  • If you decide to order T-shirts, remember to provide a selection of different sizes and cuts.

Venue

• Verify the availability of equipment (screen, sound, etc.)

• Will there be someone to manage audio/video, or are you only provided with a projector and speaker?

• Verify if presentations can be played using HDMI.

• Determine the format and resolution — 4:3/16:9, 800x600, or perhaps HD, etc. Inform the speakers about this!

• Verify the actual capacity (for instance, a room may have 417 seats on paper, but 2 are for disabled individuals and 24 for technical staff, leaving only 391 available).

• Ensure there is space for coffee and lunch; identify the specific location; accommodating 400 people is no small task.

• Determine EXACTLY how much space will be available for sponsors. Today you have 10 sponsors, but will there be room for 11? 12? 13? Plan to ensure they all fit.

• Prepare a display board to be shown on the projector during breaks between presentations. Include sponsor logos.

• Create a map of the venue for sponsors, including dimensions and booth locations.

• Carefully consider how many people are needed to help manage everything. At least:

  • 3 for registration

  • 2 for the room

  • 1 to assist speakers

  • 1 to assist sponsors

Sponsors

• Prepare a variety of sponsorship packages; suggested:

  • main

  • afterparty

  • just a booth

  • without a booth (an affordable option)

• Describe in detail what is included in each package.

• Accurately measure, count, draw, and describe the space and dimensions of their booths to prevent misunderstandings.

• Following each phone call, send an email summarizing the conversation.

• Never respond to the question "Will the booth fit?" without knowing its dimensions. It may seem obvious, but in practice, a casual "it will definitely fit" mentioned over the phone can lead to numerous issues later on.

• Create and expand a contact list of sponsors that can be used in the future.

• Ask speakers if the companies they work for would like to sponsor the event.

• Remember to provide parking spaces (free of charge!) for sponsors.

• Print (or order from a print house) signs with directions: auditorium, cloakroom, lunch, restroom, etc…

Catering

• If you plan to provide catering for participants, be aware that a specific venue often has one company holding exclusive rights to such services. To avoid surprises, inquire about the situation before signing a contract.

• If you don't want to use on-site catering services, you can organize lunch, for example, in the form of food trucks outside the venue or at a restaurant across the street.

• If possible, provide a coffee break or breakfast before the first presentation.

• Even if you don't offer free coffee breaks or meals to participants, make sure there is a store, cafe, or restaurant on-site or close by.

• When negotiating prices, inquire about various options – for example, coffee is often priced for continuous availability throughout the entire event. If you request a quote for coffee only during breaks between presentations, you might be pleasantly surprised.

After party

• Determine your budget.

• Free food and drinks are nice, but they're not required :)

• Try to estimate as accurately as possible how many people will attend. Based on my experience, typically ¼ to ⅓ of conference attendees join the party.

• The location should be close to the conference venue. Ideally, it should be within walking distance.

• Is there music?

• Are there other attractions?

• Will the place be exclusive for your event?

• How much food is needed?

• Can a drink limit be set, after which attendees pay for their own drinks?

• Request at least two proposals – a "luxurious" option and a "budget-friendly" one.

Speakers

• Call For Papers? If so, plan it well in advance.

• Ensure a maximally objective selection process. Those who choose presentations from CFP should not have access to the presenter's name or photo.

• Encourage participation from individuals with no prior experience. They often create the most engaging presentations!

• If you're hosting a Call For Papers, refrain from inviting "stars," as it may discourage beginners.

• Consider allocating time for lightning talks and encourage beginners to participate. This is often the most interesting content at conferences.

• Request that speakers submit their slides a few days prior to the conference to ensure everyone is well-prepared.

• Ensure that the slides do not contain hate speech. I wish I was joking. I attended a conference where a speaker displayed a swastika on a slide, and another one where the entire presentation revolved around poking fun at stereotypes about male and female programmers. You'll want to avoid such situations.

• Are you planning a dinner for the speakers? If so, where, when, and at what expense?

Ticket Sales

• I won't recommend any specific ticketing system. Explore various options and choose one that helps you minimize any legal formalities.

• Consider your target audience and prevalent payment systems in their countries. For instance, over 40% of Polish participants pay using Blik.

• Activating an account with third-party payment providers can take quite a long time. You'll need to prepare contracts, terms and conditions, privacy policies, and who knows what else. It requires a great deal of patience.

• Keep in mind that, ultimately, your account will receive the ticket price minus 5% for various commissions.

Miscellaneous

• Purchase extension cords, adhesive tape, markers, and pens. Don't forget to bring some paper.

• Arrive at the conference venue early and ensure everything is in order :).

Conference Organizer's Guide

The primary objective of this post is to assist those who wish to organize a large event. However, as evident, organizing a conference is certainly no easy task. I hope that this post has provided insight into what you're getting into and demonstrated how time-consuming and complex organizing something on a larger scale can be.

Organizing a top-notch conference is undeniably a massive challenge, and even the smallest mistake can affect your reputation. However, it also provides an incredible adrenaline rush and a sense of satisfaction when everything goes according to plan.

While the list above is comprehensive, it is by no means exhaustive. I have entirely left out the subject of event marketing.

I encourage you to comment! If you have any thoughts to share or additional insights, please feel free to write about them in the comments.

Independence

OpenNext exists because Next.js is difficult to deploy anywhere but Vercel.

The sentence could be true if it read "OpenNext exists because deploying Next.js on AWS with serverless is challenging." And that's true; it's quite complex. Complex to the extent that Remix also doesn't provide a ready-made AWS serverless template either, contrary to what Kent seems to suggest in his article.

OpenNext uses SST (Serverless Stack) – a project designed to simplify the deployment of applications on AWS. It is not specific or targeted only at Next.js; quite the opposite: the SST website mentions Next.js, Astro, SvelteKit, SolidSite… and Remix.

Now, does Vercel have an interest in making it easier to use Next.js on other hosting solutions, even though they offer their paid services? Of course not. Nonetheless, in the Next.js repository, you can find examples of how to do that 1 2 3, and the documentation even describes how to implement your own Data Cache.

Next.js is eating React

Ever since then, the React team has felt much less collaborative.

This section in Kent's is very subjective. From my perspective, not much has changed except for the velocity - the development and implementation of new things in React have accelerated significantly over the past year. But it still happens publicly, through an RFC process, new features land in the canary, and only much, much later in the stable version.

The issue for the Remix team might be that it wasn't them, but the Next.js team that was the first to utilize the new features of React. We're talking about React Server Components and Server Actions – things that aren't specific to Next.js but are part of React itself, and essentially any meta-framework can make use of them. Remix intentionally and deliberately does not use them.

Experimenting on my users

Features that Next.js is shipping as stable are in the canary release of React.

Yes, exactly! However, the term canary in React has a slightly different meaning than in other projects. The React maintainers state that by "canary," they mean a version of React.js that is ready for adoption in meta-frameworks. The unstable version of React is labelled with the experimental tag. I hope this clarification addresses the doubts.

Too much magic

Contrary to what the article seems to suggest, Next.js has fully embraced the Web APIs. Forms are just regular form elements, API Routes use Request and Response, there's a strong emphasis on fetch, and so on... Definitely has less magic than in previous versions.

In contrast, Remix is heading in the opposite direction:

• instead of standard async/server components they have loader

• instead of standard server actions and "use server" they have action

• instead of standard "use client" they have code splitting

• instead of standard async components they have defer and SSR ErrorBoundary

• instead of standard <form action> they have Form

• instead of standard useFormStatus, useOptimistic they have useNavigation/useFetcher

And for now, they don't plan on changing that.

What's outrageous for many people is that Next.js overrides the fetch function and adds its cache handling to it. Kent compares this to overwriting prototypes of built-in objects by MooTools, which, seems to me, is a complete misunderstanding of the problem.

Adding or overwriting properties in prototypes is indeed problematic for compatibility and the functioning of code originating from different sources. However, wrapping a global function in your code and invoking the original function underneath doesn't create too many issues for end users. Interestingly, Next.js isn't setting a precedent here. For example, Angular overwrites practically all global functions. As for other interesting examples, Cloudflare, a company involved in developing Web APIs, also overwrites fetch in their workers like Next.js to add their cache handling.

Is it perfect? Some might argue it's far from it and I think I agree. But does it work? Yeah, it does. Does it break your code? No; at least not if implemented correctly.

Complexity

The author claims that Next.js is becoming too complex, and as examples of this, he mentions the APIs added to React.js and not Next. Dan Abramov commented on this quite nicely, so I guess there's not much more to add.

Stability

If I understand the intention correctly, the thesis of this paragraph is: "Remix had only 2 versions, so it's more stable than Next.js, which had 14 versions." This is not only absurd but also entirely untrue. Let's take a closer look.

Next.js has been in development since November 2016, celebrating its 7th birthday just recently. The first release of Next.js was... 1.0.1. To follow SemVer, from that point on, every modification of Next.js's public API had to result in a major version bump, meaning 1 to 2, 2 to 3, and so on... Also, note that version 13 was bumped to 14 solely due to the requirement for a higher Node.js version; there were no other breaking changes.

Remix adopted a different versioning strategy. The first public release marked as 0.8.0 was released in 2021. Versions starting with 0., according to SemVer, can introduce breaking changes without the need to bump the major version, so 0.8.0 becomes 0.9.0, not 1.0.0. I've spent some time going through Remix's entire changelog and found 12 breaking changes. Had the Remix team adopted the same versioning model, they would be at version 13 after two years, just like Next.js is after seven. Makes you think, doesn't it?

Additionally, the article seems to suggest that Next.js doesn't provide a migration path from old versions to new ones – but that might just be my mistaken impression. Anyway, migrating from Next.js 12 to 13 took 3 minutes – the changes are minimal, and the new router is entirely optional. The previous routing method will be supported for a long time, for many years. On the other hand, migrating from 13 to 14 took us literally 30 seconds in a production project.

Summary

A year ago, Zaiste and I recorded a video "Remix Marketing Exposed" (in Polish), in which we dissected the Next.js and Remix comparison published by the Remix team. We demonstrated that the content therein is far from being objective and we pointed out multiple biased examples used to present Remix as better, faster, stronger.

Kent C. Dodds' article is certainly more balanced, however, I still managed to find some inaccuracies in it. I hope this helps you build a more balanced and educated opinion about both Next.js and Remix.

Do you agree? Do you think I've made any mistakes in my assessment? Let me know your thoughts in the comments!

PS Kent is selling his Remix course on a website written in Next.js. That's just inconsistent, isn't it?

Links

1. github.com/vercel/next.js/tree/canary/examples/with-docker-compose

2. github.com/vercel/next.js/tree/canary/examples/with-docker-multi-env

3. github.com/vercel/next.js/tree/canary/examples/with-docker

4. nextjs.org/docs/app/api-reference/next-config-js/incrementalCacheHandlerPath

5. remix.run/blog/react-server-components#remix-can-take-full-advantage-of-rsc

6. twitter.com/ryanflorence/status/1686757173202997249

7. github.com/angular/angular/blob/HEAD/packages/zone.js/STANDARD-APIS.md#browser

8. twitter.com/zaiste/status/1717595898312642786

9. react.dev/blog/2023/05/03/react-canaries

10. youtube.com/live/XKeN9WsUAzM