Forem: Junsu Park

My 2023 Web Development Highlights

Junsu Park — Wed, 27 Dec 2023 21:53:35 +0000

Web technology is constantly evolving and new front end libraries and frameworks are constantly being released. New primitives, improved developer experience, and so many headless UI libraries. It’s hard to keep up sometimes. Let me make that easier for you by sharing my highlights from this year.

CSS - :has selector

The Chrome Team has written a beautiful blog post that lists all the changes that CSS had this year. Go check it out and skim through it at least.

What I (and everyone else) loved and would probably use the most is the new :has selector. You can now style the parent element based on some condition present in its child elements without JavaScript. For example, give it a background color if a child element is an input and has the :checked state.

From Tailwind Connect 2023 Keynote

Or as Web Bae has demonstrated, create a CSS-only dark mode toggle.

I love when CSS adds features that usually required workarounds in JavaScript. Speaking of which…

HTML - Exclusive Accordion

Sadly there’s no pretty blog post detailing all the changes to HTML like the CSS one had. In fact, I had a hard time figuring out when certain things were released. There is this State of HTML 2023 Survey that asks people about their familiarity with the newer features and changes. The survey is over and I recommend perusing it because I learned a lot.

For example, I did not know you make an accordion element by wrapping the element around elements.

The survey has not been updated because it says no browser has implemented the exclusive accordion yet. But as of Chrome 120, it is! Just give the the same name, and voila! The behavior that required JavaScript is now native to HTML.

JavaScript - new array methods

The new ECMAScript 14 came out this year and I would love to check it out but it kills my browser every time I try to load it. So instead I relied on reading blog posts about it. Please check them out:

The main highlight are new array methods. These include:

findLast
findLastIndex
toReversed
toSorted
toSpliced
with

The last 4 allow you to change array by copy, which follows the same behavior as .map and .filter, resulting in less confusion and also following functional programming patterns. And according to MDN, all these methods have already been implemented by browsers!

Web APIs - View Transitions API

I’d describe Web APIs as a set of standardized features and behaviors that are implemented through a combination of HTML, CSS, JavaScript, and browser APIs. And View Transitions API is a great example of that.

This API allows you to seamlessly transition between “different DOM states while also updating the DOM contents in a single step”. Such behavior that would have required complicated and verbose CSS and JavaScript is now available in the DOM. Furthermore, the transitions can be controlled by JavaScript and CSS.

This API has been implemented by Chrome but is still being worked on by the W3C. Still, its current state is quite exciting already.

UI Component Libraries - ShadCN

I wrote an article about headless UI libraries so feel free to skim that to get up to date.

On Dec. 20th, React Aria has updated their landing page for the GA release of React Aria Components, which is built on top of React Aria hooks.

Also on Dec 20th, Lemon Squeezy released Wedges, which is built on Radix UI and Tailwind.

Then on Dec 22nd, shadcn also updated shadcn/ui, adding the following new components:

Drawer
Carousel
Pagination
Toast
Resizable

Before, I was team React Aria. But as time went on, I have to say shadcn has outdone everyone. It has more components than the others and are very easy to use. The copy-paste approach that allows your codebase to own the component code instead of relying on an external package and have full control over it is really what won me over. And since copy-pasting manually is tiring, the CLI does all that work for you. And it works amazingly well. There’s a reason he was hired at Vercel.

I still have to try out Wedges, but for 2023, shadcn/ui was the clear winner.

Conclusion

So these were the highlights of 2023 for me. I need to take some time and tinker around with all these new features and updates to really solidify them in my head.

I thought about writing about my highlight for UI framework (React, Svelte, Vue, Solid, etc) and metaframework (Next.js, SvelteKit, Nuxt, SolidStart, etc) but I need more time with all of them. Though two things stood out to me as they gained more adoption by these frameworks: signals and server actions. Once I have enough experience and wisdom (ie. read the opinions of people way smarter than me), I'll share mine.

All in all, I’m excited for what 2024 has to offer. Let me know what your highlights were!

4 Things I Have Read That Are Good for Web Devs

Junsu Park — Thu, 16 Nov 2023 00:32:42 +0000

I usually write about what I made and learned, but this time, I wanted to share knowledge I gained from other people. I think these 3 articles and 1 documentary will help you become a better web developer.

Rules of Margin Collapse by Josh Comeau

CSS rules are ~~frustrating~~ are a nightmare. What is even more frustrating are behaviors that are not well documented. One of these are CSS margins. Here’s an example: did you know margins only collapse vertically?

Thankfully, Josh Comeau has written all the weird arbitrary rules that margins have. I personally won’t be using margin unless it’s for one-off spacing that Flexbox gap wouldn’t work for.

The Uphill Battle of Memoization by TkDodo

React re-renders are hard to tame. Any state change in a component will propagate re-renders to all its children components. You may already know some ways to isolate re-renders:

Move state down
1. If state can’t be moved down, use a global state management with atomic picks to isolate re-renders
Pass the component as a prop or children

There’s also React.memo but TkDodo warns against using it for very good reasons. For example, using inline props can easily break it since inline functions and objects are recreated when the component re-renders.

Operating without Foreign Key Constraints by Planetscale

This article is from the Planetscale’s documentation, which is a MySQL serverless database service. Planetscale explains it doesn’t support foreign key constraints because it interferes with Online DDL operations and it becomes harder to maintain over multiple database servers. By enforcing referential integrity at the application level instead of at the database level, Planetscale can benefit from online DDL and unlimited scaling through sharding.

Initially I thought this was a weird approach but I agreed with it after reading through the page. I love it when developers rethink best practices.

How a Small Team of Developers Created React at Facebook | React.js: The Documentary by Honeypot

Speaking of rethinking best practices, this 76 minute documentary goes into the origin and early public reception to React when it was released as open source. The initial reception was extremely negative; people hated JSX and thought React broke separation of concerns.

Thankfully, early adopters started using React, few in production, and an open source community quickly grew around React, which the React team cultivated by fixing bugs, releasing new features, and organizing meetups. I found this documentary inspiring for two reasons.

I’m now a full stack engineer with a year of professional experience under my belt and I have spent almost all of my time deferring to other people’s opinions on how things should be built. And I should since I don’t know much. But now as I gain more experience, I am starting to become more opinionated. And the fact that traditional best practices have been broken and innovated upon gives me confidence to experiment and try out new approaches.
The strength of the open source community makes me want to contribute to open source projects. I think it’s beautiful to see really smart people passionately work together for no compensation just because they love building cool things. And I want to be part of that.

Next.js 14

Junsu Park — Tue, 07 Nov 2023 04:11:17 +0000

I attended the Next.js Conference 2023 in person and I had a great time listening to the talks, talking to people way smarter than me, and getting free food and swag. The main theme of the conference seemed to be about getting people to transition from the Pages Router to the App Router. I already use and love the App Router so I did not learn much from those kinds of talks.

If you are still on the fence about App Router and React Server Components, then I recommended watching this talk by Sam Selikoff, who gives great talk that explains how these features execute React’s goal of composable UI.

The keynote about Next.js 14 by Guillermo Rauch was great. This major release is focused on improving current features and aiming for stability. You can read the official blog post here for more in-depth read. I am excited that Server Actions are now stable and am looking forward Partial Prerendering.

Server Actions

First off, if you don’t know what React Server Components are, I suggest reading up on it before continuing. I also wrote an article about it and NextJS features, including Server Actions, with lot of simple examples and pictures.

Server Actions allows you to invoke server functions from the client without needing to explicitly define an API endpoint and write a request to that endpoint. NextJS will handle all of that for you. You can also send data from the client to the server function.Simply mark a function with “use server” at the top and everything inside will only live and execute on the server.

There were people pushing back on Server Actions with the usual worry about separation of concerns, which is expected whenever React does anything. I agree with what React and NextJS is doing - concerns should be component based. I personally believe this improves DX through easier mental models and improved code maintainability. All the code required to render some piece of UI will all be in one file (especially if you use CSS utility libraries like Tailwind).

Other frameworks also have ways of defining server-only code, such as Solid and Qwik. And I’m excited to see how this new paradigm grows.

Partial Prerendering

I recently wrote a basic summary of server side rendering, and in it, I talk about the difference between build time - more accurately, ahead of time - and request time. There was one thing I did not mention for sake of conciseness which is that it’s all or nothing. If your page was static but had just one tiny part that needed to be dynamically rendered, you either had to:

Pre-render it all at request time

Or pre-render everything else ahead of time and make the client fetch the dynamic data and render it themselves.

What if there was a way to render all the static content, such as the navbar and footer, ahead of time? All the static content will be served immediately when the client makes a request. Then the dynamic content, such as product information, can be rendered and streamed in later. Partial prerendering is exactly that.

No waterfalls. No new API - this is all done through React Suspense.

This feature is not released yet but I’m very excited to try it out.

Conclusion

Next.js is an already amazing production-grade framework with great developer experience and it keeps outdoing itself with every release. They fully enable React to be used to its fullest extent in the easier manner possible. And I can’t wait to see what comes next.

Highlights from ViteConf 2023

Junsu Park — Sun, 22 Oct 2023 16:40:53 +0000

I spent 12 hours watching ViteConf 2023 talks to learn lot of cool new things about web dev, open source softwares, and front end technology. You can find the list of talks here. I became aware of so many amazing web dev tools and frameworks to improve developer experience. I’m going to highlight the talks I personally found most interesting.

Stop Writing Docs; Start Helping by Sarah Rainsberger - Docs Lead at Astro

Sarah talks about how to write great docs with many concrete examples and advices. I think this talk is beneficial to everyone because great docs is how you get people to use your software. “Write less, help more” is the central idea of the talk. I screenshotted some slides with great advice.

Road to Open Source: The Set Theory by Anthony Fu

Anthony Fu talks about converting OOS that work universally instead of one specific use case or software.

Anthony and his collaborators talks about building tools in Nuxt that allow server functions of apps - server side rendering and server APIs - to to work with specific features of cloud providers, such as edge rendering and serverless functions. The tool auto detects each platform and allows apps to be written isomorphically.

They realized this is a problem every metaframework has to deal with and is not specific to Nuxt. So they extracted those tools into a standard tool called Nitro - a universal server builder. With Nitro taking care of the details of dealing with servers, it actually allows Nuxt to have more clear architecture for handling server side rendering, APIs, etc.

Now Nitro has been adopted by other metaframeworks such as Analog and Stacks.

Similarly, they built first-party integrations to allow Nuxt to be compatible with Webpack and Vite for bundling. However, the architecture and plugin ecosystem are quite different. For example, if you want to add some transformation to some modules in the pipeline, that would require implementing the logic twice for each-plugin. That doubles the work as well as the effort for community modules to support it.

Thus they created unplugin, a universal plugin interface, that now has its own community and expanded the scope to support Rollup, Esbuild, and potentially more in the future.

Qwik: Performance is a Human Design Issue by Manu Martinez-Almeida

Manuel explains performance differences between frameworks thoroughly and concisely with great visuals. He shows how Qwik is the first O(1) framework with regards to hydration. I highly recommend watching the whole thing.

Qwik does not ship any JavaScript initially. Everything is static. When you click on an interactive component, then the browser will download the JavaScript. This is called Resumability.

Conclusion

I’m definitely going to try out Qwik for its unique hydration approach. Also it’s re-rendering approach is interesting as well, somewhere between React and Solid - solving for performance and mental overhead. I recommend reading this article about Qwik’s Signals.

I’m also going to NextJS conference on 10.26.2023 and I’ll share what I learned from that as well. Follow me on LinkedIn or DEV for more updates about web dev and full stack engineering!

Server Side Rendering: what’s SSR, SSG, ISR, build time, request time, hydration mismatch?

Junsu Park — Fri, 20 Oct 2023 20:40:45 +0000

You may have heard about server side rendering and may be bit confused by all these terms being thrown around. And is this related to React server components? (No, kind of, but not really).

Here’s a brief and maybe bit oversimplified explainer on what all these concepts mean.

Server Side Rendering

Client side rendering sucks 👎 Why?

Poor initial page load - big bundle and rendering takes time
Poor SEO - web crawlers only get blank HTML

Solution? Make server do most or all of the work. 👍

Fast initial page load
Great SEO - web crawlers get HTML with content

I will refer to server side rendering as ****pre-rendering**** also. The terms are synonymous; the pre-rendering generates HTML before the client, and the computer this happens in is the server. Pre-rendering is also a less ambiguous term since SSR can have a different meaning (explained below).

Question: when should the server do the rendering work? Initially when the server starts or when the client makes a request?

Build Time or Static Site Generation (SSG)

(Also called static rendering)

This is when the server starts up and pre-renders all the pages by creating all the HTML files and Javascript bundles - the content - beforehand.

This is great for content that will not change:

Portfolios
Marketing pages
Documentations
E-commerce product listings

Sites like Apple changes every few months or so, which is perfect for SSG

If a page requires dynamic data, such as updating the stock of a product, that can be done through client-side data fetching. The stock count will not be in the pre-rendered HTML but information like this can be excluded without impacting SEO or performance.

If the page can be pre-rendered ahead of the user’s request, then this approach works.

Request Time or Server Side Rendering (SSR)

What if the page ***can’t*** be pre-rendered ahead of client’s request? For example, take the home page of news sites such as New York Times, Los Angeles Times, etc. There will be new stories to display throughout the day. And if the user has an account and selected their preferences for topics, then the home page will have to be modified in regards to that as well.

Thus any pre-rendered content will likely be outdated by the time the client makes a request.

Hence, pre-rendering at request time. Also called dynamic rendering or server side rendering (Yes, it’s a bit confusing how developers reuse the same term to mean different things. Looking at you, NextJS docs 😠). Note: I don’t know what those sites do, this is just an example of where request time pre-rendering can apply.

Incremental Static Regeneration (ISR)

Well, pre-rendering every time the user makes a request can be costly. The news probably has not changed significantly within a minute. And if it did, they can wait and go touch grass.

Thus the concept of ISR: pre-render the page again at intervals.

Let’s say interval is X seconds
Client makes a request
Server pre-renders the content, caches it, and sends the content to the client
Client makes a request within X seconds
Server sends cached content
Client makes a request after X seconds
Server invalidates cached content, pre-renders, caches, and sends content

Check back in a few hours later and the home page will be different

On-Demand Revalidation

What if you have very static sites that still needs to be updated from time to time but not:

Every time the client makes a request?
At time intervals?

For example, you need to change the metadata of a product on your e-commerce site - the price, description, category. If your database or headless CMS updates, this will make your server pre-render the relevant pages again and cache the new content.

This product page won’t change often and is perfect for on-demand revalidation.

Hydration Mismatch

This occurs when the pre-rendered HTML has a mismatch with the rendered content DOM in the server. This can occur for variety of reasons such as outdated cached Javascript or time differences. Here’s a very simple example to understand how this happens:

export default function Component = () => {
  return <div>{Math.random()}</div>;
};

This is a simple server component in NextJS that is pre-rendered (server components are separate but related to pre-rendering). It outputs a random number.

Now I convert the server component into a client component by marking it with ‘use client’.

'use client'
export default function Component = () => {
  return <div>{Math.random()}</div>;
};

This means that this component will still be pre-rendered by NextJS but this code will also be sent to the client.

Uh oh, there’s a mismatch. Math.random() executed again in the client and obviously output a completely different number. NextJS’s dev build displays errors for us as well.

Why does this matter? The client creates an internal representation of the page and maps the internal representation to the DOM elements of the pre-rendered HTML. This allows it to attach event handlers to the correct DOM elements. If there is a mismatch, interactivity can be broken or UI components can be duplicated. The example was a text mismatch but there can be element mismatch as well.

Conclusion

Client side rendering is still required for adding interactivity and displaying dynamic data. But it should no longer be used to render entire pages. Hopefully I explained these concepts well and if I didn’t and you have questions, please ask!

You can follow me on LinkedIn or DEV.

3 great Typescript libraries to speed up your full stack development

Junsu Park — Fri, 13 Oct 2023 10:22:26 +0000

I have been hard at work turning my Instagram clone project from a front-end mock to a full stack application. It’s still a ways off but I wanted to share new libraries I picked up:

React Hook Form
Zod
Prisma

They’re very popular and I must say their popularity is well deserved. They provide amazing developer experience and type-safety, which reduces my mental overhead and enforces good code structure. I will always have these libraries in my tech stack from now on until better ones come along.

React Hook Form - client-side validation that reduces boilerplate code

Forms require lot of boilerplate - validation, error state, submitting state, default values. This makes writing forms very error-prone, especially as the number of inputs increases. This library handles all of it for you. It can validate the input values without causing un-necessary re-renders. If an input value is invalid or missing, trying to submit the form will put focus on to the input.

Additionally, you can extract form state from the useForm hook to render error messages or disable the submission button when the form is executing its onSubmit function.

If you’re interested in trying it out, here’s a great tutorial by ByteGrad, who demonstrates the reduction in boilerplate thanks to React Hook Form.

Zod - schema validation for client and server

However, what if you need more complex validation than just checking if a value is string or number? Zod is a schema declaration and validation library. Here’s a code I’ve written for a sign up form for new users.

All the required inputs here are strings, which could have been reinforced with regular TypeScript types. But Zod can also reinforce regex pattern matching, minimum and maximum character requirement. An error message can be provided for each requirement as well. And a TypeScript type can be generated with the z.infer method.

Now all you need to do is change the schema and the type will change automatically.

Define the generic type and pass in the schema with a zodResolver - a package that integrated Zod and React Hook Form. Now errors will update with the error messages I provided. Also, Intellisense provides autocompletion!

Update the input and the form will only re-render when input is valid (or invalid again), not on every input change. It does this with Proxies, which allows subscribing to value changes.

Here’s what’s really great about Zod: you can use the same schema on the server. Which is great because you should always validate on both the client and the server! Who knows what malicious actor will bypass your client-side validation. Use the parse or safeParse method in your API endpoint.

One source of truth. Less error-prone, type safe, elegant.

Prisma - TypeScript ORM

Unlike RHF and Zod, Prisma is a very big library and it’s hard to go over everything in detail. To be concise, I’ll tell you what I used Prisma for.

I created a database schema with Prisma’s own syntax. I installed their official VS Code extension to enable Intellisense, which provided errors for constraints and relationships. It also warned me to add an index for a foreign key field to improve performance.

Then I generated Prisma client and TypeScript types for all the models with npx prisma generate. In the example below, I queried the Post table to return 100 posts and join it with other tables. Autocomplete prevents me from making mistakes with my query.

TypeScript knows the shape of the query object. I don’t need to validate the query response anymore.

I connected Prisma to a database of my choosing and pushed the schema to the database, which is Supabase. With Prisma’s CLI command npx prisma db push, it generated all the tables for me.

I realized I neglected to add certain fields required for an entity. No worry, I just update the Prisma schema file, re-run npx prisma generate and npx prisma db push. Supabase is updated for me. If any table must be cleared of its data, Prisma will warn me and ask if I want to proceed.

Supabase has a visual database but if it didn’t like most CLI apps, I would run npx prisma studio and it would provide one for me on a localhost port.

Prisma has accelerated my backend development. I don’t have to write complex and long SQL strings that are error prone. I have autocompletion and type-safety to prevent me from making mistakes.

Conclusion

I hope I convinced you to add these 3 libraries to your stack. These libraries work at any scale and helps you write clean code that is self-documenting.

Accessibility and Headless UI Libraries - Adobe, Radix, Tailwind, MUI

Junsu Park — Sun, 24 Sep 2023 12:31:11 +0000

There are lot of UI libraries out there. Their goal is to speed up development by providing a design system and accessibility right out of the box. The design system comes with a tradeoff: it helps speed up development since the developers don’t need to create their own design system from scratch but it can be very restrictive with customization, which makes sites built with that library look similar to each other. It’s easy to identify which sites were built using Bootstraps, for example. This tradeoff is acceptable for developers who are not good at frontend and their sites’ features rely more on the backend.

Lately there has been more headless (i.e. ‘unstyled’) UI libraries that provides the accessibility with very minimal or no styling so devs can style it however they want. They provide features such as keyboard navigation, labels and attributes for screen readers, and focus management I have been perusing through some of them to incorporate into my own tech stack. Here are 4 libraries I looked at and my thoughts on them.

Tailwind - Headless UI

Component based - must be assembled in a certain way
Incremental installation - can install install individual components instead of whole library
Minimal - only 10 components at time of writing
Tailwind has Tailwind UI, which is styled and fully customizable components but with no behavior

Radix UI - Primitives

Component based
Incremental installation
Radix UI Themes - minimally styled component library that is more of a superset of Primitives
ShadCN UI - 3rd party minimally styled component library built with Radix Primitives

Adobe - React ARIA

Provides hooks that returns props to be assigned to corresponding elements
Documentation explains thoroughly how to use the hooks and the problems they solve
Complete visibility and control over DOM structure
State management decoupled from accessibility behavior - provided by React Stately hooks
React Spectrum - component library built with React Aria and React Stately - documentation is confusing since there is a component section in React Aria that is nearly identical to React Spectrum
NextUI - 3rd party minimally styled component library built with React ARIA

Material - Base UI

Behavior and accessibility logic decoupled from Material UI
- Material UI - completely styled component library and follows Google’s Material Design design system
Provides components like Tailwind and Radix
Provides hooks like React Aria
In beta - certain components are not complete or are experimental. Documentation is lacking, especially for hooks.

My winner is React ARIA

My main problem with the other libraries is that I have to learn and think in their design system whereas with React ARIA, I’m thinking in native HTML.

For example, Radix’s Dialog component has 8 pieces: Root, Trigger, Portal, Overlay, Content, Title, Description, Close. It abstracts away the state management, logic and behavior, and HTML elements with these pieces that I have to assemble in a specific way.

And tweaking their behavior is exposed through certain props, not DOMAttribtues.

With React ARIA, it’s a lot more code I have to write but working with semantic HTML and attributes makes me a better frontend engineer overall. With Radix, Tailwind, and Material, I only get better at using their library - knowing Dialog.Content must wrap around Dialog.Title and Dialog.Description does not transfer to anything else. Additionally, I can intuit what the hooks do and see what their return values do. It reminds me of React Hook Form in this way.

This is a lot more boilerplate than other libraries but it makes more natural sense to me.

As Tailwind makes you think in native CSS, I want to think in native HTML elements as much as possible.

Also, React ARIA documentation is superb - it lists all the features of the hooks and provides an anatomy diagram for each UI component.

Conclusion

Thinking about accessibility is hard. Implementing them is harder. Keeping up with guidelines and thinking of different devices take up lot of time and research. It requires lot of boilerplate code and is very easy to get wrong. That’s why I highly recommend using one of these libraries so people that require on assistive technology to browse the internet can do so easily on your site. If React ARIA seems too daunting, I recommend Radix Primitives since it has more features and documentation than Headless UI and Base UI.

Instagram Clone Project Part 1

Junsu Park — Mon, 04 Sep 2023 17:16:19 +0000

Link to Instagram clone project

Tech Stack: NextJS + React, TypeScript, Tailwind, Zustand, Radix UI + ShadCN UI, html-react-parser

I spent the past 4 weeks working on an Instagram clone to develop my front end skills. I challenged myself to build more features than my Twitter clone project. The features I focused on were:

Modal routing
Virtual List
Dark mode
Carousel
Custom video player (shoutout to Web Dev Simplified for his tutorial!)
Autoplay behavior
Text parsing for hashtags and @ links

Please check out the project and let me know what you think. I tried to mimic Instagram as closely as possible. I also share my thoughts about implementing the features above in the post descriptions. If you have any questions, feel free to ask me in the comments of this article!

This is only part 1 of the project. I will turn it into a full stack app with the following features:

User Authentication
Reels
Messenger
Stories
Notifications
And many more

I’ll also implement end-to-end testing and fix some bugs (NextJS modal routing has a known issue I need to work around). I would have fixed these issues before deployment but I spent too long on this project and I needed to ship it for my own sanity 😭.

I’ll also implement the following optimizations and compare the differences in speed:

useMemo
useCallback
React.memo
React.lazy + Suspense
React Hook Form
Loading UI

Follow me here on LinkedIn or DEV to follow me on my journey to building robust web apps!

Learning NextJS and React Full Stack Features

Junsu Park — Thu, 10 Aug 2023 01:05:34 +0000

Currently there are many full stack frameworks or metaframeworks that build on top of a UI library. NextJS and Remix for React, SvelteKit for Svelte, Nuxt for Vue, and SolidStart for Solid. There's even a framework called T3 that builds on top of NextJS - just frameworks on top of frameworks 🤯, but I'm getting ahead of myself. These frameworks vary in terms of opinionated they are and usually provide the following:

💻 Enhanced developer experience via default tooling and configurations (Eslint, TypeScript, compiler, optimizations, etc)
🚏 File-based routing and nested layouts
💪 Backend server that provides server-side rendering, API endpoints

NextJS is extremely popular due to how robust it is and is the recommended way to build React apps by the React devs. The NextJS team and React team work closely together to bring the next evolution of web technology. The current aim is to reduce the amount of client side Javascript and pre-render as much as possible in order to improve SEO and speed for users. This also helps reduce risk of exposing private APIs and improves developer experience. I spent the past week tinkering with NextJS to learn about these features and here's some of what I learned. I'll try to be concise and bring up only salient points.

No more installing 3rd party libraries and losing hours trying to configure them all together to make them work. Batteries are included here!

Brief background about me: I'm became a full stack engineer last year and have been working at Wells Fargo since January 2023. I love learning about new web technologies, design patterns, and building things.

1. Server Side Rendering

All components by default are pre-rendered on the server. This means the HTML sent to the client will have contents of the app. Previously, client side rendering was the default, in which a barebones HTML and JS is sent to the client after which JS takes over and renders the app. This was not good for two reason:

Bad for SEO - web crawlers 🤖 would not see the actual content since the HTML is empty
Slow for users if JS bundle is big 🐌 - users would see a blank site until the JS code was downloaded. Worse if data fetching then needed to be done afterwards to update UI - resulting in big waterfall and blocked UI. And slow initial load speed can lose customers.

With SSR, both of these problems are solved. Static content and data are present in the HTML. Only dynamic data (ie. requires hydration) is not present.

'use client'
import { useEffect, useState } from "react"

export default function Page() {
  const [text, setText] = useState("This will also be in source page")

  useEffect(() => {
    setText("But this won't since it can't be pre-rendered")
  }, [])

  return <div>
    <div>This will be in source page</div>
    <div>{text}</div>
  </div>
}

Turned throttling on to show the initial HTML sent to client

After JS is downloaded and takes over (hydration), the UI is updated.

Source page shows static and initial state are pre-rendered and present in the HTML.

However, server-side fetched data IS pre-rendered.

async function getData() 
  const res = await fetch("https://swapi.dev/api/people/1");
  const data = await res.json();
  return data;
}

async function Luke() {
  const data = await getData();

  return (
    <div>
      <div>Name: {data.name}</div>
      <div>Gender: {data.gender}</div>
      <div>Height: {data.height}</div>
    </div>
  );
}

export default async function Page() {
  return <Luke />;
}

It's at the bottom of the source page because it was streamed in later.

2. Server and Client Components

So how do you do server-side data fetching? 🤔 By default, all components are server components, ie. their code is executed on the server. So just fetch the data, simple. This also has the added benefit of not sending private API endpoints and secrets to the client.
However, code that require interactivity such as event handlers and useState can't be executed on the server since they're meant for the browser, ie. the client.

async function Luke() 
  const data = await getData();

  return (
    <div>
      <div>Name: {data.name}</div>
      <div>Gender: {data.gender}</div>
      <div>Height: {data.height}</div>
      {/* error: interactivity cannot be added to server components */}
      <button onClick={() => console.log("Something")}>Console log something</button>
    </div>
  );
}

Therefore the 'use client' directive must be written at top of the file to declare a boundary between server code and client code. All other modules imported into a client file is now part of the client bundle.
In order to reduce client-side JS and keep its size cacheable and predictable, client components should be smallest as possible and at the leaves of the component tree. Note though client components are still pre-rendered as shown above.

3. Data Fetching

By default, all data fetching done with the fetch() API are cached. Thus if identical fetch requests are made (same URL, methods, body, headers), then it will only be executed once and the data will be shared.

In order to avoid stale data, revalidation or no-caching can be set. Revalidation can be time-based or on-demand (imperatively). Revalidation will cause the server to pre-render a new HTML.

4. Server Actions

This is an ⚠️ experimental feature ⚠️ that allows interactivity in server components. It allows to send requests to server and update the UI with revalidation. The <form> element has an action prop which takes an async function with the 'use server' directive at the top of the function definition. Wrap it around a text or element. Here I wrapped it around a button.

let likes = 0
let dislikes = 0;

async function incrementLikes() {
  "use server";
  likes++;
  revalidatePath("/");
}
async function incrementDislikes() {
  "use server";
  dislikes++;
  revalidatePath("/");
}

async function Count() {
  return (
    <div>
      <div>Likes: {likes}</div>
      <form action={incrementLikes}>
        <button className="bg-blue-300 p-1 rounded-md">Increment Likes</button>
      </form>
      <div>Dislikes: {dislikes}</div>
      <form action={incrementDislikes}>
        <button className="bg-blue-300 p-1 rounded-md">
          Increment Dislikes
        </button>
      </form>
    </div>
  );
};

Clicking on these buttons will mutate the server data. The revalidatePath function will cause the server to re-render the page and send the HTML to the client.

I think the most practical application of this would be to send some form data to the server since form data can be accessed without state or refs. This feature is still experimental and will likely change in the future but it's a cool way to run server-side code on the client without exposing the code.

let email = ""

async function submitEmail(formData: FormData) {
  'use server'
  email = formData.get('email')?.toString()!;
  revalidatePath('/')
}

async function EmailForm() {
  return <div>
    <div>Submit your email</div>
    <form action={submitEmail}>
      <input className="bg-gray-300 p-2 rounded-md" name="email" type="email" />
    </form>
    <div>Your email: {email}</div>
  </div>
}

Before submitting

After submitting and revalidation.

5. Suspense

What happens if a server component is fetching data but it takes a long time? It'll block the UI. I mentioned streaming HTML earlier and this is something we can do with React Suspense so the UI isn't blocked by a slow server component.

The code here has a DelayedComponent that takes 3 seconds to render. By wrapping it React Suspense and providing the fallback prop with a JSX content to be rendered while it waits for DelayedComponent to be rendered, our UI is no longer blocked and is progressively loaded.

async function DelayedComponent() 
  await new Promise((resolve) => setTimeout(resolve, 3000));
  return <div>Delayed Component</div>;
}

export default async function Page() {
  return (
    <div>
      <div>This is visible immediately</div>
      <Suspense fallback={<div>Loading Delayed Component...</div>}>
        <DelayedComponent />
      </Suspense>
    </div>
  );
}

Without React Suspense, I'd see a blank page for 3 seconds

You can see the fallback content in the source page at the top then the actual content streamed in at the bottom.

6. lazy

If there is a client component or library that takes a long time to load and is not critical to your UI, you can defer it from the initial client bundle with React lazy, aka code splitting.

"use client"
import { lazy, useState } from "react";

const LazyComponent = lazy(() => import("@/components/LazyComponent"));

export default function Page() {
  const [isVisible, setIsVisible] = useState(false);
  return (
    <div>
      <button onClick={() => setIsVisible(true)} className="p-2 bg-blue-300 rounded-md">Load Lazy Component</button>
      {isVisible && <LazyComponent />}
    </div>
  );
};

// separate file
export default function LazyComponent()
  return <div>Lazy Component</div>
}

Before clicking the button

Click the button downloads the bundle for LazyComponent on demand and renders it.

If the bundle takes a long time to download, it can block the UI. To prevent this, wrap it in Suspense. All lazily loaded components are pre-rendered by default (though in this example it's not since the initial state is not to show the component).

7. NextJS Dynamic

I highly recommend reading the doc linked since it gives a very good explanation. Dynamic is composite of Suspense and lazy. There is no need to wrap the lazy component in Suspense, and to give it a fallback UI, it's passed in as an option parameter. Pre-rendering can also de disabled by setting ssr to false..

ComponentA below will be loaded in a separate client bundle but will not be streamed in.

import dynamic from "next/dynamic";

const ComponentA = dynamic(() => import("../components/A"), 
  loading: () => <div>Loading A...</div>,
  ssr: false,
});

Conclusion

All these features help create a more robust front-end by reducing client bundle sizes, improving initial page load, reducing waterfall and blocking of UI. By leveraging the server more, less burden is placed on the client.

If you liked what you read, follow me on LinkedIn or DEV as I continue along my journey towards building more robust web applications. My next article will be comparing the full stack frameworks I mentioned at the start of this article. I want to understand the different approaches and mental models these frameworks have developed.

What I learned from building a high fidelity Twitter UI clone

Junsu Park — Mon, 31 Jul 2023 21:19:39 +0000

To deepen my frontend skills, I decided to build a high-fidelity Twitter clone. I was bored of the very basic CRUD app tutorials on Youtube that barely mimicked Twitter’s UI. Replicating Twitter’s UI was very challenging for a relatively new developer like me and I learned a lot, especially how to dissect UIs in Chrome Dev Tools.

Tech Stack: NextJS, TypeScript, Tailwind, Zustand.

Brief introduction about me: I became a full stack engineer last year and have been enjoying working at Wells Fargo helping to build their new security that enables more sophisticated logins for customers. I love building interfaces and systems and reading about thoughtful design.

Please check out my Twitter clone - I explain my thoughts about the tech stack I used and challenges I had in replicating Twitter’s UI behavior. Here are a few key points I learned:

This project took me about 3 weeks. I initially projected a week but soon learned just how complex each component is. One thing that surprised me initially was that almost every element in Twitter is a div and all the divs are flex containers with accessibility added via ARIA labels. Then I quickly learned that the inconsistent CSS properties of semantic tags are extremely frustrating.
NextJS's default optimizations and server-side rendering gave me great Google Lighthouse scores right out of the box. I tried to make interactive parts of the app as small as possible and sectioned them off as client components at edges of the component tree to improve FCP. When I build a full stack app, I'll implement data fetching with React Server Components and Suspense.

I got really good at finding where height and width of an element comes from. In Chrome Dev Tools, I would analyze from the leaf all the way to the parent to check for padding, margins, borders, and hard-coded width and height. Twitter has lot of redundant divs that do apply one or two styles at a time. I assume this is due to the complexity of working in a extremely big team.

I feel extremely confident about my ability to create high-quality production-grade UIs now. Follow me here on LinkedIn or on DEV as I continue along my journey towards building robust web applications! My goals are to build more high-fidelity clone projects with other frameworks, such as Remix, SvelteKit, SolidStart, and WASM.