React and Next.js 를 대체할 수 있는 새로운 프레임 워크
이것이 자바스크립트 프레임워크의 다음 혁명의 시작인가? 분명히, 그렇다!
웹 개발의 역설은 고객이 원하는 기능을 구현하기 위해 더 많은 자바스크립트가 필요하다는 것이다. 그러나 사이트를 빠르게 로드하는 데 필요한 JavaScript는 줄어듭니다.
개발자로서, 당신은 항상 둘 사이의 균형을 맞추려고 하다가 중간에 무너질 것이다.
만약 당신이 원하는 만큼(기가바이트) 자바스크립트를 쓸 수 있지만 여전히 당신의 앱의 성능에 대해서는 걱정하지 않아도 된다고 말한다면 어떨까요?
만약 지금까지 당신이 사용한 모든 유명한 웹 프레임워크가 설계에 의해 근본적으로 결함이 있다고 말한다면 어떨까요? 그들은 당신이 삶을 어렵게 만드는 방식으로 행동하기를 기대한다.
자바스크립트는 불가피하다.
이 현실을 받아들이고 (더 나은 방향으로) 여러분의 삶을 단순화시킬 때입니다.
우리가 처한 혼란 (아무도 말하지 않는)
우리는 (현재) 웹 개발 상황이 엉망이라는 사실을 인정하기엔 너무 고집이 세다.
우리는 오래 전에 HTML(클라이언트 to 서버)을 보내는 것이 너무 비싸다는 (실수) 결론을 내리고 (더 나쁜) 대안을 개발하기 시작했습니다.
그동안 우리는 다양한 프레임워크를 개발해 왔습니다. 우리는 웹이 구축된 바로 그 토대와 싸워왔습니다.
전체 그림을 보여드리면 무슨 말인지 이해하실 수 있을 겁니다.
일반적인 웹 응용 프로그램에서 우리는 서버 측에서 렌더링된 HTML을 클라이언트(신이 SPA 사람들에게 자비를 베풀어 줄 수 있음)에게 보내고 클라이언트는 렌더링(그때까지 비활성)합니다. - 사용자는 그것과 상호 작용할 수 없습니다.
다음으로 브라우저가 수행하는 작업은 다음과 같습니다. 페이지에 대한 응용 프로그램(JavaScript 부분)을 다운로드합니다.
마지막으로, 애플리케이션을 실행합니다(수신기 연결). 이제 애플리케이션과 상호 작용할 수 있습니다.
전체 구조(뷰 포함)를 고객에게 보냈음에도 불구하고, 우리는 여전히 그것이 상호 작용이 될 때까지 기다려야 합니다.
전체 프로세스로 인해 시동 시간이 불필요하게 늘어납니다. 물론 이것은 문제가 되지 않습니까?
웹 사이트를 로드하는 데 그렇게 오랜 시간이 걸리는 주된 이유는 웹 사이트가 매번 처음부터 시작해야 하기 때문입니다.
우리는 수화(우리는 모든 것에 대해 멋진 이름을 가지고 있다)라고 부른다. 우리가 의미하는 것은 브라우저가 자바스크립트 부분을 읽고 웹 페이지의 (청취자를 첨부하는) 어디에 속하는 코드의 섹션을 결정하는 것이다.
음, 소름— 만약 그게 문제라면, 모든 것을 게으르게 싣는 것으로 고칠 수 없을까? (당신이 그렇게 말하는 게 들려요.)
우리는 그렇게 할 수 있지만, 그것은 (대부분의 사람들이 생각하는 것처럼) 해결책이 아니다.
서버 측 HTML을 전송하고 클라이언트가 다운로드하여 실행한 후, 우리는 웹 앱을 특정 청크에서 게으르게 로드하려고 합니다.
글쎄, 그거 알아?
시스템이 느리게 로드된 경계에 도달했을 때 구성 요소가 보이기 때문에 시스템이 다시 돌아가서 느리게 로드된 구성 요소를 요청하고 다운로드하여 수분 공급을 완료할 수 밖에 없습니다.
이것은 우리가 애초에 게으른 부하를 사용한 바로 그 목적에 실패한다.
지연 로딩은 기존 시스템에서만 유용하며, 현재 렌더 트리에 없는 구성요소에 대해서만 유용합니다. 이 경우 컨텍스트가 필요하지 않기 때문입니다.
현재 렌더 트리에 있는 구성요소의 경우 느린 로딩은 주의를 산만하게 합니다.
사람들은 당신의 애플리케이션이 너무 크다고 말할 때 이것을 깨닫지 못한다. 그들은 "아! 그냥 게으르게 모든 것을 싣기만 하면 괜찮을 거야."라고 말할 것이다.
그들은 사실 우리가 방금 논의한 문제 때문에 그것이 그렇게 쉽지 않다는 것을 깨닫지 못합니다.
우리는 또한 (Astro에 의해 대중화 된) 이러한 섬 건축물을 가지고 있다.
처음에 모든 것에 수분을 공급하는 대신(가격이 다소 비싼 편) 고객이 가서 특정 구성 요소와 상호 작용할 때 수분을 공급합니다.
그래서, 제가 메뉴와 상호작용한다면, 저는 단지 메뉴에 수분을 공급하고, 만약 제가 어떤 특정한 구성 요소들과 상호작용한다면, 저는 전체 앱이 아니라 그것에만 수분을 공급합니다.
이것은 발전된 것이다.
하지만 이 섬들은 여전히 비교적 큽니다. 그리고 섬 간 의사소통은 문제가 됩니다. 왜냐하면 섬이 하나의 애플리케이션이기 때문입니다. 이제 어떤 방식으로든 해결해야 할 애플리케이션 간 통신 문제가 있습니다.
이제 큐빅이 온다.
특정 구성 요소와 상호 작용하면 해당 구성 요소만 해결됩니다.
구체적으로, 이 경우 (Astro의 경우와는 달리) 구성 요소의 부모도 자식도 해결할 필요가 없다는 것을 관찰하십시오.
Qwik은 "이 사람만 하면 되고 다른 건 아무것도 하면 안 돼요."라고 말한다.
Qwik은 또한 한 구성 요소가 다른 구성 요소에 종속되어 있는 경우를 인식하고(전자 상거래 앱에서 카트 버튼에 추가) 종속 구성 요소를 깨울 수 있을 만큼 지능적입니다.
네트워크 탭을 열면 초기 페이지 로드에서 자바스크립트가 0입니다.
이 특정 페이지에 JavaScript가 표시되지 않는 것은 그다지 인상적이지 않습니다. 정적 페이지를 요청하는 경우 모든 프레임워크가 이 작업을 수행할 수 있습니다.
QWIK를 특별하게 만드는 것은 스스로 이것을 알아냈다는 것이다.
그것은 본질적으로 당신의 코드를 찾아보고 "사실, 당신은 여기에 어떤 자바스크립트도 필요하지 않습니다. 나는 그것을 보내려고 애쓰지도 않을 것입니다."라고 말했다.
버튼을 클릭할 때까지 JavaScript가 로드되지 않습니다.
JS의 "스프링클"은 폭포가 되는 데 오래 걸리지 않는다. 스프링클이 커질수록 로딩 시간은 길어지지 않습니다. Qwik을 사용하면 번들 크기에 대한 부담이나 성능 저하 없이 원하는 만큼 자바스크립트를 작성할 수 있습니다.
게다가, 그것은 침체된 네트워크의 사용자들을 위해 백그라운드에서 파일을 프리페치할 수 있을 만큼 충분히 영리하다.
당신은 생각조차 하지 않고 놀라운 앱 성능을 달성할 수 있다.
독창성은 종종 마법으로 변장된다.
내가 가상 머신에 대해 알게 된 것은 나에게 마법 같은 순간이었다. "뭐라고요? 그럴 리가 없어요. OS 내에서 OS를 실행할 수 있다고요?" 나는 혼자 생각했다.
하지만 제게 마술처럼 보이는 것은 순수한 기술입니다.
윈도우 머신 안에서 리눅스를 부팅할 수 있다는 것 자체가 내게는 놀라운 일이었다.
하지만 나를 흥분시킨 것은 그게 아니었다.
리눅스를 부팅하고, 로그인하고, 앱을 열고(예를 들어 워드 프로세서) 입력을 시작한 다음, 어느 시점에서 가상 머신을 저장하고, 저장한 파일을 친구에게 보낼 수 있습니다.
내 친구가 파일을 열고 기계를 다시 시작하면, 기계는 정확히 내가 멈췄던 곳에 있다.
부팅 프로세스를 다시 수행할 필요가 없습니다. 워드프로세서를 여는 과정을 거치지 않고, 편지를 타이핑하는 과정을 거치지 않고, 당신은 정확히 내가 편지를 열어 다음 캐릭터를 맡을 준비가 된 위치에 있다.
그게 제 관심을 끌었어요.
그것이 바로 QWIK에서 일어나고 있는 일입니다.
응용프로그램이 서버에서 시작됩니다. 그것은 특정한 상태에 이르게 됩니다. 상태를 스냅하고, HTML 형태로 클라이언트에 보내고, 클라이언트에서는 중단했던 부분을 계속합니다.
기본적으로, 웹사이트의 시작이 느린 이유를 생각해보면, 부팅을 해야 하기 때문입니다. 속도가 느린 이유는 이미 살펴본 바와 같이 부팅 비용인 하이드레이션(Hydration)을 부담하기 때문입니다.
우리는 "아! 웹사이트가 계속 로딩되고 있다"고 말하지만, 기본적으로 웹사이트가 부팅되고 있습니다. 이것이 일어나고 있는 일입니다. 그렇지 않나요?
QWIK 응용 프로그램의 시작 속도가 빠른 이유는 부팅을 건너뛰고 서버에 있는 정확한 상태로 이동한 후 중단한 상태로 계속 진행하기 때문입니다.
그것은 우리가 실행하고자 하는 코드를 포함하고 있으며, 또한 다른 구성 요소들이 공유할 수 있는 상태를 업데이트하기 위해 어휘 환경에 액세스할 수 있다.
Qwik은 효율적이기 때문에 빠르지는 않지만, 일을 피하는 것이 좋기 때문에 빠릅니다!
그것은 (수분의 필요성을 없애주는) resumability라는 테이블에 완전히 새로운 렌더링 패러다임을 가져온다.
이것이 바로 우리가 온라인으로 영화를 스트리밍하는 방법입니다. 하지만 여기서는 비선형적인 방식으로 하고 있습니다. 사용자가 원하는 응용 프로그램 부분과 시기를 결정하므로 이를 다시 시작할 수 있다고 합니다.
큐빅은 완전히 새로운 가능성의 세계를 열어줍니다. 예를 들어, 여러 백엔드 에지 서비스에서 페이지를 렌더링하고 단일 응답으로 조립할 수 있습니다.
결론
수천 년 전, 고타마—부처님은 우리에게 중간 길을 선택하라고 말씀하셨습니다. 우리 개발자들은 너무 완고하지만, 여전히 극단으로 치닫는 것을 선택한다.
모든 JavaScript(다른 모든 SPA)를 선택하라고 말하는 부족이 하나 있고, JavaScript(라이브뷰와 같은 WebSocket 기반 프레임워크)를 선택하라고 말하는 부족이 하나 있으며, 나머지 부족은 번들 크기에 대한 부담과 성능 비용으로 JS를 사용할 수 있습니다.
큐빅은 이 모든 것에서 신선한 공기를 내뿜는 것이다, 그것은 우리가 전에 사용했던 것과는 전혀 다르다.
나는 어떤 틀을 전도하기 위해 여기 있는 것이 아니지만, 우리는 이 접근 방식이 혁명적이라는 사실을 인정해야 한다.
나는 더 많은 프레임워크가 이 접근 방식을 제안하기를 바란다.
이 접근법은 앞으로 나아가는 길입니다. 그렇지 않으면 우리는 영원히 순환할 것입니다.
Note of Gratitude
I wanted to take this last opportunity to say thank you.
Thank you for being here! I would not be able to do what I do without people like you who follow along and take that leap of faith to read my post.
I hope you’ll join me in my future blog post and stick around because I think we have something great here. And I hope that I will be able to help you along in your career for many more years to come!
See you next time. Bye!