지난 2 년 동안,나는 긍정적 인 방식으로 언급 된 동형 웹 앱이라는 용어를 점점 더 자주 들었습니다. 또한이 시간 동안,나는 기술에 대해 자신을 생각 했어. 내 결론은 동형 웹 앱이 나 또는 내가 일하는 전형적인 조직에 대한 가치를 추가하지 않을 무언가이다. 몇 가지가 나를 이 결론에 이르게 했다.
그러나 이유를 나열하기 전에 먼저 동형 자바 스크립트 라이브러리(즉,lod)를 생각한다는 것을 강조하겠습니다.제이스)는 굉장합니다. 또한 고립 된 동형 구성 요소가 가치가있을 수 있다고 생각합니다(예:라이브 업데이트 주식 시장 지표).
동형 웹 앱이 나 또는 내가 일하는 조직에 가치가 있다고 믿지 않는 이유는 다음과 같습니다:
- 웹 서버는 이제 자바 스크립트로 작성 될 수있다
- 동형 웹 앱은 비 사소한 애플 리케이션을위한 점진적 향상 될 수 없다
- 비 차단 데이터 흐름 대 차단
- 시간-투-상호 작용과 기괴한 계곡
- 자바 스크립트의 구문 분석시 모바일 장치 동결
- 최고의 개발자는 이제 값을 생산하지 바쁜
-
동형 웹 앱의 정의로 시작하고 싶습니다. 동형 웹 앱은 응용 프로그램 코드가 실행되는 위치를 알지 못하는 웹 앱입니다. 대신,이 지식은 인프라 코드에 보관되며 응용 프로그램 전체가 클라이언트 측과 서버 측 모두에서 실행되도록 합니다.
웹 서버는 이제 자바 스크립트로 작성 될 수있다
클라이언트 코드와 서버 코드가 동일한 경우(클라이언트는 오늘 자바 스크립트를 해석 할 수 있습니다),우리는 서버에 자바 스크립트를 사용하도록 제한됩니다. 나는 노드를 좋아한다.하지만 제 관점에서 볼 때 미래에 대안들을 개방하는 것이 더 낫다고 생각합니다.
동형 웹 앱은 사소한 앱에 대해 점진적 향상이 될 수 없습니다
클라이언트 측 자바 스크립트는 매우 낮은 대기 시간(하위 밀리 초)으로 세밀한 수준의 상호 작용을 허용하는 메모리 내 상태 시스템에 액세스 할 수 있습니다. 이는 링크 클릭 및 양식 제출에 의해 구동됩니다.
나에게 점진적 향상은 가능한 모든 장치/브라우저에서 이전 장치부터 현재 장치,미래에 이르기까지 액세스 할 수있는 기준선으로 시작하는 것입니다. 실제로 이는 서버 측 렌더링의 기준선을 의미합니다. 향상 단계는 가치를 높이기 위해 사이트/앱을 향상시킬 위치에 대한 비즈니스 결정입니다. 즉,향상은 응용 프로그램 코드(특정)에서 수행되며 인프라 코드(일반)에서 수행되지 않습니다.
동형 웹 앱이 점진적 향상을 얻는 방법은이 세분화 된 메모리 내 상태 시스템을 사용하여 링크와 양식 만 사용하도록”번역”하는 것입니다. 이것이 가능한 곳을 볼 수있는 유일한 경우는 처음부터 전체 클라이언트 측 렌더링이 필요하지 않은 곳이지만 경험을 향상시키기 위해 위에서 언급 한 최적화 기술 및 클라이언트 측 구성 요소(예:날짜의 입력 필드에 대한 캘린더 구성 요소)에 의존 할 수 있습니다.
이 솔루션의 변형은 서버 쪽 상태 시스템에서 모든 클라이언트 쪽 상태/전환을 지원하지 않는 것입니다. 이 경우 이는 응용 프로그램 코드에 반영되어 응용 프로그램 코드 환경을 민감하게 만드는 비즈니스 결정이어야하며 이는 동형 웹 앱의 아이디어에 어긋납니다.
동형 웹 앱이 점진적 향상을 얻는 방법은이 세분화 된 메모리 내 상태 시스템을 사용하여 링크와 양식 만 사용하도록”번역”하는 것입니다.
블로킹 대 비블로킹 데이터 흐름
서버 측 웹 및 클라이언트 측 웹의 렌더링 시퀀스는 다릅니다.
뷰를 렌더링하기 위해 일부 서비스에 대한 두 가지 요청을 수행해야한다고 상상해보십시오. 이러한 요청을 병렬로 수행 할 수 있습니다.
서버 측에서 두 번째 요청이 먼저 반환되면 응답의 해당 부분을 렌더링 할 수 있지만 첫 번째 요청이 렌더링되어 응답의 해당 부분을 브라우저로 다시 반환 할 때까지 해당 바이트를 보내는 것을 차단해야합니다.
클라이언트 측에서는 이 제약 조건이 존재하지 않습니다.
또한 위의 예가 가장 간단한 예라고 생각합니다. 루트 구성 요소가 스마트 한 구성 요소 트리(스마트/벙어리 구성 요소에 대한 설명은 프레젠테이션 및 컨테이너 구성 요소 참조),몇 가지 수준의 벙어리 구성 요소,그리고 스마트 한 리프 구성 요소가 있다고 상상해보십시오.
인프라는 스마트 리프의 컨텍스트가 손실되지 않도록하는 방법을 필요로하므로 서버/클라이언트 모드에 따라 차단/비 차단 실행을 제어 할 수 없습니다. 이 문제를 해결하는 한 가지 방법은 전체 프로그램을 자유 모나드로 실행하여 실행을 나중에 해석 할 데이터로 나타내는 것입니다. 또 다른 해결책은 어떤 형태의 방문자 패턴을 사용하고 구성 요소가 필요한 데이터를 선언하도록하는 것입니다(튜토리얼:동형 돌아 오는 응용 프로그램(사랑과 함께)을 손으로 만드는 것과 유사). 후자는 아마도 가장 쉽습니다. 내 요점은 다른 차단 모드의 문제는 아마도 처음에 상상하는 것이 훨씬 더 복잡 할 것입니다.
다른 디자인은”루트 구성 요소만 스마트 구성 요소가 될 수 있습니다”라는 규칙을 갖는 것입니다. 이 디자인은 서버 측에서는 좋지만 클라이언트 측에서는 그렇지 않다고 생각합니다:클라이언트 측의 구성 요소는 적어도 일부 시나리오(예:소셜 미디어 관련 구성 요소)에서 자체 데이터를로드 할 수 있어야합니다. 이러한 시나리오를 결코 허용하지 않는 규칙을 갖는 것은 매우 비생산적인 것처럼 보입니다.
시간-투-상호 작용과 기괴한 계곡
동형 웹 애플리케이션 접근 방식으로,사용자가 대화 형으로 보이지만 그렇지 않은 화면에 그래픽 요소를 보는 시간이 될 것입니다.즉,브라우저가 서버 응답을 렌더링 한 시간과 자바 스크립트를 다운로드,구문 분석 및 실행하는 시간 사이의 시간입니다. 이것은”기괴한 계곡”또는”포템킨 마을”이라고합니다.
이 트윗과 자세한 내용은 응답을 참조하십시오.이 트윗에 따르면”일반적인”휴대 전화에서 자바 스크립트
를 구문 분석하는 동안 모바일 장치가 정지됩니다. 말테 유블은 앰프 프로젝트의 기술 책임자이기 때문에 그가 말하는 것을 알고 있다고 생각합니다.
최고의 개발자가 가치를 창출하지 못함
동형 웹 앱은 높은 수준의 개발 기술을 요구하는 접근 방식입니다. 많은 지역(서구 세계에서는 적어도)에서 고도로 숙련 된 개발자를 찾고 모집하는 것은 어렵습니다. 동형 웹 앱을 개발하기로 선택하면 개발자가 내가 질문하는 것을 할 수 있도록 할당하여 비즈니스 가치를 전혀 창출 할 수 있습니다. 그들의 시간을 사용하는 더 나은 방법이 있다.
요약
동형 웹 앱은 웹 서버 언어/플랫폼 선택을 자바 스크립트로만 제한합니다. 그것은 점진적 향상을 허용하려는 야망을 가지고 있지만 제공 할 수는 없습니다. 차단/비 차단 데이터 흐름의 차이로 인해 높은 수준의 기술적 복잡성을 도입합니다. 그것은 일이 상호 작용하는 것으로 나타납니다 시간 창을 소개하지만,(기괴한 계곡)이 아니다. 자바 스크립트의 높은 금액은 자바 스크립트의 1 킬로바이트는 실속 사용자 인터페이스 스레드의 1 천분의 1 을 의미 규칙-에-엄지 손가락으로,모바일 브라우저를 정지. 이 복잡한 소프트웨어 설계를 필요로하기 때문에 그리고,그것은 당신의 최고의 개발자에서 귀중한 시간과 노력이 필요합니다–자신의 시간을 활용할 수있는 더 좋은 방법이있다.
마지막으로,나는 당신의 경험이 나와 다를 수 있음을 강조하고 싶습니다. 어쩌면 동형 웹 앱이 좋을 때 시나리오가있을 수 있습니다. 그러나 그들은 서버 측 웹 혜택과 클라이언트 측 웹 혜택 사이의 모든 격차를 해소하는 은색 총알이 아니며 두 가지 접근 방식의 단점을 모두 얻지 못합니다.
어떻게 생각하세요? 당신은”동형 것”을 고려 했습니까? 당신은 도전과 비용에 대한 어떤 생각을 가지고? 너는 어떻게 그들을 다루는가?
감사
이 주제에 대한 귀중한 토론에 대한 오스카 윅 스트어 및 퍼트 러스트에게 감사드립니다. 오스카는이 게시물을 검토-당신에게 오스카 감사합니다.
