로컬 최초 HTMX pt1

개요

인터넷에는 상황이 점점 더 악화되고 있고 계속해서 악화되고 있다는 일반적인 자제 말이 있습니다. 모든 웹사이트에 끔찍하고 빠르게 로딩되는 광고가 급증하고 있으며, 모든 검색 엔진이 검색 결과 앞에 형편없는 AI 요약을 표시하고, 모든 사이트/웹앱이 점점 더 느려지는 것 같습니다. 나는 이 모든 것에 대한 해결책을 제시할 수는 없지만 웹 사이트와 웹 앱 디자인에 대한 더 나은 패러다임을 제시할 수 있습니다. 그 패러다임은 로컬 우선입니다.

로컬 우선은 UI와 데이터가 같은 위치에 있고 데이터 변경 사항이 원격 서버와 동기화되는 웹 앱의 설계 원칙입니다. 로컬 우선 앱은 사용자 작업과 작업 결과 렌더링 사이에 네트워크 RTT가 필요하지 않기 때문에 빠르고 성능이 뛰어납니다. 일류 로컬 최초 앱이 어떤 느낌인지 경험하기 위해 선형.app을 가지고 놀기를 권장합니다. 나는 나쁜 웹 앱에 대해 설득하는 데 많은 시간을 소비하지 않을 것입니다. 왜냐하면 당신이 무지하고 행복하다면 나는 그 행복을 망치고 싶지 않기 때문입니다.

Jira 또는 Github 문제에 익숙하다면 로컬 최초 앱이 얼마나 큰 차이를 가질 수 있는지 즉시 알 수 있을 것입니다. Jira는 제가 아는 한 느리고 느리고 많은 데이터를 천천히 로드하기 때문에 느립니다. 클릭한 다음 다시 돌아가면 동일한 데이터를 모두 다시 로드해야 합니다. Github는 HTML이 서버에서 생성된 다음 사용자에게 전송된다는 의미의 SSR 웹앱입니다. 즉, 모든 상호 작용에는 일반적으로 브라우저와 서버 간의 완전한 왕복이 필요하며 이는 일반적으로 매우 눈에 띕니다. 아이러니하게도 Github의 느린 SSR은 내 경험상 Jira보다 훨씬 더 나은 성능을 발휘합니다. 그들은 서로 다른 일을 하지만 맙소사 Jira를 사용하는 것을 싫어합니다. 언젠가는 직장에서 Linear를 사용할 수 있고 지금처럼 속도가 빨라지길 바랄 뿐입니다.

여기서 잠시 멈추고 거의 모든 앱 아키텍처가 제대로 구현되지 않으면 고통스러울 정도로 느려질 수 있다는 점을 분명히 하겠습니다. 나는 우리가 매일 방문하는 대부분의 웹사이트, 웹앱 등이 제대로 구현되지 않았다고 강력히 주장합니다. 이러한 다양한 아키텍처(기존 SPA, SSR 등)에 사용할 수 있는 다양한 기술이 있지만 로컬 우선은 성능과 관련하여 아키텍처로서 가장 큰 이점을 제공합니다.

밈 중심 개발

그것은 제가 의도한 것보다 더 심각했습니다. 따라서 MDD(Meme Driven Development)에 대해 자세히 살펴보겠습니다. 이번 포스팅의 본론으로 들어가 Local First HTMX에 대해 이야기해보겠습니다.

HTMX는... 뭐 밈이고 진지할 수도 있지만, 실제로 아는 사람이 있는지는 잘 모르겠습니다. HTMX는 안티 자바스크립트 자바스크립트 프런트엔드 프레임워크/라이브러리입니다(idk 프런트엔드 사람들은 이러한 용어를 매우 느슨하게 사용합니다). 더 중요한 것은 이것이 정말 좋은 밈이고 이것이 MDD의 핵심입니다. 그래서 저는 HTMX와 로컬을 먼저 결합하여 정말 끔찍하면서도 아름다운 것을 만들어야 한다고 생각했습니다. 이 접근 방식을 반드시 권장하는 것은 아니지만, 최초의 Local First HTMX Todo 앱을 만들기 위해 제가 한 일을 공유하게 되어 기쁩니다.

HTMX는 올바른 프레임워크는 아니지만 그럴 수도 있습니다.

HTMX의 목표는 여전히 좋은 수준의 상호작용성을 유지하면서 프런트엔드 개발을 단순화하는 것입니다. HTMX의 일반적인 아이디어는 HTML이 백엔드(서버 측 렌더링)에 의해 렌더링된다는 것입니다. 기술 용어는 HATEOS 상태의 엔진인 하이퍼미디어입니다. SSR(모든 상호 작용에 대해 서버에 RTT가 필요함)에는 성능 문제가 있으며 웹 사이트가 느리게 느껴질 수 있다는 점을 기억하신다면(빛의 속도에 맞서기가 어렵습니다). 대화형 기능만 추가하면 효과가 있을 수 있습니다. 그러나 이것이 Local First HTMX의 핵심 아이디어입니다. 즉, 백엔드에서 HTML을 렌더링할 필요가 없습니다. "서버"를 구축하고 WASM으로 컴파일한 후 브라우저에서 실행할 수 있습니다. 이렇게 하면 JS가 전혀 포함되지 않은(물론 JS가 포함되지 않은) 일급 Javascript Local First SPA의 모든 기능을 제공할 수 있습니다. 목표는 JS를 피하는 것이 아니라 더 간단한 앱을 만드는 것입니다.

아키텍처 개요

요약하자면 SSR 코드를 WASM으로 컴파일한 다음 서비스 워커에서 실행하여 Local First HTMX 앱을 구축하고 있습니다. 브라우저에 관한 몇 가지 사항을 간략하게 그리고 아마도 부정확하게 설명하겠습니다. 메인 스레드가 있는데, 여기에서 JS 및 HTML 작업이 일반적으로 발생합니다. 메인 스레드는 DOM에 액세스할 수 있고 실제로 콘텐츠를 렌더링할 수 있는 스레드입니다. 브라우저에는 많은 기능이 추가되었지만 두 가지를 언급하고 싶습니다. 첫 번째는 제한된 권한(DOM에 대한 액세스 없음)이 있는 다른 스레드에서 코드를 실행할 수 있는 웹 작업자입니다. 두 번째는 서비스 워커입니다. 이는 웹 워커와 비슷하지만 중요한 차이점이 있습니다. 모든 fetch 요청을 가로채도록 서비스 워커를 구성할 수 있습니다.

서비스 워커는 프록시 처리, 캐시 확인, 요청 자체 처리 등 원하는 작업을 수행할 수 있습니다. 이것이 제가 활용하고 싶은 것입니다. 모든 가져오기 요청을 프록시하고 선택적으로 HTML을 렌더링하여 다시 보내도록 선택하고 싶습니다.

기본 HTMX 요청은 다음과 같습니다

일반적으로 이는 HTTP 요청을 서버로 보내지만 우리는 서비스 워커에서 이 요청을 가로채서 요청을 처리하고 HTML을 반환하려고 합니다. 그러면 서비스 워커는 백그라운드에서 로컬 데이터 저장소를 유지하면서 서버와 데이터를 동기화할 수 있습니다. 후속 게시물에서는 이 작업을 수행한 방법에 대한 구현 세부 사항과 직면한 몇 가지 문제를 살펴본 다음 몇 가지 추가 아이디어에 대해 이야기하겠습니다.

앞으로 계속 지켜봐 주시기 바랍니다.

위 내용은 로컬 최초 HTMX pt1의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!