프로그레시브 향상 vs. 단일 페이지 앱

방금 보스턴에서 열린 컨퍼런스에서 An Event Apart 라고했습니다 .

연사들 사이에서 가장 인기있는 주제는 점진적 향상 이라는 아이디어였습니다 . 사이트의 콘텐츠는 HTML로 이동해야하며 JavaScript는 행동을 향상시키는 데만 사용해야합니다.

화자들이 점진적으로 향상시키기위한 주장은 매우 설득력이있었습니다. 구형 브라우저와 대역폭이 낮은 네트워크의 장치를 지원하기위한 견고한 패턴 일뿐만 아니라 HTML은 JavaScript보다 훨씬 우아하게 실패합니다 (예 : 지원되지 않는 마크 업은 무시 됨). 스크립트-당신은 호스입니다).

Jeremy Keith 는 이에 대해 특히 통찰력있는 연설을했습니다.

그러나 Backbone 및 Angular와 같은 단일 페이지 웹 앱은 어떻습니까? 이러한 프레임 워크의 기본 디자인은 개발자가 HTML에서 JSON API와 같은 컨텐츠로 컨텐츠를 이동하도록 개발자를 밀어 붙이는 것 같습니다.

점진적 향상 대 단일 페이지 웹 앱의 두 가지 디자인 패턴을 간과 할 수 없습니다. 하나가 다른 것보다 더 좋은 경우가 있습니까? 아니면 적대적 기술조차도 아니고, 내 정신 모델에 뭔가 빠진 것이 있습니까?

단일 페이지 앱이 점진적 향상의 모래에 선을 그리는 것 같습니다. SPA는 구현 및 기능이 수십 년 동안 돌아가는 브라우저마다 다르다는 사실을 해결하려고 시도하기 전에 특정 사이트의 대부분의 방문자가 충족 할 것이라고 합리적으로 판단 할 수있는 특정 기준이 있다고 가정합니다. 나는 두 사람이 서로 다르다고 생각하지 않습니다. SPA로 시작한 후에도 <video>태그로 시작한 다음 그 위에 풍부한 기능을 갖춘 플레이어를 레이어링 하는 등 계속 향상시킬 수 있습니다 .

그런 다음 스크립팅이 비활성화 된 방문자가 있지만 방문자가 무엇을하는지 알고 있습니다. "이 사이트에 스크립팅이 필요합니다"라는 메모 외에 개발자가 방문자를 위해 뒤로 구부려 야하는 이유는 알 수 없습니다. 이를 허용한다면 CSS를 비활성화 한 방문자에게도 어떻습니까? 이미지 비활성화는 어떻습니까? 이것들은 핵심 웹 기술입니다. 그들은 조각을 고르고 선택할 때 완벽하게 작동하는 웹 경험을 기 대해서는 안됩니다.

자동차 유추없이 도망 치지 않기 위해 특정 기능이 마음에 들지 않으면 자동차가 작동하지 않을 것이라고 생각합니다. 토목 기사에게 "헤드 라이트를 비활성화 했으므로 방문 할 수있는 곳마다 125 피트마다 가로등을 설치하십시오."라고 말할 수 있습니다. 전조등이 없으면 내 차는 많은 시간을 할애하지만 방문 할 수없는 곳도 있습니다.

SPA는 기존 요청 / 응답 페이지 모델에 맞지 않는 응용 프로그램을 만드는 경우 가장 유용합니다. 웹의 요청 / 응답주기에 잘 맞더라도 정규 웹 사이트가 SPA로 작성되는 최근 경향이 있습니다. IMHO가하는 일은 어리석은 노력입니다. 이러한 웹 사이트에서 좋아하는 작업은 버그가 많고 기능이 적은 웹 브라우저를 제대로 구현하지 못하는 것입니다.

점진적인 향상 및 SPA에 대한 아이디어는 이러한 어리석은 단일 페이지 응용 프로그램 웹 사이트에서 상호 배타적이지 않습니다. 컨텐츠 협상 (예 : 헤더 수락)을 수행하려면 SPA의 Javascript가 사전 렌더링 된 HTML 페이지 대신 자체 렌더링 할 수있는 JSON 자원을 수신하기 위해 Javascript가 필요합니다. 이러한 종류의 웹 사이트 SPA의 문제는 명백합니다. 서버와 클라이언트 모두에서 웹 사이트 렌더링을 중복 구현해야합니다.

진정한 웹 애플리케이션, 즉 표준 요청 / 응답 패턴에 맞지 않기 때문에 진정으로 SPA 여야하는 애플리케이션; 점진적 향상은 실제로 응용 프로그램을 이식 가능하게 작성하기위한 기술 플랫폼으로 브라우저를 사용하기 때문에 실제 응용 프로그램의 경우 훨씬 더 어렵습니다. 스크립팅 언어는 개선을 위해 선택적으로 볼트로 묶을 수있는 것이 아니라 진정한 웹 응용 프로그램의 필수 부분입니다. 그래도 플래시 비디오 / 오디오를 <video>/ <audio>태그로 대체하는 점진적인 개선 기술이 계속 작동 하지만 실제 웹 응용 프로그램에는 기본으로 자바 스크립트가 필요합니다.

나는 단일 페이지 웹 응용 프로그램과 점진적 향상이 거의 길항제라고 생각합니다. json API에서 검색 한 데이터를 사용하여 HTML을 클라이언트에서 계산하면 정상적으로 저하 될 수 없습니다. 그러나보다 풍부하고 쾌적한 사용자 인터페이스를 제공 할 수 있습니다.

응용 프로그램을 크롤링하고 정적 버전을 저장하는 봇을 설정할 수 있습니다. 이 기술은 자바 스크립트 (맹인 또는 검색 엔진 봇에서 사용)없이 브라우저에 HTML을 제공하는 데 사용할 수 있습니다. 이것은 투자이므로 실제로 귀하의 요구 사항에 부합합니다.

특정 회사를 위해 HR 관리 웹앱을 만들고 있습니까? 우아한 성능 저하가 필요하지 않으며 SPA를 구축하는 것이 더 간단 할 수 있습니다. 회사는 특정 브라우저 사용을 강제 할 수 있으므로 테스트 횟수가 줄어 듭니다.

접근성 요구 사항 및 검색 엔진 가시성 요구 사항과 관련된 협회를위한 공개 웹 사이트를 만들고 있습니까? 그런 다음 서버에서 HTML을 작성하십시오. 또는 예산에 따라 정적 버전으로 SPA를 만드십시오.

프로그레시브 향상으로 얼마나 멀리 가고 싶은가에 달려 있다고 생각합니다. 단단하고 빠른 규칙 세트가 아닌 디자인 패러다임입니다.

SPA 프레임 워크를 사용하는 경우 Javascript를 허용하는 것이 좋습니다. 그러나 페이지를 향상시키기 위해 작성하는 Javascript는 프레임 워크가 생성 할 수있는 HTML을 처리 할 수있을 정도로 똑똑해야합니다.

최신 브라우저 릴리스에 대한 최신 CSS 기능 또는 HTML5에서 HTML4 로의 성능 저하와 같은 다른 PE 기술의 이점을 활용할 수도 있습니다.

점진적 향상과 단일 페이지 앱이 공존 할 수 있습니다. 이런 식으로 앱을 빌드 할 때 들었던 가장 강력한 두 가지 주장은 다음과 같습니다.

• 완전하지만 참조 된 스크립트로 HTML 파일 다운로드가 발생하는 네트워크 연결 (모바일 네트워크에서 가능)로 인해 완전히 다운로드되지 않은 상황에서 내결함성
• 초기 페이지로드시 인식 성능 향상 가능성 (렌더링 시간 단축)

서버 측 렌더링 (이것은 SEO의 이유가 아니라 사용자를위한 것임)과 오해를 차단하는 것은 현대적인 클라이언트 측 JS 프레임 워크를 사용하여 점진적으로 향상된 단일 페이지 앱을 빌드하는 데 도움이되는 두 가지 기술입니다.

일부 클라이언트 쪽 JS 프레임 워크는 다른쪽에 비해 서버 쪽 렌더링 작업이 더 쉽습니다 ( 일부 서버 쪽 렌더링 솔루션은 프레임 워크 조합이 서버를 렌더링하는 페이지가 검색 엔진 소비만을위한 것이기 때문에 작동하는 SPA를 생성하지 않음에주의하십시오). -사용자 ).

글을 쓰는 시점에 React.js와 Ember (곧 출시 될 FastBoot 포함)는 서버 측 렌더링을 일류 시민으로 만들려고하거나 알고있는 두 사람입니다. 서버 측 렌더링 페이지는 클라이언트 브라우저에서 구문 분석 될 때 여전히 작동하는 SPA입니다.

나는 페이지로드 감소가 아마도 서버와 네트워크에 상당히 좋다는 견해를 가지고 있습니다. 더 많은 SPA가 올바르게 사용되기를 바랍니다.

나는 두 가지가 필요하지만 견해를 벗어났습니다.

1) 초기로드시 모든 링크를 표준 ​​요청 / 응답 링크로 설정하고, SPA 프레임 워크 / 라이브러리가 브라우저가로드되고 JS 엔진이 SPA 지원이 사용 가능한 것으로 확인되면이를 업데이트 된 (대화식) 버전으로 바꾸십시오. 이것은 진정으로 진보적 인 향상입니다. JS는 기존 html 웹 사이트 위에로드되며 검색 엔진, 보조 기술 및 이전 브라우저에 더 좋습니다.

과

2) 서버는 올바른 형식을 제공하여 / foo / bar / json 및 foo / bar와 같은 경로에 응답해야합니다. 사실 첫 페이지를 얻기 위해 레이아웃과 부분으로 모든 것을 래핑하는 경우 두 번째 및 이후 페이지의 레이아웃과 부분을 통해 모든 것을 가져올 수 있습니다.

여기에는 약간의 작업이 있습니다. 물론, 전체 스택을 제어 할 수 있다면 두 기술의 균형을 맞 춥니 다.