[Vebut]

Jag skulle säga att man bör skippa en template-motor, blir sjukt mycket overhead jämfört med PHP som faktiskt i sig är ett template-språk. Varför ska man flytta script'ningen till ytterligare ett lager?

Skulle jag välja någon motor skulle den vara xml eller html baserad så man tar del av DOM, vilket PHP har stöd för i standardutförande.

Många gillar twig och liknande som gör samma jobb som PHP om du bygger funktioner för det. Tänk på att parsing är dyrt.

[Clarence]

Ursprungligen postat av Vebut

Jag skulle säga att man bör skippa en template-motor, blir sjukt mycket overhead jämfört med PHP som faktiskt i sig är ett template-språk. Varför ska man flytta script'ningen till ytterligare ett lager?

Skulle jag välja någon motor skulle den vara xml eller html baserad så man tar del av DOM, vilket PHP har stöd för i standardutförande.

Många gillar twig och liknande som gör samma jobb som PHP om du bygger funktioner för det. Tänk på att parsing är dyrt.

Ett par anledningar för att man enligt mig verkligen inte bör använda PHP som ett template-språk:

- Det är verbose ... <?php htmlspecialchars($object->attribute, ENT_QUOTES, 'UTF-8') ?> vs {{ object.attribute }} (Visst du kan ersätta <?php echo med <?= och förlora kompatibilitet eller så kan du skriva ett kortare funktions-namn utan parametrar ...)
- Det är inte säkert by default. Du har ingen output escaping om du inte själv lägger på den. Glöm den på fel ställe och du är sårbar för XSS. (Precis samma situation som att använda manuell sql escaping). Vanligaste sårbarheterna i större websiter beror på enkla misstag för att man antog det omöjliga - att man alltid gör rätt och aldrig är slarvig.
- Återigen säkerheten. Du har ingen sandboxing i PHP och att låta användare som inte har 100% koll ändra i templates är därmed mycket farligare.
- Dåliga programmerare tenderar att flytta logik till templates eftersom det "funkar lika bra där". Även bättre programmerare har en tendens att först "testa" i templaten och slarv leder lätt till att det blir kvar där. Separation of concerns är ytterst viktigt vid större projekt.
- Frontend-programmerare och designers måste lära sig PHP. Ett template-språk är mer begränsat och framförallt template-orienterat. Du får per default en logik som passar ett presentationslager och därmed är mer lätttillgängligt för de som jobbar med presentation.
- Arv är både krångligt och blir ofta ostabilt om man inte lägger mycket tid på det. Kräver fortfarande egen parsing för att fungera på ett enkelt och logiskt sätt om man tänker på att man är i ett presentationslager. Template-arv är för mig ett måste för allt annat än en väldigt enkel sajt.

Bygger du en lite mer komplicerad sajt med fokus på prestanda är det tvärtom svårt och mycket kod för att vara effektiv. Släng dit lite ESI-controllers, template-arv och asynkron content så har du en slö PHP-röra eller så har du spenderat alldeles för många timmar på att bygga det som redan finns.

Att "parsning" tar resurser för att man använder en template-motor är också ett ytterst tveksamt påstående. Alla vettiga template-system cachar en "kompilerad" PHP-version som sedan bytecode cachas som all övrig kod. Fokuserar man på prestanda bör man ha trafik för det vilket betyder att kompileringen sker på ytterst liten del av requesten oavsett om man bryr sig om att förkompilera dom (vilket man bör göra). Det som sedan är kvar av overheaden är mestadels säkerhetsaspekten och eventuell data-kompatibilitet (t ex variable.field för både attribut och array-access eller automatisk output escaping).

[linusoleander]

Ursprungligen postat av Clarence

Ett par anledningar för att man enligt mig verkligen inte bör använda PHP som ett template-språk:

- Det är verbose ... <?php htmlspecialchars($object->attribute, ENT_QUOTES, 'UTF-8') ?> vs {{ object.attribute }} (Visst du kan ersätta <?php echo med <?= och förlora kompatibilitet eller så kan du skriva ett kortare funktions-namn utan parametrar ...)
- Det är inte säkert by default. Du har ingen output escaping om du inte själv lägger på den. Glöm den på fel ställe och du är sårbar för XSS. (Precis samma situation som att använda manuell sql escaping). Vanligaste sårbarheterna i större websiter beror på enkla misstag för att man antog det omöjliga - att man alltid gör rätt och aldrig är slarvig.
- Återigen säkerheten. Du har ingen sandboxing i PHP och att låta användare som inte har 100% koll ändra i templates är därmed mycket farligare.
- Dåliga programmerare tenderar att flytta logik till templates eftersom det "funkar lika bra där". Även bättre programmerare har en tendens att först "testa" i templaten och slarv leder lätt till att det blir kvar där. Separation of concerns är ytterst viktigt vid större projekt.
- Frontend-programmerare och designers måste lära sig PHP. Ett template-språk är mer begränsat och framförallt template-orienterat. Du får per default en logik som passar ett presentationslager och därmed är mer lätttillgängligt för de som jobbar med presentation.
- Arv är både krångligt och blir ofta ostabilt om man inte lägger mycket tid på det. Kräver fortfarande egen parsing för att fungera på ett enkelt och logiskt sätt om man tänker på att man är i ett presentationslager. Template-arv är för mig ett måste för allt annat än en väldigt enkel sajt.

Bygger du en lite mer komplicerad sajt med fokus på prestanda är det tvärtom svårt och mycket kod för att vara effektiv. Släng dit lite ESI-controllers, template-arv och asynkron content så har du en slö PHP-röra eller så har du spenderat alldeles för många timmar på att bygga det som redan finns.

Att "parsning" tar resurser för att man använder en template-motor är också ett ytterst tveksamt påstående. Alla vettiga template-system cachar en "kompilerad" PHP-version som sedan bytecode cachas som all övrig kod. Fokuserar man på prestanda bör man ha trafik för det vilket betyder att kompileringen sker på ytterst liten del av requesten oavsett om man bryr sig om att förkompilera dom (vilket man bör göra). Det som sedan är kvar av overheaden är mestadels säkerhetsaspekten och eventuell data-kompatibilitet (t ex variable.field för både attribut och array-access eller automatisk output escaping).

Mycket bra sammanfattning! Ska blir intressant och se vad Vebut och Kimppa kontrar med.

[Conny Westh]

Ursprungligen postat av Vebut

Jag skulle säga att man bör skippa en template-motor, blir sjukt mycket overhead jämfört med PHP som faktiskt i sig är ett template-språk. Varför ska man flytta script'ningen till ytterligare ett lager?

Skulle jag välja någon motor skulle den vara xml eller html baserad så man tar del av DOM, vilket PHP har stöd för i standardutförande.

Många gillar twig och liknande som gör samma jobb som PHP om du bygger funktioner för det. Tänk på att parsing är dyrt.

Det finns givetvis sunkiga framework, men generellt är det bra att "återanvända" redan skriven och testad kod. Det kan göras på flera olika sätt.

Ett är att använda ett Framework, ett annat är att använda färdiga komponenter som man kan köpa för en billigare peng än att utveckla eget helt från grunden. Det finns alltid en tröskel både för ett Framework och komponenter, samma principer är giltiga oavsett programspråk.

Men jag har en pragmatisk inställning till detta. Man måste göra en bedömning från fall till fall vad som är optimalt mellan att använda:

- Inköpta Framework
- Inköpta komponenter
- Egenutvecklade Framework
- Egenutvecklade Komponenter
- Helt egenutvecklad kod
- Helt outsourcad kod

I verkliga projekt brukar man behöva kunna kombinera dessa delar i olika proportioner, alldeles oavsett vilket programspråk, eller plattform man jobbar med.

[linusoleander]

Ursprungligen postat av ConnyWesth

Det finns givetvis sunkiga framework, men generellt är det bra att "återanvända" redan skriven och testad kod. Det kan göras på flera olika sätt.

Ett är att använda ett Framework, ett annat är att använda färdiga komponenter som man kan köpa för en billigare peng än att utveckla eget helt från grunden. Det finns alltid en tröskel både för ett Framework och komponenter, samma principer är giltiga oavsett programspråk.

Men jag har en pragmatisk inställning till detta. Man måste göra en bedömning från fall till fall vad som är optimalt mellan att använda:

- Inköpta Framework
- Inköpta komponenter
- Egenutvecklade Framework
- Egenutvecklade Komponenter
- Helt egenutvecklad kod
- Helt outsourcad kod

I verkliga projekt brukar man behöva kunna kombinera dessa delar i olika proportioner, alldeles oavsett vilket programspråk, eller plattform man jobbar med.

Vart tog punkten "OSS-ramverk/bibliotek"?

[Conny Westh]

Ursprungligen postat av linusoleander

Vart tog punkten "OSS-ramverk/bibliotek"?

De sorterar under Inköpta dito, men jag skulle kanske ha valt begrepet 3:e parts i stället för det var det jag menade, dvs sånt man inte gjort själv.