Nem túl erős a felhozatal, sablonozó rendszernek nem nevezném őket, főleg nem natívnak. Az első csak egy szimpla láthatatlan elem, a template stringek sebességét mértem, de nagyjából ugyanannyi, mint ragasztgatással.
Pedig mindkettő be van építve a böngészők jelentős részébe, és kellőn kifinomult API-t kínálnak.A sebességgel pedig foglalkozzanak az implementálók, idővel javulni fog, főleg ha az emberek elkezdik használni.
Előbb akkor célszerű lenne definiálni, miről is beszélünk.
A sablonozás (számomra legalábbis) azt jelenti, hogy egy adattömbből szabályok/parancsok segítségével HTML-t gyártunk. Ezek a parancsok többek között:
adatok behelyettesítése
iteráció
feltételes feldolgozás
include-olás (sablonok beolvasása külső fájlból)
változók kezelése sablonon belül
A sablonozás egyik fontos funkciója, hogy elkülönítse a feladatokat, a frontendet a backend-től, a megjelenítést az üzleti logikától. Így elkerülhető, hogy egy HTML huszár véletlenül rossz helyre nyúljon, valamint a sablonokat tartalmazó könyvtár teljesen külön vehető a szerveren futó kódtól.
A sablonozásnak tehát menedzsment, kódszervezési és biztonsági szerepe van. Emellett a frontenden elválasztható a HTML előállítása/manipulációja az események kezelésétől (onclick, onchange és társaik).
Ha a fentieket veszem alapul, a <template> elem és a template karakterláncok nem tűnnek komoly próbálkozásnak. Sőt, a React-ben is keveredik a szezon a fazonnal, azaz tíz-tizenöt évet visszaléptünk az időben, pont tegnap találtam erről egy cikket, ahol ezt szépen illusztrálják.
Nem igazán. Ismertem, és amikor a fenti hozzászólást írtam, átnéztem megint, mit tud, és elég korlátozottak a lehetőségei. Előnye, hogy támogatva van kliens- és szerveroldalon is, cserébe jó lassú, nodejs-sel játszottam vele egy-két éve meg php-val.
Egyébként nem rossz, de egy feltételes feldolgozást igazán beletehettek volna.
Köszönöm, jól van, épp azt tesztelgetem, hogy sebességben hogyan viszonyul a manapság népszerű keretrendszerekhez. Egyedül a React versenyképes, bár az trükkös, mert az első kirajzolás jóval lassabb, utána felgyorsul, gondolom, a virtuális DOM miatt; a második hívástól nagyjából ugyanazt a szintet hozza mindkettő, nagy elemszám esetén (1600 elemű, dinamikusan generált űrlap).
Dehogynem, csak óriási munka. Van már pár kisebb projektem, ami működik, de szeretnék még pár tipikus példát mellétenni, hogy látható legyen, mi mindenre lehet használni.
Látszólag
<template> és template
Nem túl erős a felhozatal,
Natív
Sablonozás
A sablonozás (számomra legalábbis) azt jelenti, hogy egy adattömbből szabályok/parancsok segítségével HTML-t gyártunk. Ezek a parancsok többek között:
- adatok behelyettesítése
- iteráció
- feltételes feldolgozás
- include-olás (sablonok beolvasása külső fájlból)
- változók kezelése sablonon belül
A sablonozás egyik fontos funkciója, hogy elkülönítse a feladatokat, a frontendet a backend-től, a megjelenítést az üzleti logikától. Így elkerülhető, hogy egy HTML huszár véletlenül rossz helyre nyúljon, valamint a sablonokat tartalmazó könyvtár teljesen külön vehető a szerveren futó kódtól.A sablonozásnak tehát menedzsment, kódszervezési és biztonsági szerepe van. Emellett a frontenden elválasztható a HTML előállítása/manipulációja az események kezelésétől (onclick, onchange és társaik).
Ha a fentieket veszem alapul, a
<template>
elem és a template karakterláncok nem tűnnek komoly próbálkozásnak. Sőt, a React-ben is keveredik a szezon a fazonnal, azaz tíz-tizenöt évet visszaléptünk az időben, pont tegnap találtam erről egy cikket, ahol ezt szépen illusztrálják.Mustache
Nem
Egyébként nem rossz, de egy feltételes feldolgozást igazán beletehettek volna.
Lefordítva volt lassú?
Nem emlékszem, de nem hiszem,
Minden kérésnél
A Mustache nagy kedvencem, és
Mi a helyzet az XSLT-s
Köszönöm, jól van, épp azt
Nem osztod meg valamikor?
De