Jamstack의 의미론

"Jamstack"이라는 용어는 최근 최신 응용 프로그램을 포함하도록 정의가 확장됨에 따라 활발한 논쟁을 불러 일으켰습니다. 나의 이전 기사 인 "STATIC vs. Dynamic vs. Jamstack : Line은 어디에 있습니까?"는 Jamstack 정의에 대한 나의 관점을 제시했습니다. 이 작품은 Jamstack의 진화와 용어의 의미에 미치는 영향을 탐구합니다.

정적 사이트 제작은 "Jamstack"레이블을 선행합니다. 얼리 채택에는 종종 GitHub 페이지에서 주최되는 간단한 블로그 또는 오픈 소스 문서가 포함되었습니다. 일부 개척자들은 더 큰 상업 프로젝트를 다루었지만 이것이 표준이 아니 었습니다.

정적 사이트는 한때 구식으로 간주되었습니다. 90 년대의 유물입니다. 문제는 발생했습니다. 왜 현대 기업들은이 겉보기에 구식 접근법을 받아 들일까요? Phil Hawksworth의 통찰력있는 IJS Talk는 모호성을 강조했습니다. "우리는 정적 경험 이나 정적 아키텍처 에 대해 이야기하고 있습니까?"

이 모호성, 특히 비 개발자에게는 이러한 모호성이 문제가됩니다. 현대 정적 사이트는 90 년대와 크게 다릅니다. 몇 가지 주요 기술 발전으로 인해 정적 사이트 개발이 활성화되었습니다.

• 강력한 브라우저 기반 애플리케이션 언어로의 JavaScript의 Evolution (Gmail의 2004 년 런칭은 초기 영향을 보여줍니다).
• 2008 년 Jekyll이 개척 한 정적 사이트 생성기 (SSG)는 컨텐츠 분리 및 레이아웃 관리와 같은 동적 기능을 도입했습니다.
• 한때 대기업에 전용 된 CDNS 는 AWS CloudFront와 같은 서비스 덕분에 쉽게 액세스 할 수 있고 저렴하게 이루어졌습니다 (2008 년에 출시).
• GIT 워크 플로 및 관련 CI/CD 도구는 오류가 발생하기 쉬운 FTP 배포를 대체했습니다.
• 번성하는 도구 생태계는 검색, 전자 상거래, 데이터베이스 및 댓글 시스템을 포함한 정적 사이트에 추가 기능을 제공합니다.

Jamstack은 정적 웹 사이트의 인식을 재정의했습니다. Matt Biilmann은 2016 년이 용어를 만들어 "정적"의 부정적인 의미없이 현대 정적 사이트의 장점을 포착했습니다. Cassidy Williams는 Jamstack의 본질을 적절하게 요약했습니다. "Jamstack은 모바일 앱과 같은 웹 애플리케이션을 구축합니다.

Jamstack은 WordPress 개발자와 강력하게 공감하여 복잡한 테마 및 플러그인 API에 비해 상쾌한 단순성과 제어를 제공합니다. Jamstack의 분리 된 건축물을 중심으로 한 커뮤니티가 등장했습니다.

Jamstack이 인기를 얻자 프로젝트 규모와 복잡성이 증가했습니다. Jamstack 원칙은 웹 사이트를 넘어 웹 응용 프로그램으로 확장되어 정적 사이트가 달성 할 수있는 것의 경계를 넓혔습니다. 플랫폼은 Jamstack 원칙을 사용하여 더 크고 더 복잡한 응용 프로그램을 수용하기 위해 기능과 워크 플로를 도입했습니다.

Cloudcannon 의이 진화에 대한 참여는 흥미 롭습니다. 우리는 프론트 엔드 개발자에게 힘을 실어주고 정교한 에지 기반 애플리케이션을 가능하게하는 도구의 번성하는 생태계와 함께 웹 개발의 큰 변화를 목격하고 있습니다.

도전은 Jamstack의 의미에 대한 합의가 부족하다는 것입니다. 간결한 정의가 존재하지만, 점점 더 역동적 인 행동에 대한 용어의 적용은 커뮤니티 내에서 분열을 일으키고 있습니다. 이 모호성은 용어가 만들어진 목적을 훼손하는 위험이 있습니다.

Jamstack의 원래와 진화 된 해석 사이의 겹치면 어려운 문제가 발생합니다. Jamstack 원칙을보다 역동적 인 접근 방식에 적용하는 것에 감사하지만 단순히 "Jamstack"과 같은 새로운 용어를 만드는 것은 혼란을 악화시킬 수 있습니다.

Netlify의 분산 영구 렌더링 (DPR)에 대한 Matt Biilmann의 관찰은 통찰력이 있습니다. "모든 기술의 경우 가장 어려운 부분은 단순성을 확립하는 것이 아니라 시간이 지남에 따라 보호하는 것입니다."

이것은 깊이 공명합니다. Jamstack의 유연성이 중요합니다. 프로젝트가 성장하거나 동적 기능이 필요한 경우 옵션이 존재해야합니다. 이러한 옵션이 없으면 Jamstack은 소규모 응용 프로그램으로 강등됩니다. 그러나 역동적 인 솔루션을 과도하게 강조하면 Jamstack 움직임에 힘 입어 우아한 단순성을 잃을 위험이 있습니다.

DPR은 대형 사이트를 사전 건설하는 한계를 우아하게 다루는 중요한 발전입니다. 100,000 페이지의 사이트의 경우, 하위 집합을 사전 건설하고 주문에 따라 다른 사람들을 구축하는 것이 가치있는 최적화입니다.

Jamstack 프레임 워크 내 DPR의 위치는 신중한 고려가 필요합니다. 포함 또는 배제는 중대한 영향을 미칩니다. Sean Davis의 정의는 다음과 같이 공명합니다. "Jamstack은 Edge에서 사전 컴파일 된 분리 된 프론트 엔드 웹 프로젝트를 원자 적으로 구축하고 전달하는 아키텍처입니다." DPR을 포함하도록 이것을 조정하려면 수정이 필요합니다. 그러나 공식 Jamstack 정의는 DPR을 잘 수용합니다.

공식 Jamstack 정의의 진화는 주목할 만하다. "Serverless"를 포함 시키면 프론트 엔드 개발자에 대한 접근성이 증가하는 것이 반영되지만 사전 렌더링 및 디커플링의 핵심 원칙과 충돌 할 수 있습니다. 이러한 핵심 원칙에는 업데이트가 필요합니까?

Jamstack의 미래에는 몇 가지 가능성이 있습니다.

1. 보다 역동적 인 접근 방식을위한 별도의 용어와 함께 원래 의미 (사전 렌더링 및 분리)의 유지.
2. 정의와 원칙의 확장으로, 잠재적으로 모호성이 증가합니다.
3. 엄격한 규칙이 부족한 커뮤니티 중심의 지침 세트로 Jamstack.
4. Jamstack은 "정적"레이블을 초월하여 정적, 하이브리드 및 동적 웹 사이트를 구분할 수 있습니다.
5. Jamstack은 주류가되어 단순히 "현대 웹 개발"으로 간주됩니다.

공동체 내의 다양한 관점은 합의와 명확한 길을 필요로합니다. 그렇지 않으면 옵션 3, 4 및 5의 조화가 가능합니다. Jamstack을 둘러싼 열정은 부인할 수 없으며 혁신은 흥미 롭습니다. 필요한 것은 앞으로의 계약입니다.

위 내용은 Jamstack의 의미론의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!