정적이든 아니든?

정적 웹 사이트 생성기? 내가 왜 그것을 사용하지 않습니까? Kev Quirk의 짧은 의견 : Kev는 WordPress를 사용합니다.

iPad에서 블로그를 원하십니까? 괜찮아요. 휴대 전화로 쓰고 싶습니까? 괜찮아요. 자주 사용하지 않는 기계에 작성 되었습니까? 브라우저가있는 한 문제가 없습니다.

우선, WordPress를 사용한다고해서 정적 웹 사이트 생성기를 사용할 수 없다는 의미는 아닙니다. WordPress에는 API가있어 빌드 프로세스 중에 API를 호출하여 웹 사이트를 구축 할 수 있습니다. 그것이 Gatsby가하는 일이며, 정적 웹 사이트를 내보내는 플러그인이 있으며 Frontity와 같은 프로젝트는 라인을 흐리게합니다.

그러나 나는 Kev의 이유에 동의합니다. 그의 모든 이유와 수많은 다른 사람들이 WordPress 웹 사이트를 운영하는 것은 완벽하게 받아 들여지고 종종 현명한 선택입니다. 나는 그것이 견고성과 기능적 완전성에 관한 것이라고 생각합니다. 전자 상거래 기능이 필요하십니까? WordPress에는 그것을 가지고 있습니다. 양식이 필요하십니까? 훌륭한 플러그인이 많이 있습니다. CMS의 기능을 향상시켜야합니까? 컨텐츠 유형과 콘텐츠를 제어 할 수 있습니다. 인증이 필요하십니까? 이것이 핵심 기능입니다. 훌륭한 편집 경험을 원하십니까? Gutenberg는 굉장합니다.

몇 번이고, 나는 WordPress로 원하는 것을 빠르고 효율적으로 구축하여 효율적이고 강력하게 느끼게합니다. 그러나 나는 특히 WordPress에 대해 이야기하고 싶지 않습니다. "클래식"CMS에도 동일하게 적용됩니다. Craft CMS에는 기본적으로 그래프 QL API가 있습니다. 방금 Drupal Jamstack 웹 세미나에 대한 게시물을 게시했습니다.

비교적 새로운 정적 웹 사이트의 세계에서 작은 일은 긴 연구와 구현 과정으로 바뀔 수 있으며, 지구상의 유일한 사람이 그렇게하는 것처럼 느껴집니다.

말한다 ...

정적 웹 사이트 생성기와 Jamstack의 세계에 대해 어떻게 생각하십니까? 그들은 훌륭합니다 .

이런 식으로 웹 사이트를 구축하는 데 많은 이점이 있다고 생각합니다. 데이터와 프론트 엔드의 분리는 현명합니다. 매우 안전합니다. 개발자 경험도 훌륭하며 미리보기 및 GIT 기반을 배포하는 데 모든 것이 좋습니다. 스타트 업 속도는 놀랍습니다 (CDN에서 HTML 서비스를 제공하는 것은 위업입니다).

고전적인 서버 측 CMS와 마찬가지로 정적 웹 사이트를 사용하면 정적 웹 사이트를 사용하더라도 역동적 인 일을하는 것을 막을 수는 없습니다. Josh Comeau는 이것에 깊이 들어가는 새로운 기사를 가지고 있습니다. 그는 브라우저에서 React와 많은 작업을 수행하는 멋진 작은 앱을 만들었지 만 여전히 대부분의 콘텐츠에 정적으로 서비스를 제공 할 수는 없습니다. 그는 이것을 "사고 방식의 변화"라고 부르며 데이터베이스 호출이 필요하다고 생각할 수있는 것을 말하지만 실제로 필요합니까? 데이터베이스 호출이 발생하고 정적 파일이 생성 되었습니까? 그렇지 않은 경우 컨텐츠 의 일부는 여전히 정적으로 생성 될 수 있으며 나머지는 동적으로 얻을 수 있습니다.

나는 우리가 두 세계의 최고를 진정으로 보기 시작하는 세상을 고대합니다. 우리는 가능한 한 많은 컨텐츠를 생성하고, API를 통해 가능한 많은 콘텐츠를 얻을 수 있도록 정적으로 생성 할 수 없으며, 프로세스 전반에 걸쳐 최고의 도구를 희생하지 않습니다.

정적 웹 사이트를 선택할 때 ...

• 가능하다면 속도와 안전성이 비교할 수 없기 때문에 고려해야합니다.
• 그린 필드 프로젝트를 진행하는 경우.
• 프로젝트가 구축되어 접근 가능한 API를 사용하는 경우 빌드 프로세스 중에 API를 호출하여 초기 HTML이로드 된 후 사용할 수 있습니다.
• 정적 웹 사이트 생성기가 자신이하고있는 일에 멋지게 보입니다.
• 비용 분석에서 더 저렴하다는 것을 보여줍니다.
• 특정 기능 (예 : 빌드 미리보기)이 워크 플로에 매우 유용한 경우.

서버 측 소프트웨어를 선택할 때 ...

• 클래식 CMS (예 : WordPress)의 기능이 필요한 경우 기술 부채가 너무 높습니다.
• 서버 측 렌더링 프로젝트 (Ruby on Rails, Python 등)에 깊이 관여 한 경우 기존 문제가 발생하지 않은 경우.
• 팀이 현장에서 가장 많은 전문 지식을 가지고 있다면.
• 비용 분석에서 더 저렴하다는 것을 보여줍니다.
• 구축하려는 내용에 대한 정적 솔루션 (예 : 포럼 소프트웨어)이없는 경우.
• 수백만의 URL과 같은 극단적 인 상황에 있고 정적 빌드 시간이 너무 길다면.

정적 웹 사이트를 선택하는 잘못된 이유 ...

• 서버를 사용해야합니다. (왜? 빌드 타임 또는 런타임에 서버에서 API를 계속 호출 할 수 있습니다.)
• 인증이 필요합니다. (왜? Jamstack은 JWT 등으로 인증을 완벽하게 구현할 수 있습니다)
• Jamstack 접근법도 고려하지 않았습니다.

서버 측 소프트웨어를 선택한 오류 이유 ...

• Jamstack 접근법도 고려하지 않았습니다.
• 편안한/기존/클래식/성숙/지원되는 잘 지원되는 도구를 사용하면 정적으로 무엇이든 구축 할 수 없다고 생각하기 때문입니다.
• SEO와 같은 질문. (무엇이든, 정적 렌더링은 더 나은 성능을 발휘해야합니다. 그러나 정적으로의 전환이 클라이언트 전화로 전환하여 제품 데이터를 얻는 등을 이해할 수 있습니다.)

위 내용은 정적이든 아니든?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!