프론트엔드 두 개의 트리 & Tree shaking이 뭔데

CSS 트리와 DOM 트리가 다른 위치에 있는 것은 문제가 된다.

The Two-Tree Problem with Styling on the Web

I get to the root of the problem with styling on the web.

심윤섭: 흥미로운 CSS-in-JS와 Utility-First CSS에 대한 자신의 관점을 드러낸 글입니다. CSS-in-JS(styled-components, emotion)의 CSS의 선택자를 결국 사용해야 한다는 점, Utility-First CSS에서 기존 CSS 기능들을 모두 사용하지 못한다는 점을 말하면서 UI 프레임워크에서 CSS기능을 모방해서 인라인 스타일링을 하는 것은 어떻냐는 관점을 제시합니다. 하지만 CSS의 기능을 모방한 JS는 성능을 보장받지 못할 뿐더러 역시 CSS의 많은 기능을 포기하게 되기 때문에 역시 도입을 신중하게 해야 합니다(댓글에서 이를 지적하고 있습니다!). CSS-in-JS와 Utility-First CSS에 대해 궁금하신 분은 관련 글을 보세요 🙂

Tree shaking이 뭔데

Deep Dive into Rspack & Webpack Tree Shaking · web-infra-dev · Discussion #17 · GitHub

Deep Dive into Rspack & Webpack Tree Shaking

심윤섭: Rspack팀에서 Tree Shaking를 정의하고 webpack에서 어떻게 진행되는지 알려줍니다. 프론트엔드에서는 사용자에게 코드가 그대로 노출되므로 매우 중요한 개념입니다. 어떤 속성을 제공하는지, 그에 따라 중요한 내부 코드가 노출될지 아닐지 결정하니까요.

환경 변수 설정의 지속 가능한 해결책

The process.env frontend time bomb (plus: a sustainable definition of “fixed”) | Massimiliano Mirra

Massimiliano Mirra

심윤섭: 환경변수 설정을 배포하기 전에 까먹을 수도 있습니다. 그를 방지하기 위해 문제를 정의하고 이를 zod와 명령어로 이를 해결하는 방식을 보여줍니다. Context를 사용하는 것을 제외하고는 실제로 적용해볼만한 방식입니다. 또는 이와 관련된 패키지를 사용할 수도 있겠죠. 아니면 번들링 설정에서 Define에 들어갈 값의 유효성 검사를 하는 방법도 있겠죠(Vite, Webpack). 그래야 환경변수를 통해 트리 셰이킹으로 원치 않은 코드가 들어가는 것을 방지할 수 있겠죠.

TypeScript 5.5의 신기능: 타입 술어 추론

Type Predicate Inference: The TS 5.5 Feature No One Expected | Total TypeScript

TypeScript 5.5 introduces type predicate inference from function bodies, simplifying type narrowing and making development easier.

The Making of a TypeScript Feature: Inferring Type Predicates

Effective TypeScript: The Making of a TypeScript Feature: Inferring Type Predicates

심윤섭: 첫번째 글은 이전에 소개했던 타입스크립트의 추론 방식을 작성한 저자가 타입 술어 추론 기능을 추가한 PR을 설명하는 글입니다. 이후 Type Guard를 더 쉽게 쓸 수 있겠네요. 두 번째 글은 자신이 기능 추가 PR을 생성하기 까지의 일지를 적은 것입니다. 이 글에서 추론을 어떻게 달성했는지를 볼 수도 있지만 오픈소스에서 기여하기까지의 과정도 한 번 보고 어려운 일이 아니라는 것을 알 수 있습니다. 오픈소스에 기여하는 것에 두려움을 갖지 마세요!

CSS-in-JS의 발전과 SSR의 충돌

CSS in React Server Components

You can’t make an omelette without cracking a few eggs, and when the core React team unveiled their vision for the future of React, some of my favourite libraries got scrambled 😅. In this blog post, we’re going to explore the compatibility issues between React Server Components and CSS-in-JS libraries like styled-components. You’ll understand what the issue is, what the options are, and what’s on the horizon.

심윤섭: 기존 CSS-in-JS의 작동방식과 SSR, React Server Components의 충돌과 최신 CSS-in-JS이 이충돌 문제를 해결하는 방식을 소개합니다. 기존 CSS-in-JS가 이를 해결하지 못하는 이유를 자세하게 설명하고 현재 CSS-in-JS이 가고 있는 방향성을 설명하므로 CSS-in-JS에 관심있는 분들은 모두 보시길 바랍니다.

Protected Route를 위해 미들웨어를 사용하지 마세요.

Please stop using middleware to protect your routes

Stop overthinking and over-abstracting.

심윤섭: Protected middleware가 잘못된 추상화이며, RBAC로 기능을 확대한다면 이는 너무 복잡해진다라고 저자는 말합니다. 그리고 기능 추가시 디버깅과 테스트를 위해 적절한 추상화의 중요성을 강조합니다. 항상 생각하지만 "적절하게"는 어렵습니다. 이전에 소개했던 추상화는 적절하게 글도 다시 보는 것도 나쁘지 않습니다!

`any`는 언제 써야 하나요?

`any` Considered Harmful, Except For These Cases | Total TypeScript

Discover when it's appropriate to use TypeScript's `any` type despite its risks. Learn about legitimate cases where `any` is necessary.

심윤섭: any를 써야 하는 때는 분명히 있습니다. React를 배울 때 유명한 글인 언제 useMemo와 useCallback을 써야 하나요?에서도 대부분의 경우에서 사용하지 않아도 되지만 사용처는 있다고 밝히죠. 물론 장단점을 저울질하면서 써야하지만요.

정말 재사용 가능한 Button 만들기

Empathetic Coding - Button Component - React Japan

In this article, we’ll be creating a Button component from the ground up using an empathetic approach.

심윤섭: 디자인 시스템에서, 그게 아니더라도 간단한 컴포넌트를 재사용 가능하게 만들라고 하면 어떻게 접근해야 할지 모르는 경우가 많습니다. 이 글은 단계별로 재사용 가능한 컴포넌트를 만들면서 미래를 위해 어떻게 접근해야 하는지, 현재 단계의 한계점은 어떻게 되는지 말해줍니다. 공용 컴포넌트로 분리할 때 고려해야 할 점을 제시하므로 나중에 공용 컴포넌트를 만들 때 적용하면 좋습니다. 이 컴포넌트를 만들면서 공감형 접근방식이라는 철학도 제시하니 이 것도 보면 코딩을 할 때 도움이 됩니다(Kent C. Dodds.씨가 AHA를 제시한 것처럼요!).

우리 Qwik 월클 아닙니다

Outshift | Qwik vs. Next.js: Which framework is right for your next web project?

Explore Qwik vs Next.js and see why Qwik's innovative features and seamless developer experience make it the preferred framework for web development projects.

심윤섭: 뉴스레터 초기 버전에서 Hydration의 발전을 설명하면서 Resumablity 개념을 가져온 것이 생각나네요. 해당 개념을 적용한 Qwik의 장점과 Next.js대신 선택한 이유를 설명하는 글입니다. 좋은 프레임워크이지만.. 아직 관심만 가지는 것이 좋다고 생각합니다.