00:00:00새로운 자바스크립트 프레임워크가 나왔습니다.
00:00:03풀스택 프레임워크인데요, 일단 나가시기 전에 제 말 좀 들어보세요.
00:00:07꽤 흥미롭거든요.
00:00:08Remix를 만든 사람들이 개발했거든요.
00:00:11그러니까 Remix JS를 만든 Ryan Florence와 Michael Jackson이요.
00:00:18아니, 그 Michael Jackson 말고요.
00:00:21이들은 React Router의 원작자이기도 합니다.
00:00:25이들이 자신들의 비전과 실제로 첫 프로토타입이라고 할 수 있는, 초기 데모들을 공개했습니다.
00:00:31그들의 완전히 새로운 자바스크립트 프레임워크 Remix 버전 3의 말이죠.
00:00:36그러니까 완전히 새로운 이름은 아니고요, 기존에 있던 이름이긴 한데 완전히 새로운 프레임워크입니다.
00:00:43이 영상에서는 이 모든 것을 이해하기 쉽게 설명해드리려고 합니다.
00:00:48이게 뭔지,
00:00:48그리고 제 의견은 어떤지,
00:00:50정말로 또 다른 자바스크립트 프레임워크가 필요한지,
00:00:54그리고 성공하거나 채택될 가능성이 어떨지 말씀드리겠습니다.
00:00:58물론 요즘은 대형 언어 모델들이 기본적으로 React 앱을 뚝딱 만들어내는 시대지만 말이죠.
00:01:04하지만 차근차근 알아보죠.
00:01:06Remix가 정확히 뭐고, 왜 중요할까요??
00:01:11Remix는 혹시 못 보셨을 분들을 위해 설명하자면, React 메타 프레임워크입니다.
00:01:17결국 Next.js의 대안이라고 볼 수 있죠.
00:01:20Remix는 이미 몇 년 전에 출시되었습니다.
00:01:23Remix 버전 2는 제 기억이 맞다면 2022년에 출시되었고요.
00:01:28그리고 2024년에 Remix 버전 2는 본질적으로 React Router와 합쳐졌습니다.
00:01:34그래서 지금 React Router를 사용하면 예전처럼 React 앱에서 라우팅 라이브러리로 사용할 수도 있습니다.
00:01:42여전히 잘 작동하고요, 그 용도로는 여전히 훌륭한 라이브러리입니다.
00:01:47하지만 프레임워크 모드로도 사용할 수 있어서 본질적으로 풀스택 React 애플리케이션을 만들 수 있습니다.
00:01:55React Router가 단순한 라우터 이상의 역할을 하면서 데이터 페칭,
00:02:00데이터 로딩,
00:02:01데이터 변경까지 도와주죠.
00:02:03Remix처럼요.
00:02:04왜냐하면 사실 Remix가 React Router에 합쳐진 거거든요.
00:02:08하지만 물론 이것 때문에 그럼 Remix라는 브랜드는 어떻게 될 건가 하는 의문이 생겼죠..
00:02:17그래서 Remix는 버전 3에서 새로운 프레임워크가 될 예정입니다.
00:02:22중요한 건, React와는 독립적인 새로운 프레임워크가 된다는 점입니다.
00:02:28React 메타 프레임워크가 아니에요.
00:02:31또 다른 Next.js 대안도 아니고요.
00:02:34그 대신 완전히 새로운 풀스택 자바스크립트 프레임워크입니다.
00:02:38처음부터 새로 작성된 거죠.
00:02:40Ryan Florence와 Michael Jackson이 새로운 자바스크립트 프레임워크에 갖고 싶어 했던 모든 기능과 API를 담아서요.
00:02:51기본적으로 그들이 자바스크립트 생태계에서 보고 경험했던 문제들을 해결하는 거죠.
00:02:57기존 라이브러리와 프레임워크 환경의 문제들을 말이에요.
00:03:01특히 물론 React의 문제들이죠.
00:03:04React가 우리가 가진 주요 라이브러리이자 프레임워크니까요.
00:03:09뭐라고 부르든 간에요.
00:03:11그래서 이 새로운 Remix는 뭘 다루는 걸까요.
00:03:14지난 금요일에요.?
00:03:18첫 데모를, API의 첫 모습을 볼 수 있었습니다.
00:03:21전체 발표 이벤트를 볼 수 있는 라이브 스트림 링크를 이 영상 아래에 물론 달아놓을게요.
00:03:28다 보고 싶으신 분들을 위해서요.
00:03:30하지만 약 4시간 동안 논스톱 데모와 설명이 진행된다는 점을 알아두세요.
00:03:35제가 다 봤으니 여러분이 원하지 않으시면 안 보셔도 됩니다.
00:03:40하지만 더 알고 싶으시다면 꼭 한번 보세요.
00:03:43그리고 여기서 이 새로운 프레임워크의 주요 특징 중 하나를 보실 수 있습니다..
00:03:49이 프레임워크의 핵심이 될 것입니다.
00:03:52아니 정확히는 X에서 파장을 일으킨 주요 특징이라고 해야겠네요.
00:03:56바로 this.update예요.
00:03:58별로 대단해 보이지 않죠.
00:04:00하지만 실제로는 두 가지 중요한 의미를 담고 있습니다.?
00:04:04자바스크립트 개발자들이 요즘은 익숙하지 않은 것들이죠.
00:04:08첫째, this 키워드의 사용입니다.
00:04:11저 같은 옛날 사람들은 자바스크립트를 시작할 때 this의 모든 특이사항과 기능들을 배웠죠.
00:04:17요즘은 그걸 많이 사용하지 않습니다.
00:04:20React에서는 아마 this를 쓸 일이 없을 겁니다.
00:04:24하지만 이건 자바스크립트에 내장된 키워드예요.
00:04:27그들은 이 this 키워드를 활용해서 여러분에게 일부 API를 제공합니다.
00:04:33그 API들은 어디서 접근할 수 있느냐?
00:04:36여전히 함수를 작성합니다..
00:04:39그러니까 클래스를 작성하는 게 아닙니다.
00:04:41this 키워드 때문에 그렇게 생각하실 수도 있지만요.
00:04:45Remix로 작업할 때도 여전히 컴포넌트를 만들고, 그걸 위해 함수를 사용합니다.
00:04:50React에서 아시는 것처럼요.
00:04:52하지만 그 컴포넌트 함수들이 좀 다르게 생겼을 겁니다.
00:04:56하지만 this.update로 돌아가죠.
00:04:58거기엔 두 가지 중요한 것이 있다고 말씀드렸죠.
00:05:01this가 그중 하나고요.
00:05:03update가 나머지입니다.
00:05:05왜냐하면 Remix 버전 3에서는 프레임워크에게 언제 화면을 업데이트해야 하는지,
00:05:10언제 다시 렌더링해야 하는지 직접 알려줘야 하기 때문입니다.
00:05:14그리고 이건 물론 우리가 더 이상 익숙하지 않은 방식이죠.
00:05:18React에서도, Vue나 Angular에서도 프레임워크가 언제 업데이트할지 알아서 결정해주니까요.
00:05:25React에서 setState를 호출하면 관리하는 상태에 새 값을 할당하는 거고,
00:05:30그러면 UI 업데이트도 트리거됩니다.
00:05:32하지만 반드시 즉시 일어나는 건 아니죠.
00:05:35대신 React가 배칭을 하고 여러 상태 업데이트를 모으는 등의 작업을 합니다.
00:05:40하지만 결국엔 UI를 업데이트하죠.
00:05:43setState로 React에게 UI를 업데이트하라고 어느 정도 알려주는 거지만,
00:05:48주로 어떤 값이 변경됐다고 알려주는 거고,
00:05:51그 결과로 UI가 업데이트되고 다시 렌더링되는 거죠.
00:05:54Remix는 다릅니다.
00:05:56Remix 버전 3에서 말이에요.
00:05:58거기서는 일반 변수로 상태를 관리합니다.
00:06:01특별한 건 없어요.
00:06:02useState 훅 같은 것도 없고요.
00:06:04사실 훅 자체가 전혀 없습니다.
00:06:06그리고 UI가 업데이트되어야 한다고 판단될 때 this.update를 호출하면 됩니다.
00:06:12여러 변수를 바꾸고 this.update를 안 부르면 UI는 업데이트되지 않습니다.
00:06:17아니면 여러 변수를 바꾸고 this.update를 부르면 UI가 업데이트되고요.
00:06:23그게 작동 방식입니다.
00:06:24그런데 인터넷 사람들 아시잖아요, 끔찍하죠.
00:06:27몇몇 사람들은 이것 때문에 문제를 제기했습니다.
00:06:30제 생각엔 일단 어떻게 작동하는지 봐야 할 것 같아요.
00:06:34새로운 접근 방식이고 기존 접근 방식도 확실히 잘 작동합니다.
00:06:38그 라이브러리와 프레임워크들에서 사용되는 데는 이유가 있을 겁니다.
00:06:42하지만 기존 접근 방식도 확실히 발등을 찍을 수 있는 가능성이 있어요.
00:06:47무언가가 왜 업데이트되는지 또는 안 되는지 명확하지 않은 상황이 생길 수 있거든요.
00:06:52특히 더 복잡한 앱에서,
00:06:54그리고 많은 훅과 여러 기능들로 꽤 복잡해진 최신 버전의 React에서는 실제로 무슨 일이 일어나는지 완전히 이해하는 게 부담스러울 수 있습니다.
00:07:04그래서 그들이 더 단순한 API로 돌아가는 이유 중 하나가 바로 그겁니다.
00:07:09완전한 제어권을 가질 수 있도록요..
00:07:16또한 this 키워드를 사용하여 몇 가지 다른 API들도 노출하고 있지만, 실제로는 그리 많지 않습니다.
00:07:23왜냐하면 명확히 프레임워크를 단순하고 집중적으로 유지하고,
00:07:27좋은 개발자 경험을 제공하며,
00:07:29이 프레임워크를 사용하기 쉽게 만들려는 의도가 있기 때문입니다.
00:07:34또한 이 프레임워크의 명확한 목표는 - 그들이 올해 초 공유한 블로그 게시물에서 언급했듯이 - 대형 언어 모델이 사용하기 쉬워야 한다는 것입니다.
00:07:44즉,
00:07:44문서 기사나 예제를 대형 언어 모델과의 채팅 기록에 제공하고,
00:07:49일부 정보를 컨텍스트로 제공한 다음,
00:07:51LLM과 코드 어시스턴트가 코드 생성을 도와줄 수 있도록 한다는 아이디어입니다.
00:07:57물론 이것은 완전히 새로운 프레임워크이기 때문에 필요한 작업입니다.
00:08:01당연히 기존의 대형 언어 모델들은 이 코드베이스로 학습되지 않았고, 가까운 미래에도 학습되지 않을 것입니다.
00:08:09왜냐하면 모든 프론트엔드 코드 예제의 80%가 React인 것처럼 보이기 때문입니다.
00:08:15특히 shadcn을 사용한 React 말이죠.
00:08:18따라서 당연히 개발자들이 대형 언어 모델에게 Remix v3 코드를 작성하는 방법을 인식시킬 수 있는 다른 방법을 찾아야 합니다.
00:08:27이것이 그들이 API를 단순하게 유지하는 또 다른 이유일 것이며,
00:08:31표현력이 풍부하고 이해하기 쉽고 사용하기 쉽게 유지하려는 이유입니다.
00:08:36왜냐하면 인간만이 아니라 대형 언어 모델도 사용할 수 있어야 하기 때문입니다.
00:08:41이것이 그들이 가진 명확한 목표 중 하나입니다.
00:08:45그리고 그들이 공유한 예제들에서 이를 볼 수 있습니다.
00:08:48또한 그들이 키노트 프레젠테이션에서 여러 차례 언급한 또 다른 목표는 웹 프리미티브를 사용한다는 것입니다.
00:08:56최신 브라우저에서 사용 가능한 기능들을 사용하는데, 브라우저뿐만 아니라 백엔드에서도 마찬가지입니다.
00:09:03백엔드에 대해서는 잠시 후에 다루겠습니다만, 브라우저에 내장된 기능들을 사용하고 있습니다.
00:09:09네이티브 이벤트와 커스텀 이벤트를 디스패치하는 내장 기능에 크게 의존하고 있습니다.
00:09:15브라우저에서 커스텀 이벤트를 생성하고 디스패치할 수 있는데, 그들은 이를 적극 활용하고 있습니다.
00:09:22예를 들어 컴포넌트가 언마운트되었음을 알리기 위해 abort signal을 활용하고,
00:09:28이벤트 리스너를 자동으로 중지할 수 있도록 합니다.
00:09:31그들은 브라우저에 내장된 것들을 사용하고 있습니다.
00:09:35왜냐하면 제 생각에 우리 웹 개발자들은 최신 브라우저가 할 수 있는 것들을 따라가지 못하고 있기 때문입니다.
00:09:42최신 브라우저뿐만 아니라 수년간 존재해 온 특정 기능들이 있지만 우리는 그것들을 사용하지 않습니다.
00:09:49심지어 그것들에 대해 알지도 못할 수 있습니다.
00:09:52DOM이 제공하는 것,
00:09:54브라우저가 제공하는 것,
00:09:55어떤 API들이 사용 가능한지 정말 깊이 파고들면,
00:09:59거기서 할 수 있는 것들이 많고,
00:10:01추가적인 서드파티 라이브러리가 필요하지 않을 수도 있는 많은 것들이 있습니다.
00:10:07그것이 결국 그들이 활용하려는 것입니다.
00:10:09단순하게 유지하고 그러한 내장 기능들을 사용하는 것, 그것이 그들의 접근 방식입니다.
00:10:15그런데 제가 말했듯이, 그래도 여전히 프레임워크입니다.
00:10:19createElement와 같은 DOM API로 DOM 노드를 생성하지는 않을 것입니다.
00:10:25대신 앞서 언급했듯이 함수를 만들고 그 안에서 JSX 코드를 사용하여 컴포넌트를 만들 것입니다.
00:10:32그들은 그 모든 것을 보여주었습니다.
00:10:34다만 상태 관리가 완전히 다르게 작동하고, 일반적으로 더 가볍고, 훅 같은 것이 없을 것입니다.
00:10:41또한 React에서처럼 컴포넌트 함수가 계속해서 호출되지 않기 때문입니다.
00:10:46대신 두 가지 종류의 함수가 있을 것이고,
00:10:49작성 방법에 따라 한 번만 호출되거나 일부가 여러 번 호출될 수 있습니다.
00:10:54그리고 여기 2017년경 React로 작업했던 분들을 위한 내용이 있습니다.
00:10:59당시 우리는 두 가지 유형의 컴포넌트가 있었던 것을 기억하실 겁니다.
00:11:04상태를 관리할 수 있고 상태가 변경될 때 업데이트될 수 있는 클래스 기반 stateful 컴포넌트가 있었고,
00:11:12당시 컴포넌트 함수였던 stateless 컴포넌트가 있었습니다.
00:11:16그 다음 React 훅이 나왔고 모든 컴포넌트가 결국 컴포넌트 함수가 되었으며,
00:11:21stateful이거나 stateless일 수 있습니다.
00:11:25Remix 버전 3는 그 옛날 React 접근 방식을 취하고 있습니다만,
00:11:30클래스나 함수가 아니라 항상 함수이되 다른 타입의 함수입니다.
00:11:35JSX를 반환하는 함수가 있다면, 결국 stateless 컴포넌트입니다.
00:11:40그 안에서 this.update를 호출하고 컴포넌트 함수가 다시 실행될 것을 기대할 수 없습니다.
00:11:46그렇게 작동하지 않습니다.
00:11:48props를 받을 수 있고,
00:11:50부모 컴포넌트가 다시 렌더링되면 컴포넌트 함수가 다시 실행되는 식이지만,
00:11:55그 안에서 상태를 관리할 수는 없습니다.
00:11:58컴포넌트 함수를 stateful 컴포넌트 함수로 바꾸려면 JSX 코드를 반환하지 않고 대신 JSX 코드를 반환하는 함수를 반환하면 됩니다.
00:12:08따라서 JSX 코드를 반환하는 함수를 포함하고 반환하는 컴포넌트 함수는 stateful 컴포넌트가 될 수 있으며,
00:12:15그때 this.update를 호출하면 반환한 그 함수가 다시 실행됩니다.
00:12:20적어도 제가 이해한 바로는 그렇습니다.
00:12:23그래서 다른 컴포넌트 타입들이 있지만,
00:12:26결국 매우 간단한 API이고 stateful이나 stateless 컴포넌트 함수를 구분하는 매우 간단한 방법입니다.
00:12:34그리고 백엔드가 있습니다.
00:12:35왜냐하면 Remix 버전 3는 단순히 프론트엔드 프레임워크가 아니기 때문입니다.
00:12:41대신 풀스택 프레임워크입니다.
00:12:43풀스택 프레임워크가 되도록 의도되었습니다.
00:12:46그런데 그들은 복잡한 폼 컴포넌트 등을 구축하기 쉽게 만드는 컴포넌트 라이브러리도 제공할 것이라는 점을 언급해야겠습니다만,
00:12:54백엔드로 돌아가서,
00:12:56백엔드 부분도 함께 제공될 것입니다.
00:12:58프론트엔드와 백엔드가 결합된 풀스택 프레임워크를 목표로 합니다.
00:13:03다시 말하지만 React 없이 완전히, 대신 처음부터 모든 것을 다시 구축하고 있습니다.
00:13:09하지만 백엔드에서는 라우터를 얻게 됩니다.
00:13:12매우 강력한 라우터인데,
00:13:13명백히 그들이 지난 10년간 React Router를 구축해왔기 때문에 라우팅에 대해 많이 알고 있습니다.
00:13:21그래서 강력한 라우터를 얻게 되고,
00:13:23라우트에서 JSX 코드와 Remix 컴포넌트를 반환할 수 있는 기능을 얻습니다.
00:13:28그리고 서버에서 그 컴포넌트들을 hydrate할 수 있습니다.
00:13:33그들은 React 서버 컴포넌트에 대한 자체적인 대안, 더 간단한 대안을 제시합니다.
00:13:39이를 통해 클라이언트에서 서빙된 후에도 업데이트할 수 있는 컴포넌트를 반환할 수 있습니다.
00:13:45DOM의 일부를 다시 가져옴으로써 말이죠.
00:13:48예를 들어 무언가를 삭제할 때,
00:13:50클라이언트에서 서버로 요청을 보내고 다시 hydrate될 수 있는 일부 HTML 코드를 받아서 DOM의 일부를 업데이트할 수 있습니다.
00:13:59그래서 그들은 Next.js나 React Router 프레임워크 모드 또는 TanStack Start와 같은 다른 프레임워크들처럼 빠르고 현대적인 단일 페이지와 같은 풀스택 애플리케이션을 구축할 수 있는 모든 기능을 제공하지만,
00:14:15더 간단합니다.
00:14:16그것이 명확한 목표입니다.
00:14:18이러한 앱을 구축하는 간단한 방법을 제공하는 것.
00:14:21그것이 그들이 하고자 하는 것입니다.
00:14:24이 프레젠테이션에는 더 많은 내용이 있습니다.
00:14:27길지만 제가 말한 것이 가장 중요한 부분이라고 생각합니다.
00:14:31그것이 제 주요 요점입니다.
00:14:33그들은 강력하고 간단한 풀스택 프레임워크를 제공하고 싶어 합니다.
00:14:37처음부터 작성하고 있고, 수동 업데이트 등이 있습니다.
00:14:41제가 설명한 모든 것, 우리에게 이것이 필요할까요?.
00:14:56그것이 큰 질문이고, 또 다른 큰 질문이 있습니다. 성공할까요?
00:15:02분명히 두 질문 모두 대답하기 꽤 어렵지만, 최선을 다해 답해보겠습니다. 우리에게 이것이 필요할까요?
00:15:08음,
00:15:08제 생각에 우리는 이미 많은 JavaScript 프레임워크를 가지고 있고,
00:15:14분명히 너무 많다고 말하는 사람들이 많을 것이므로 그렇다면 답은 '아니오'입니다.
00:15:19저는 항상 - 심지어 2018년에 매주 새로운 프레임워크가 나오던 그때도 - 혁신을 하고 새로운 아이디어를 시도하는 것은 항상 좋다고 생각했습니다.
00:15:29작은 차이만 있는 React와 같은 새로운 프레임워크가 필요하다고 생각하지 않습니다.
00:15:35그런 건 필요하지 않다고 생각하지만,
00:15:38수동으로 트리거되는 업데이트와 그들이 가진 다른 작은 것들이 있는 완전히 새로운 접근 방식,
00:15:44저는 그것이 훌륭한 아이디어라고 생각합니다.
00:15:47확실히 시도해볼 가치가 있습니다.
00:15:49흥미롭게 들립니다.
00:15:50React에 대한 더 간단한 대안을 제공할 수 있을지도 모르는데,
00:15:55React는 놀랍지만 수년에 걸쳐 꽤 복잡해졌습니다.
00:15:58그래서 네, 우리에게 필요할 수도 있습니다.
00:16:01성공할까요??
00:16:04물론 그것은 또 다른 질문입니다.
00:16:06특히 지금 AI와 대규모 언어 모델 시대에는 명백히 이러한 모델들이 일반적으로 기본적으로 React를 추천할 것이기 때문입니다.
00:16:14한편으로 코드 작성 방법을 모르는 사람들은 물론 적어도 직접적으로는 반드시 대상 청중이 아닙니다.
00:16:21그 부분은 나중에 다시 다루겠습니다.
00:16:23그래서 거기서는 문제가 되지 않습니다.
00:16:25하지만 경험 많은 개발자들은 Remix를 사용하는 데 관심이 있을 수 있으며,
00:16:31공식 예제 등의 도움으로 대규모 언어 모델을 조종하여 Remix 코드를 생성할 수 있습니다.
00:16:37단순히 더 간단한 코드베이스를 원하기 때문입니다.
00:16:40궁극적으로 개발자로서 우리는 여전히 우리의 코드를 다루기 때문입니다.
00:16:44우리는 코드의 상당 부분을 생성할 수 있지만, 여전히 대규모 언어 모델을 제어합니다.
00:16:50우리는 여전히 코드의 일부를 조정합니다.
00:16:52AI가 제대로 이해하지 못하는 매우 구체적인 기능을 염두에 두고 있다면 코드의 더 큰 부분을 작성할 수도 있습니다.
00:17:00따라서 명백히 개발자로서 우리는 여전히 기술 스택에 관심을 가지고 있습니다.
00:17:05저는 적어도 여전히 관심이 있고, 여러분 중 일부도 그럴 것이라고 확신합니다.
00:17:10그래서 거기서는 다른 것을 시도하는 것이 흥미로울 수 있으며,
00:17:14그 프레임워크가 대규모 언어 모델과 함께 사용하기 쉽고,
00:17:18대규모 언어 모델에게 그것을 사용하는 방법을 가르칠 수 있는 충분한 리소스가 있는 한 말이죠.
00:17:24물론 이것은 그들이 집중하고 우선순위로 두고 있는 것처럼 보입니다.
00:17:28그것은 제게 좋게 들립니다.
00:17:30그래서 그것은 확실히 그들에게 성공의 타당한 기회를 줄 수 있습니다.
00:17:34물론 어려울 것입니다.
00:17:36하지만 이봐요, 그것은 항상 그랬을 것입니다.
00:17:39아마도 그래서 저는 기회를 보지만, 물론 이렇게 말하자면 경쟁이 치열한 시장입니다.
00:17:44이제 중요한 것은 Remix가 Shopify에 속한다는 것입니다.
00:17:482022년에
00:17:52Shopify가 Remix를 인수했다고 말할 수 있습니다.
00:17:56그래서 Remix 팀은 Shopify의 일부가 되었습니다.
00:18:00이제 Shopify는 명백히 물론 적극적으로 유지되고 적어도 Shopify 내부에서 사용되는 프레임워크를 갖는 데 관심이 있습니다.
00:18:09그리고 그것으로 저는 단지 Shopify 마케팅 및 브랜딩 페이지를 위한 회사 내부를 의미하는 것이 아닙니다.
00:18:16Shopify 상점을 의미합니다.
00:18:19목표는 Shopify 위에 자신의 상점을 구축하고 싶어하고 그러한 상점을 조정하고 전체 상점을 구성하는 맞춤형 상점 전면이나 페이지를 구축하는 쉬운 방법을 원하는 Shopify 판매자들을 위한 옵션으로 Remix를 갖는 것일 가능성이 있습니다.
00:18:36그리고 그들은 물론 사용하기 쉽고 대규모 언어 모델과 함께 사용하기 쉬운 프레임워크를 갖는 것은 엄청날 수 있습니다.
00:18:44물론 여전히 보장은 아니지만 Remix 뒤에 Shopify가 있다는 것은 물론 많은 가치가 있을 것이라고 생각합니다.
00:18:52따라서 저는 Remix의 미래에 대해 상당히 긍정적입니다.
00:18:56또한 물론 그들이 작지만 제가 알 수 있는 한 매우 열정적인 커뮤니티를 가지고 있기 때문입니다.
00:19:02그들은 명백히 React Router 등을 개발하면서 훌륭한 실적을 가지고 있습니다.
00:19:08그래서 네, 저는 우리가 무엇을 얻게 될지 보게 되어 매우 기대됩니다.
00:19:13저는 마침내 그것을 직접 사용하게 되어 기대됩니다.
00:19:16왜냐하면 지금은 그것이 실제로 가능하지 않기 때문입니다.
00:19:20그리고 이것들이 그것에 대한 제 생각입니다.
00:19:23그러니까 항상 그렇듯이 우리가 그것을 필요로 한다고 생각하는지,
00:19:28그리고 그들이 성공할지에 대한 여러분의 생각을 알려주시고,
00:19:32관심이 있고 더 배우고 싶다면 컨퍼런스의 전체 4시간 분량을 시청하세요..