JavaScript 프레임워크의 가격

웹사이트에 JavaScript 코드를 많이 사용하는 것보다 웹사이트 속도를 늦추는 더 빠른 방법은 없습니다. JavaScript를 사용할 때 XNUMX배 이상의 프로젝트 성능으로 비용을 지불해야 합니다. 사이트의 JavaScript 코드가 사용자 시스템을 로드하는 방법은 다음과 같습니다.

• 네트워크를 통해 파일을 다운로드합니다.
• 다운로드 후 압축을 푼 소스 코드를 파싱하고 컴파일합니다.
• JavaScript 코드 실행.
• 메모리 소비.

이 조합이 나온다 매우 비싸다.

그리고 우리는 프로젝트에 점점 더 많은 JS 코드를 포함합니다. 조직이 React, Vue 등과 같은 프레임워크 및 라이브러리로 구동되는 사이트로 이동함에 따라 우리는 사이트의 핵심 기능을 JavaScript에 크게 의존하게 만들고 있습니다.

JavaScript 프레임워크를 사용하는 매우 무거운 사이트를 많이 보았습니다. 그러나 이 문제에 대한 나의 시각은 매우 편향되어 있다. 사실 제가 함께 일하는 회사는 사이트 성능 분야에서 복잡한 문제에 직면했기 때문에 정확하게 저에게 의지합니다. 그 결과 이 ​​문제가 얼마나 흔한지, 특정 사이트의 기반으로 하나 또는 다른 프레임워크를 선택할 때 어떤 종류의 "벌금"을 지불하는지에 대해 궁금해졌습니다.

이 프로젝트는 내가 이것을 알아내는 데 도움이 되었습니다. HTTP 아카이브.

데이터

HTTP 아카이브 프로젝트는 일반 데스크톱 사이트에 대한 총 4308655개의 링크와 모바일 사이트에 대한 5484239개의 링크를 추적합니다. 이러한 링크와 관련된 많은 지표 중에는 각 사이트에서 발견되는 기술 목록이 있습니다. 즉, 다양한 프레임워크와 라이브러리를 사용하는 수천 개의 사이트를 샘플링하고 클라이언트에 보내는 코드의 양과 이 코드가 사용자 시스템에 생성하는 로드의 양을 알 수 있습니다.

내가 접근할 수 있었던 가장 최근 데이터인 2020년 XNUMX월 데이터를 수집했습니다.

모든 사이트에서 집계된 HTTP 아카이브 데이터를 React, Vue 및 Angular를 사용하여 찾은 사이트의 데이터와 비교하기로 결정했지만 다른 소스 자료도 사용하는 것을 고려했습니다.

더 흥미롭게 만들기 위해 소스 데이터 세트에 jQuery를 사용하는 사이트도 추가했습니다. 이 라이브러리는 여전히 매우 인기가 있습니다. 또한 React, Vue 및 Angular에서 제공하는 단일 페이지 애플리케이션(SPA) 모델과 다른 웹 개발 접근 방식을 도입합니다.

관심 있는 기술을 사용하는 것으로 확인된 사이트를 나타내는 HTTP 아카이브의 링크

프레임워크 또는 라이브러리
모바일 사이트 링크
일반 사이트 링크

jQuery를
4615474
3714643

반응
489827
241023

뷰
85649
43691

모난
19423
18088

꿈과 희망

데이터 분석으로 넘어가기 전에 제가 바라는 점에 대해 이야기하고 싶습니다.

이상적인 세상에서 프레임워크는 개발자의 요구 사항을 충족하는 것 이상이어야 하며 우리 사이트에서 작업하는 일반 사용자에게 특정한 이점을 제공해야 한다고 생각합니다. 성능은 이러한 이점 중 하나에 불과합니다. 여기서 접근성과 보안이 작용합니다. 그러나 이것은 가장 중요한 것입니다.

따라서 이상적인 세상에서는 일종의 프레임워크를 통해 고성능 사이트를 쉽게 만들 수 있어야 합니다. 이는 프레임워크가 개발자에게 프로젝트를 구축할 수 있는 적절한 기반을 제공하거나 개발에 제한을 부과한다는 사실 때문에 수행되어야 합니다. 천천히 밖으로.

최고의 프레임워크는 두 가지 모두를 수행해야 합니다. 좋은 기반을 제공하고 작업에 제한을 가하여 적절한 결과를 얻을 수 있도록 합니다.

데이터의 중앙값을 분석해도 필요한 정보를 얻을 수 없습니다. 그리고 사실 이 접근 방식은 우리의 관심에서 벗어납니다. 많은 중요한. 대신 내가 가지고 있는 데이터에서 백분율을 도출했습니다. 이들은 10, 25, 50(중앙값), 75, 90 백분위수입니다.

저는 특히 10번째와 90번째 백분위수에 관심이 있습니다. 10번째 백분위수는 특정 프레임워크의 최고 성능(또는 적어도 최고에 거의 근접)을 나타냅니다. 즉, 특정 프레임워크를 사용하는 사이트의 10%만이 이 수준 이상에 도달한다는 의미입니다. 반면에 90번째 백분위수는 동전의 뒷면입니다. 상황이 얼마나 나빠질 수 있는지 보여줍니다. 90번째 백분위수는 JS 코드가 가장 많거나 메인 스레드에서 코드를 처리하는 데 가장 오랜 시간이 걸리는 하위 10% 사이트입니다.

JavaScript 코드의 양

먼저 네트워크를 통해 여러 사이트에서 전송되는 JavaScript 코드의 크기를 분석하는 것이 좋습니다.

모바일 장치로 전송된 JavaScript 코드의 양(Kb)

백분위수
10
25
50
75
90

모든 사이트
93.4 
196.6 
413.5 
746.8 
1201.6 

jQuery 사이트
110.3 
219.8 
430.4 
748.6 
1162.3 

뷰 사이트
244.7 
409.3 
692.1 
1065.5 
1570.7 

각도 사이트
445.1 
675.6 
1066.4 
1761.5 
2893.2 

반응 사이트
345.8 
441.6 
690.3 
1238.5 
1893.6 

모바일 장치로 전송된 JavaScript 코드의 양

데스크톱 장치로 전송된 JavaScript 코드의 양(Kb)

백분위수
10
25
50
75
90

모든 사이트
105.5 
226.6 
450.4 
808.8 
1267.3 

jQuery 사이트
121.7 
242.2 
458.3 
803.4 
1235.3 

뷰 사이트
248.0 
420.1 
718.0 
1122.5 
1643.1 

각도 사이트
468.8 
716.9 
1144.2 
1930.0 
3283.1 

반응 사이트
308.6 
469.0 
841.9 
1472.2 
2197.8 

데스크톱 장치로 전송된 JavaScript 코드의 양

사이트에서 장치로 보내는 JS 코드의 크기에 대해서만 이야기하면 모든 것이 예상대로 보입니다. 즉, 프레임 워크 중 하나를 사용하면 이상적인 상황에서도 사이트의 JavaScript 코드 양이 증가한다는 의미입니다. 이는 놀라운 일이 아닙니다. JavaScript 프레임워크를 사이트의 기반으로 만들 수 없으며 프로젝트의 JS 코드 양이 매우 적을 것이라고 예상할 수 없습니다.

이 데이터에서 주목할 만한 점은 일부 프레임워크와 라이브러리가 다른 것보다 더 나은 프로젝트 시작점으로 간주될 수 있다는 것입니다. jQuery가 있는 사이트가 가장 좋아 보입니다. 사이트의 데스크톱 버전에서는 모든 사이트보다 15% 더 많은 JavaScript를 포함하고 모바일에서는 18% 더 많이 포함합니다. (물론 여기에는 약간의 데이터 손상이 있습니다. 사실 jQuery는 많은 사이트에 존재하므로 그러한 사이트가 다른 사이트보다 총 사이트 수와 더 밀접하게 연관되는 것은 당연합니다. 그러나 이것이 얼마나 원시적인지에 영향을 미치지는 않습니다. 각 프레임워크에 대한 데이터가 출력됩니다.)

코드 볼륨의 15-18% 증가는 눈에 띄는 수치이지만 이를 다른 프레임워크 및 라이브러리와 비교하면 jQuery가 부과하는 "세금"이 매우 낮다는 결론을 내릴 수 있습니다. 10번째 백분위수에 있는 Angular 사이트는 모든 사이트보다 데스크탑에 344% 더 많은 데이터를 전송하고 모바일에 377% 더 많은 데이터를 전송합니다. React 사이트는 모든 사이트보다 데스크탑에 193% 더 많은 코드를 전송하고 모바일에 270% 더 많은 코드를 전송하여 그 다음으로 무거운 사이트입니다.

앞에서 프레임워크를 사용한다는 것은 일정량의 코드가 프로젝트에 포함된다는 것을 의미하지만 작업 초기에는 프레임워크가 개발자를 제한할 수 있기를 바랍니다. 특히 최대 코드 양을 제한하는 것에 대해 이야기하고 있습니다.

흥미롭게도 jQuery 사이트는 이 아이디어를 따릅니다. 10번째 백분위수에서 모든 사이트보다 약간 무겁지만(15-18%) 90번째 백분위수에서는 데스크탑과 모바일 모두에서 약 3%로 약간 가볍습니다. 이것은 이것이 매우 중요한 이점이라고 말하는 것은 아니지만 jQuery 사이트는 적어도 가장 큰 버전에서도 JavaScript 코드 크기가 크지 않다고 말할 수 있습니다.

그러나 다른 프레임워크에 대해서도 마찬가지입니다.

10번째 백분위수의 경우와 마찬가지로 Angular 및 React의 90번째 백분위수 사이트는 다른 사이트와 다르지만 불행히도 더 나쁩니다.

90번째 백분위수에서 Angular 사이트는 모든 사이트보다 모바일에 141% 더 많은 데이터를 보내고 데스크탑에 159% 더 많은 데이터를 보냅니다. React 사이트는 모든 사이트보다 데스크톱에 73% 더 많이 보내고 모바일에 58% 더 많이 보냅니다. 90번째 백분위수에 있는 React 사이트의 코드 크기는 2197.8KB입니다. 즉, 이러한 사이트는 Vue를 기반으로 가장 가까운 경쟁사보다 모바일 장치에 322.9KB 더 많은 데이터를 전송합니다. Angular 및 React를 기반으로 하는 데스크톱 사이트와 다른 사이트 간의 격차는 훨씬 더 큽니다. 예를 들어 데스크톱 React 사이트는 동등한 Vue 사이트보다 554.7KB 더 많은 JS 코드를 장치에 보냅니다.

메인 스레드에서 JavaScript 코드를 처리하는 데 걸리는 시간

위의 데이터는 연구 중인 프레임워크와 라이브러리를 사용하는 사이트에 많은 양의 JavaScript 코드가 포함되어 있음을 분명히 나타냅니다. 그러나 물론 그것은 우리 방정식의 한 부분일 뿐입니다.

JavaScript 코드가 브라우저에 도착한 후에는 작동 가능한 상태로 가져와야 합니다. 특히 메인 브라우저 스레드에서 코드로 수행해야 하는 작업으로 인해 많은 문제가 발생합니다. 기본 스레드는 사용자 작업 처리, 스타일 계산, 페이지 레이아웃 작성 및 표시를 담당합니다. JavaScript 작업으로 메인 스레드를 압도하면 나머지 작업을 제 시간에 완료할 기회가 없습니다. 이로 인해 페이지 작업이 지연되고 "제동"됩니다.

HTTP 아카이브 데이터베이스에는 V8 엔진의 기본 스레드에서 JavaScript 코드를 처리하는 데 걸리는 시간에 대한 정보가 있습니다. 이것은 우리가 이 데이터를 수집하고 메인 스레드가 다양한 사이트의 JavaScript를 처리하는 데 걸리는 시간을 알아낼 수 있음을 의미합니다.

모바일 장치의 스크립트 처리와 관련된 프로세서 시간(밀리초)

백분위수
10
25
50
75
90

모든 사이트
356.4
959.7
2372.1
5367.3
10485.8

jQuery 사이트
575.3
1147.4
2555.9
5511.0
10349.4

뷰 사이트
1130.0
2087.9
4100.4
7676.1
12849.4

각도 사이트
1471.3
2380.1
4118.6
7450.8
13296.4

반응 사이트
2700.1
5090.3
9287.6
14509.6
20813.3

모바일 장치의 스크립트 처리와 관련된 프로세서 시간

데스크톱 장치의 스크립트 처리와 관련된 CPU 시간(밀리초)

백분위수
10
25
50
75
90

모든 사이트
146.0
351.8
831.0
1739.8
3236.8

jQuery 사이트
199.6
399.2
877.5
1779.9
3215.5

뷰 사이트
350.4
650.8
1280.7
2388.5
4010.8

각도 사이트
482.2
777.9
1365.5
2400.6
4171.8

반응 사이트
508.0
1045.6
2121.1
4235.1
7444.3

데스크톱 장치의 스크립트 처리와 관련된 프로세서 시간

여기에서 매우 친숙한 것을 볼 수 있습니다.

우선 jQuery가 있는 사이트는 다른 사이트보다 메인 스레드에서 JavaScript 처리에 훨씬 적은 비용을 소비합니다. 10번째 백분위수에서 모든 사이트와 비교하여 모바일의 jQuery 사이트는 기본 스레드에서 JS 코드를 처리하는 데 61% 더 많은 시간을 소비합니다. 데스크톱 jQuery 사이트의 경우 처리 시간이 37% 증가합니다. 90번째 백분위수에서 jQuery 사이트는 집계 점수에 매우 근접한 점수를 얻습니다. 특히 모바일 장치의 jQuery 사이트는 모든 사이트보다 기본 스레드에서 1.3% 적은 시간을 보내고 데스크톱 장치에서는 0.7% 적은 시간을 보냅니다.

우리 평가의 다른 측면에는 메인 스레드에서 가장 높은 로드를 특징으로 하는 프레임워크가 있습니다. 이것은 다시 Angular와 React입니다. 이 둘의 유일한 차이점은 Angular 사이트가 React 사이트보다 브라우저에 더 많은 코드를 보내는 반면 Angular 사이트는 코드를 처리하는 데 CPU 시간이 덜 걸린다는 것입니다. 훨씬 적은.

10번째 백분위수에서 데스크톱 Angular 사이트는 모든 사이트보다 JS 코드를 처리하는 기본 스레드에서 230% 더 많은 시간을 소비합니다. 모바일 사이트의 경우 이 수치는 313%입니다. 반응 사이트는 최악의 성능을 보입니다. 데스크톱에서는 모든 사이트보다 코드 처리에 248% 더 많은 시간을, 모바일에서는 658% 더 많은 시간을 소비합니다. 658%는 오타가 아닙니다. 10번째 백분위수에서 React 사이트는 코드를 처리하는 데 2.7초의 메인 스레드 시간을 사용합니다.

90번째 백분위수는 이러한 거대한 숫자와 비교할 때 적어도 조금 더 좋아 보입니다. 모든 사이트와 비교하여 Angular 프로젝트는 메인 스레드의 데스크톱 장치에서 29% 더 많은 시간을, 모바일 장치에서 27% 더 많은 시간을 소비합니다. React 사이트의 경우 같은 수치가 각각 130%와 98%로 보입니다.

90번째 백분위수에 대한 백분율 편차는 10번째 백분위수에 대한 유사한 값보다 더 좋아 보입니다. 그러나 여기서 시간을 나타내는 숫자가 다소 무섭게 보인다는 점을 기억할 가치가 있습니다. React로 구축된 웹사이트의 메인 모바일 스레드에서 20.8초라고 가정해 봅시다. (이 기간 동안 실제로 일어난 이야기는 별도의 기사에 합당하다고 생각합니다).

여기에 한 가지 잠재적인 합병증이 있습니다(감사합니다. 예레미야 이 기능에 주의를 기울이고 이 관점에서 데이터를 신중하게 고려했습니다). 사실 많은 사이트에서 여러 프런트 엔드 도구를 사용합니다. 특히 React나 Vue와 함께 jQuery를 사용하는 사이트를 많이 봤습니다. 이러한 사이트는 jQuery에서 다른 프레임워크나 라이브러리로 마이그레이션하고 있기 때문입니다. 결과적으로 데이터베이스에 다시 접근하여 이번에는 React, jQuery, Angular 또는 Vue만 사용하고 이들의 조합은 사용하지 않는 사이트에 해당하는 링크만 선택했습니다. 여기 내가 가진 것이 있습니다.

사이트에서 하나의 프레임워크 또는 하나의 라이브러리만 사용하는 상황에서 모바일 장치의 스크립트 처리와 관련된 프로세서 시간(밀리초)

백분위수
10
25
50
75
90

jQuery만 사용하는 사이트
542.9
1062.2
2297.4
4769.7
8718.2

Vue만 사용하는 사이트
944.0
1716.3
3194.7
5959.6
9843.8

Angular만 사용하는 사이트
1328.9
2151.9
3695.3
6629.3
11607.7

React만 사용하는 사이트
2443.2
4620.5
10061.4
17074.3
24956.3

사이트에서 하나의 프레임워크 또는 하나의 라이브러리만 사용하는 상황에서 모바일 장치의 스크립트 처리와 관련된 프로세서 시간

첫째, 놀라운 일이 아닙니다. 사이트에서 하나의 프레임워크나 하나의 라이브러리만 사용하는 경우 해당 사이트의 성능이 자주 향상됩니다. 각 도구는 10번째 및 25번째 백분위수에서 더 잘 수행됩니다. 말된다. 하나의 프레임워크를 사용하여 만든 사이트는 두 개 이상의 프레임워크나 라이브러리를 사용하여 만든 사이트보다 더 나은 성능을 발휘해야 합니다.

실제로 조사된 각 프런트 엔드 도구의 성능은 한 가지 흥미로운 예외를 제외하고 모든 경우에서 더 좋아 보입니다. 저를 놀라게 한 것은 50번째 백분위수 이상에서 React를 사용하는 사이트가 그들이 사용하는 유일한 라이브러리일 때 성능이 더 나빴다는 것입니다. 그건 그렇고, 이것이 내가 이 데이터를 여기에 제시한 이유입니다.

이것은 조금 이상하지만 여전히 이 이상함에 대한 설명을 찾으려고 노력할 것입니다.

프로젝트가 React와 jQuery를 모두 사용하는 경우 해당 프로젝트는 jQuery에서 React로 전환하는 과정의 중간에 있을 가능성이 높습니다. 아마도 이러한 라이브러리가 혼합된 코드베이스가 있을 것입니다. 우리는 이미 jQuery 사이트가 React 사이트보다 메인 스레드에서 더 적은 시간을 소비한다는 것을 보았기 때문에 jQuery에서 일부 기능을 구현하면 사이트 성능이 조금 더 향상된다는 것을 알 수 있습니다.

그러나 프로젝트가 jQuery에서 React로 전환되고 React에 더 많이 의존함에 따라 상황이 변하고 있습니다. 사이트가 정말 고품질이고 사이트 개발자가 React를 신중하게 사용한다면 그러한 사이트에서 모든 것이 잘 될 것입니다. 그러나 일반적인 React 사이트의 경우 React를 광범위하게 사용한다는 것은 메인 스레드가 많은 부하를 받고 있음을 의미합니다.

모바일과 데스크톱 기기의 격차

내가 조사한 데이터를 살펴본 또 다른 관점은 모바일과 데스크톱 장치에서 사이트 작업 사이에 얼마나 큰 격차가 있는지 연구하는 것이었습니다. JavaScript 코드의 양을 비교하는 것에 대해 이야기하면 그러한 비교는 끔찍한 것을 드러내지 않습니다. 물론 다운로드할 수 있는 코드의 양이 적으면 좋겠지만 모바일과 데스크톱 코드의 양에는 큰 차이가 없습니다.

그러나 코드를 처리하는 데 필요한 시간을 분석하면 모바일과 데스크톱 장치 사이의 매우 큰 격차가 눈에 띕니다.

데스크톱과 비교하여 모바일 장치에서 스크립트를 처리하는 것과 관련된 시간(백분율) 증가

백분위수
10
25
50
75
90

모든 사이트
144.1
172.8
185.5
208.5
224.0

jQuery 사이트
188.2
187.4
191.3
209.6
221.9

뷰 사이트
222.5
220.8
220.2
221.4
220.4

각도 사이트
205.1
206.0
201.6
210.4
218.7

반응 사이트
431.5
386.8
337.9
242.6
179.6

휴대폰과 랩톱 간의 코드 처리 속도에 약간의 차이가 있을 것으로 예상되지만 이러한 큰 숫자는 최신 프레임워크가 저전력 장치를 충분히 대상으로 하지 않으며 그들이 발견한 격차를 좁히기 위해 노력하고 있음을 말해줍니다. 10번째 백분위수에서도 React 사이트는 데스크톱 메인 스레드보다 모바일 메인 스레드에서 431.5% 더 많은 시간을 소비합니다. jQuery는 격차가 가장 적지만 여기에서도 해당 수치는 188.2%입니다. 웹 사이트 개발자가 처리에 더 많은 프로세서 시간이 필요한 방식으로 프로젝트를 만들면(그리고 시간이 지남에 따라 악화될 뿐임) 저전력 장치 소유자는 비용을 지불해야 합니다.

결과

좋은 프레임워크는 개발자에게 웹 프로젝트(보안, 접근성, 성능 측면에서)를 구축하기 위한 좋은 기반을 제공하거나 이러한 제한을 위반하는 것을 구축하기 어렵게 만드는 기본 제공 제한이 있어야 합니다.

이것은 웹 프로젝트의 성능에는 적용되지 않는 것 같습니다. 유효성).

React 또는 Angular 사이트가 다른 사이트보다 코드를 준비하는 데 더 많은 CPU 시간을 소비한다고 해서 반드시 React 사이트가 Vue 사이트보다 CPU를 더 많이 사용한다는 의미는 아닙니다. 사실 우리가 검토한 데이터는 프레임워크와 라이브러리의 운영 성능에 대해 거의 알려주지 않습니다. 그들은 의식적이든 아니든 이러한 프레임워크가 프로그래머를 압박할 수 있는 개발 접근 방식에 대해 더 많이 이야기합니다. 우리는 프레임워크 문서, 생태계, 일반적인 개발 기술에 대해 이야기하고 있습니다.

여기에서 분석하지 않은 것, 즉 사이트의 페이지 사이를 탐색할 때 장치가 JavaScript 코드를 실행하는 데 소비하는 시간도 언급할 가치가 있습니다. SPA를 선호하는 주장은 단일 페이지 애플리케이션이 브라우저에 로드되면 이론적으로 사용자가 사이트의 페이지를 더 빨리 열 수 있다는 것입니다. 내 자신의 경험에 따르면 이것은 사실이 아닙니다. 그러나 이 문제를 명확히 할 데이터가 없습니다.

분명한 것은 웹 사이트를 만들기 위해 프레임워크나 라이브러리를 사용하는 경우 초기에 프로젝트를 로드하고 준비하는 측면에서 타협을 하고 있다는 것입니다. 이는 가장 긍정적인 시나리오에도 적용됩니다.

적절한 상황에서 어느 정도 타협하는 것은 완벽하게 가능하지만 개발자가 그러한 타협을 의식적으로 하는 것이 중요합니다.

그러나 낙관할 이유도 있습니다. Chrome 개발자가 이러한 도구의 성능을 개선하기 위해 검토한 일부 프런트 엔드 도구의 개발자와 얼마나 긴밀하게 협력하고 있는지 알게 되어 기쁩니다.

그러나 나는 실용적인 사람입니다. 새로운 아키텍처는 성능 문제를 해결하는 만큼 자주 발생합니다. 그리고 버그를 수정하는 데 시간이 걸립니다. 우리가 기대해서는 안 되는 것처럼 새로운 네트워크 기술 모든 성능 문제를 해결할 것입니다. 우리가 가장 좋아하는 프레임워크의 새 버전에서 이것을 기대해서는 안 됩니다.

이 기사에서 설명한 프런트 엔드 도구 중 하나를 사용하려면 그 동안 프로젝트 성능에 해를 끼치지 않도록 추가적인 노력을 기울여야 합니다. 다음은 새 프레임워크를 시작하기 전에 고려해야 할 몇 가지 고려 사항입니다.

• 상식으로 자신을 테스트하십시오. 선택한 프레임워크를 사용해야 합니까? 오늘날 순수 자바스크립트는 많은 것을 할 수 있습니다.
• 이 프레임워크 기능의 90%를 제공할 수 있는 선택한 프레임워크(예: Preact, Svelte 또는 기타)에 대한 더 가벼운 대안이 있습니까?
• 이미 프레임워크를 사용하고 있다면 더 좋고 더 보수적인 표준 옵션을 제공하는 것이 있는지 고려하십시오(예: Vue 대신 Nuxt.js, React 대신 Next.js 등).
• 당신의 예산 자바스크립트 성능?
• 어떻게 할 수 있니? 제한하다 절대적으로 필요한 것보다 더 많은 JavaScript 코드를 프로젝트에 삽입하는 것을 어렵게 만드는 개발 프로세스?
• 개발 용이성을 위해 프레임워크를 사용하는 경우 다음을 고려하십시오. 당신이 필요로 할 프레임워크 코드를 클라이언트에 보냅니다. 서버의 모든 문제를 해결할 수 있을까요?

일반적으로 이러한 아이디어는 프런트 엔드 개발을 위해 정확히 무엇을 선택했는지에 관계없이 검토할 가치가 있습니다. 그러나 처음부터 성능이 부족한 프로젝트를 작업할 때 특히 중요합니다.

독자 여러분! 이상적인 JavaScript 프레임워크를 어떻게 보십니까?

출처 : habr.com