DEV Community: Nitzan Kletter

From Zero to Launch: Key Takeaways from Our Remix-Powered Development Journey

Nitzan Kletter — Fri, 06 Sep 2024 14:33:23 +0000

Around six months ago, I made what some would say is a bold decision by choosing Remix as the foundation for our company's web application. Fast forward to today, and I think it's time to take a step back and reflect on the choices we made. I'll go over the main infrastructure decisions made and sprinkle a bit of practical usage examples on the way.

So, without further ado, let’s jump straight into the highlights and lowlights of this journey — a mix of satisfaction and lessons learned.

Remix (or should I say React Router?)

Highlight: Remix

This is probably the "riskiest" infrastructure decision I made at that time, as Remix was not remotely as popular as NextJS and there weren't many examples of big enterprises using Remix to my knowledge.
Fast forward to today - ChatGPT migrated from Next to Remix just a few days ago!

As I detail in my previous article, I chose Remix for many reasons, some being its simplicity, the "full-stack" aspect (namely, utilizing the remix server as a "backend for frontend") and its great abstractions for routing, data fetching and mutations.

Fortunately, Remix delivered 😎 The framework is intuitive, easy to learn and teach others and ensures best practices are being used, making both writing code and testing it straightforward.

A few months into working with Remix, they announced the official merge with React Router, which I hope will persuade even more people to use it, just like their move to vite did.

It became clear to me in many occasions that Remix was the right call. I'll give one practical example I tackled lately - using a single logger instance in the remix server to be able to log and trace actions and errors across the entire app to enhance our monitoring abilities. The implementation was very straight-forward:

Step 1 - create your logger (in my case I used winston, which works great with Datadog that we use for monitoring)

Step 2 - add your logger to the server's load context (in my case it was express):

app.all(
  '*',
  createRequestHandler({
    getLoadContext: () => ({
      logger,
      // add any other context variables here
    }),
    mode: MODE,
    // ...
  }),
);

Step 3 (for typescript users) - update Remix's default type definitions to include the logger in the app load context

import '@remix-run/node';
import { type Logger } from 'winston';

declare module '@remix-run/node' {
  interface AppLoadContext {
    logger: Logger;
  }
}

Step 4 - use the logger as you wish in any route's loader or action!

export async function action({ request, context }: ActionFunctionArgs) {

  try {
    await someAction();
  } catch (e) {
    context.logger.error(e);
  }
}

Before we conclude this section, I do wish to say that there are also things I wish Remix had but they don't yet, like an implementation of RSC for streaming data/components, and Route Middlewares which would be great for authentication/authorization. Fortunately, it looks like these things (and other cool features) are prioritized in their roadmap, so hopefully we could get them soon!

Tanstack Query. An all-time favorite

Highlight: React Query

Choosing @tanstack/react-query was an easy decision for me, based on my past positive experiences, and it didn’t disappoint this time either. The API is versatile, extendable, and unopinionated in the best way — making it easy to integrate with other tools.

I like it so much that I chose it knowing our internal API is GraphQL-based, instead of the more obvious choice that is Apollo Client. There are many reasons as to why: Tanstack Query has an excellent API, it’s significantly more lightweight than Apollo, and because I didn’t want to depend on a tool that’s heavily tailored to a specific technology like GraphQL, in case we ever need to switch or incorporate other technologies.

Plus, since we're using Remix, I could fully utilize Tanstack Query’s SSR capabilities — prefetching queries on the server-side while still maintaining the ability to mutate, invalidate, or refetch these queries on the client side. Here's a simplified example:

import { dehydrate, QueryClient, HydrationBoundary, useQuery } from '@tanstack/react-query';
import { json, useLoaderData } from '@remix-run/react';


const someDataQuery = {
  queryKey: ['some-data'],
  queryFn: () => fetchSomeData()
}

export async function loader() {
  const queryClient = new QueryClient();
  try {
    await queryClient.fetchQuery(someDataQuery);

    return json({ dehydrate: dehydrate(queryClient) });
  } catch (e) {
    // decide whether to handle the error or continue to
    // render the page and retry the query in the client
  }
}

export default function MyRouteComponent() {
  const { dehydratedState } = useLoaderData<typeof loader>();
  const { data } = useQuery(someDataQuery);

  return (
           <HydrationBoundary state={dehydratedState}>
             <SomeComponent data={data} />
           </HydrationBoundary />
  );
}

Tailwind CSS

Highlight: Tailwind

I was initially skeptical about Tailwind, having never used it before, and because I didn’t quite understand the hype (it seemed to me at first just like syntactic sugar over CSS). However, I decided to give it a try because of its strong recommendations and popularity within the community, and I’m really glad I did. Tailwind’s utility-first approach made it incredibly easy to build a consistent and robust design system right from the start, which, looking back, was a total game changer.
It also pairs perfectly with shadcn, which we used, and together they allowed me to deliver quickly while keeping everything modular and easy to modify later on - a crucial advantage in a startup environment.

I also really like how easy it is to customize tailwind's theme to your needs - for example, overriding tailwind's default scheme:

First, define your colors as variable's under tailwind's main .css file:

@tailwind base;
@tailwind components;
@tailwind utilities;

@layer base {

  :root {
    /* define the primitive design system tokens */
    --colors-blue-100: hsl(188 76% 90%);
    --colors-blue-200: hsl(187 63% 82%);
    --colors-blue-25: hsl(185 100% 98%);
    --colors-blue-300: hsl(190 52% 74%);
    --colors-blue-400: hsl(190 52% 61%);
    --colors-blue-50: hsl(188 92% 95%);
    --colors-blue-500: hsl(190 74% 39%);
    --colors-blue-600: hsl(191 77% 34%);
    --colors-blue-700: hsl(190 51% 35%);
    --colors-blue-800: hsl(191 52% 29%);
    --colors-blue-900: hsl(190 51% 23%);
    --colors-blue-950: hsl(190 52% 17%);
    --colors-gray-100: hsl(0 0 90%);
    --colors-gray-200: hsl(0 0 85%);
    --colors-gray-25: hsl(0 0 98%);
    --colors-gray-300: hsl(0 0 73%);
    --colors-gray-400: hsl(0 1% 62%);
    --colors-gray-50: hsl(0 0 94%);
    --colors-gray-500: hsl(0 0% 53%);
    --colors-gray-600: hsl(0 0 44%);
    --colors-gray-700: hsl(0 0 36%);
    --colors-gray-800: hsl(0 2% 28%);
    --colors-gray-900: hsl(0 0 20%);
    --colors-gray-950: hsl(0 0 5%);
    --colors-red-100: hsl(4 93% 94%);
    --colors-red-200: hsl(3 96% 89%);
    --colors-red-25: hsl(12 100% 99%);
    --colors-red-300: hsl(4 96% 80%);
    --colors-red-400: hsl(4 92% 69%);
    --colors-red-50: hsl(5 86% 97%);
    --colors-red-500: hsl(4 88% 61%);
    --colors-red-600: hsl(4 74% 49%);
    --colors-red-700: hsl(4 76% 40%);
    --colors-red-800: hsl(4 72% 33%);
    --colors-red-900: hsl(8 65% 29%);
    --colors-red-950: hsl(8 75% 19%);

    /*
      ...
    */

    /* define the semantic design system tokens */

    --primary-light: var(--colors-blue-200);
    --primary: var(--colors-blue-600);
    --primary-dark: var(--colors-blue-800);
    --primary-hover: var(--colors-blue-50);

    --text-default-primary: var(--colors-gray-700);
    --text-default-secondary: var(--colors-gray-800);
    --text-default-tertiary: var(--colors-gray-900);
    --text-default-disabled: var(--colors-gray-300);
    --text-default-read-only: var(--colors-gray-400);

    --disabled: var(--colors-gray-300);
    --tertiary: var(--colors-gray-50);

    /*
      ...
    */
  }
}

Then, extend Tailwind's default theme via the tailwind config file:

import { type Config } from 'tailwindcss';

const ColorTokens = {
  BLUE: 'blue',
  GRAY: 'gray',
  RED: 'red',
} as const;

const generateColorScale = (colorName: string) => {
  const scales = [25, 50, 100, 200, 300, 400, 500, 600, 700, 800, 900, 950];
  return scales.reduce(
    (acc, scale) => {
      acc[scale] = `var(--colors-${colorName}-${scale})`;
      return acc;
    },
    {} as Record<string, string>,
  );
};

export const customColors = Object.values(ColorTokens).reduce((acc, color) => {
  return {
    ...acc,
    [color]: generateColorScale(color),
  };
}, {});

const config = {
  // ... additional config
  theme: {
    extend: {
      colors: customColors
    },
  },
} satisfies Config;

export default config;

This is just the tip of the iceberg - you can go on to define custom spacing, text sizing and much more!

Playwright - makes writing e2e tests fun

Highlight: Playwright

Previously using Cypress, I was inclined to choose it, but I kept hearing hype around Playwright and figured I'll research it extensively before making a decision. After comparing Playwright with Cypress, it was clear Playwright is the right choice to make - the fact it comes with parallel execution out of the box, the broader browser support, running times and debugging capabilities - all made Playwright the obvious choice.
And, while this is very subjective, I like Playwright's syntax much better. I find it similar to React Testing Library's syntax, which I like, and I tend to think the tests are a lot more readable, with the asynchronous aspect of the tests being very straight forward, unlike the syntax of Cypress that can cause tests to feel bloated by .then() statements and subsequent indentations.

I think my favorite feature of Playwright is their implementation of Test Fixtures. They provide a clean way to initialize and reuse resources like page objects, making tests more modular and maintainable. Make sure to check out the above link to learn more about it!

Tanstack Table vs AG Grid

Lowlight: (Starting with) Tanstack Table

First off, let me clarify — @tanstack/react-table is a fantastic tool, which is why I was inclined to choose it in the first place, but it wasn’t the best fit for my particular use case. The very features that make it great, like its small bundle size and customizable API, ended up being less relevant to our needs than I originally thought. Despite having full control of the rendering of the Table, I was having some issues aligning its scrolling behavior to our desired outcome (why is it still not possible in 2024 to have a <table> element with dynamic sizing and scrolling on its body only, without resorting to clunky solutions? 🤦).

I soon realized that to deliver my feature fast and provide a good user experience, I needed a table with built-in features like pagination, column resizing and row auto-sizing, and I preferred having those out of the box over full control of the UI rendering. Additionally, since the table only appears after a query is run, I could lazy load it, making the bundle size less of a concern.

I highly recommend using the AG Grid theme builder to customize AG Grid according to your preferences/design system. And, for those using Cypress for their testing purposes - I found this cool plugin that abstracts AG Grid to easily interact with it in tests (sadly I could not find the same for Playwright 😔)

Final thoughts

Looking back, I definitely feel a sense of pride in what we’ve accomplished. Not every decision was perfect, but taking the time to research and find the most fitting solution was worth it. And when things didn’t go as planned - it challenged us to think critically and adapt quickly, which is important no less.

Please let me know in the comments if there’s something you’d like to see explored further in future articles.
Here’s to more lessons learned, personal growth and having fun along the way 💃

Choosing a Frontend framework in 2024, a practical tale

Nitzan Kletter — Tue, 06 Feb 2024 17:14:51 +0000

Introduction

I find that one of the hardest parts of starting a new project that requires a user interface is having to choose between the endless options that exist in the front-end ecosystem - React, Vue, Angular, Svelte, HTMX - to only name a few.

I bumped into this recently when attempting to choose the technology for a new upcoming work project. So, I thought I'd document my thought process in hopes of sharing my findings.

I hope that this article will be of value to devs in a similar position, and also to those who have little FE experience and want to understand the current challenges in the ecosystem, some solutions that exist and what each brings to the table.

What's in this article

I will compare 5 notable FE frameworks/libraries that are either popular, on-the-rise, or both:

ReactJS, and the React-based frameworks NextJS and Remix
SolidJS
HTMX

I will give a short description of each, as well as a few pros/cons as I see them for my own situation, and finally, I will share my decision.

I am taking into account that in the near future more people will join me in maintaining this project as it grows in scale, so I'm looking for a solution that will seem easy to kickstart but also to maintain and grow.

About myself

I'm Nitzan, and I've been a (mostly Web) developer for the past 7 years. I come from a hands-on cyber background but found that my passion is in the intersection between technology and the user experience, hence my passion for frontend. Over those 7 years I worked on multiple cybersecurity products, generally focusing on threat detection and asset visibility, and will continue my journey with a new startup in the very near future 🙌

TL;DR plz!

Skip to the final section at the bottom :)

Dictionary

If you come from a FE background you can probably skim through this section, but I think it's necessary for understanding the bigger picture in the comparison later.

SPA = Single page application; A website that re-renders its content in response to navigation actions (e.g. clicking a link) without making a request to the server to fetch new HTML
CSR = Client side rendering; A web development approach where the rendering of a webpage occurs primarily in the browser using JavaScript. This approach is closely associated with SPAs.
SSR = Server side rendering. The initial content page of the website is generated on the server, so that browser can download a page with HTML content already in place. Updates to the content are still handled in the browser.
SEO = Search engine optimization; It's the practice of optimizing websites to improve their visibility and ranking in search engine results pages. When SEO is important, SSR approach is preferred over SPA.

If you couldn't tell, I wrote this "joke" myself. Props to https://www.makewordart.com/

DOM = Document Object Model; A programming interface for web documents. It represents the browser page as a tree of objects, where each object corresponds to a part of the page. Via the DOM, programs can change the document structure, style, and content (objects/elements within).
VDOM = Virtual DOM; A concept implemented in libraries like React. It's a lightweight copy of the actual DOM. The VDOM allows for efficient updating of the web page, as it involves only re-rendering components in the VDOM when their state changes, therefore optimizing rendering (and potentially performance), and providing a smooth(er) user experience.

DOM vs VDOM, from this article

UI component = a self-contained and reusable piece of code that represents a part of the user interface (e.g a button or a form)
JSX = Syntax extension to JavaScript, combining markup (HTML) with the power of javascript. This syntax is commonly used in the React ecosystem, and UI components in React are usually written with JSX syntax.
State Management = the process of managing the dynamic data, or "state", that controls the behavior and appearance of an application and its UI components. This state can include user inputs, server responses, and other variables that determine what the UI displays at any given moment.

stateful UI component lifecycle in React, from this article

Lets compare!

React

https://react.dev

React is a JavaScript library used for building user interfaces, primarily SPAs (at least historically). It allows developers to create reusable UI components, manage the state of these components, and efficiently update and render just the right components when data changes (using the VDOM approach).

Upsides:

It has an incredibly large developer community, leverages widely-used JSX syntax, and its idiomatic nature to JS/TS can be a lesser learning curve for people coming from the JS ecosystem.
It has proved itself to be a very stable option for many years now and a favorite among web devs, and therefore its not surprising that the job market favors it (and, while this isn't strictly a "technical" reason, it is still important when focusing on long-term maintainability)

Downsides:

React is a UI library at its core (not a framework), therefore it requires, by definition, the usage of additional tools to reach its full potential. While this "unopinionated" approach makes React more flexible on paper, it can make its DX for large scale applications worse compared to meta-frameworks like NextJS, that provide more out-of-the-box features and therefore requires less code to be written.
As of writing this, there's a lot of criticism of React and where its heading. Apparently, React themselves recommend using a meta-framework and not just "plain React" in their "getting started" page, which is... interesting. I particularly resonated with this article, and also enjoyed this funny video, which I think explains the current turmoil in the React ecosystem (and FE ecosystem in general) pretty well.

Summarizes the atmosphere pretty well

Solid

https://solidjs.com

Solid is a JS library for creating user interfaces. Instead of using a Virtual DOM, it compiles its templates to real DOM nodes and updates them with fine-grained reactions. While React is well known for its declarative architecture, SolidJS takes a different approach to state management and reactivity.

Upsides:

Its bare-metal, minimal abstractions approach allows for direct access to the DOM, making it easy to use native JavaScript libraries.
It is more performant and efficient than React - when there is a change in data, it updates only the necessary components (meaning in cases of deeply nested components, it would perform better than React's VDOM).

Downsides:

Both because SolidJS is relatively new (created in 2018) and because of its relatively-small community adaptation, there's limited documentation and less available tools and plugins. These reasons, especially compared to React's mature ecosystem and community support, makes SolidJS less appealing, especially when building large scale, complex applications.
While SolidJS provides efficient SSR capabilities, it does not not offer a built-in, comprehensive solution for hybrid rendering similar to Next.js, which seamlessly combines Server-Side Rendering (SSR), Static Site Generation (SSG), and client-side rendering within the same application framework.

HTMX

https://htmx.org

HTMX is a library that allows you to access modern browser features directly from HTML/markup, without having to utilize JavaScript. It encapsulates AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML using attributes, so you can build modern user interfaces with the simplicity and power of hypertext. With HTMX, elements can now issue an HTTP request, any event can trigger API requests (not just clicks/form submission), and any element can be the target for update by the request (not just the entire window).

Upsides:

Has the potential to simplify the tech stack dramatically - no more different BE and FE frameworks and duplicated utility functions, straight-forward deployment.
Developer velocity can be greater by eliminating the need to juggle between FE and BE for small changes - no more need to understand the entire code architecture to follow a feature end-to-end (just use "go to definition"!).

Downsides:

HTMX, while on-the-rise, remains a smaller community compared to React. Its adoption by the job market and web developers, particularly for large-scale applications, is still limited today next to older frameworks such as React.
HTMX still doesn't fully replace existing market technologies, especially in developing interactive, complex applications. It has limitations such as client-side interactivity, lack of reusable components and type safety. These factors are essential for scalability and maintainability of applications as they expand.

NextJS

https://nextjs.org

NextJS is a framework built on top of React that enables functionality such as SSR and SSG, which are not readily available in vanilla React. It implements a set of conventions for structuring React applications as well as commonly needed features like automatic code splitting, optimized prefetching, and route preloading out of the box, offering a streamlined setup for building fast and scalable web applications.

Upsides:

It's a stable, well-established framework with a mature ecosystem, has a large community and has been going stronger and stronger for years. Even though its a meta-framework, NextJS still feels in-line with how React themselves are evolving the library, being the first mature implementation of React Server Components, and as I said above, the first option that's recommended in React's "getting started" page.
The conventions and out-of-the-box features implemented by Next make it a very robust choice, especially fitting for larger-scale applications.

Downsides:

Next has a relatively big learning curve - both needing to learn about the React ecosystem as well as Next's own robust ecosystem. Even developers that have used Next previously (most likely with the Page Router) could still have a big learning curve getting used to the App Router paradigm, which has been deemed stable in Next's v13.4 release in May 2023 (just less than a year ago).
It's owned by Vercel, meaning it also leans towards Vercel as a hosting platform and raises concerns for vendor lock-in. While it is possible to deploy without Vercel, I tend to prefer solutions that allow for easy deployment in whichever way ends up being chosen.

Remix

https://remix.run

Remix is yet another meta-framework built on top of React, which similarly to NextJS, also implements many common features and use-cases out-of-the-box such as enhanced data loading and caching mechanisms, optimized network requests, built-in state management for forms and more.

Upsides:

Remix places a strong emphasis on leveraging web fundamentals, aiming for accessible and performant web applications, and features a very straight-forward, declarative syntax for data fetching and data mutations, with the concepts of "loaders" and "actions". This relatively low learning curve (especially for devs with React knowledge) makes it a very interesting candidate.
Remix seem to fair better than NextJS in performance and build-related aspects (serving static and dynamic content fast even on slow networks, stable build times, etc), and the framework itself focuses on flexibility as to not sacrifice performance or require application architecture changes when your data scales.

Downsides:

As of February 2024, Remix has yet to implement React Server Components (which seems to be the future of React), and has a smaller community relative to other React meta-frameworks, specifically Next, making Next the more obvious and "safe" choice for a new large-scale application focusing on maintainability.
Its been acquired by Shopify, which draws skepticism that stem from concerns about the future independence and direction of Remix under Shopify's ownership (especially because of its open-source nature)

Some more thoughts on Next vs Remix

As I wrote above, Next indeed seemed like the more obvious choice at first glance, but I thought it would be right to try out both before choosing one over another.

After experimenting with both, I can say that writing in Remix was a very smooth and pleasant ride, while getting used to the new App Router paradigm in Next was not too enjoyable for me. It seemed, with Remix, I could spend 2 minutes on reading documentation and get the application up and running, while with Next I had to spend a lot more time reading about the in-and-outs of the App Router and React Server Components just to get a basic example working.

So, after trying it out myself and doing a lot of reading (especially this great article), and to my own surprise, I actually felt more comfortable choosing Remix over Next, and I look forward to seeing how they decide to implement React Server Components in the future.

Final Thoughts

I'll be picking Remix for a few main reasons:

It's built upon the well-known React ecosystem and implements great abstractions for routing, data fetching and mutations, and I find it has a very small learning curve for devs with previous React knowledge (which is common as its favored by the job market).
I like how flexible the framework is (regarding deployment and otherwise), and I particularly love their philosophy and the emphasis they put on web fundamentals.
Remix fits great to our planned architecture - since the main business logic will be written in a non-JS language, we will use Remix in a "BFF" (Backend for Frontend) architecture, which is also a strategy recommended by Remix themselves.

That said, I'm extremely intrigued by HTMX because of their innovative approach, but I think that at its current state and community adaptation it's too much of a risky choice. I will definitely try out HTMX for my next personal project though!