지난 몇 년간의 주요 프론트엔드 기술 동향을 요약하고 2022년 기술 동향을 기대합니다.

2021년대규모 프론트엔드 분야에서는 혁명적인 스타 프로젝트가 없지만 다양한 세분화된 기술 분야에서는 확실한 확장과 심화가 이루어지고 있으며 2022년에는 폭발적으로 증가할 것으로 예상되는 신기술이나 새로운 기능이 많이 있습니다.

현재 인터넷의 '추운 겨울'에서 프론트 엔드 기술자는 내부 기술을 배양하고 끊임없이 자신을 강화함으로써 봄의 '동풍'을 더 잘 만날 수 있습니다. 그렇다면 프런트 엔드 기술자는 어떤 "근육"을 연습해야 할까요? 아마도 "2021 JavaScript Star Project"에서 답을 찾을 수 있을 것입니다:

• zx Toolkit은 단 7개월 만에 연간 Star Growth에 선정되었습니다. 전체 스택에서 프런트엔드 개발의 지속적인 침투와 영향력을 보여줍니다.

• 프론트엔드 프레임워크 측면에서 선도적인 React와 Vue는 여전히 꾸준히 발전하고 혁신을 이어가고 있습니다. 올해는 다크호스 스벨트(Svelte)가 등장해 Angular를 제치고 단숨에 3위를 차지하며 1위 자리를 노리고 있다. 그렇다면

  Svelte가 돌파할 수 있을까요?

• Node.js 프레임워크 중에는 React의 “메타 프레임워크” ​​Next.js가 선두를 달리고 있습니다. 루키 리믹스(Rookie Remix)가 불과 2개월 만에 4위를 기록했다는 점은 주목할 만하다.

• 빌드 도구 측면에서는

  네이티브 ES 모듈의 수용이 계속되고, vite는 막을 수 없는 반면, 성능 고려 사항으로 인해 점점 더 많은 프런트 엔드 도구가 다른 언어를 사용하기 시작했습니다. ​​​( Rust, Go)를 구축합니다.

• 데스크톱에서 인기 있는 Tauri는 Electron의 지배력을 무너뜨렸습니다. Rust(교체 가능)를 기반으로 하는 Tauri는 Electron보다 패키지 크기와 메모리 공간이 더 작으며 미래가 유망합니다.

다음으로, 2021년 프런트엔드 업계에서 일어났던 중요한 일들을 살펴보고, 지난 1년 동안 Tencent IMWeb 팀이 이룬 성과도 공유하겠습니다.

2021년 연간 트렌드 요약

1. TypeScript의 꾸준한 성장

Github의 언어 사용 데이터(수년 간 상위 언어)로 판단하면

2021 TypeScript는 여전히 4위입니다.

최신 2020 JS 설문 조사 데이터에 따르면 TypeScript 사용은 유사한 도구 경쟁 중에서 여전히 1위를 차지하고 있습니다(JS 현황 설문 조사).

2021년 스택 오버플로 개발자 설문조사에 따르면 TypeScript의 인기는 여전히 높아지고 있으며, 2022년에도 계속해서 성장할 것으로 추정됩니다.

Review

2021년을 되돌아보면 공식 로드맵에서는 TypeScript의 목표가 유형 시스템을 지속적으로 개선하고, 생산성을 향상하기 위한 강력한 도구를 구현하고, 사용자 경험을 개선하고, 커뮤니티 참여를 늘리고, 인프라 및 엔지니어링을 개선하는 것이라고 명시합니다. 체계. 목표를 설정한 후 TypeScript 팀은 올해 4가지 버전을 출시하는 데 매우 효과적이었습니다. 최신 버전은 4.5입니다. 다음과 같은 많은 새로운 기능이 실제로 더 재미있어졌습니다.

• 더 나은 튜플 유형 지원 임의의 위치에 있는 나머지 및 선택적 유형.

• 더 나은 템플릿 문자열 리터럴 유형 지원.

• 조건 분기 필드에 대한 더 스마트한 유형 추론.

• 인덱스 유형은 기호 및 템플릿 문자열 모드를 지원합니다.

• Awaited 유형 및 Promise 유형 개선.

• 등등.

기능 외에도 다음과 같은 다양한 사용 경험도 향상됩니다.

• 더 빠른 유형 생성, 증분 컴파일 및 소스 맵 생성과 같은 성능 최적화.

• 더 스마트해진 IDE 완성.

• 자바스크립트가 아닌 소스 파일 위치.

• 등등.

또한, 8월에 새로운 TypeScript 공식 홈페이지가 오픈되어 새로운 문서를 더욱 편리하게 찾아보실 수 있습니다.

현재 TypeScript는 IMWeb 팀의 표준이 되었습니다.

웹 프런트엔드, Node.js 프로젝트 또는 공용 모듈이든, 스캐폴딩 템플릿은 기본적으로 TypeScript를 지원합니다. 공용 모듈 시스템은 TypeScript를 사용하여 코드를 작성하고 유형 검사를 수행할 뿐만 아니라 ESLint를 사용하여 구현합니다. TS 언어 표준 AST의 특정 검증. 공개 모듈 사양을 구현하고 TypeDoc을 결합하여 사용 문서 등을 생성합니다.

기대됩니다

TypeScript는 앞으로 다음과 같은 더 흥미로운 기능을 제공할 것입니다.

• 평탄화 선언은 각 모듈 d.ts 파일당 하나가 아닌 총 d.ts 파일 하나만 출력합니다.

• Ambient 데코레이터는 API가 더 이상 사용되지 않는지 여부와 같은 일부 환경 정보를 선언하는 데 사용됩니다. 출력에 영향을 주지 않는 런타임 코드는 d.ts 선언 파일에만 반영됩니다.

• C++의 #if 매크로 정의와 다소 유사한 조건부 컴파일은 컴파일 전에 코드를 전처리하고 조건을 충족하는 코드 분기를 유지할 수 있습니다.

• 함수 표현식/화살표 함수용 데코레이터. 현재 TypeScript의 데코레이터는 클래스에서만 사용할 수 있습니다. 향후에는 클래스 장치 외부에서 함수 표현식 및 화살표 함수에 대한 장식 사용을 지원할 수도 있습니다.

• 등등.

로드맵에 따르면 TypeScript는 생산성을 향상하기 위해 수행할 수 있는 많은 유형 기능, 성능 최적화, 경험 최적화 및 지원 도구가 있는 올바른 방향으로 나아가고 있습니다. JS 언어의 TypeScript의 개발과 개선이 증가함에 따라 TypeScript는 향후 브라우저와 Node.js에서 기본적으로 지원됩니까? 함께 기대해 봅시다.

2. React는 앞장서며 혁신을 이어갑니다

React 18은 2021년 하반기에 Alpha, Beta, Release Candidate 버전 출시를 완료했고, 2022년 초에 정식 버전을 출시할 예정입니다.

React 18이 출시되면 즉시 사용 가능한 개선 사항(예: 자동 일괄 처리), 새로운 API(예: startTransition) 및 React.lazy에 대한 기본 지원이 포함된 새로운 SSR 아키텍처가 포함됩니다.

이러한 기능은 React 18에 새로 추가된 선택적 "동시 렌더링" 메커니즘 덕분에 가능합니다. 이 메커니즘은 React의 많은 새로운 가능성을 열어 애플리케이션의 실제 성능과 인지된 프로그램 성능을 향상시키는 데 도움이 됩니다.

React 18은 점진적인 전략을 채택합니다. React 18의 동시성은 선택적인 기능이므로 구성 요소 동작에 명백한 파괴적인 변화를 즉시 가져오지는 않습니다. 애플리케이션의 코드를 거의 변경하지 않고 React 18로 직접 업그레이드할 수 있으며 자신의 속도와 필요에 따라 새로운 기능을 사용해 볼 수 있습니다.

일반적으로 React 18은 다음 3가지 측면에서 업데이트를 제공합니다.

Ø 자동 일괄 처리

Ø Suspense용 SSR

Ø 앱 및 라이브러리 개발자를 위한 새로운 API

● 자동 일괄 처리

React 18에 다음이 추가됩니다. 기본적으로 더 많은 일괄 처리를 수행하여 기본 성능이 향상되므로 애플리케이션이나 라이브러리 코드에서 수동 일괄 업데이트가 필요하지 않습니다.

배칭은 React가 콜백 함수의 여러 setState 이벤트를 하나의 렌더링으로 결합할 수 있음을 의미합니다.

React 17은 이벤트 콜백에서만 일괄 처리하는 반면, React 18은 모든 소스의 setState에 대해 가능한 한 많은 일괄 처리를 수행합니다. setState가 약속, ​​시간 초과 또는 이벤트 콜백에서 여러 번 호출되더라도 하나의 렌더링으로 병합됩니다.

이 새로운 기능을 활성화하려면 ReactDOM.render를 ReactDOM.createRoot 호출 메서드로 바꾸세요.

● SSR for Suspense

전체 이름은 Streaming SSR with Selective Hydration입니다.

RenderToString과 같은 일회성 렌더링 메커니즘 대신 서버에서 클라이언트까지 지속적인 렌더링 파이프라인을 생성하는 물 흐름과 같습니다. 선택적 수화(Selective hydration)는 백엔드 콘텐츠가 프런트엔드에 도달한 후 JS가 사용자 상호 작용이나 DOM 업데이트 동작에 응답하기 위해 이벤트를 바인딩해야 함을 의미합니다. 전체적으로, 수화 과정이 느려지고 전체적인 지연이 발생할 수 있으므로 필요에 따라 선택적 수화를 통해 수화를 우선시할 수 있습니다.

● 앱 및 라이브러리 개발자를 위한 새로운 API

동시 API:

동시 렌더링 관련 변경 사항은 React 18의 주요 변경 사항 중 하나입니다. 즉, 이 기능을 통해 React 애플리케이션의 응답성이 향상됩니다. 이는 렌더링을 방해할 수 있는 디자인 아키텍처입니다. 렌더링을 언제 중단해야 합니까? 우선 순위가 높은 렌더링이 도착하면 더 빠른 시각적 반응을 위해 현재 렌더링이 중단되고 우선 순위가 높은 렌더링이 즉시 실행됩니다.

• useTransition: 구성 요소가 다음 인터페이스로 전환하기 전에 콘텐츠가 로드될 때까지 기다릴 수 있도록 하여 불필요한 로드 상태를 방지합니다.

• startTransition: startTransition 콜백에 래핑된 setState에 의해 트리거된 렌더링은 긴급하지 않은 렌더링으로 표시되며 이러한 렌더링은 다른 긴급 렌더링에 의해 선점될 수 있습니다.

• useDeferredValue: 선택 입력 상자가 목록을 필터링하는 시나리오와 같이 지연된 응답 값을 반환합니다. 목록에 대해 useDeferredValue를 사용하여 선택기에 해당하는 값을 전달할 수 있습니다.

새로운 startTransition 및 useDeferredValue API를 사용하면 기본적으로 UI의 일부를 업데이트 우선순위가 낮은 것으로 표시할 수 있습니다.

기타 API:

• useSyncExternalStore: useSyncExternalStore는 동시 렌더링으로 인해 발생할 수 있는 데이터 불일치 문제를 해결하기 위해 외부 소스를 구독하는 useMutableSource를 대체합니다. 일반 개발자가 사용합니다.

• useId: useId는 SSR 하이드레이트 중에 요소 불일치를 방지하기 위해 클라이언트와 서버 간의 고유 ID를 생성하는 데 사용됩니다.

• useInsertionEffect: 전역 DOM 노드를 삽입하는 데 사용됩니다.

React 18은 새로운 React Native 아키텍처(React 18 기능 사용 가능)와 함께 내년에 출시될 예정입니다.

3. 프론트엔드 프레임워크 전쟁의 다크호스, Svelte

프런트엔드 분야가 격동하고 있으며, 프레임워크 3대인 React, Vue, and가 속속 등장하고 있습니다. Angular는 항상 상위 3위 안에 들었습니다. 동시에 우리는 많은 프론트엔드 프레임워크 중에서 Rich Harris(Ractive, Rollup 및 Bubble의 저자)가 개발한 Svelte가 다크호스가 되어 프론트엔드 프레임워크 중에서 두각을 나타낼 것으로 예상된다는 점도 알아냈습니다.

2021년 Stack Overflow가 준비한 최신 설문조사에서는 응답자의 71.47%가 Svelte를 가장 인기 있는 프레임워크로 선택했으며, React.js(69.28%), Vue(64.41%)를 앞섰습니다. JS Status 2020 설문조사에서 Svelte는 사용자 만족도 89%, 관심도 66%로 1위를 차지했습니다. Svelte는 탄생 이후 React/Vue와 같은 프레임워크를 벤치마킹하는 데 사용되었습니다. 우리는 또한 Svelte 및 React에 대한 논쟁을 보았고 2019년 Youda가 답변한 "Svelte를 프런트엔드 프레임워크로 처리하는 방법"과 vue-Svelte- 규모 분석 평가는 Svelte의 발전 추세를 보여줍니다.

프론트 엔드 전투의 다크호스

저희 설문 조사에 따르면 개발자는 다음과 같은 점 때문에 Svelte를 좋아하는 것으로 나타났습니다.

1. Svelte는 매우 간결한 구문을 가지고 있으며 대화형 튜토리얼을 통해 학습 곡선이 낮고 시작 비용이 저렴합니다. vue 구문에 익숙한 사용자는 기본적으로 빠르게 시작할 수 있습니다.

2. 더 작은 크기. Svelte의 핵심 아이디어는 정적 컴파일을 통해 프레임워크의 런타임에 코드 양을 줄이는 것입니다. 이는 소규모 애플리케이션에서 확실한 이점을 제공합니다. React의 압축 버전은 42.2KB이고 Svelte의 압축 버전은 1.6KB입니다. . 그러나 중대형 애플리케이션에서는 이러한 장점이 점차 줄어들고 심지어 단점이 되기도 합니다.

3. 더 높은 성능. Svelte는 일반적으로 사용되는 Virtual Dom을 사용하지 않고 대신 템플릿 구문을 사용하여 컴파일러가 컴파일 단계에서 업데이트해야 하는 데이터를 기록할 수 있도록 합니다. 이로 인해 Svelte는 React뿐만 아니라 Angular 및 Vue보다 더 나은 성능을 발휘합니다.

4. 웹 구성 요소 배포 개선. Svelte는 JS로 직접 컴파일되어 브라우저에서 인식할 수 있는 웹 컴포넌트를 생성합니다. 이를 통해 Svelte를 기반으로 개발된 컴포넌트를 React/Vue/Angular 등 다른 프레임워크에서 사용할 수 있습니다.

시간이 흐르고 Svelte의 개발 속도는 우리의 상상을 뛰어넘을 수도 있습니다. TypeScript를 지원하지 않는 프런트엔드 프레임워크로 미래가 없다는 비판을 받아온 Svelte도 2021년에는 TypeScript를 지원합니다. UI 라이브러리 Svelte Material UI도 점차 iterating 중이며, 개발자 커뮤니티도 점점 더 소규모로 합류하고 있습니다. 파트너, 테스트, 웹 구성 요소, SSR 등에서 Svelte의 단위 실습을 강화합니다.

2021년을 돌아보면 Svelte에서 가장 중요한 점은 다음 두 가지입니다.

1 2021년 11월 20일에 가을 서밋이 열렸습니다. 정상회담에서 Rich Harris는 Svelte의 역사에 대해 설명하고 Vercel에 합류한 후 Svelte를 정규직으로 유지할 것이라고 발표했습니다. 커뮤니티의 많은 개발자들도 정상회담에 초대되어 Svelte의 관행 중 일부를 공유함으로써 Svelte의 더 많은 가능성을 볼 수 있었습니다.

2. SvelteKit이 공식적으로 베타 버전을 출시합니다. SvelteKit은 Vue.js를 기반으로 개발된 Nuxt.js 프레임워크와 유사하게 Svelte를 기반으로 개발된 웹 애플리케이션 프레임워크입니다. 서버 측 렌더링 SSR, 라우팅, TypeScript 지원, less/sass 지원, Vite 패키징 및 기타 기능을 상속합니다. 효율적으로 개발이 가능하며 고성능을 가지고 있습니다. SvelteKit에는 아직 해결해야 할 버그가 있고 일부 누락된 기능을 시급히 개선해야 합니다. 그러나 여전히 프로젝트가 프로덕션 환경에서 이를 사용하는 것을 방해하지는 않습니다.

Disruptor가 꽃피기를 기다리며

Svelte가 개발자들 사이에서 큰 인기를 얻고 있음을 알지만, 아직까지는 Svelte를 사용한 대규모 애플리케이션을 보기 어렵고 성능 장점, 크기 장점 등이 눈에 띕니다. 대규모 애플리케이션에서는 입증되지 않았습니다. 특히 대기업에서는 React/Vue/Angular가 가장 먼저 지배하기 때문에 이미 매우 완벽한 시스템 지원 솔루션이 있습니다. . Svelte는 가야 한다. 갈 길은 아직 멀다. 그러나 우리는 Alibaba, Byte, Tencent를 포함한 대기업들도 Svelte 개발을 새로운 비즈니스에 활용하려고 시도하고 있음을 관찰했습니다. 이는 중소 규모 애플리케이션, h5 애플리케이션, 웹 구성 요소 등에 장점이 있으며, 시도해 볼 가치가 있습니다. Svelte에는 많은 장점이 있지만 React/Vue/Angular의 상태에 직접 도전하고 싶다면 여전히 대규모 애플리케이션 벤치마크를 기다려야 하며 주요 회사가 Svelte를 기반으로 하는 UI 라이브러리를 출시할 때까지 기다려야 합니다. 이륙하십시오. 위대함의 시간이 올 것입니다.

4. 데스크톱 - 프론트엔드 개발의 차세대 전장

데스크톱 애플리케이션의 영향력을 계속 확대해 나가세요

Github은 2014년 Electron 오픈소스 프레임워크를 출시한 이후 프론트엔드가 웹 클라이언트의 한계를 벗어나 최근에는 Electron, React Native, Flutter 등의 애플리케이션 프레임워크에 의존하여 데스크톱 애플리케이션 개발이 가능해졌습니다. , 데스크톱 애플리케이션의 프런트엔드 크로스엔드 개발 개념이 계속해서 뜨거워지고 있습니다. 이러한 솔루션은 QT 및 Xaramrin과 같은 기존 기술 스택에 비해 반드시 최고의 성능을 제공할 수는 없지만 매우 비용 효율적인 옵션이 등장하여 데스크톱 애플리케이션 개발의 문턱이 크게 낮아졌다는 의미입니다.

2021년에는 프런트엔드 Electron 및 React Native Desktop과 같은 애플리케이션 프레임워크의 업데이트된 반복이 안정적인 경향을 보였습니다. 일부 획기적인 하이라이트 기능은 나타나지 않았지만 각 프레임워크는 다음과 같은 문제점에 대한 심층적인 연구를 계속하고 있습니다. 성능 및 애플리케이션 시나리오 최적화, 최근 화두인 Flutter도 2021년 베타 단계에 데스크톱 버전을 포함시켰습니다. 갑자기 등장한 Tauri는 뛰어난 성능과 패키지 크기로 주목을 받았고, 그리고 그 잠재력은 과소평가될 수 없습니다. 전반적으로 데스크톱 애플리케이션 개발 분야에서는 프런트엔드 기술의 영향력이 나날이 커지고 있으며, 프런트엔드가 참여할 수 있는 콘텐츠의 비율도 늘어나고 있다.

Electron

Electron은 GitHub에서 개발한 오픈 소스 프레임워크입니다. Node.js(백엔드)와 Chromium의 렌더링 엔진(프런트엔드)을 사용하여 크로스 플랫폼 데스크톱 GUI 애플리케이션을 개발합니다. Slack, VSCode 등 잘 알려진 수많은 데스크톱 애플리케이션이 Electron을 사용하여 개발되었습니다. Electron에 필요한 개발 역량은 프런트엔드 개발 역량 기술 스택과 크게 중복됩니다. 따라서 프런트엔드 개발을 전공하는 학생의 경우 데스크톱 개발에 Electron을 사용하는 임계값은 상대적으로 낮습니다. Electron은 8년 동안 깊이 있게 개발되고 반복되어 왔으며 풍부한 체인을 통해 시작 비용을 더욱 절감합니다.

데스크톱 애플리케이션 개발에 Electron을 사용하면 프런트엔드 자체 기능을 향상시킬 수 있으며 한편으로는 기술의 폭을 확장하고 프런트엔드 비즈니스 기능의 범위를 단일 웹 페이지에서 PC 애플리케이션으로 확장할 수 있습니다. 일부는 현재 Electron에서 지원되지 않습니다. 반면에 Node 구성 요소를 C++로 작성하면 일부 기존 웹 보안 제한 사항 및 호출과 같은 프런트 엔드 측의 많은 제한 사항이 깨졌습니다. 개발 능력을 강화할 수 있는 시스템의 기본 인터페이스.

물론 Electron에 결함이 없는 것은 아닙니다. 일반적으로 비판받는 단점 중 일부는 다음과 같습니다.

• Chromium 커널과 함께 번들로 제공되는 종속 항목이 많기 때문에 일반적으로 패키지 크기가 너무 큽니다. 100M+. 최적화를 위해 Asar 압축, 동적 링크 라이브러리 등을 사용할 수 있습니다.

• 높은 메모리 사용량 마찬가지로 번들로 제공되는 Chromium 커널로 인해 Electron의 메모리 사용량도 일반적으로 높습니다.

• UI 레이어의 시각적 렌더링 효율성은 다중 프로세스 처리 작업과 같은 최적화 방법을 통해 최적화될 수도 있으며 시각적 아티팩트를 사용하여 사용자 경험을 향상시킬 수도 있습니다.

Electron에는 몇 가지 알려진 문제가 있지만, Electron의 완전한 생태계 체인과 프런트엔드 기술과의 높은 중첩은 여전히 ​​데스크톱 애플리케이션의 신속한 개발을 위해 권장되는 솔루션입니다. 또한 몇 가지 일반적인 최적화 방법을 통해 성능 문제를 해결하는 것이 더 쉽습니다. .을 해결하고 80점 레벨에 도달하세요. 2021년에도 Electron은 8주마다 하나의 주요 버전의 안정적인 업데이트 빈도를 유지하고 있으며 V12에서 V15까지 여러 주요 버전을 출시했습니다. 업데이트된 콘텐츠는 주로 API 삭제 및 수정, 시스템 기능 적용 및 종속 항목에 중점을 둡니다. Chromium 커널 업데이트 및 기타 세부 정보와 같은 버전.

React Native Desktop

React Native는 이전 React 프런트엔드 프레임워크를 기반으로 Facebook 기술팀이 2015년 4월 오픈소스로 공개한 모바일 크로스 플랫폼 개발 프레임워크입니다. 데스크톱 애플리케이션 구축과 관련하여 RN 팀은 아직 공식 데스크톱 버전을 출시하지 않았으며 주로 커뮤니티 프로젝트에 의존하여 지속 가능한 개발 역량을 구축합니다. 그 중 마이크로소프트가 개발한 React Native For Windows + macOS 기술 솔루션은 2015년 말 프로젝트가 출시된 이래로 가장 축적된 경험과 가장 안정적인 개발 반복을 거친 솔루션이다. . 2021년에 RN 팀은 세 가지 중요한 버전 0.64-0.66을 출시했으며 Microsoft는 항상 React Native For Windows 반복에서 RN의 기본 버전에 대한 업데이트를 보장하고 수많은 Windows 관련 기능도 지원합니다. 주요 대상 사용자가 Windows 플랫폼을 사용하는 데스크톱 애플리케이션을 구축하는 경우 React Native For Windows를 사용하는 것이 좋습니다.

2021년에 출시된 중요한 버전에서 새로운 Android 12 및 iOS 15 시스템에 대한 지원을 제공하는 것 외에도 RN 기술 팀은 Microsoft 팀과 함께 데스크톱 애플리케이션 구축 기술의 공동 구축을 강조했다는 점을 언급할 가치가 있습니다. RN 팀은 React Native 데스크톱 버전의 사용자 경험을 개선하기 위해 Facebook의 메신저 팀 도입을 통해 데스크톱 애플리케이션에 대한 "독특한" 기술 기능을 제공할 것이라고 밝혔습니다.

Flutter Desktop

Flutter는 Google에서 출시한 모바일 UI 하이브리드 개발 프레임워크로 사용자가 iOS 및 Android에서 고품질 기본 사용자 인터페이스를 구축할 수 있도록 상향식 기본 라이브러리 세트를 구현합니다.

현재 Flutter는 데스크톱 측의 개발 기능을 지원하기 위해 코드를 웹으로 변환하는 크로스엔드 렌더링 솔루션을 채택하고 있습니다. 하지만 Flutter to Web의 성능에는 여전히 개선의 여지가 많습니다. 올해 업계에서 많은 최적화 계획이 있지만, 성능을 크게 향상시키려면 마술처럼 수정하면 어느 정도 달성될 것입니다. Flutter 소스 코드는 장기적으로 효과적이지 않습니다. Flutter 버전을 반복하는 동안에는 많은 최적화 비용이 발생합니다. 그럼에도 불구하고 최적화된 Flutter to Web 성능은 기존 웹 프로젝트에 비해 약간 부족합니다. 따라서 웹 솔루션을 사용하는 개발자는 호환성을 고려하지 않고 Canvaskit 렌더링 모드를 사용해 보아야 합니다. 이 모드는 Skia의 WebAssembly 솔루션을 기반으로 하며 더 나은 렌더링 성능을 가지지만 로딩 성능은 지속적으로 최적화되어야 합니다.

아마도 데스크톱의 성능 문제를 완전히 해결하기 위해 Flutter Desktop은 2021년 중반에 Windows Native 솔루션을 출시했지만 현재는 64비트 시스템만 지원하므로 32비트 이하의 Windows 버전은 지원할 수 없습니다. Win7과 같은 시스템에서는 개발자의 호환성 비용이 크게 증가합니다. 그러나 2022년 2월 Flutter Desktop은 공식적으로 카메라, file_picker 및 shared_preferences를 포함하여 Windows 지원을 포함하도록 많은 일반 플러그인을 적용한 안정적인 버전을 출시했습니다. 또한 커뮤니티에서는 Windows 작업 표시줄 통합부터 직렬 포트 액세스까지 모든 것을 포괄하는 다양한 다른 패키지와 함께 Windows에 대한 지원을 추가했습니다. 동시에 많은 Microsoft 팀도 공식 버전 출시에 적극적으로 협력하고 큰 공헌을 했습니다. 2022년에는 Flutter Desktop을 시도해 볼 가치가 있습니다.

Tauri

최근 Rust를 활용한 Tauri는 Electron에 비해 크게 주목을 받았습니다.

• 더 작은 패키지 크기

• 더 많은 메모리 사용량 런타임 중 작음

• 안전이 최우선

• 진정한 오픈 소스

하지만 합리적으로 생각해보면 프론트 엔드 개발에는 세 가지 치명적인 단점이 있습니다.

• Tauri는 시스템 웹뷰를 사용합니다. 호환성 문제는 Electron이 해결하는 핵심 문제이기도 합니다

• nodejs를 버리면 생태계는 여전히 Electron의

• 기본 개발에는 Rust가 필요하며 시작하려면 일정한 비용이 듭니다

물론 Tauri는 아직 성숙하지 않았지만 Rust 생태계가 발전하고 브라우저 호환성이 작아짐에 따라 결과는 여전히 불확실합니다.

5. Rust - 새로운 언어를 마스터할 시간입니다

Rust는 JS 인프라의 미래입니다

프런트엔드 생태학적 도구의 점진적인 개선과 함께 새로운 영역을 탐구합니다. 끝, 여러분 동시에 우리는 여전히 도구의 성능을 향상시킬 방법에 대해 생각하고 있습니다. 우리 모두 알고 있듯이 JavaScript의 성능은 항상 모든 사람에게 비판을 받았지만 프런트 엔드 인프라는 성능을 매우 요구합니다. 프론트엔드 도구를 작성하기 위해 Rust는 탄생 이후 많은 개발자들의 관심을 끌었습니다. 지난 6년 동안 Stackoverflow는 가장 인기 있는 프로그래밍이 되었으며 언어는 지속적으로 1위를 차지했으며, Linux 프로젝트에서도 Rust를 사용하고 있다고 합니다. 일부 기능을 다시 작성하는 것도 Rust의 프론트엔드 분야 진출은 피할 수 없는 추세라고 할 수 있습니다. 2021년 Lee Robinson이 작성한 기사 "Rust는 JavaScript 인프라의 미래입니다"는 Rust로 작성된 많은 프런트엔드 도구 프로젝트를 나열하고 Rust가 Javascript 생태계에 미치는 영향을 계속 증가시킬 것이라고 말했습니다. 이 기사는 많은 공개 계정에서 리트윗되었습니다. , 모든 사람 사이에서 열띤 토론을 촉발했습니다.

Rust 도구가 프런트엔드 생태계에 통합되었습니다

프런트엔드 구축 분야에서 2021년에 매우 눈에 띄는 프로젝트가 등장했습니다. swc는 Rust로 작성된 빌드 도구이며 컴파일에 사용할 수 있습니다. 현재 Next.js, Parcel, Deno 등과 같은 일부 잘 알려진 프로젝트에서 사용하고 있으며 Next.js 12에서는 babel 대신 swc를 직접 사용하며 공식 웹 사이트 블로그에 다음과 같이 명시되어 있습니다. swc를 사용한 후 핫 업데이트 속도가 3배로 빨라졌고, 빌드 속도도 5배로 빨라져 Rust의 강력한 성능을 보여줍니다.

Rust는 구축 외에도 프런트엔드의 다른 영역에서도 사용됩니다. 예를 들어 Deno의 런타임 엔진도 Rust로 작성된 차세대 프런트엔드 도구인 Family Bucket Rome입니다. Rust를 사용하여 다시 작성됩니다. Node.js는 고성능 확장을 위해 Rust 모듈을 호출할 수 있습니다. Rust로 작성된 dprint 표준 코더는 Rust를 WASM 및 WASM으로 컴파일할 수도 있습니다. yew와 Percy처럼 프론트엔드 프레임워크가 등장했습니다.

Rust 도구가 프런트엔드 생태계에 더욱 깊이 통합될 것으로 예상되며, 이는 프런트엔드 생태계의 또 다른 업데이트를 촉발할 수 있습니다.

프런트엔드 사람들이 새로운 언어를 배울 시간입니다

많은 사람들이 이러한 트위터 스크린샷을 본 적이 있을 것입니다. Redux 작성자 Dan Abramov는 "향후 3년 동안 가장 배울 가치가 있는 언어는 무엇입니까?"라는 질문에 답했습니다. "Rust"는 프론트 엔드 인력에게 영감을 줄 수 있습니다. 이제 프론트 엔드 생태계를 활성화하기 위해 새로운 언어를 배워야 할 때입니다. 그러나 많은 사람들은 Rust의 가파른 학습 경로에 낙담할 것입니다. 그러나 실제로 Rust는 유사합니다. 프론트엔드 개발은 많은 곳에서 이루어지고 있으며 시작하는 것이 그렇게 가파르지는 않습니다.

예를 들어, 툴 체인에서 Rust의 Rustup은 실행 중인 툴 카고(Rust 버전의 npm)를 전환할 수 있는 nvm과 동일하지만, Rustup을 설치하면 nvm보다 더 강력합니다. , Clippy(Eslint의 Rust 버전), Rustfmt(Prettier의 Rust 버전)도 설치되며 Rust 지원 도구를 사용하여 생성된 프로젝트에는 이미 코드 형식 지정 및 분석 지원 도구가 함께 제공됩니다.

cargo와 npm의 유사점을 살펴보겠습니다. 두 도구는 많은 명령에서 유사하며, 프로젝트에서 구성해야 하는 npm의 일부 명령은 화물에서도 구성할 필요가 없습니다. 모노레포 관리 없이 멀티 패키지 프로젝트를 직접 구성할 수 있습니다. 카고는 npm에 해당한다고 하기보다는 npm과 Yarn의 조합에 더 가깝습니다. 이는 Rust 팀이 최신 언어 도구 체인을 참조한 결과이기도 합니다. .

Rust는 구문 측면에서도 매우 현대적인 언어의 특성을 갖고 있으며, 함수형 프로그래밍과 구조화된 언어의 특성을 활용하고 이를 기반으로 더욱 발전된 구문을 많이 만들어냅니다. 함수형 프로그래밍에는 JavaScript도 많이 있습니다. 예를 들어, JS의 화살표 함수는 Rust의 폐쇄형 함수에 해당하며, Rust의 배열에는 Map, Reduce, Filter 등의 함수도 있습니다. 변수에 할당되었습니다.

프런트 엔드가 배울 수 있는 두 번째 언어가 과거에 C++였다면 지금은 Rust일 것입니다. 이는 C++보다 더 현대적인 종속성 관리, 구문 및 도구 체인을 갖추고 있으므로 , 또한 프런트엔드 분야에서 경쟁력을 높일 수도 있습니다.

6. 로우코드는 계속해서 화두가 될 것입니다

2020년 기술 트렌드에서 '로우코드'를 이야기한 지 벌써 1년이 지났습니다. 시장 규모는 2020년 19억 개에서 2.85억 개로 늘어났습니다. 이는 의심할 여지 없이 이 분야가 여전히 뜨겁고 빠르게 발전하고 있음을 보여줍니다. 2020년이 로우코드 분야의 지속적인 가열에 ​​대한 기대를 주었다면, 2021년에는 로우코드 분야의 향후 발전에 대한 더 많은 추세를 볼 수 있는 해가 될 것입니다.

한편으로는 Tencent WeChat 및 Alibaba YiDe와 같은 엔터프라이즈급 로우 코드 플랫폼이 업계에서 탄력을 받기 시작하는 것을 확인했으며, 다음과 같은 관리 데스크 구축에 중점을 두는 회사 내 플랫폼도 있습니다. Wuji와 점차 성숙해지고 있습니다. 수많은 플랫폼 기반 제품이 여전히 차별화되고 빠른 속도로 개발되고 있으며 여전히 주류 개발 아이디어로 자리 잡고 있습니다. IMWeb 팀 내에서는 2019년 로우코드 플랫폼 Vision을 운영한 이후 20년 만에 로우코드 관리 플랫폼인 Hulk를 운영하는 등 수직적 로우코드 플랫폼을 통해 비즈니스 연구 개발에 박차를 가해 왔습니다. 2021년에는 서버측 시나리오를 더욱 시도하고 인터페이스 구축에 중점을 두고 HulkData 플랫폼을 다듬었습니다.

HulkData는 웹 시각적 구성 요소를 통해 파이프라인을 구축하고, 적은 양의 코드로 데이터베이스 또는 기존 API를 기반으로 새로운 API 인터페이스를 생성합니다. HulkData는 BPMN 2.0 프로토콜을 사용하여 그래픽을 사용하여 비즈니스 프로세스를 표현하고, 여러 비즈니스, 여러 데이터 리소스, 로우 코드, 플러그인 메커니즘, 프로세스 조정, 요청 및 응답 매개변수 수정을 지원합니다. 서버리스는 점점 성숙해지고 있으며, 서버리스의 운영이 필요 없는 기능은 HulkData에 매우 좋은 기회입니다. HulkData에서 생성된 인터페이스는 SCF 형식으로 Tencent Cloud에 배포되며 서버 운영에 주의를 기울일 필요가 없습니다. 그리고 유지 보수. HulkData 서버 측 인터페이스 오케스트레이션을 사용하면 비즈니스 로직을 신속하게 구현하고 비즈니스 애플리케이션을 민첩하게 수신 및 전달할 수 있습니다. 전송 속도는 기존 개발 모델보다 80% 빠릅니다. 현재 3대 내부업무 접속은 총 400개 이상의 인터페이스를 사용하고 있으며 정상적으로 운영되고 있습니다.

한편, 빠르게 발전하고 있는 차별화된 시나리오 기반 플랫폼 제품들 사이에는 어떤 공통점이 있는지 생각해 볼 필요가 있을까요? 결국 어떤 시나리오를 목표로 하든 로우 코드 플랫폼을 처음부터 구축하는 데 드는 비용은 결코 낮지 않으며 이러한 유형의 리소스 낭비는 대형 제조업체에서 특히 두드러집니다.

2020년 말 IMWeb 팀 내에서 시작된 Gems 로우 코드 엔진 프로젝트는 실제로 이 문제를 탐구한 것입니다. 로우코드 엔진의 핵심 목표는 상위 계층 플랫폼을 보다 효과적으로 구축할 수 있도록 기본 표준 및 기능 세트를 제공하는 것입니다. 이 사고의 핵심은 엔진 모델과 기능의 완성도는 물론 다양한 시나리오에서의 확장성에 있습니다. 로우 코드 엔진인 Gems는 지난 21년 동안 기본 기능과 디자인을 지속적으로 개선하여 전체 보드 플러그인, 핵심 편집 개체 API 및 기타 기능을 제공했습니다. 팀 내 운영 및 관리를 위한 로우 코드 플랫폼을 안정적으로 지원하는 것 외에도 팀을 넘어 점차 확장되어 회사 내 여러 팀이 자체 비즈니스 시나리오에 맞는 로우 코드 플랫폼을 효율적으로 구축할 수 있도록 지원합니다.

동시에, 우리는 올해 말 GMTC 컨퍼런스에서 알리바바가 그룹의 로우코드 엔진을 외부 세계에 홍보한 것을 보았습니다. 공유 콘텐츠로 판단하면, 60개 이상의 로우 코드 플랫폼과 Tencent의 내부 로우 코드 엔진인 Code Oteam도 2021년에 구성되기 시작했으며 주요 목표도 기본 코어를 공동 구축하는 것입니다. 업계 전체를 보면 로우코드 엔진이 등장하기 시작했고, 그 추세는 계속해서 상승할 것으로 예상된다. 이 분할된 트랙에는 대규모 제조업체만 포함될 수 있습니다. 소규모 제조업체나 독립 개발자에게는 없는 많은 장면 지원 검증이 필요하기 때문입니다.

전반적으로 차별화된 플랫폼 제품은 여전히 ​​로우 코드 분야에 접근하는 주요 방법이 될 것이며 로우 코드 엔진의 출현은 전체 산업에 더 많은 가능성을 가져올 것입니다.

7. D2C 프론트엔드 인텔리전스의 미래는 유망합니다

"프런트엔드 인텔리전스"는 최근 몇 년간 프론트엔드 + AI 방향으로 업계에서 새로운 탐구입니다. 지능이란 무엇입니까? 이는 지능형 알고리즘을 프런트엔드 엔지니어링 관행과 결합하고 기계가 개발을 지원할 수 있도록 하는 것을 의미합니다.

D2C: 역사와 현황

지금까지 프론트 엔드 인텔리전스 분야에서 가장 큰 제품 형태는 다양한 Design to Code(이하 D2C) 도구: UI 디자인 초안을 시리즈를 통해 입력하는 것입니다. 알고리즘의 사용 가능한 코드를 출력합니다.

2017년 논문 pix2Code는 이미지 생성 코드에 대한 아이디어를 제안했습니다.

2018년 Microsoft는 Sketch2Code 프로젝트를 오픈 소스화하여 이 방향의 타당성을 더욱 검증했습니다.

2019년 Alibaba Taobao는 imgcook을 출시했으며 그 후 몇 년 동안 Double Eleven, 618 등 수많은 비즈니스를 지원했습니다. 이는 D2C 기술의 점진적인 성숙과 대규모 비즈니스 구현의 필요성을 나타냅니다.

2021년이 다가오고 있으며, 국내외 주요 기업들이 이 분야에 대한 탐색과 실천에 나섰습니다.

Tencent IMWeb 팀은 Project Auton을 출시했으며, 내부 테스트를 거쳐 올해 6월 외부 서비스를 제공할 예정입니다. Alibaba imgcook은 계속해서 빠르게 반복하고 있습니다. Byte는 로우 코드 플랫폼을 기반으로 하는 "ALYX" 프로젝트를 인큐베이팅했으며 58팀은 오픈 소스 Picasso를 출시했습니다. ... .

이 외에도 D2C 분야에도 수많은 스타트업이 등장했습니다. 국내 CodeFun, Blue Lake, 해외 Framer, Anima 등

CodeFun은 사용 편의성과 복원 측면에서 비교적 좋은 성능을 가지고 있으며 출시 이후 좋은 평판을 얻었다는 점은 언급할 가치가 있습니다.

그러나 전체 프론트엔드 오픈소스 커뮤니티를 통틀어 현재 D2C 분야에서 충분히 영향력 있는 오픈소스 프로젝트는 없습니다. 따라서 각 기업은 기본적으로 '밀폐 작업' 상태에 있다.

동전의 양면: 결함, 시나리오 및 기회

순수한 시각적 알고리즘을 기반으로 한 초기 솔루션에 비해 현재 대규모 D2C 제품은 기본적으로 디자인 소스 파일(Sketch, Figma, XD 등)을 다음과 같이 사용합니다. 원래 들어가요.

순수한 시각적 알고리즘은 2차원 이미지에서 UI 레벨과 같은 정보를 추출하기 어렵기 때문에 디자인 초안 파일은 내부 DSL을 구문 분석하여 보다 자세한 구조화된 UI 설명을 얻을 수 있으며, 이는 후속 처리 및 코드에 더 편리합니다. 세대.

전통적인 프로 코드 개발 모델에서는 일반적으로 "PRD + 디자인 초안"이 비즈니스 코드 생성을 위한 입력으로 사용됩니다. 그러나 D2C 시스템은 디자인 초안을 유일한 입력으로 사용하고 디자인 초안은 단순한 UI 설명일 뿐이므로 디자인에서 유추할 수 없는 정보가 많이 발생합니다. 예를 들어 애니메이션, 상호 작용, 논리, 심지어 반응성까지 D2C에만 의존해서는 달성할 수 없습니다.

이러한 단점으로 인해 대부분의 D2C 시나리오는 개발을 위한 보조 도구로만 사용됩니다. 진정한 완전 지능화(완전한 논리로 코드를 생성할 수 있고 사람의 개입 없이 프로덕션 환경에서 사용할 수 있음)하기에는 아직 너무 이르습니다.

위에 언급된 많은 단점에도 불구하고 D2C는 UI 개발 분야에서 큰 잠재력을 가지고 있습니다.

D2C 제품(UI를 설명하는 구성 요소/페이지 코드 또는 DSL)은 일반적으로 다음과 같은 소비 경로를 갖습니다.

• 출력 코드는 기본 UI 구성 요소로 개발자가 2차 개발한 것입니다.

• 출력코드는 기본자료로 제공되며, 로우코드/노코드 플랫폼과 결합하여 2차 편집 및 편곡이 가능합니다.

• DSL을 제작하고 이를 맞춤형 렌더링과 결합하여 직접 렌더링합니다.

특히 2차 소비 경로의 경우 최근 각광받는 로우코드 플랫폼의 도움으로 수동 개입과 ​​데이터 바인딩, 논리적 배열, 스타일 편집, 대화형 배열 등의 2차 개입이 수행됩니다. D2C Editing으로 제작된 UI 자료는 D2C 기능의 단점을 보완하고 빠르고 효율적이며 보관 가능하고 재사용 가능한 코드 제작 SOP 세트를 구축할 수 있습니다.

또한 D2C는 공급 효율성이 높아 로우코드/노코드 소재 생산 병목 현상을 극복할 수 있어 프런트엔드 R&D 패러다임이 프로코드에서 로우코드로 전환되는 데 힘을 더해줍니다.

D2C + 로우 코드/노 코드의 도움으로 최근 몇 년간 SaaS, FaaS, BaaS와 같은 인기 있는 기술 제품 형태가 결합되어 가까운 미래에 실제로 이를 달성할 수 있을 것으로 예상됩니다. 엔지니어가 제로 코드 속도를 달성하려면 완전한 데이터, 상호 작용 및 논리를 갖춘 제품을 출시해야 합니다. 이는 많은 혁신적인 기업의 초기 비용을 크게 줄였으며 심지어 차세대 인터넷 기업가 정신을 촉진할 수도 있습니다.

그러나 아직까지 위의 제품 형태(D2C + 로우코드/노코드 + SaaS/FaaS/BaaS)를 완벽하게 통합하여 우수한 사용자 경험을 유지하면서 폐쇄 루프를 형성할 수 있는 플랫폼은 없습니다. 향후 몇 년 안에 이 분야에서 몇몇 스타 스타트업이 탄생할 수도 있습니다.

미래를 바라보며: 심층 육성, 통합, R&D 패러다임 변화

2022년을 바라보며 프론트엔드 산업의 지능화와 D2C는 다음과 같은 두 가지 주요 트렌드로 계속해서 발전할 것으로 예측할 수 있습니다. 전체적으로:

• 수직적으로: 지속적 프로세스, 알고리즘 및 경험을 심층적으로 육성하고 최적화하여 "지능적"을 점점 더 "지능적"으로 만듭니다.

• 수평적으로: 표준 및 프로세스를 확립하고, 업스트림 및 다운스트림 기능을 통합하고, 로우 코드, 노코드, FaaS, BaaS, SaaS, 디자인 시스템, 알고리즘 시스템, R&D 시스템, 데이터 시스템 등을 연결합니다... 산업화된 급속 생산 시스템으로 생산성이 향상됩니다.

장기적으로 위 시스템이 확립되면 업계는 반드시 R&D 모델의 다음 변혁을 시작하도록 이끌 것입니다. 현재의 프로코드 기반 R&D 모델에서 프로코드, 로우코드, 노코드 3가지 모델이 서로 보완하고, 서로 공급하고 힘을 실어주는 모델로 변모하게 된다. 동시에, 표준화된 시스템 구축으로 인해 자재 및 제품의 일반화 및 재사용이 더욱 용이해졌습니다. R&D 효율성에 미치는 영향은 의심할 여지 없이 엄청납니다!

이것들은 모두 상상력으로 가득 차 있습니다. 지능을 향한 여정은 의심과 장애물로 가득 차 있지만 미래는 기대할 가치가 있습니다. 새해에도 계속해서 육성하고 발전할 것이며, 2022년에도 미래를 기대할 수 있습니다...

8. DevOps, R&D 효율성은 여전히 ​​​​중점입니다

R&D 효율성은 매우 뛰어난 영역입니다. 인터넷 기업과 기존 소프트웨어 기업 모두에 대한 관심입니다. 인터넷 거대 기업은 점점 더 복잡해지는 제품 개발에 대처하기 위해 R&D 능력을 지속적으로 향상시키기 위해 "R&D 효율성"을 사용하여 구석구석에서 추월하기를 희망합니다. 후발업체의 장점을 최대한 활용하고, 더 많은 중소기업이 이 분야에 만장일치로 막대한 투자를 한 것을 보고 성과 분야에서도 노력을 기울이고 있습니다.

애자일 개념과 유사하게 R&D 효율성이 무엇인지 정확하게 정의하기는 어렵습니다. 실제로 많은 복잡한 개념은 정의되지 않고 점차적으로 현상으로 나타나고 적절한 표현을 찾아냅니다. 실제로 효율성과 효율성은 소프트웨어 엔지니어링에서 결코 독점적인 용어가 아니었습니다. 인류 발전의 역사를 통틀어 생산성과 생산 효율성은 지속적으로 향상되었습니다. 디지털 시대에 소프트웨어 R&D 효율성의 중요성이 강조되었습니다. R&D 효율성을 한 문장으로 요약한다면 "더 효율적으로, 더 높은 품질로, 더 안정적이고 지속 가능하게 더 나은 비즈니스 가치를 제공"이라고 요약할 수 있습니다.

우리가 할 수 있는 것은 R&D 효율성의 절대값을 높이는 것이 아니라, R&D 효율성 저하가 너무 빨리 떨어지지 않도록 최대한 늦추는 것, 현상 유지를 위해 노력하는 것이 성공입니다. .

IMWeb 팀은 2021년 DevOps에서 큰 진전을 이루었습니다. 한편으로는 개발, 테스트, 배포, 운영 및 유지 관리 등 다양한 분야에서 Tencent Cloud Coding과 공동 구축했습니다. 팀이 자체 개발한 성능 플랫폼 Thanos와 코딩 팀은 심층적인 애플리케이션 워크플로우 솔루션을 구축했습니다. 기관 공동 디버깅 플랫폼 TDE 및 Coding 팀은 테스트 환경을 위해 Nohost 게이트웨이를 공개했으며 인터페이스 공동 디버깅 계약 플랫폼 Tolstoy와 Coding은 API 호스팅, 모의 및 테스트 기능을 공동으로 구축했습니다. 연구 효율성 측면에서 우리는 Tencent Cloud Coding을 통해 통합 성능 플랫폼을 달성했으며 전반적인 연구 개발 효율성이 30% 이상 향상되었습니다.

9. 마이크로 프런트엔드, 과소평가할 수 없는 링크

2016년 ThoughtWorks는 대규모 프로젝트를 작고 유연한 프로젝트로 분할하는 아이디어를 제안했습니다. 독립적으로 작동하고 독립적으로 배포할 수 있어 마이크로 프런트엔드 커튼이 열립니다. Alibaba가 2019년 싱글 스파 기반의 qiankun 마이크로 프런트엔드 프레임워크를 개발한 이후 마이크로 프런트엔드의 인기가 높아지고 있습니다. 마이크로 프런트엔드 개발 과정에서 개발자들은 마이크로 프런트엔드의 현재 적용 시나리오도 천천히 알아냈습니다.

2021년에는 이미 많은 마이크로 프런트엔드 프레임워크가 있으며 그 중 유명한 프레임워크가 있습니다. 오래된 싱글 스파, Github 스타 수가 가장 많은 마이크로 프론트엔드 프레임워크인 qiankun, 그리고 신흥 마이크로 프론트엔드 프레임워크인 JD.com의 MicroApp이 있습니다.

single-spa 2020년 v5.0이 출시된 이후 작년 상반기에는 v5.0의 일부 버그를 수정하는 것이 주요 작업이었고, 하반기에는 v6의 베타 버전이 출시되었습니다. .0은 7월에 출시되었습니다. v6.0에도 일부 주요 변경 사항이 있지만 대부분의 사용자는 이러한 변경 사항에 대해 코드를 업데이트할 필요가 없습니다. 더 중요한 것은 브라우저 측면에서 v6.0이 IE11을 지원하는 마지막 버전이 될 것이며 향후 버전 v7.0+에서는 더 이상 IE11을 지원하지 않을 것이라는 점입니다. 싱글 스파 팀은 브라우저에 더 많은 에너지를 집중할 것입니다. 호환성은 전체 단일 스파 생태계를 유지하는 데 달려 있습니다. v6.0에는 두 가지 새로운 기능도 추가되었습니다.

• 페이지 탐색의 비동기 취소를 지원합니다.

• 공개된 patchHistoryApi, 개발자는 단일 스파로 캡슐화된 pushState/replaceState/popstate/hashchange를 사용할 수 있습니다.

오래된 프레임워크가 열심히 작동할 뿐만 아니라 "아마 지금까지 본 것 중 가장 완벽한 마이크로 프런트엔드 솔루션"이라고 주장하는 qiankun도 지속적으로 업데이트되고 있습니다. qiankun은 주로 다양한 애플리케이션 시나리오의 일부 문제를 해결하고 샌드박스의 DefineProperty 문제 및 샌드박스 성능 문제와 같은 샌드박스의 일부 JavaScript 호환성 문제를 수정합니다. qiankun은 작년에 업데이트가 많지 않은 것 같았지만 많은 업데이트가 언급된 흥미로운 V3.0 RoadMap도 출시했습니다. 주요 업데이트에는 독립 애플리케이션 로딩 모듈과 독립 샌드박스 모듈이 포함됩니다.

그러나 qiankun은 여전히 ​​강력한 침입 문제를 해결하지 못했고 iframe만큼 쉽게 페이지를 삽입할 수 없습니다.

하반기 좋은 소식 중 하나는 JD.com이 자체 마이크로 프런트엔드 솔루션인 MicroApp도 출시했다는 것입니다. Single-spa, qiankun의 컴포넌트화 아이디어를 채택하지 않고 WebComponent의 아이디어를 활용하며, 맞춤형 ShadowDom과 결합된 CustomElement를 사용하여 마이크로 프런트 엔드를 클래스 WebComponent 컴포넌트로 캡슐화하여 컴포넌트 렌더링을 구현합니다. 마이크로 프런트 엔드의 다음과 같은 특성을 가지고 있습니다. e 클래스 웹 구성 요소 + html Entry

• 라이프 사이클

• 리소스 주소 보충

• , 스타일 격리, 요소 격리

• 데이터 통신

• Preloading

• 플러그인 시스템

• MicroApp은 유용성과 침입성 측면에서 완벽합니다. 이 프레임워크의 발전과 미래는 매우 기대됩니다.

일반적으로 마이크로 프런트 엔드의 기본은 "모든 대규모 시스템은 엔트로피 증가의 법칙을 벗어날 수 없다"에서 비롯됩니다. 마이크로 프런트 엔드가 해결할 수 있는 문제는 일부 모놀리식 애플리케이션을 해체하는 것이기도 하므로 마이크로 프런트 엔드는 " 비관적인 엔지니어"에 대한 엔지니어링 타협. 마이크로 프런트엔드 사용 여부에 대해서는 이 기사 "마이크로 프런트엔드가 필요하지 않을 수도 있습니다"에서 qiankun 작성자 kuitos의 분석을 읽을 수 있습니다.

IMWeb 팀은 지난 해 마이크로 프론트엔드에 대한 심층적인 연구를 수행했으며, 이전 Vue 모놀리스 프로젝트를 새로운 React 프로젝트와 통합하여 qiankun을 기반으로 한 증분 재구성 xiankun x 증분 재구성의 매우 성공적인 마이크로 프론트엔드 실행을 완료했습니다. 유기적으로 통합되어 병렬 개발과 원활한 재구성을 달성하여 프런트 엔드 생산성을 크게 향상시킵니다. 구체적인 실제 세부 사항에 대해서는 IMWeb 팀 공개 계정의 후속 기사를 주의 깊게 살펴보시기 바랍니다.

2022년 기술 트렌드를 전망합니다

비즈니스에 병목 현상이 발생할 수 있지만 기술 발전은 결코 멈추지 않습니다. 표준화, 산업화, 지능화, 대통일의 시대에 앞선 사람들은 항상 자신을 단련하고 자신의 경계를 돌파해야 합니다! 분할된 분야 측면에서 2022년에 대한 몇 가지 전망을 만들 수 있습니다.

React와 Vue는 여전히 각자의 특성에 따라 계속 개발하고 있으며,

초점은 여전히 ​​사용자 경험과 개발자 경험에 있습니다

. 다크호스 스벨트가 돌파할 수 있을지, 스벨트의 새로운 사고방식이 어떤 파급력과 영향을 미칠지 기대해 볼 만하다.

• 풀 스택의 심층 개발을 통해 각 주요 UI 프레임워크에는 풀 스택 애플리케이션을 구축하기 위한 자체 "메타 프레임워크"가 있습니다. 기존의 큰 형인 Nest 및 떠오르는 스타인 Remix와 함께 사용할 수 있습니다. 수백 개의 사상 학교가 경쟁하고 있다고 말했습니다.

  하지만 백엔드 개발의 깊은 바다는 특정 프레임워크로 채울 수 없습니다. 더 필요한 것은 프런트엔드 개발자의 인식과 경험 축적입니다. 더 포괄적으로.

• TypeScript는 이미 프런트엔드 프로젝트의 표준입니다.

  미래에는 생산성과 사용자 경험을 향상시키기 위한 더욱 강력한 지원 도구가 나올 것으로 예상됩니다.

• 모든 주요 크로스엔드 프레임워크는 데스크톱을 대상으로 하고 있습니다. 게다가 "클라우드 게임"의 인기와 함께 "클라우드 애플리케이션"도 큰 잠재력을 가지고 있습니다. 물론 프런트엔드 개발도 이러한 위치를 잃을 수는 없습니다. Electron의 커뮤니티와 Tauri의 퍼포먼스는 기대해볼 만합니다.

• 더 멀리 가고 싶다면 새로운 언어를 배울 시간, JS 인프라의 미래 - Rust, 풀스택 - Go, AI - Python, Flutter - Dart, 프론트엔드 언제쯤 할 수 있을까요? 자신의 경계를 깨기 위해? WASM은 앞으로 확실히 대박을 터뜨릴 것이고, 프론트엔드 없이는 알 수 없을 것입니다!

• ToB의 변화 추세는 분명하고, 로우 코드에는 많은 잠재력이 있으며, 만족스러운 점은 더 많은 대기업이 로우 코드, 오픈 소스 엔진을 통합하고 어디에서나 실행되는 로우 코드 플랫폼의 혼란을 끝내는 경향이 있다는 것입니다. , 이것도 인터넷 산업이 산업화와 지능화를 향해 나아갈 수 있는 유일한 길이다.

• D2C는 프론트엔드 인텔리전스의 시작이며, 아직 갈 길이 멀습니다. 더 많은 프론트엔드 인텔리전스 제품이 출시되길 기대합니다!

• 연구 및 효율성 플랫폼도 통일 단계에 있으며 내년에도 계속되어야 합니다 비록 고통이 따르겠지만 미래의 R&D 산업화와 지능화를 위해 노력할 가치가 있습니다!

• 5G 네트워크의 대중화와 휴대폰 하드웨어의 지속적인 개선으로 인해 기존 그래픽 미디어는 더 이상 대다수 네티즌의 욕구를 충족시킬 수 없습니다. 오디오 분야에는 아직 발전할 여지가 많다고 생각합니다. and video field in the future, 가상화와 메타데이터에서 우주시대가 오기 전에도 오디오와 비디오 분야는 여전히 이 시대의 핵심이었습니다.

• 비즈니스의 발전, 관리 시스템의 지속적인 성장 및 대통합 추세로 인해 Jushi 애플리케이션은 불가피하며 점점 더 많아질 것입니다. 마이크로 프론트엔드 구축의 생태와 발전, WebComponent에서 아이디어를 차용한 MicroApp의 모습은 매우 기대할만한 가치가 있습니다!