집 > 기사 > 웹 프론트엔드 > 웹 프런트엔드 템플릿 엔진을 선택하는 방법(권장)

웹 프런트엔드 템플릿 엔진을 선택하는 방법(권장)

不言앞으로: 2018-10-17 15:13:564184검색

이 글의 내용은 웹 프론트엔드 템플릿 엔진을 선택하는 방법(권장)에 대한 내용입니다. 참고할만한 가치가 있으니 도움이 필요한 분들에게 도움이 되었으면 좋겠습니다.

템플릿 엔진은 데이터를 조합하고 데이터를 다른 형태나 모양으로 표현하는 역할을 담당합니다. 브라우저의 페이지는 웹 템플릿 엔진의 최종 표현입니다.

템플릿 엔진을 직접 사용하든 안하든 웹 템플릿은 프런트엔드가 아니라 백엔드에 항상 존재했습니다. 그 출현은 Hypertext Markup Language HTML 표준이 공식적으로 확립되기 이전까지 거슬러 올라갑니다. .

서버 측 템플릿 엔진

내가 아는 최초의 웹 템플릿 엔진은 1997년에 공식적으로 탄생하여 서버 측에서 작동하는 PHP입니다. PHP의 공식 소개 내용을 살펴보겠습니다.

HP 사용자는 일반적으로 PHP 자체가 가장 자연스럽고 기본 PHP 템플릿 엔진이라는 데 동의합니다. PHP 세계에는 리패키지된 템플릿 엔진이 많이 있으며 그 중 유명한 것이 똑똑합니다.

다른 많은 서버 측 언어에는 JSP 및 Mustache와 같은 HTML 템플릿 엔진이 있습니다.

이러한 서버 측 템플릿 엔진이 생성한 최종 결과는 HTML(XML) 문자열이라는 점에는 의심의 여지가 없으며, 처리 흐름 로직은 호스트 언어 자체의 구문을 사용하여 구현됩니다.

공통 특징: HTML은 단순한 문자열이며 최종 결과에는 Tidy와 같은 정리 또는 수정 검증 도구가 필요할 수 있습니다.

질문입니다. 보조 캡슐화된 smarty가 필요한가요?

브라우저 측 템플릿 엔진

제가 아는 최초의 프런트엔드 템플릿 엔진은 Google Code에서 호스팅되고 탄생한 jCT입니다. 2008년에는 호스트 언어가 JavaScript이며 브라우저에서 작동합니다.

오늘 OSC에서 JavaScript 템플릿 엔진을 검색하면 100개 이상의 결과를 얻을 수 있습니다.

경량: tpl.js, T.js
Awareness: arttemplate, mustache.js, doT.js, 핸들바. pug
DOM 트리 기반: domTemplate, 투명도, 플레이트
VDOM 기반: htmltemplate-vdom, virtual-stache, html-patcher
인기 프레임워크: Vue.js, ReactJS, riot
Real-DOM: PowJS

공통 기능: 모두 보간을 지원합니다.

템플릿 엔진의 인기 비교, 최고의 자바스크립트 템플릿 엔진 투표 및 장단점에 대한 이유도 있습니다.

선택 방법

모든 엔진과 프레임워크는 적어도 특정 시대에는 항상 장점이 있으므로 이 기사에서는 특정 엔진의 나쁜 점에 대해 언급하지 않습니다. 객관적이지 않습니다. 이제 앞서 언급한 질문에 답해 보겠습니다. 스마트함이 존재하는 데 필요한가요? 내 대답은: 그렇습니다. 그 이유는 매우 간단합니다. 누구에게 사용되는지, 전반적인 배경에 따라 다릅니다. 프론트엔드와 백엔드가 분리되지 않거나, 프론트엔드 직원이 백엔드 언어에 익숙하지 않거나, 업무상 이를 요구하는 애플리케이션의 경우, 프론트엔드 직원이 백엔드 언어를 마스터하는 것이 현실적입니다. 더 일반적인 템플릿 구문(언어). 반대로 PHP 자체를 현명하게 사용하도록 놔두는 것은 정말 낭비입니다.

다음은 엔진 선택에 대한 일반적인 제안입니다.

전제는 선택한 엔진이 데이터 렌더링 요구 사항을 충족할 수 있고 기존 종속성과 충돌하지 않는다는 것입니다. 이미 엔진에 대해 잘 알고 있다면 이미 답을 알고 있습니다.

일회성 프로젝트 요구 사항인가요? 그렇다면 학습 복잡성이 가장 낮은 가벼운 프로젝트를 선택하세요. 컴포넌트 개발을 원하시나요?

엔진이 사전 컴파일된 결과를 지원하므로 매번 실시간으로 컴파일할 필요가 없습니다.

크로스 플랫폼을 원하시나요? React-JSX와 유사한 엔진이나 순수 VDOM 엔진이 선호됩니다.

배우거나 유지 관리하는 데 가장 덜 복잡한 것을 선택하세요. 우리 모두 알고 있듯이 개발자는 코드 작성보다 디버깅에 더 많은 시간을 소비하는 것을 싫어합니다.

마지막 단계는 성능 비교입니다. 성능 비교는 매우 상세한 작업이므로 다른 사람의 비교 결과가 반드시 귀하의 시나리오와 일치하지 않을 수도 있습니다.

문법 스타일의 비교가 약화되어야 한다고 생각합니다. 어떤 문법은 심지어 특별한 배경적 이유도 있습니다.

성능 비교가 마지막인 이유는 무엇인가요?

성능은 실제로 중요하지만 성능이 애플리케이션 경험에 영향을 미치지 않았다면 무시하십시오. 실제로 애플리케이션 시나리오를 시뮬레이션하는 것은 어렵습니다. 일반적으로 실제 시나리오를 통해서만 테스트할 수 있습니다. 현재 테스트 도구는 이 효과를 얻을 수 없습니다.

앞서 언급한 질문 중 일부에는 고정된 답변이 있습니다. 나머지 질문인 구성 요소 개발, 사전 컴파일 지원 및 복잡성을 고려하는 방법에 대해 논의해 보겠습니다.

컴포넌트 개발

컴포넌트 개발은 더 이상 템플릿 엔진 선택의 문제가 아닌 생태환경 선택의 문제입니다. 애플리케이션을 더 빨리 완료해야 한다면 시간이 최우선입니다. 사용하거나 참조할 수 있는 구성 요소가 충분한 인기 있는 프레임워크를 선택하세요. 귀하의 응용 분야가 독립적인 생태 환경을 갖고 있고 장기적인 유지 관리를 위해 기술 선택이 필요한 경우 아래를 계속 읽으십시오.

사전 컴파일

사전 컴파일에는 다음이 있어야 합니다.

컴파일 결과에는 더 이상 대상 환경에서 컴파일 프로세스가 필요하지 않습니다.
디버깅 가능성을 위해 결과를 컴파일합니다. 즉, 결과에는 순수 데이터 설명이 아닌 기본 ECMAScript 코드가 포함되어야 합니다.
React-JSX가 사전 컴파일을 지원한다는 것은 누구나 알고 있습니다. 공식 성명에 따르면 JSX가 없는 React는 항상 빌드된다는 의미입니다.

일부 문자열 처리 기반 엔진은 사전 컴파일도 지원합니다. 사전 컴파일이 필요한 경우 컴파일 결과가 여전히 문자열 연결을 기반으로 하는 엔진을 포기하는 것이 좋습니다. 이는 HTML5가 널리 지원되기 전에는 기술적인 방법이었습니다.

적어도 React-JSX 같은 컴파일 결과가 있어야 디버깅이 가능합니다. 참고: Vue.js는 동일한 효과를 얻기 위해 여러 템플릿 엔진을 지원합니다.

웹 구성 요소 기술을 사용하는 원본 ReactJS 코드:

class HelloMessage extends React.Component {
  render() {
    return <p>Hello <x-search>{this.props.name}</x-search>!</p>;
  }
}

컴파일 후:

class HelloMessage extends React.Component {
  render() {
    return React.createElement(
      "p",
      null,
      "Hello ",
      React.createElement(
        "x-search",
        null,
        this.props.name
      ),
      "!"
    );
  }
}

많은 VDOM 엔진도 htmltemplate-vdom과 같은 유사한 효과를 컴파일할 수 있습니다.

  <script>
        var id = 3;
        var env = {
            people: [
                {
                    id: &#39;id1&#39;,
                    name: &#39;John&#39;,
                    inner: [{ title: &#39;a1&#39; }, { title: &#39;b1&#39; }],
                    city: &#39;New York&#39;,
                    active: true
                },
                {
                    id: &#39;id2&#39;,
                    name: &#39;Mary&#39;,
                    inner: [{ title: &#39;a2&#39; }, { title: &#39;b2&#39; }],
                    city: &#39;Moscow&#39;
                }
            ],
            githubLink: &#39;https://github.com/agentcooper/htmltemplate-vdom&#39;,
            itemClick: function(id) {
                env.people.forEach(function(person) {
                    person.active = String(person.id) === String(id);
                });
                loop.update(env);
            }
            // Omitted ....
        };
    </script>

복잡성

두 엔진 중 어느 엔진이 덜 복잡한지 판단하기 위해 단일 기준을 사용하는 것은 어렵습니다. 이는 사용자의 사고 패턴이 다르기 때문입니다. 예를 들어, 위에 나열된 엔진의 사용 및 사전 컴파일된 결과의 차이는 사용자마다 다릅니다. 이는 서로 다른 엔진이 존재하는 합리성과 가치입니다.

일부 사용자는 문자열 템플릿이 이 애플리케이션 시나리오의 요구 사항을 충족할 수 있고 가볍고 충분하다고 생각합니다.
일부 사용자는 문자열 접합 기술의 템플릿 엔진이 충분히 강력하지 않고 충분히 현대적이지 않다고 생각합니다.
일부 사용자는 OOP가 충분히 합리적이고 논리적이며 추상적이라고 생각합니다.
일부 사용자는 기본 HTML을 프런트엔드라고 생각합니다.
일부 사용자는 VDOM의 적용 범위가 더 넓다고 생각합니다.

이러한 판단에는 각기 다른 초점과 기준이 있는 나름의 이유가 있습니다. 그러나 우리는 공통점을 통해 복잡성을 고려할 수 있습니다.

String 클래스 템플릿은 일반적으로 매우 가벼우며 이 섹션의 범위를 벗어납니다. 문자열이 아닌 템플릿의 복잡성을 판단하는 일반적인 기준은 무엇입니까? 데이터 바인딩의 복잡성을 고려할 수 있다고 생각합니다.

이 문서에서 언급된 데이터 바인딩은 단순한 보간이 아니라 컨텍스트와 이벤트, 심지어 전체 런타임의 호스트 환경까지 포함합니다.

실제로 VDOM이 실제 DOM 노드에 매핑될 수 있기 때문에 이 기능을 갖추려면 최소한 VDOM 수준에 도달하는 엔진이 필요합니다.

여러 가지 모드(조합)가 있을 수 있습니다.

1. 항목 매개변수는 객체이고 템플릿의 변수 x는 객체의 .x 속성입니다(예: virtual-stache-example
2). Vue.js의..., 계산된 속성 및 메소드
3와 같은 구문 또는 속성: Vue.js의 활성 단어는 다양한 시나리오에 적합하고 이해하기 쉽고 모호성을 생성하지 않습니다. 4. 바인딩에 대한 책임이 없습니다. 사용자는 네이티브 메서드에 매우 익숙해야 하며 다음과 같은 바인딩을 위한 네이티브 메서드를 사용해야 합니다. PowJS

이러한 모드는 이론적인 것일 뿐이며 일반적으로 템플릿 엔진 디자이너가 해결해야 하는 문제입니다. 사용자의 경우 직접 물어보는 것이 좋습니다.

1. 디버깅을 위해 가장 간단한 console.log(context)를 HTML 템플릿에 직접 작성할 수 있습니까?

2. 다양한 컨텍스트 매개변수를 다중 계층 DOM에 바인딩하거나 전달할 수 있습니까? 트리가 가능할까요?
3. 생성된 Node를 다층 DOM 트리에서 위쪽으로 접근할 수 있나요?

템플릿 엔진 팀에서 올바른 해결 방법을 제공하지만 일반적으로 리터럴 설명에 설명된 목표와 다릅니다. 문제의. 나는 이것이 당신의 선택 판단, 공무원이 제시한 올바른 방법에 대한 인식의 핵심이라고 생각합니다.

DOM에 포함

HTML에 포함

PowJS는 다음과 같이 구현됩니다.

템플릿을 구현하기 위해 구현해야 하는 지침

사전 컴파일되어 기본 ECMAScript 코드를 출력합니다.
템플릿 구문 구조는 ECMAScript 함수 작성과 일치합니다.
마지막으로 PowJS 템플릿 작성은 ECMAScript 함수 작성과 같습니다.

GoHub 인덱스에 쓰기

<template>
  <details>
    <summary>{{ctx.Description}}</summary>
    <p>
      </p>
<p>{{pkg.Import}}</p>
    
  </details>
  <dl>
    <details>
      <summary>{{rep.synopsis}}</summary>
    </details>
  </dl>
</template>

대부분의 템플릿 엔진은 if 및 각 명령을 구현합니다. 위의 PowJS 템플릿에는 다음도 포함됩니다.

전역 개체는 sel

template(함수) 이름이 repo, list
template(함수) 항목 매개 변수 데이터입니다.
맞춤형 지역 변수 ctx
하위 템플릿(함수) 형식 매개변수 파생 data.sha->sha
값을 하위 수준 템플릿 형식 매개변수 파생(ctx.Package,val-pkg)->pkg, ( data .content,val-rep)->rep
DOM 노드 연산 this.renew, this.appendTo, 렌더링 시 페이지 DOM 트리
Process 제어 break
pseudo 노드 if="':';"에 직접 렌더링 p 노드는 생성되지 않으며 블록 코드 기호 "{}"에 해당하는 유사 노드입니다.
핵심은 전체 템플릿 구조이며 명령 의미는 ECMAScript 함수와 정확히 동일합니다.

데이터 바인딩이 없습니다. ECMAScript 함수를 작성하고 매개변수를 전달합니다. 좋아요, 어떤 종류의 바인딩이 필요합니까? 이벤트 바인딩이 없으며, 각 노드는 실제입니다. 그냥 addEventListener를 직접 작성하면 됩니다. 디버깅하려면 do 또는 if를 찾으세요. 또는 _=console.log(x)를 삽입하고 삽입하세요. 좋습니다. 거의 모든 기본 명령문에 쉼표 표현식을 삽입할 수 있습니다.

모든 비즈니스 로직은 사용자가 직접 작성하며, PowJS는 이를 함수에 연결하는 역할만 담당합니다.
내보낸 view는 ECMAScript 소스 코드이고 아래 사진은 My Folders

웹 프런트엔드 템플릿 엔진을 선택하는 방법(권장) 시연에서 가져온 것입니다. 그렇다면 PowJS가 최종 선택일까요? PowJS의 개념은 네이티브, 네이티브 DOM 및 네이티브 ECMAScript입니다.

Native도 PowJS의 문제입니다. 모든 사용자가 네이티브를 좋아하는 것은 아닙니다. 일부 사용자는 더 추상적인 스타일을 선호한다고 생각합니다.

Native는 일치를 위해 다른 라이브러리를 확장하고 도입할 수 있다는 것을 의미하지만, PowJS에는 템플릿 엔진의 범위를 벗어나는 setter/getter 정의에 의해 구현된 감시자가 없는 경우 독립 프로젝트여야 합니다.

마지막으로 내 요점은 템플릿을 선택하는 데 있어 귀하의 요구 사항이 중요하며 귀하에게 가장 적합한 템플릿이 가장 좋다는 것입니다.

위 내용은 웹 프런트엔드 템플릿 엔진을 선택하는 방법(권장)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명：

이 기사는 segmentfault.com에서 복제됩니다. 침해가 있는 경우 admin@php.cn으로 문의하시기 바랍니다. 삭제

이전 기사：프런트 엔드에서 일반적으로 사용되는 JavaScript 작업(코드 예)다음 기사：프런트 엔드에서 일반적으로 사용되는 JavaScript 작업(코드 예)