การสร้างเทมเพลตฝั่งเซิร์ฟเวอร์ Jinja2 Handlebars

เทมเพลตฝั่งเซิร์ฟเวอร์จะสร้าง HTML บนเซิร์ฟเวอร์ก่อนส่งไปยังเบราว์เซอร์ ทำให้ได้มาร์กอัปที่เป็นมิตรต่อ SEO ตั้งแต่ไบต์แรก ทำงานได้โดยไม่ใช้ JavaScript และหลีกเลี่ยงปัญหา "หน้าว่างจนกว่า JS จะโหลด" ของการแสดงผลฝั่งไคลเอนต์ล้วน

Jinja2 คือไลบรารีเทมเพลต Python ที่ได้รับความนิยมเป็นมาตรฐานโดยพฤตินัย — ใช้โดย Flask, Django (ผ่านแบ็กเอนด์ที่มีให้หรือ jinja2), Pelican และ mkdocs ตรรกะอยู่ในแท็ก {% %} ส่วนนิพจน์อยู่ใน {{ }}: <h1>{{ title }}</h1> ใช้สำหรับตัวแปร และ {% for item in items %} ใช้สำหรับการวนซ้ำ

Handlebars คือไลบรารีเทมเพลต Node.js ที่มีผู้ใช้มากที่สุด นิยมใช้กับอีเมลธุรกรรม (SendGrid, Mailgun) และ SSR ผ่าน Express นิพจน์อยู่ใน {{ }} ส่วนบล็อกใช้ {{# }}: {{#each items}}<li>{{name}}</li>{{/each}}

เอนจินทั้งสองจะหลีกอักขระผลลัพธ์ของตัวแปรโดยอัตโนมัติเป็นค่าเริ่มต้น — {{ user.name }} เมื่อ name = "<script>" จะให้ผลลัพธ์เป็น "&lt;script&gt;" ซึ่งช่วยทำให้ XSS ไม่สามารถทำงานได้ โปรดอาศัยการหลีกอักขระอัตโนมัติเสมอ ใช้ตัวกรองดิบโดยระบุอย่างชัดเจน (Jinja: {{ x|safe }}, Handlebars: {{{x}}}) เฉพาะกับ HTML ที่เชื่อถือได้เท่านั้น

Jinja: {% extends "base.html" %} ในเทมเพลตลูก และ {% block content %}{% endblock %} ในเทมเพลตฐาน Handlebars: {{#> layout }}{{/layout}} พร้อมบล็อกส่วนย่อย ช่วยให้เลย์เอาต์ฐานกำหนดโครงสร้างไว้เพียงครั้งเดียว แล้วแต่ละหน้าจึงเติมส่วนที่เปลี่ยนแปลงได้

Jinja: {% include "header.html" %} Handlebars: {{> header}} ทั้งสองแบบจะแทรกเทมเพลตอีกชุดลงในเทมเพลตปัจจุบัน ส่วนย่อยเป็นองค์ประกอบพื้นฐานสำหรับคลังส่วนประกอบขนาดใหญ่ โดยนำมาประกอบกันเป็นหน้าและเลย์เอาต์

ฟิลเตอร์ของ Jinja: {{ price|currency }} ตัวช่วยของ Handlebars: {{currency price}} ทั้งสองแบบช่วยให้คุณเรียกใช้ฟังก์ชันจัดรูปแบบกับค่าได้ คุณสามารถกำหนดฟังก์ชันของตนเองสำหรับการแปลงข้อมูลเฉพาะโครงการ เช่น การจัดรูปแบบวันที่ การทำให้เป็นพหูพจน์ และการสร้างลิงก์

Jinja: {% if user.is_logged_in %}Welcome{% else %}Sign in{% endif %} Handlebars: {{#if user.isLoggedIn}}Welcome{{else}}Sign in{{/if}} แยกเส้นทางของเทมเพลตตามข้อมูลได้โดยไม่ต้องพึ่ง JS ฝั่งไคลเอ็นต์เพื่อซ่อนหรือแสดงเนื้อหา

เอนจินทั้งสองจะแปลเทมเพลตล่วงหน้าเป็นฟังก์ชัน แล้วเรียกใช้ฟังก์ชันเหล่านั้นในแต่ละคำขอ การแปลเกิดขึ้นเพียงครั้งเดียว ส่วนการเรนเดอร์ทำได้อย่างรวดเร็ว สำหรับเว็บไซต์ที่มีปริมาณการเข้าชมสูงมาก ให้แคชผลลัพธ์ที่เรนเดอร์แล้วไว้ที่เอดจ์ (Varnish, Cloudflare) แทนการเรนเดอร์หน้าที่เหมือนเดิมซ้ำ

ใช้เทมเพลตร่วมกับไลบรารีสำหรับการรองรับหลายภาษา: Jinja2 + Babel สำหรับ Python และ Handlebars + i18next สำหรับ Node เทมเพลตจะเก็บคีย์การแปล ({{ t "welcome" }}) จากนั้นชั้นการรองรับหลายภาษาจะค้นหาข้อความในภาษาที่ถูกต้อง ทำให้เทมเพลตเดียวแสดงผลได้หลายภาษา

เฟรมเวิร์กสมัยใหม่นำรูปแบบเทมเพลตของตนเองมาให้ เช่น ERB (Rails), Twig (Symfony), Blade (Laravel), Razor (.NET) และ Slim/Haml (ซึ่งกระชับกว่า) แนวคิดเหมือนกัน แต่ไวยากรณ์แตกต่างกัน โปรดเลือกเอนจินที่เข้ากับภาษาฝั่งเซิร์ฟเวอร์และระบบนิเวศของคุณ

เทมเพลตเหมาะอย่างยิ่งกับเว็บไซต์แบบดั้งเดิมที่เรนเดอร์บนเซิร์ฟเวอร์ สำหรับแอปที่มีการโต้ตอบมากขึ้น เฟรมเวิร์กอย่าง Next.js (React), Nuxt (Vue) และ SvelteKit ทำให้เส้นแบ่งไม่ชัดเจน เพราะสามารถเรนเดอร์เทมเพลตบนเซิร์ฟเวอร์ได้ ขณะเดียวกันคอมโพเนนต์เดิมก็เริ่มทำงานบนไคลเอ็นต์เพื่อรองรับการโต้ตอบ

เหตุใดการหลีกอักขระอัตโนมัติจึงเป็นพฤติกรรมเริ่มต้นของเอนจินเทมเพลตอย่าง Jinja2 และ Handlebars

เอนจินเทมเพลตฝั่งเซิร์ฟเวอร์ (Jinja2 สำหรับ Python, Handlebars สำหรับ JS และ ERB/Twig/Blade สำหรับชุดเทคโนโลยีอื่น) จะสร้าง HTML บนเซิร์ฟเวอร์โดยใช้ตัวแปร ลูป เงื่อนไข ส่วนย่อย และการสืบทอด การหลีกอักขระอัตโนมัติช่วยป้องกัน XSS เป็นค่าเริ่มต้น ควรใช้ร่วมกับไลบรารีสำหรับการรองรับหลายภาษาเมื่อสร้างเว็บไซต์หลายภาษา เทมเพลตเป็นรากฐาน ส่วนเฟรมเวิร์กสมัยใหม่จะเพิ่มการทำงานบนไคลเอ็นต์หลังการเรนเดอร์