웹 페이지는 최초 렌더링 단계나 네트워크에서 렌더링/파서 차단(redner-blocking, parser-blocking)을 어떻게 다루냐에 따라 성능에 크게 좌우가 된다. 그 중에서 CRP(Critical Rendering Path)가 어떻게 흘러가는지 이해하고, HTML 속성과 CSS 처리 옵션을 다룰 줄 알면 사용자 경험을, 개선을 크게 향상 시킬 수 있다.이번 글에선 브라우저 렌더링 단계에서 CRP가 무엇이고 어떤 단계에서 리소스가 차단되는지 그리고 렌더링 우선순위를 어느 위치에 잡아야 하는지 알아보고 브라우저에서 제공하는 기능들을 통해 브라우저 리소스 로딩을 최적화하는 방법을 알아보자. CRP(Critical Rendering Path)CRP란 브라우저가 서버로부터 HTML, CSS, Javas..
개요디자인 시스템 구축을 위해 `Radix-UI` 를 사용 중인데 내부 구조를 살펴보다가 이벤트 핸들링 방식에 대해 궁금하여 오픈 소스 코드를 살펴보던 중 2년전 React가 17에서 18로 업데이트 되면서 이벤트 처리에 대한 큰 변화로인해 트러블 슈팅을 겪은 사례에 대해 알게되어 조사하게되었다. (이 글은 저의 트러블 슈팅이 아닙니다...!) 사건의 발단으로는 하나의 이슈 사항으로 인해 PR이 머지 된 사례가 있었다. 이슈로는 `ContextMenu`에 대한 일관된 동작이 이루어지지 않는 다는 것. 이는 React 18의 핵심 변경 사항 중 하나로, 모든 이벤트 핸들러에 일관되게 자동 일괄 처리(automatic batching)를 도입한 것으로, 특정 이벤트만 일괄 처리를 적용이 가능했던 17버전과는..
개요프론트엔드에서 비동기 처리 중 가장 많은 비중을 차지하는 것이 "데이터 페칭"이라고 생각한다. React의 Suspense는 선언적 비동기 처리 작업 중에서 많은 개발자들 활용하는 기능이지만 일반적인 방식의 데이터 페칭 방식으로는 Suspense 처리를 할 수 없다.왜 그런 걸까? React의 Suspense의 개념과 기능에 대해서는 많이 알려져 있으니, 개념과과 기능은 따로 알아보고 지원하지 않은 이유와 Suspense의 구조/처리 방법에 대해 알아보고, tanstack-query나SWR와 같은 라이브러리에서는 어떤 식으로처리하여 선언적으로 사용할 수있는지해 알아보고자 한다.React 팀이 Suspense의 데이터 패칭을 지원하지 않은 이유Suspense는 이펙트 또는 이벤트 핸들러 내부에서 데..
개요 이번엔 RN(React Native)을 살펴볼 일이 생겼는데, 문득 RN이 어떤 방식으로 JavaScript에서 브라우저 엔진 없이 Native(iOS,Android)에서 상호작용과 UI가 그려지는지 궁금하게 되었다. 이번 글은 RN의 과거와 현재의 아키텍처가 어떤 식으로 구성되어 왔고, 개선된 아키텍처는 어떤 방식의 메커니즘을 가지게 되는지 정리해 보고자 한다. 웹 개발만 해 오던 분들이라면 너무 깊게 이해할 필요는 없을 것 같고, 단순히 React와 RN이 어떻게 다르게 동작하는지를 아키텍처 관점으로만 가볍게 봐도 괜찮을 것 같다. 먼저 RN의 메커니즘을 이해하기 위해선 아키텍처를 이해해야 하는데, RN은 0.68 버전 전부터 적용해 오던 브릿지(Bridge) 메커니즘을 적용하고 있었다. 하지만..
본 강의는 글또를 통해 무료로 지원받은 유데미 강의입니다. TDD(Test Driven Development)란, 작성하고자 하는 코드가 어떤 일을 할 것인지를 묘사하고 동작을 검증할 테스트 코드를 먼저 작성하고 빠르게 테스트를 진행하는 방법 아직 많은 프론트엔드 개발자에게 있어서 테스트 코드와 테스트 프로세스를 적용하는 것에 있어서 선뜻 수행하기가 쉽지 않은 게 현실인 것 같다. 그런데 TDD요...? 웹 프론트엔드 개발자 입장에서 수많은 경우의 수가 존재하는 환경(브라우저, 모바일, 태블릿 디바이스 등)의 유저 인터렉션을 테스트하기란 정말 쉽지 않은 환경이라고 생각한다. (하기 싫어서 안 하는 것도 있겠지만...) 필자도 테스트를 깊게 적용해 보진 않았지만 이것 저것 찍먹으로 해봤던 경험이 있다 보니..
[원문]: https://code.visualstudio.com/blogs/2023/06/05/vscode-wasm-wasi#_how-does-it-work 한때 우리는 웹용 VS Code(https://vscode.dev)를 브라우저에서는 모든 편집 / 컴파일 / 디버그 주기를 지원하는 것을 목표로 하고 있었습니다. 브라우저에서 자바스크립트 실행 엔진이 제공된 후로 자바스크립트와 타입스크립트와 같은 언어는 비교적 쉽게 적용할 수 있었습니다. 하지만 코드를 실행(디버깅 같은)할 수 있게 된 후로 다른 언어에서는 더욱 어려웠습니다. 예를 들어, 브라우저에서 Python 코드를 실행하려면 Python 인터프리터를 실행할 수 있는 실행 엔진이 필요합니다. 이런 언어 런타임은 보통 C/C++로 작성됩니다. 웹 ..