새로운 프런트엔드 프로젝트를 계획하거나 기존 프로젝트를 리팩토링하는 경우 현재의 프런트엔드 개발 환경이 더 이상 예전과 같지 않다는 점을 깨달아야 합니다. 다양한 선택: React, Flux, Angular, Aurelia, Mocha, Jasmine, Babel, TypeScript, Flow... 원래 의도는 개발을 단순화하는 것이지만 사실상 학습 비용을 늘리고 문제를 야기합니다. 미래 프로젝트의 유지보수.
다행히도 이러한 현상은 사라지고 있으며, 우수한 프로젝트가 서서히 자리잡고 있으며, 개발 방식도 점점 명확해지고 있습니다. 일부 개발자들은 위의 기술을 기반으로 한 프레임워크를 개발에 활용하려고 노력하고 있으며, 이로 인해 학습 비용도 어느 정도 절감됩니다.
이 글에서는 제가 웹 애플리케이션 개발에 참여하고 추천하는 몇 가지 기술을 주로 소개합니다. 그 중 일부는 기술적으로 논란이 있기 때문에 각 기술에 대해 간략하게 소개하고 분석하겠습니다. 모든 의견은 저의 개인적인 경험과 커뮤니티와의 접촉을 바탕으로 한 것이므로, 적절하게 활용해 주시기 바랍니다.
React가 대세입니다.
컴포넌트화로 애플리케이션 개발 및 유지 관리가 더 쉬워집니다
학습 곡선이 완만하고 핵심 API가 간결하고 명확하며 배우기 쉽습니다
JSX 구문은 틀에 얽매이지 않으며 JavaScript의 기능을 완벽하게 활용합니다
Flux 및 Redux에 자연스럽게 적응
커뮤니티는 활발하고 창의적이며 많은 훌륭한 개발 도구에 기여해 왔습니다
단방향 데이터 흐름은 복잡한 애플리케이션에 더 적합하며 양방향 데이터 바인딩보다 품질이 더 높습니다
서버 측 렌더링 지원
React는 Ember, Aurelia, Angular 등 기능이 풍부한 프레임워크에 비해 만능은 아니지만 React의 개발 환경은 더 강력합니다. 현재로서는 React를 사용하는 것은 기술 선택이 아니라 보다 효율적이고 효과적인 생산성을 제공하는 비즈니스 관행입니다.
모바일 애플리케이션을 개발하려는 경우 이미 React 구문을 배웠으므로 React Native를 사용하여 크로스 플랫폼 애플리케이션을 직접 개발할 수 있습니다.
이제 뷰 레이어를 개발할 수 있으므로 다음으로 여기에서 권장하는 대로 다른 도구를 사용하여 애플리케이션의 상태 및 수명 주기를 관리해야 합니다. 도구는 Redux입니다.
Facebook은 React와 협력하기 위해 단방향 데이터 흐름을 관리하는 도구인 Flux를 개발했습니다. Flux는 기본적으로 단일 데이터 흐름을 지원하지만 상태를 저장하는 방법 및 위치와 같은 다른 문제도 발생합니다. Ajax 요청 등을 수행하십시오.
이러한 문제를 해결하기 위해 Flux 모델을 모방한 일련의 프레임워크가 파생되었습니다: Fluxible, Reflux, Alt, Flummox, Lux, Nuclear, Fluxxor...
현재, 개발 커뮤니티에서 널리 사용됩니다. 지원되는 구현 중 하나는 Redux입니다.
Redux에서는 대부분의 구성 요소가 순전히 기능적인 구성 요소이며 중앙 집중식 저장소와 리소스 센터가 하나만 있습니다. Redux의 인스턴스 메소드는 전체 데이터의 운영 및 유지 관리를 담당합니다. Flux와 비교할 때 Redux의 아이디어는 더 명확합니다.
더 중요한 것은 Redux가 배우기 매우 쉽다는 것입니다. Redux의 저자인 Dan Abramov는 깊이 있고 이해하기 쉬운 Redux 비디오 튜토리얼 시리즈를 만든 훌륭한 교사입니다. 이 비디오를 시청하여 Redux 전문가가 되어보세요. 나는 제로 기반 React 팀이 단 몇 주 만에 베타 제품을 빠르게 개발하는 것을 본 적이 있는데, 코드는 매우 강력하고 정교했습니다.
Redux를 둘러싼 생태계는 Redux만큼 강력합니다. 놀라운 개발 도구부터 강력한 메모 도구 재선택까지 Redux 개발 커뮤니티는 개발자에게 필요한 모든 것을 제공합니다.
개발자는 본능적으로 Redux 템플릿을 추상화하려고 시도할 수 있지만, 그렇게 하면 많은 이점이 있지만 맹목적으로 시도하기보다는 요구 사항에 대한 명확한 이해를 바탕으로 템플릿을 캡슐화하시기 바랍니다.
CoffeeScript의 많은 기능이 ES6과 유사한 구문을 갖고 있고, ES6은 구현 표준이자 JavaScript의 향후 개발 방향을 나타내기 때문에 이제는 포기해야 할 때입니다.
최신 브라우저는 이미 ES6의 대부분의 기능을 지원합니다. Babel은 ES6를 ES5로 변환하는 강력한 변환 도구입니다. 또한 대상 브라우저에 따라 트랜스코딩 정도를 조정할 수 있습니다.
그럼 타입 시스템이 있나요? TypeScript와 Flow는 모두 JavaScript용 정적 유형 시스템을 제공합니다. 정적 유형 검사를 사용하면 오류를 효과적으로 포착하고 테스트 양을 줄일 수 있습니다. 지금은 이에 대해 관망적인 접근 방식을 취하는 것이 좋습니다.
TypeScript는 JavaScript가 C#이나 Java 방향으로 개발되도록 최선을 다하고 있지만 대수 데이터 유형과 같은 고급 유형 시스템 기능이 많이 부족합니다. 또한 Flow만큼 효율적으로 null을 처리할 수 없습니다.
이에 비해 Flow는 더 강력하고 더 많은 오류 유형을 캡처하지만 구성하기가 어렵습니다. 또한 새로운 JavaScript 기능에 대한 지원은 Babel보다 약하며 Windows 시스템을 지원하지 않습니다.
내 개인적인 관점에서 볼 때 유형 시스템은 프런트엔드 개발에서 중요한 부분이 아닙니다(여기서 논란의 여지가 있을 수 있음). 유형 시스템이 더욱 강력해지고 바벨 친화적이 될 때까지 기다려 보겠습니다.
또 다른 확실한 도구는 ESLint입니다. ESLint는 ES6 구문을 지원하고 React 플러그인도 제공합니다. 이는 더 이상 단순한 코드 검토 도구가 아닙니다. 현재 JSLint는 더 이상 사용되지 않으며 ESLint는 자체 클래스에서 JSHint 및 JSCS를 대체할 수 있습니다.
개발자는 자신의 필요에 따라 ESLint를 구성할 수 있지만 여기서는 AirBNB의 개발 사양에 따라 구성하는 것을 권장하거나 ESLint airbnb config를 직접 사용할 수도 있습니다. 물론, 이 사양에는 여전히 부족한 부분이 있지만, 팀 전체 코드의 일관성을 유지하면 코드의 가독성을 효과적으로 향상시킬 수 있습니다.
ESLint에 익숙해진 후에는 개발자가 ESLint의 규칙을 심층적으로 시도해 보는 것이 좋습니다. ESLint가 더 많은 오류를 포착할수록 제품이 더 안정적입니다.
Bower는 잊어버리고 NPM이 대신하세요. Browserify 및 Webpack과 같은 빌드 도구는 웹 개발에서 NPM의 위상을 간접적으로 높였습니다. NPM을 사용하면 버전 관리가 더 간단해지고 Node.js 생태계와 더 많은 접촉이 가능해집니다. 현재 CSS 처리가 아직 충분히 완료되지 않았습니다.
배포 서버에서 빌드를 수행하는 방법을 고려할 수 있습니까? Ruby의 Bundler와 달리 NPM은 와일드카드를 사용하여 파일을 검색하며, 타사 패키지는 코드 개발 도중과 프로젝트가 출시되기 전에 임의로 수정할 수 있습니다. Shrinkwrap 파일을 사용하여 프로젝트의 타사 종속성을 고정합니다. 출력의 일관성을 향상하려면 사용자의 Shrinkwrap을 사용하는 것이 좋습니다. 또한 개발자는 Sinopia와 같은 도구를 사용하여 자체 개인 NPM 서버를 호스팅하는 것을 고려할 수도 있습니다.
Babel은 ES6 모듈 구문을 CommonJS로 변환합니다. CommonJS는 검증된 구문으로 안정적이고 보편적입니다. 또한 트리 쉐이킹과 같은 메커니즘을 사용하여 정적 코드 분석을 수행할 수 있습니다(Webpack 2.0 및 Rollup은 이미 이 기능을 지원함).
페이지에 수백 개의 스크립트 태그를 추가하고 싶지 않다면 빌드 도구를 사용하여 페이지 리소스를 패키징해야 합니다. 또한 NPM 타사 패키지에 대한 브라우저 지원을 활성화하려면 몇 가지 도구가 필요합니다. 여기서는 Webpack을 사용하는 것을 추천합니다.
1년 전만 해도 개발자들은 위 작업을 위해 JavaScript 기반의 RequireJS, Browserify, Webpack 솔루션은 물론 ES6 모듈에 가장 최적화된 RollupJS 등 선택할 수 있는 도구가 많았습니다. .
모든 도구를 사용해 본 후 개발자는 Webpack을 선택하는 것이 좋습니다.
다양한 상황을 처리할 수 있는 구성
주류 모듈 로딩 방법(AMD, CommonJS, globals) 지원
내부 메커니즘으로 손상된 모듈을 복구할 수 있음
CSS 처리 가능
포괄적인 캐싱 시스템
핫 리로드 지원
대부분의 리소스 로드 가능
효율적인 성능 최적화 솔루션 제공
Webpack은 또한 대규모 단일 페이지 애플리케이션을 처리하고 코드 분할 및 지연 로딩을 지원하는 데 매우 능숙합니다.
하지만 Webpack의 학습 곡선이 매우 가파르다는 점은 주목할 가치가 있습니다. 그러나 일단 배우고 나면 가장 강력한 빌드 시스템을 마음대로 사용할 수 있게 됩니다.
걸프와 그런트는 어떻습니까? 이에 비해 Webpack은 다양한 리소스를 처리하는 데 더 좋습니다. Gulp와 Grunt는 다른 유형의 빌드 작업을 수행해야 하는 경우 여전히 유용합니다. Webpack 실행과 같은 기본 작업에는 NPM 스크립트를 직접 사용하는 것이 좋습니다.
JavaScript에는 각각 안정적이고 강력한 선택적 단위 테스트 도구가 많이 있습니다. 단위 테스트용으로만 사용하는 경우 기존 도구가 귀하의 요구 사항을 완벽하게 충족할 것입니다.
일반적인 테스트 도구로는 Jasmine, Mocha, Tape, Ava, Jest 등이 있으며 각각 고유한 장점이 있습니다.
테스트 프레임워크에 대한 내 요구 사항은 다음과 같습니다.
손쉬운 디버깅을 위해 브라우저에서 실행할 수 있습니다.
빠름 실행
비동기 테스트 처리가 용이함
명령줄에서 사용이 용이함
예 임의의 주장 및 데이터 시뮬레이션과 호환되는 타사 라이브러리
첫 번째 기준에서는 Ava 및 Jest가 제외됩니다.
저는 모든 기능을 갖춘 다양한 플러그인이 있는 Chai 어설션을 좋아하고, 비동기를 잘 지원하는 Mocha를 좋아합니다. 특정 문제를 피하려면 Dirty Chai를 사용하는 것이 좋습니다. Webpack의 mocha-leader 플러그인을 사용하면 개발자가 테스트를 자동화할 수 있습니다.
React의 경우 개발자는 AirBNB의 Enzyme과 Teaspoon을 참고할 수 있습니다.
저는 Mocha의 기능을 매우 좋아합니다. 가장 기본적인 기능만 원한다면 이 기사를 참조하여 Tape에 대해 알아볼 수 있습니다.
JavaScript에는 Java나 .NET과 유사한 핵심 도구 라이브러리가 없으므로 개발자는 대부분 외부에서 외부 도구 라이브러리를 참조합니다.
현재 이 분야에서는 Lodash가 선두를 달리고 있습니다. 또한 지연 실행 특성으로 인해 최고의 성능을 발휘하는 도구 중 하나입니다. Lodash를 사용할 때 모든 리소스를 참조할 필요는 없으며 개발자는 필요에 따라 기능을 사용할 수 있습니다. 버전 4.x에서 Lodash는 함수형 프로그래밍을 선호하는 개발자를 위해 "함수 개발" 모드를 제공합니다.
함수형 프로그래밍에 익숙하다면 Ramda에 대해 배울 수 있습니다. 이 라이브러리를 사용하기로 결정한 경우 일부 Lodash 함수를 참조해야 할 수도 있습니다.
많은 React 기반 애플리케이션은 더 이상 jQuery를 사용하지 않습니다. 오래된 프로젝트를 유지 관리하거나 jQuery에 의존하는 타사 라이브러리를 사용하지 않는 한 더 이상 사용할 필요가 없습니다.
저는 프로젝트를 단순하게 유지하고 코드에서만 가져오기를 사용하는 것을 좋아합니다. 가져오기는 약속을 기반으로 하며 Firefox와 Chrome 모두 이 인터페이스를 캡슐화합니다. 다른 브라우저의 경우 Putty 스크립트를 제공해야 합니다. 브라우저와 서버 전반에서 기능을 일관되게 유지하려면 isomorphic-fetch를 사용하는 것이 좋습니다.
물론 다른 우수한 타사 라이브러리를 사용하여 비동기적으로 데이터를 얻을 수도 있지만 가져오기만으로 충분하다고 생각합니다.
동형 JavaScript는 클라이언트와 서버 모두에서 실행되는 JavaScript를 의미하며 성능을 향상하고 SEO를 용이하게 하기 위해 서버에서 페이지를 사전 렌더링하는 데 자주 사용됩니다. 동형 JavaScript는 React를 사용하여 구현할 수 있지만 간단하지 않습니다. 이는 프로그램의 복잡성을 증가시키고 개발자가 사용할 수 있는 도구 및 타사 라이브러리를 제한합니다.
전자상거래 웹사이트와 같은 B2C 사이트를 구축하는 경우 동형 JavaScript를 사용해야 할 수도 있습니다. 그러나 내부 사이트나 B2B 애플리케이션의 경우 성능이 가장 중요한 것은 아니므로 동형 JavaScript는 그다지 중요하지 않습니다.
요즘 다들 API로 뭘 할까 고민하는 것 같아요. 모두가 RESTfull API 사용에 편승하고 있으며 SOAP는 과거의 일입니다. 현재 업계에는 HATEOAS, JSON API, HAL, GraphQL 등 다양한 API 프로토콜이 있습니다.
GraphQL은 클라이언트에게 임의의 쿼리를 수행할 수 있는 기능을 제공합니다. Relay와 함께 사용하면 클라이언트의 상태와 캐시를 더 잘 처리할 수 있습니다. 그러나 GraphQL 서버 인터페이스를 만드는 것은 여전히 어렵고 대부분의 문서는 Node.js에 대한 것입니다.
Netflix의 Falcor는 GraphQL/Relay와 유사한 기능을 제공하면서 서버 측 요구 사항도 줄이는 것으로 보이지만 현재 개발자 프리뷰 단계이며 아직 실제 개발에 사용되지는 않았습니다.
알려진 모든 사양에는 고유한 결함이 있고, 일부는 너무 복잡하고, 일부는 데이터 읽기만 처리할 수 있지만 업데이트는 할 수 없으며, 일부는 REST와 크게 다릅니다. 많은 개발자들이 스스로 개발을 선택하지만 여전히 위와 같은 문제에 직면합니다.
위 사항에 대한 완벽한 해결책은 없다고 생각하지만 API에 대해 저 나름대로 이해하고 있습니다.
예측 가능, 일관된 프로토콜 따르기
하나의 쿼리로 여러 엔터티 가져오기 지원
업데이트 작업 지원
디버그 용이
사용하기 쉬움
지금까지 위의 기준을 모두 충족하는 솔루션을 찾지 못했습니다.
RESFful을 사용한다면 Swagger를 참고하여 API를 작성하는 것을 권장합니다.
Electron은 프런트 엔드 기술을 사용하여 데스크톱 프로그램을 구축할 수 있습니다. GitHub 팀에서 제작한 Atom 편집기는 Electron을 기반으로 합니다. 기본적으로 Electron은 Node.js를 내부적으로 캡슐화하여 Chrome 창을 열어 UI를 렌더링하고 운영 체제의 로컬 API에 액세스할 수도 있으며 브라우저에는 샌드박스 메커니즘이 없습니다. 개발자는 Electron을 통해 애플리케이션을 패키징하고 배포할 수 있습니다.
이것은 크로스 플랫폼 소프트웨어를 만들고 위에 언급된 모든 도구를 활용하는 가장 쉬운 방법입니다. 또한 Electron은 완전한 문서와 활발한 개발 커뮤니티를 보유하고 있습니다.
nw.js라는 이름을 들어보셨을 것입니다. 비록 수년 동안 사용되어 왔지만 Electron이 더 안정적이고 사용하기 쉽습니다.
Electron, React, hot reload를 기반으로 한 템플릿이 있으니 한번 사용해 보세요.
다음은 내가 Twitter에서 팔로우하는 사람들입니다.
Dan Abramov, Redux 창시자
Christopher Chedeau, 현재 Facebook에서 근무 중인 매우 활동적인 React 개발자
Flow의 핵심 기여자 중 한 명인 Jeff Morrison
Sebastian Markbåge, React 창시자 중 한 명
Pete Hunt
React
더 많은 객체 보기 주목할 만한 React Influencers를 참조하세요
Pate Hunt의 Learning React를 읽어보는 것이 좋습니다!
Dan Abramov가 비디오 튜토리얼 시리즈를 공개했습니다. Redux 시작하기, 적극 추천합니다! 또한 Dan은 위보다 더 자세한 관심 목록을 게시했습니다.
Mark Erikson의 React/Redux 링크 모음도 좋은 학습 자료입니다.
JavaScript 생태계는 빠르게 발전하고 있으며 점점 더 강력해지고 있습니다. React의 모범 사례가 확고해지고 주변 도구의 책임과 기능이 점점 더 명확해지고 있습니다.
기억해야 할 가장 중요한 점은 간단하게 유지하고 필요할 때만 사용한다는 것입니다.
애플리케이션에 화면이 2개 또는 3개만 있는 경우 단일 페이지 애플리케이션을 만드는 경우 라우팅 시스템을 사용할 필요가 없으며, React 자체 상태 속성만 있으면 됩니다. 간단한 CRUD 프로그램을 만들고 있다면 Relay를 사용할 필요가 없습니다. ES6를 배우고 있다면 Async/Await나 데코레이터를 이제 막 React를 배우기 시작했다면 깊이 이해할 필요가 없습니다. 핫 리로딩 및 서버 측 렌더링을 사용할 필요가 없습니다. Webpack을 처음 사용하는 경우 Redux를 배우는 중이라면 코드를 분리하고 여러 리소스를 병합할 필요가 없습니다. Redux-Form의 사용을 이해할 필요가 없습니다. 그리고 Redux-Saga.
간단하게 한 번에 한 가지씩만 하세요!
위 내용은 JavaScript 기술 스택의 전망에 대한 자세한 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
