JavaScript 프레임워크의 4가지 시대

2012년에 저는 주로 JavaScript로 코딩을 시작했습니다. 저는 지역 비즈니스를 위해 PHP 애플리케이션, 기본 CMS 및 웹사이트를 처음부터 끝까지 구축한 적이 있는데, 회사에서는 이를 다시 작성하고 일부 기능을 추가하기로 결정했습니다.

프로젝트 관리자는 제가 .NET을 사용하기를 원했습니다. 부분적으로는 자신이 알고 있었기 때문이기도 하지만 앱이 기본 앱처럼 느껴지기를 원했기 때문이기도 합니다. 즉, 페이지를 새로 고치거나 작업 작업을 오래 기다리지 않아도 됩니다. 몇 가지 조사와 프로토타입 제작 후에 저는 당시 막 등장하기 시작한 새로운 JS 프레임워크를 사용하여 이러한 작업을 수행할 수 있다고 관리자를 설득했습니다.

제가 선택한 첫 번째 프레임워크는 사실 Angular 1이었습니다. 상당히 큰 앱을 구축하고 FuelPHP의 백엔드를 사용한 후 라우터에 몇 가지 문제가 발생했습니다. 하위 경로/출구가 다시 렌더링될 때마다 깜박거리고 실제로 설계 중인 것처럼 느껴졌습니다. 이 시나리오는 고려되지 않았습니다. 시간.

​나중에 어떤 분이 Ruby on Rails + Ember를 추천해 주셨는데, 사용해 보시고 정말 효과가 좋다고 생각했어요. 또한 두 프레임워크의 아이디어도 마음에 들고, 이러한 커뮤니티 생태도 마음에 들고, 전반적으로 당시 대안에 비해 매우 생산적이었습니다.

그 이후로 많은 변화가 있었습니다. 프레임워크가 많이 등장하고 발전했습니다. 브라우저에서 JavaScript를 사용하여 애플리케이션을 구축할 수 있다는 아이디어는 다소 비주류에서 표준 관행으로 발전했습니다. 우리가 구축한 인프라가 완전히 바뀌어 새로운 가능성이 가능해졌습니다.

이 기간 동안에도 다양한 아이디어 사이에 경쟁과 갈등이 꽤 있었습니다. 사용할 JavaScript 프레임워크, CSS 작성 방법, 기능적 프로그래밍과 객체 지향 프로그래밍, 상태를 가장 잘 관리하는 방법, 가장 유연하고 빠른 빌드 시스템 또는 도구 등 돌이켜보면 우리가 종종 잘못된 것에 대해 논쟁하고 일부 미래 지향적 고려 사항을 무시하는 모습이 재밌습니다. 물론 이것도 뒤늦은 판단입니다.

그래서 저는 지난 수십 년간의 JavaScript 개발을 되돌아보고 우리가 얼마나 멀리 왔는지 회고하고 싶었습니다. 크게 4개의 시대로 나눌 수 있습니다. :

• 원래 시대
• 첫 번째 프레임워크
• 컴포넌트 중심 뷰 레이어
• 풀 스택 프레임워크

모든 시대에는 고유한 테마와 핵심 모순이 있으며 동시에 핵심 교훈도 배우고 싶어합니다. , 그리고 꾸준히 전진하십시오.

오늘도 논쟁은 계속됩니다. 웹이 너무 비대해지고 있나요? 일반 웹사이트를 정말 React로 작성해야 할까요? JavaScript를 사용해야 할까요? 물론, 현재가 미래를 대변할 수는 없으며 기존 프레임워크는 미래에 교체될 가능성이 높습니다. 그러나 이는 우리가 앞으로 나아갈 수 있도록 일부 기존 관점을 기반으로 합니다.

Original Years

JavaScript는 1995년에 처음 출시되었습니다. 위에서 언급했듯이 저는 거의 20년 후인 2012년에 JS를 작성하기 시작했습니다. 이는 소위 첫 번째 프레임워크 시대가 시작될 무렵이었습니다. 내가 여기에서 많은 역사를 얼버무리고 있을 수도 있고 이 시대가 각각 고유한 패턴, 라이브러리, 빌드 도구 등을 가진 여러 하위 시대로 나누어질 수도 있다고 가정할 수 있습니다.

즉, 경험하지 않은 것에 대해서는 글을 쓸 수 없다는 거죠. 제가 프런트엔드 애플리케이션을 작성하기 시작했을 때, 새로운 세대의 프레임워크가 이제 막 성숙해지기 시작했습니다. Angular.js, Ember.js, Backbone 등.

이전에는 jQuery, MooTools 등의 라이브러리가 가장 앞선 기술이었습니다. 이러한 라이브러리는 그 시대에 중요했습니다. 브라우저가 중요했던 JavaScript를 구현하는 방식의 차이점을 완화하는 데 도움이 되었습니다.

예를 들어, IE가 이벤트를 구현하는 방식은 이벤트를 버블링하고 이벤트를 캡처하는 Netscape와 완전히 다릅니다. 이것이 오늘날 우리 표준이 마침내 두 가지를 모두 구현하는 이유입니다. 하지만 그때까지는 라이브러리를 사용하여 두 브라우저 모두에서 작동하는 코드를 작성해야 합니다.

이 라이브러리는 주로 작고 독립적인 사용자 인터페이스 구성 요소를 만드는 데 사용됩니다. 대부분의 애플리케이션 비즈니스 로직은 여전히 ​​양식과 표준 HTTP 요청을 통해 수행됩니다. HTML은 서버에서 렌더링되어 클라이언트에 제공됩니다.

적어도 제가 아는 한 요즘 시대에 말할 수 있는 빌드 도구는 없습니다. 당시 JavaScript에는 모듈이 없었기 때문에(적어도 표준 모듈은 없었음) 코드를 가져올 방법이 없었습니다. 모든 것이 글로벌하므로 정리하기가 매우 어렵습니다.

이러한 환경에서 JS는 완전한 애플리케이션을 작성하는 데 사용하는 언어라기보다는 장난감 언어로 간주되는 경우가 많습니다. 그 당시 우리가 했던 가장 일반적인 일은 jQuery를 사용하고 일부 UI 위젯에 대한 스크립트를 작성하는 것이었고 그게 전부였습니다.

시간이 흐르고 XHR이 도입되고 대중화되면서 사람들은 UI 프로세스의 일부를 페이지에 넣기 시작했습니다. 특히 클라이언트와 서버 간에 여러 번의 앞뒤 상호 작용이 필요한 복잡한 프로세스의 경우 애플리케이션이 대부분의 프로그램에 사용되었습니다. 서버에 남아있습니다.

이것은 모바일 앱이 등장하기 시작했을 때와는 완전히 대조적입니다. 처음부터 iOS 및 Android의 모바일 앱은 Objective C 및 Java와 같은 의미 없는 언어™로 작성된 완전한 애플리케이션이었습니다. 또한 완전히 API 기반입니다. 모든 UI 로직이 장치에 있고 서버와의 통신은 순전히 데이터 형식입니다. 이는 더 나은 사용자 경험과 모바일 앱의 폭발적인 증가로 이어졌으며 오늘날 모바일이 더 나은지 웹이 더 나은지에 대한 논쟁으로 직접 이어졌습니다.

이 모든 작업을 JavaScript로 수행하는 것은 처음에는 터무니없는 것으로 간주되었습니다. 그러나 시간이 지남에 따라 응용 프로그램이 더욱 야심적으로 변하기 시작했습니다. 소셜 네트워크에는 채팅, DM 및 기타 실시간 기능이 추가되었으며 Gmail과 Google Docs는 동등한 데스크톱 애플리케이션을 브라우저에서 작성할 수 있음을 보여 주었고 웹이 어디에서나 작동하고 더 쉬웠기 때문에 점점 더 많은 회사가 웹 애플리케이션 작성으로 전환했습니다. -기간 유지 관리. 이로 인해 업계 전체가 발전하게 되었습니다. 이제 JS를 사용하여 사소하지 않은 애플리케이션을 작성할 수 있다는 것이 분명해졌습니다.

당시 JavaScript에는 오늘날의 모든 기능이 없었으며 모든 것이 전역적이었고 일반적으로 각 외부 라이브러리를 수동으로 다운로드하여 정적 폴더에 추가해야 했습니다. NPM은 아직 존재하지 않았고, 모듈도 존재하지 않았으며, JS에는 현재 기능의 절반도 없었습니다.

대부분의 경우 각 애플리케이션은 사용자 정의되고, 각 페이지에는 서로 다른 플러그인 설정이 있으며, 각 플러그인에는 상태 관리 및 업데이트 업데이트를 위한 서로 다른 시스템이 있습니다. 이러한 문제를 해결하기 위해 가장 초기의 JavaScript 프레임워크가 등장하기 시작했습니다.

첫 번째 프레임워크

2000년대 후반과 2010년대 초반에 첫 번째 JS 프레임워크는 완전한 클라이언트 측 애플리케이션을 작성하기 위해 특별히 등장하기 시작했습니다. 이 시대의 몇몇 유명한 프레임워크:

1. Backbone.js
2. Angular 1
3. Knockout.js
4. SproutCore
5. Ember.js
6. Meteor.js

물론 더 많은 프레임워크가 있습니다. 일부는 특정 서클에서 더 큽니다. 이것은 제가 기억하는 것들입니다. 주로 Xiao Ming이 이를 코딩에 사용했고 비교적 인기가 있었기 때문입니다.

미지의 영역으로 진입하는 세대 프레임워크입니다. 한편으로 그들이 하려고 했던 일은 매우 야심적이었고 많은 사람들은 그것이 실제로 성공하지 못할 것이라고 생각했습니다.

단일 페이지 JS 애플리케이션(SPA)이 근본적으로 더 나쁘고 여러 면에서 그들이 옳다고 주장하는 반대자들이 많습니다. 클라이언트 측 렌더링은 봇이 이러한 페이지를 쉽게 크롤링할 수 없으며 사용자가 심지어 기다려야 함을 의미합니다. 애플리케이션 그리기를 시작하는 데 몇 초가 걸립니다. 이러한 앱 중 다수는 접근성이 좋지 않으며 JavaScript가 꺼져 있으면 전혀 작동하지 않습니다.

반면에 우리는 JS로 전체 애플리케이션을 구축한 경험이 없기 때문에 최선의 접근 방식에 대해 수많은 경쟁 아이디어가 있습니다. 대부분의 프레임워크는 다른 플랫폼에서 널리 사용되는 것을 모방하려고 시도하므로 거의 모든 프레임워크가 Model-View-*의 일부 반복이 됩니다. 모델-뷰-컨트롤러, 모델-뷰-생산자, 모델-뷰-뷰모델 등이 있습니다. 그러나 장기적으로 봤을 때 이것들은 실제로 성공하지 못합니다. 특히 직관적이지 않고 매우 빠르게 매우 복잡해집니다.

이 시기는 JavaScript 애플리케이션을 컴파일하는 방법을 실제로 실험하기 시작한 시대이기도 했습니다. Node.js는 2009년에 출시되었고 NPM은 2010년에 (서버 측) JavaScript용 패키지를 도입하면서 뒤를 이었습니다.

CommonJS와 AMD는 JS 모듈을 가장 잘 정의하는 방법을 두고 싸우고, Grunt, Gulp, Broccoli와 같은 빌드 도구는 이러한 모듈을 최종 제품으로 결합하는 방법을 놓고 다투고 있습니다.

대부분의 경우 JavaScript를 구축하는 모든 것을 실제로 구축할 수 있는 매우 일반적인 작업 실행기 스타일 도구입니다. HTML, CSS/SASS/LESS 및 웹 애플리케이션에 사용되는 기타 여러 가지 도구도 있습니다.

그러나 우리는 이 시대에서 많은 것을 배웠습니다.

• URL 기반 라우팅이 기반입니다. 이 라우팅이 없는 애플리케이션은 웹을 중단시키므로 처음부터 프레임워크에서 이를 고려해야 합니다.
• 템플릿 언어를 통해 HTML을 확장하는 것은 강력한 추상화 계층입니다. 때로는 약간 투박할 수도 있지만 사용자 인터페이스를 상태와 동기화하는 것이 더 쉬워집니다.
• SPA의 성능은 매우 낮고 웹에는 기본 애플리케이션에 없는 추가 제한 사항이 많이 있습니다. 웹을 통해 모든 코드를 게시하고 JIT를 수행한 다음 로컬 애플리케이션이 다운로드되고 컴파일되는 동안 이를 실행하여 애플리케이션을 시작해야 하는데 이는 어려운 작업입니다.
• 언어로서 JavaScript에는 많은 문제가 있으며 상황을 개선하려면 개선이 필요합니다. 프레임워크만으로는 이를 수행할 수 없습니다.
• 대규모로 애플리케이션을 작성하려면 더 나은 구축 도구, 모듈 및 패키징이 확실히 필요합니다.

전반적으로 이 시대는 생산적입니다. 단점에도 불구하고 애플리케이션의 복잡성이 증가함에 따라 클라이언트를 API에서 분리함으로써 얻을 수 있는 이점은 엄청나며 많은 경우 결과적인 사용자 경험은 놀랍습니다. 특별한 사정이 없는 한 이 시대는 계속될 수 있으며, MV* 스타일의 아이디어는 계속해서 반복되고 있습니다.

그런데 갑자기 소행성이 나타나 기존 패러다임을 산산조각내고 소규모 멸종 사건을 일으키며 우리를 다음 시대로 밀어넣는다. 이 소행성을 리액트(React)라고 한다.

컴포넌트 중심 뷰 레이어

저는 React가 컴포넌트를 발명했다고 생각하지 않지만, 솔직히 말해서 그것이 처음 어디서 왔는지는 잘 모르겠습니다. 그러나 이는 적어도 .NET의 XAML로 거슬러 올라가며, 그때부터 웹 구성 요소가 사양으로 발전하기 시작했습니다. 궁극적으로 그것은 중요하지 않았습니다. 일단 아이디어가 떠오르면 모든 주요 프레임워크는 이를 매우 빠르게 채택했습니다.

돌이켜 보면 이는 완전히 의미가 있습니다. HTML을 확장하고, 수명이 긴 상태를 줄이고, JS 비즈니스 로직을 템플릿(JSX, 핸들바 또는 지시어 등)에 직접 바인딩합니다.

구성 요소 기반 응용 프로그램은 작업을 완료하는 데 필요한 대부분의 추상화를 제거하고 코드 수명 주기를 크게 단순화합니다. 모든 것이 응용 프로그램의 수명 주기가 아닌 구성 요소의 수명 주기에 연결되어 있으므로 개발자로서 생각할 것이 훨씬 적습니다. 에 대한.

그러나 그 당시에도 변화가 있었습니다. 프레임워크는 본격적인 프레임워크가 아닌 "뷰 레이어"로 스스로를 홍보하기 시작했습니다. 프런트 엔드 애플리케이션에 필요한 모든 문제를 해결하는 대신 렌더링 문제 해결에 중점을 둡니다.

라우팅, API 통신, 상태 관리 등의 기타 문제는 사용자가 결정합니다. 이 시대의 유명한 프레임워크는

1. React.js
2. Vue.js
3. Svelte
4. Polymer.js

외 다수입니다. 지금 돌이켜보면 이 프레임워크는 실제로 두 가지 주요 작업을 수행했기 때문에 2세대 프레임워크 중에서 인기 있는 프레임워크였던 것 같습니다.

• 범위가 극적으로 좁아집니다. 이러한 모든 문제를 미리 해결하려고 하기보다는 프레임워크의 핵심이 렌더링에 중점을 두고 있으며 더 넓은 생태계 내의 다른 기능에 대해 다양한 아이디어와 방향을 탐색할 수 있습니다. 나쁜 해결책도 많지만 좋은 해결책도 있어 다음 세대가 크림에서 최고의 아이디어를 선택할 수 있는 길을 열어줍니다.
• 이렇게 하면 우리가 이를 더 쉽게 받아들일 수 있습니다. 전체 웹 페이지를 장악하기 위해 완전한 프레임워크를 채택한다는 것은 대부분의 애플리케이션을 다시 작성하는 것을 의미하는데, 이는 기존 서버 측 모놀리스로는 불가능합니다. React 및 Vue와 같은 프레임워크를 사용하면 한 번에 하나의 위젯이나 구성 요소를 기존 애플리케이션에 작은 조각으로 배치하여 개발자가 기존 코드를 점진적으로 마이그레이션할 수 있습니다.

이 두 가지 요인으로 인해 1세대 프레임워크를 능가하는 2세대 프레임워크가 빠르게 개발되었습니다. 멀리서 보면 모든 것이 합리적이고 합리적인 진화입니다. 하지만 당시 그 안에 있는 것은 상당히 실망스러운 경험이었습니다.

우선, 직장에서 어떤 프레임워크를 사용할지, 애플리케이션을 다시 작성해야 할지 논의할 때, 우리는 그런 프레임워크를 자주 접하지 않습니다. 대신에 "더 빠릅니다!", "더 작습니다!" 또는 "필요한 모든 것이 있습니다!"라고 말하는 경우가 많습니다.

함수형 프로그래밍과 객체 지향 프로그래밍에 대한 논쟁도 있으며 많은 사람들이 FP를 모든 문제에 대한 해결책으로 지적합니다. 공평하게 말하면 이러한 것들은 사실입니다. 뷰 레이어 전용 프레임은 (처음에는) 더 작고, 더 빠르며(처음에는) 필요한 모든 것입니다(직접 많은 것을 만들거나 연결하는 경우).

물론 함수형 프로그래밍 패턴은 JavaScript를 괴롭히는 많은 문제를 해결하며, 평균적으로 JS가 그 패턴 때문에 더 좋다고 생각합니다.

그러나 현실은 마법의 총알이 전혀 없다는 것입니다. 애플리케이션은 여전히 ​​크고, 비대하고 복잡하며, 상태는 여전히 관리하기 어렵고, 라우팅 및 SSR과 같은 기본적인 문제는 여전히 해결해야 합니다.

우리 중 많은 사람들이 원하는 것은 이러한 모든 문제를 해결하려는 솔루션을 포기하고 독자가 스스로 해결하도록 하는 솔루션으로 대체하는 것입니다.

내 경험에 따르면 이것은 새로운 제품이나 기능을 제공하기 위해 이러한 변화를 기꺼이 수용한 다음 이러한 모든 추가 기능을 완전히 개발하는 데 필요한 시간을 투자하지 않는 엔지니어링 그룹 사이에서 일반적인 관행이기도 합니다.

그 결과 이러한 뷰 레이어를 중심으로 구축된 자체 제작 프레임워크가 탄생했습니다. 이 프레임워크 자체는 비대하고 복잡하며 작동하기 매우 어렵습니다.

사람들이 SPA를 사용하면서 겪는 많은 문제는 SPA 이용이 폭발적으로 증가하면서 이러한 파편화된 생태계에서 비롯된 것이라고 생각합니다. 나는 아직도 라우팅을 제대로 하지 않거나 다른 작은 세부사항을 잘 처리하지 않는 새로운 웹사이트를 자주 접하게 되는데, 그것은 정말 실망스럽습니다.

그러나 반면에 기존의 1세대 풀서비스 프레임워크는 이러한 문제를 해결하는 데 그다지 좋은 역할을 하지 못합니다. 그 중 일부는 기술적인 부채 부담이 많기 때문입니다. 1세대 프레임워크는 ES6 이전, 모듈 이전, Babel 및 Webpack 이전, 우리가 많은 것을 파악하기 전에 구축되었습니다.

반복적 진화는 매우 어려우며 Angular가 Angular 2에서 했던 것처럼 완전히 다시 작성하면 커뮤니티의 추진력이 사라집니다.

그래서 JavaScript 프레임워크와 관련하여 개발자는 딜레마에 빠져 있습니다. 이제 노후화되기 시작한 올인원 솔루션을 선택하거나 프레임워크의 무료 DIY 절반에 뛰어들어 희망을 품는 것입니다. 최선을 다해.

당시에는 많이 답답했지만 결국 많은 혁신을 만들어냈습니다. JavaScript 생태계는 매우 빠르게 발전했으며 이러한 프레임워크가 모범 사례를 파악함에 따라 여러 가지 주요 변경 사항이 발생했습니다.

• Babel과 같은 트랜스파일러가 표준이 되어 언어를 현대화하는 데 도움이 됩니다. 기능이 표준화될 때까지 수년을 기다리지 않고 오늘 바로 사용할 수 있으며 언어 자체가 더 빠르고 반복적인 속도로 기능을 추가하기 시작합니다.
• ES 모듈이 표준화되어 마침내 Rollup, Webpack 및 Parcel과 같은 최신 빌드 도구를 구축하기 시작했습니다. 가져오기 기반 번들링은 스타일 및 이미지와 같은 JS가 아닌 리소스의 경우에도 서서히 표준이 되어가고 있으며, 이는 빌드 도구의 구성을 크게 단순화하여 도구를 더 간결하고, 더 빠르고, 더 포괄적으로 만듭니다.
• 더 많은 API가 표준화됨에 따라 Node와 웹 표준 사이의 격차는 느리지만 꾸준히 줄어들고 있습니다. SSR은 실제로 가능성이 되기 시작했고 이후 모든 주요 애플리케이션이 수행하는 작업이었지만 매번 사용자 정의 설정이었습니다.
• Edge Computing이 출시되어 JavaScript 기반 서버 애플리케이션에 SPA의 배포/응답 시간 이점을 제공합니다(이전에는 완전히 로드하고 종료하는 데 시간이 더 오래 걸리더라도 Spas는 일반적으로 CDN의 정적 파일로 인해 더 빠르게 로드되기 시작했습니다).

이 시대의 끝에도 여전히 몇 가지 질문이 남아 있습니다. 이전보다 더 나은 모델이 있음에도 불구하고 상태 관리 및 응답성은 까다로운 문제였으며 여전히 그렇습니다.

성능은 여전히 ​​어려운 문제이고 상황이 개선되고 있지만 여전히 부풀려진 SPA가 많이 있습니다.

접근성 상황도 개선되었지만 많은 엔지니어링 조직에서는 여전히 이를 나중에 고려하는 경우가 많습니다. 그러나 이러한 변화는 우리가 현재 진입하고 있는 차세대 프레임워크를 위한 길을 열었습니다.

풀스택 프레임워크

개인적으로 마지막 프레임워크 시대가 정말 조용히 다가왔습니다. 나는 지난 4년 동안 Ember의 렌더링 레이어 내부를 파헤쳐 1세대 프레임워크(여전히)로서 영향을 미쳤던 앞서 언급한 기술적 부채를 해결하려고 노력했기 때문이라고 생각합니다. 하지만 이는 더 미묘하기 때문이기도 합니다. 모든 3세대 프레임워크가 이전 세대의 뷰 계층 프레임워크를 기반으로 구축되었기 때문입니다. 이러한 프레임워크에는 다음이 포함됩니다.

1. Next.js(React)
2. Nuxt.js(Vue)
3. Remix(React)
4. SvelteKit(Svelte)
5. Gatsby(React)
6. Astro(Any)

시작되었습니다. 뷰 레이어의 성숙도와 통합. 이제 구성 요소가 코어 위에 구축된다는 점에 모두 동의했으므로 라우터, 빌드 시스템, 폴더 구조 등 애플리케이션의 다른 부분을 표준화하는 것이 합리적입니다.

천천히, 이러한 메타 프레임워크는 1세대 올인원 솔루션과 동일한 기능을 기본적으로 구축하기 시작했으며, 각 생태계에서 최고의 패턴을 선별하고 성숙해짐에 따라 통합하고 있습니다.

그리고 그들은 한발 더 나아갔습니다.

이전까지 SPA는 클라이언트에만 집중해왔습니다. SSR은 모든 프레임워크가 해결하고 싶어하는 문제이지만 최적화, 렌더링 방법으로만 사용되며 최종적으로 메가바이트의 JS가 로드되면 대체됩니다.

1세대 프레임워크 중 하나인 Meteor.js만이 더 깊이 생각해 볼 수 있었지만 동형 JS라는 아이디어는 실제로 실현되지 않았습니다.

그러나 애플리케이션의 크기와 복잡성이 증가함에 따라 아이디어가 다시 논의되었습니다.

우리는 특정 요청에 대한 API 비밀 숨기기, 페이지 반환 시 헤더 수정, API 요청 프록시 등의 작업을 수행할 수 있도록 백엔드와 프런트엔드를 함께 페어링하는 것이 실제로 매우 유용하다는 것을 알았습니다. Node와 Deno가 점점 더 많은 웹 표준을 구현하고 서버 측 JS와 클라이언트 측 JS 간의 격차가 매년 줄어들면서 결국 그렇게 미친 아이디어는 아닌 것처럼 보이기 시작했습니다. 이를 엣지 컴퓨팅 및 놀라운 도구와 결합하면 놀라운 잠재력이 있습니다.

최신 세대의 프레임워크는 이러한 잠재력을 최대한 활용하여 클라이언트와 서버를 원활하게 혼합하며 이것이 얼마나 놀라운 느낌인지 이루 말할 수 없습니다. 지난 9개월 동안 SvelteKit을 사용하면서 몇 번이나 앉아서 스스로에게 이렇게 말했는지 모르겠습니다. "이것이 우리가 항상 해야 할 일입니다.

다음은 제가 수행하는 작업 중 일부입니다. 최근에 이 설정을 사용하면서 이러한 작업이 엄청나게 쉬워졌습니다.

• 인증 토큰이 서버를 떠나지 않도록 애플리케이션에 서버 측 OAuth를 추가하고 API에 요청할 때 토큰을 추가하는 API 프록시를 추가합니다.
• 특정 경로를 CDN에 직접 프록시하여 다른 프레임워크에 구축된 정적 HTML 페이지를 호스팅하여 사용자가 자신만의 사용자 정의 페이지(일부 클라이언트에게 제공하는 서비스)를 만들 수 있도록 합니다.
• 키가 필요한 외부 서비스를 사용해야 하는 경우 몇 가지 다른 일회성 API 경로를 추가하세요(API에 완전히 새로운 경로를 추가하고 백엔드 담당자와 조정할 필요가 없음).
• LaunchDarkly 사용을 서버 측으로 이동하여 더 적은 양의 JS를 로드하여 전체 비용을 절감합니다.
• 백엔드 라우팅을 통해 Sentry 요청을 프록시 처리하여 광고 차단기로 인해 보고되지 않은 오류를 포착할 수 있습니다.

그리고 이것은 빙산의 일각에 불과합니다. 이 패턴에는 정말 멋진 점이 많이 있습니다. 그 중 가장 큰 점은 서버와 클라이언트의 결합된 기능을 활용하여 사용자가 비활성화할 경우 클라이언트가 기본으로 돌아갈 수 있도록 하는 점진적인 향상 아이디어를 다시 활성화하는 방법입니다. 자바스크립트 HTML + HTTP.

스파 일을 시작했을 때 나 자신도 스파가 미래의 트렌드라고 생각하며 이 관행을 완전히 포기했지만, 스파가 다시 부활하는 세상을 잠재적으로 볼 수 있다는 것이 정말 멋집니다.

이것들은 새로운 기능입니다. 경험상 이러한 프레임워크를 차세대 프레임워크로 분류합니다. 이전에는 해결하기 어렵거나 불가능했던 문제가 이제는 사소한 문제가 되어 응답 처리 논리를 약간만 변경하면 됩니다.

신뢰할 수 있는 성능과 사용자 경험이 기본적으로 제공되며 추가 구성이 필요하지 않습니다. 완전히 새로운 서비스를 구축하는 대신 필요에 따라 엔드포인트나 미들웨어를 추가할 수 있습니다. 이것은 삶을 변화시켰습니다.

이 세대에서는 1세대와 2세대 프레임워크와 사용자 간의 주요 갈등 지점도 일부 해결되었다고 생각합니다.

그것은 제로 구성 용어로의 전환에서 시작되었지만 궁극적으로는 2세대 프레임워크를 중심으로 한 생태계의 성숙도와 안정성에 의해 주도되는 것이라고 생각하며, 이는 또한 문화적 전환이기도 합니다.

3세대 프레임워크는 이제 다시 올인원 솔루션이 되려고 노력하고 있으며 렌더링뿐만 아니라 프런트엔드 개발자로서 해결해야 하는 모든 근본적인 문제를 해결하려고 노력하고 있습니다.

이제 그 어느 때보다 스파를 괴롭히는 많은 문제에 대해 커뮤니티가 협력하고 중요하게는 이를 함께 해결하는 것처럼 느껴집니다.

다음은 어디로 갈까요?

전반적으로 JavaScript 커뮤니티가 올바른 방향으로 움직이고 있다고 생각합니다. 우리는 마침내 "단순한 뷰 계층"이 아닌 완전한 애플리케이션을 처음부터 구축하기 위한 성숙한 솔루션을 개발했습니다.

우리는 마침내 기본 앱 SDK와 동일한 출발선에서 경쟁하기 시작하여 즉시 사용할 수 있는 완벽한 툴킷을 제공합니다.

이 분야에서는 아직 해야 할 일이 많습니다. 접근성은 SPA 세계에서 오랫동안 사후 고려 사항이었으며 GraphQL 외부에서는 여전히 데이터 스토리가 일부 작업을 사용할 수 있다고 생각합니다(좋든 싫든 대부분의 웹은 여전히 ​​REST에서 실행됩니다).

하지만 추세는 맞고, 공유 솔루션의 방향으로 계속 나아가면 이러한 문제를 이전보다 더 나은 방법으로 해결할 수 있다고 생각합니다.

저는 또한 이러한 패턴을 웹 플랫폼 자체로 더욱 발전시킬 수 있는 잠재력에 대해서도 기대하고 있습니다. 웹 구성 요소는 여전히 조용히 반복되고 있으며 SSR과 같은 문제를 해결하고 글로벌 등록을 제거하여 이러한 3세대 프레임워크와 더 잘 호환됩니다.

다른 방향으로 WebAssembly는 이 패턴을 놀라운 방식으로 반복할 수 있습니다. 어떤 언어로든 풀스택 프레임워크를 작성할 수 있다고 상상해 보세요.

Rust, Python, Swift, Java 등과 같은 동형 언어는 마침내 앞면과 뒷면 사이의 장벽을 거의 0으로 줄일 수 있습니다. 시스템 가장자리에 있는 작은 HTML 템플릿(아이러니하게도 원을 거의 우회하게 만듭니다. 더 나은 사용자 경험을 제공하더라도).

저의 가장 큰 희망은 단편화의 시대와 새로운 JS 프레임워크의 시대를 매일 지나가고 있다는 것입니다. 자유와 유연성은 혁신을 낳지만, 웹에서의 혼란스럽고 단절되며 종종 근본적으로 망가진 경험으로 이어지기도 합니다.

개발자가 50개 이상의 옵션 중에서 선택하고 제한된 리소스와 촉박한 마감 기한으로 이를 조합해야 할 때 이것이 바로 우리가 보는 경험이며 의미가 있습니다. 일부 앱은 빠르고 일관되며 안정적이고 사용하기 재미있지만 다른 앱은 실망스럽고 혼란스럽고 느리고 손상되었습니다.

개발자에게 더 사용하기 쉽고 기본적으로 올바른 작업을 수행하는 도구를 제공할 수 있다면 전반적인 웹사이트가 더 좋아지고 전반적인 경험도 더 부드러워질 것입니다.

모든 웹사이트를 고칠 수는 없습니다. 아무리 많은 코드로도 열악한 UX 디자인을 고칠 수는 없습니다. 그러나 이는 공통 기반을 마련해 모든 웹사이트가 조금 더 나아질 수 있도록 하고 모든 개발자는 다른 일에 집중할 수 있는 시간을 더 많이 갖게 됩니다.

위 내용은 JavaScript 프레임워크의 4가지 시대의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!