[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.

[Jimmit]

Jag använder Blade mest eftersom det är inbyggt i Laravel. Dock frångått det nästan helt på senare tid till fördel för Angular.

[Johnny Viking]

Föredrar oxå templates för att på något sätt komma bort från just att köra ren PHP i view-filer. Det känns lite bakvänt. Då är det bättre med en template-motor, som visserligen kör ett ett språk, men det separerar just övrig kod från view-koden.

Körde förr ren PHP i view-filer, men ack vad rörigt det blir till slut och man fuskar lätt genom att fortsätta köra PHP i view-filer. Nu så i 90% (ärligt) av fallen så sätts alla värden före dom ska finnas tillgängliga i view-filen.

PHP som Clarence säger är knappast ett template-språk, men det kan göras som en motor till ett template-språk, twig, blade, smarty mfl...

[Kimppa]

Hej,

Kan hålla med om en del saker Clarence skriver men det mesta låter tyvärr som slarv.

Hur PHP-kod ser ut (lång/kort) spelar ingen roll för mig så länge allt är tydligt och fint strukturerat.

När det gäller escape queries och säkerhet så är det de första man implementerar om man arbetar med ett projekt som läser/skriver från en databas. Om man har en anställd, eller om man själv gör en "test-koppling" för att "fixa den senare" så har man inte planerat speciellt bra.

Jag har inte heller något problem med större webbplatser då det finns PHP dokumentation och möjligheten att programmera i objekt-stil vilket gör att jag kan återanvända min kod, hur enkelt som helst. Programmerar ungefär som Java när jag programmerar PHP, men med egna klasser (då jag vill ha total kontroll över all kod).

Front-end utvecklare hade jag inte anställt om de inte kan något annat förutom HTML/CSS/JavaScript. Jag förväntar mig att någon som är intresserad av webbutveckling, även har baskunskaperna inom HTML/CSS/PHP/JavaScript (gärna kunskaper inom Photoshop eller liknande program också).

Men det mesta går att göra med PHP. Det viktigaste är att planera.

Har du en massa fel och säkerhetsrisker på din webbplats så är det dålig planering.

Men jag förstår varför Clarence advocerar för "template motor".

Alla har sitt eget sätt att göra saker på och jag klagar inte. Antingen lyckas ni bättre än mig, eller så blir det tvärtom. Jag anser i alla fall att man bör ha bra kunskaper inom de flesta områden om man jobbar med webbutveckling. Det går självklart att outsourca allt, men du tappar man kontrollen över sitt egna projekt.

Men jag byggde min första hemsida när jag var 9-10 år. Det var i Dreamweaver (som jag aldrig använt igen efter första hemsidan, då den lägger till onödig kod). Så jag kanske har haft ett kontrollbehov av att göra allt "mitt eget" från barndomen. Vem vet. Det fungerar iaf för mig.

[Clarence]

Ursprungligen postat av Kimppa

Hej,

Kan hålla med om en del saker Clarence skriver men det mesta låter tyvärr som slarv.

Hur PHP-kod ser ut (lång/kort) spelar ingen roll för mig så länge allt är tydligt och fint strukturerat.

När det gäller escape queries och säkerhet så är det de första man implementerar om man arbetar med ett projekt som läser/skriver från en databas. Om man har en anställd, eller om man själv gör en "test-koppling" för att "fixa den senare" så har man inte planerat speciellt bra.

Jag har inte heller något problem med större webbplatser då det finns PHP dokumentation och möjligheten att programmera i objekt-stil vilket gör att jag kan återanvända min kod, hur enkelt som helst. Programmerar ungefär som Java när jag programmerar PHP, men med egna klasser (då jag vill ha total kontroll över all kod).

Front-end utvecklare hade jag inte anställt om de inte kan något annat förutom HTML/CSS/JavaScript. Jag förväntar mig att någon som är intresserad av webbutveckling, även har baskunskaperna inom HTML/CSS/PHP/JavaScript (gärna kunskaper inom Photoshop eller liknande program också).

Men det mesta går att göra med PHP. Det viktigaste är att planera.

Har du en massa fel och säkerhetsrisker på din webbplats så är det dålig planering.

Men jag förstår varför Clarence advocerar för "template motor".

Alla har sitt eget sätt att göra saker på och jag klagar inte. Antingen lyckas ni bättre än mig, eller så blir det tvärtom. Jag anser i alla fall att man bör ha bra kunskaper inom de flesta områden om man jobbar med webbutveckling. Det går självklart att outsourca allt, men du tappar man kontrollen över sitt egna projekt.

Men jag byggde min första hemsida när jag var 9-10 år. Det var i Dreamweaver (som jag aldrig använt igen efter första hemsidan, då den lägger till onödig kod). Så jag kanske har haft ett kontrollbehov av att göra allt "mitt eget" från barndomen. Vem vet. Det fungerar iaf för mig.

Ett par kommentarer;

Slarv finns alltid. Alla slarvar. Programmerare är människor.

Angående säkerheten hade jag två punkter. Ingen gällde "queries". Det var istället data som du skriver ut som kan komma från olika håll. Enda vettiga stället att formatera data för output är där du skriver ut den. Har du inget lager framför din output är den en säkerhetsrisk. Om man kan få security by default är det mycket mycket värt. XSS-sårbarheter är extremt! vanligt just för att man i de flesta system måste säkra detta manuellt.

Kontexten för frontendare blir fortfarande inte rätt oavsett om du väljer att anställa någon som kan PHP istället för den som är bäst på det den faktiskt ska/borde jobba med. Template-orienterad kod underlättar och snabbar på flödet och förbättrar resultatet.

Jag förstår mycket väl din vilja att göra allt själv. Jag har också haft det och har det fortfarande till viss grad. Men denna argumentation handlar väl egentligen inte om det. Det handlar väl mer om huruvida en template-motor har tillräckligt med fördelar över php-templates för att använda en ... oavsett om du sedan väljer att skriva den själv.

[Nihilnovi]

Twig + Symfony 2 + FOSRestBundle all the way när det gäller all typ av templating och utveckling.

Att sitta med rå php 2014 känns väldigt 2004... Jag känner också igen mig i Clarence tidslinje, det var en tid där man förespråkade "ren" php och tyckte ramverk och template motorer var onödigt och överflödigt.

När man sen får lite mer erfarenhet och tar steget att lära sig ett fully stacked ramverk så undrar man bara hur mycket tid man kunde ha sparat, hur mycket mer pengar man kunde ha tjänat och hur mycket huvudvärk man kunde ha sluppit om man bara tagit det steget tidigare.

Tiden som man satt med ren PHP ser jag på som sin novisträning, lite som om du börjar på en av världens bästa sushiställens så får du klämma svinheta handdukar åt gästerna i 3 år innan de låter dig röra fisken(Jiro sushi ^^).