이것으로 시작하겠습니다. 이것은 반드시 다음 번 프론트 엔드를 위해 무엇을 선택해야 하는지 비교하는 것이 아닙니다. 비교적 유사한 응용 프로그램의 성능, 크기 및 코드 라인의 세 가지를 비교하면서 작고 비교적 복잡하지 않습니다.

https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1 

그것을 염두에 두고 여기에 그것이 작동하는 방법이 있습니다 :

우리는 RealWorld 앱을 비교하고 있습니다 

"할 일"앱 이상의 것. 일반적으로 "해야 할 일"은 실제 응용 프로그램을 실제로 구축하기에 충분한 지식과 관점을 전달하지 않습니다.

어떻게 든 표준화 되어 있습니다. 

특정 규칙을 준수하는 프로젝트 – 사양이 있습니다. 백엔드 API, 정적 마크 업 및 스타일을 제공합니다.

전문가가 작성 또는 검토 

이상적으로는 해당 기술 전문가가 구축하거나 검토 한 일관된 실제 프로젝트.

어떤 라이브러리 / 프레임 워크를 비교하고 있습니까? 

글을 쓰는 시점에서 RealWorld 리포지토리에는 24 개의 Conduit 구현이 있습니다. 팔로어가 큰지 여부는 중요하지 않습니다. 유일한 자격은 RealWorld 저장소 페이지에 나타납니다.

어떤 측정 항목을 볼 수 있습니까? 

성능 —이 앱이 콘텐츠를 표시하고 사용하는 데 얼마나 걸립니까?

크기 — 앱이 얼마나 큽니까? 컴파일 된 JavaScript 파일의 크기 만 비교합니다. HTML 및 CSS는 모든 변형에 공통이며 CDN (Content Delivery Network)에서 다운로드 됩니다. 모든 기술은 JavaScript로 컴파일하거나 변환하므로 이 파일의 크기 만 조정합니다.

Lines of Code — 작성자가 사양에 따라 RealWorld 앱을 작성하는 데 몇 줄의 코드가 필요 했습니까? 공정하게 하기 위해 일부 앱에는 종과 휘파람이 조금 더 있지만 큰 영향을 미치지는 않습니다. 우리가 수량화 하는 유일한 폴더는 각 앱에서 src /입니다. 자동 생성 여부와 상관없이 계속 유지해야 합니다.

메트릭 # 1 : 성능 

Chrome과 함께 제공되는 Lighthouse Audit의 성능 점수를 확인합니다. Lighthouse는 0과 100 사이의 성능 점수를 반환합니다. 0은 가능한 최저 점수입니다. 자세한 내용은 Lighthouse 스코어링 안내서를 확인하십시오.

감사 설정 

이론적 해석 

더 빨리 페인트하고 누군가가 더 빨리 할 수 ​​있으면 앱을 사용하는 사람의 경험이 향상됩니다.

비고 

참고 : 데모 애플리케이션이 부족하여 PureScript를 건너 뛰었습니다.

결론 

등대 감사가 잠들지 않습니다. 올해 유지 관리 / 업데이트 되지 않은 앱이 90 절벽에서 떨어지고 있음을 알 수 있습니다. 앱의 점수가 90보다 크면 큰 차이가 없을 것입니다. 그것은 AppRun, Elm 및 Svelte가 정말 인상적이라고 말했습니다.

측정 항목 # 2 : 크기 

전송 크기는 Chrome 네트워크 탭에서입니다. 서버가 제공 한 GZIP 응답 헤더와 응답 본문.

이는 프레임 워크의 크기와 추가 된 추가 종속성에 따라 다릅니다. 또한 빌드 빌드 도구가 번들에서 사용되지 않는 코드를 얼마나 잘 제거 할 수 있습니까?

이론적 해석 

파일이 작을수록 다운로드 속도가 빨라지고 구문 분석이 줄어 듭니다.

비고 

데모 애플리케이션이 부족하여 PureScript를 건너 뛰었습니다.

Angular + ngrx + nx Angular + ngrx + nx를 비난하지 마십시오. Chrome 개발자 도구 네트워크 탭을 확인하고 잘못 계산하면 알려주세요.

Rust + Yew + WebAssembly는 .wasm 파일도 포함합니다

결론 

20KB 미만의 Svelte 및 Stencil 커뮤니티의 놀라운 작업은 실제로 성과입니다.

메트릭 # 3 : 코드 라인 

cloc를 사용하여 각 repo의 src 폴더에 있는 코드 줄 수를 계산합니다. 빈 줄과 주석 줄은 이 계산에 포함되지 않습니다. 이것이 왜 의미가 있습니까?

디버깅이 소프트웨어 버그를 제거하는 프로세스 인 경우 프로그래밍은 버그를 처리하는 프로세스여야 합니다. — Edsger Dijkstra

이론적 해석 

이것은 주어진 라이브러리 / 프레임 워크 / 언어가 간결한 지를 보여줍니다. 사양에 따라 거의 동일한 앱을 구현하는 데 몇 줄의 코드가 필요합니까 (일부는 약간 더 많은 벨트와 휘파람이 있음).

비고 

cloc가 .svelte 파일을 처리 할 수 ​​없어 Svelte를 건너 뛰었습니다.

cloc가 .riot 파일을 처리 할 수 ​​없어 riotjs-effector-universal-hot을 건너 뛰었습니다.

Angular + ngrx : .ts 및 .html 파일 만 포함하여 / libs 폴더로 LoC 계산을 수행했습니다. 이것이 틀렸다고 생각되면 정확한 숫자가 무엇이고 어떻게 계산했는지 알려주십시오.

결론 

리 프레임이 있는 Imba 및 ClojureScript만이 1000LoC 미만에서 앱을 구현할 수 있습니다. Clojure는 비정상적으로 표현적인 것으로 유명합니다. Imba는 처음으로 여기에 있습니다 (작년 cloc, .imba 파일 형식을 몰랐습니다). LoC에 관심이 있다면 무엇을 해야 하는지 알고 있습니다.

요약 

이것은 정확히 사과 대 사과 비교가 아닙니다. 일부 구현에서는 코드 분할을 사용하지만 그렇지 않은 구현도 있습니다. 그중 일부는 GitHub에서 호스팅 되고 일부는 Now 및 Netlify에서 호스팅 됩니다. 아직도 어느 것이 최고인지 알고 싶습니까? 나는 당신에게 맡깁니다.