I just discovered your channel the other day and each time ibwatch a video things i know about php (from experience since 2007) is just validated. The simple truth is that many non-php devs and beginner php devs have no clue how php works and especially how it all started. I appreciate you and your content
Templating engines make your code easy to maintain and reuse. Any performance benefits you might get by not using them will be minimal or insignificant and heavily outweighed by the benefits of using a template engine. For example, blade essentially has zero overhead with the templates being complied into plain php code and cached until you edit them again. Basically, it's your loss if you don't use them.
But what's the point? If you separete your view from your logic, you're going to include simple variables into the view anyway. Why would I use blade, if I can use use PHP template system like the guy in the video said? What's the adventage?
@@william254 In my opinion, if you render your view correctly; and in my opinion that means that the view only in fact has view logic in it; then blade and php-templates don't differ that much. Actually, in my applications the onlly difference would be
@@TheInimicus I think you're trying to argue that PHP templating is just as good as, e.g blade, and that by itself, should be a reason not to use blade. In my opinion, blade is better than php templating. Pretty much everything you mentioned that php templating can do, blade can do too, as well as adding some benefits on top. You can have logic-less views in blade, you can even write plain php if you don't want to use blade syntax. It offers you quite a bit of freedom. You argue that in promotes bad architecture with @if, but that's just the same with php templating. If someone adds @if on blade they just as likely to add *if* when templating with php. We can generally agree that blade is easier too, especially if you're just beginning. Blade is easier for both amateurs and experienced. The same can't be said about php templating. Cleaner code is just my opinion. I think loops and @if look better and are more readable, especially if there a designer in the team and they're are not familiar with php. The {{ $var }} is also easier to write. You make valid point about being able to switch a templating engine. But I also think that proper preparation should minimize the chance that you'll need. Besides, the need to change from php templating to a templating engine might occur too. If there were performance hits for using blade, then I'd seriously consider using php. But I don't think there are and even there are, they would likely be insignificant.
@@william254 I think you misunderstand me. I'm not saying "Don't ever use blade". Blade as a templating engine is fine. And I do agree, that it is slightly better than php-templating, it automatically escapes strings, has slightly cleaner syntax with {{, yes. If you compare just the CAPABILITIES of blade vs CAPABILITIES PHP, then blade is more capable than PHP, I agree. But! The cleaner your architecture becomes, the more blade and php-templating starts to look alike. In other words, the closer your application gets to having logicless-view, then more their source-codes will look alike. At the extreme, if you have view with 0 variables, 0 fors, 0 ifs, then blade and php-templating are the same file, exactly identical, wouldn't you agree? :) Plain HTML in both blade and PHP-template. (of course there's not many of such views, but I think you know what I mean - if the views are really simple, then blade and php source codes are very similar and their differences start to blend, you can't compare one against the other easily, if they're so similar). Of course, that's in well designed application. If your application has views for 3000 lines, of course blade will come on top, because it will stop you from doing stupid things, like accessing database in view; but that doesn't concern us, since we strive for well written application. So, the better your application, the adventages of blade start to disappear, as the application gets better and more mature. However, the cost of adding blade to your project (actually, any dependency for that matter) grows as the application develops. Ask any architect and they will tell you, adding libraries to your project is called "adding DEPENDENCIES" for a reason, if you add a dependency, your project starts to DEPEND on it. Examples of cost of dependencies: - if blade gets abandoned (won't be supported), we're screwed (that's what happened to faker library, for example). Yes, you can make a fork and maintain it yourself, but it's not easy and way more costly. - if there's a bug in blade, you can't fix it. Unless you fix it, and wait for the maintainer to include it, or you start maintaining it yourself - if there's a feature you use, that gets deprecated, you can't easily update blade, unless you update your code. - if there are two incompatible features in a library, and you want to use both of them at the same time, you're sqrewed. - if there are missing features in blade you need, you need to add custom logic to it - blade is actually pretty flexible, but other dependencies or other templating engines are not. - if you're customizing the engine, you can't really be sure if you don't break something - if there's a security error, but it gets fixed in the next version that's incompatbile with your current code base, you're screwed. - if blade and your application use a shared dependency (like maybe symphony polyfills) in different versions, you either try to get them to work; or downgrade blade (or try to upgrade, if it's compatible with your usage of it). if you can't downgrade or upgrade, you're sqrewed. - if blade uses an extension not supported by your PHP installation, you're sqrewed (maybe important on certain hostings) Please, keep in mind - that's not a list of reasons against blade, no! It's just a list of potential costs that might come with adding more dependencies. The list goes on, I just listed the most frequent one. The bigger your application gets, and the more dependencies you have, the more chance you'll come into one of them. So, to me, adding dependencies is a huge risk! Huge! And the adventages of blade that you listed just aren't worth it for me, only to have {{ instead of
What does your view look like? How does 'product' get into it, when the template is in an seperate file? You can not do this without some extra code in the view, right?
Template Engines are simply another abstraction layer. When using a proper IDE and plugins you can speed up development time using template engines very well. I dont take your advice, as it's like saying do not write OOP PHP, you can do everything in functions. That is as well another abstraction layer to separate code. Therefor a template engine does as well clean up your code and makes everything more readable. Sidenote: I dont use template engines.
Depends. Will the user be allowed to use logic operation like if else and transformations? If its complex and can assure no hacking you can prob opt for a template engine. But if its just html i would just use str replace vars.
@@zledwon There's always tail edge cases. Like would you use angular if the client offered 100 Bitcoins. Going deeper into the issue. 1) would they need complex logic 2) would they know what variables to use, how the variable is structured 3) would they need more functionality with the power of PHP later on. At the end of the day, I might again recommend doing PHP files.
I'm looking for a super simple way to make simple php web apps using the basics ...html,css,PHP, JavaScript without over complicating things..I come from the old school days of building websites with a text editor...any suggestions?
I would suggest just learning the yii2 framework. It will cost you a week but you don't want to learn an something under powered and then have to re-learn something else and you want to do it in a scalable long term way.
@@lionelthetechlead8839 I'll take a look.. also interested in Vue.. there are so many options these days for languages, frameworks etc it is quite overwhelming... I still find php to be my favorite
@@CoconutPete for a simple page, I would not recommend js, because of the async way that JS works makes things more complicated, you have to know what call backs and real time works like
@@lionelthetechlead8839 so Yii2 doesn't use templating engine?. I've not used Yii2 so I don't know myself. And if not what does your view template looks like
I have never used a templating engine. PHP is a templating language and for presentation of dynamic data, it does it too well. I know there are reasons for using templating engines but PHP works fine. My codebase is properly structured with the MVC approach to use the minimum required PHP for presentation of the front-end view data.
That's correct. Rasmus himself actually setup PHP as a templating language. But was confused when people started their own templating language on top of a templating language.
Hmm. I think template engines can be good, because it restricts developers from putting backend logic into frontend which keeps your project more clean. Yes you can do some if statements and loop stuff in template engines, but it doesn't go any further than that.
Have you seen the logic with template engines. They've got for loops with conditional statements and event transformations. Don't forget you can still screw up your project with javascript.
@@airaction6423 yeah lets use PDO statements within my templates because i do not like restrctions. lets call every class a helper class and put it everywhere inside the template. With every template engine you can actually choose. per default everything is disabled and you add those features which are really required in your template. those features which are needed for your template
Display logic is not the same as putting app logic into the template. I would agree a template engine encourages to keep the separation as if you see plain php you can think again in where you put it.
I had the same oppinion 10 years ago, but since then i have changed my mind. Mainly because of: 1. Requests to webserver should never go past CDN after first request to same url, so there are no overhead in having separate template libraries. This can very easily also be pre-cached. 2. One can argue it breaks SOLID design patterns to mix response and request logic or presentation layer and business logic. 3. Its easier for a human brain to see small pieces of code and allows to focus on the real job. 4. Why reinvent the wheel? There always comes a set of functions related to only php templates that very likley will be quick-hacks that can be avoided by using a template language that is properly maintained. Examples are to override either your own or others views in third party applications. 5. Its easier for code quality control tools to analyze the code if its split up so html can be analyzed separatley and php separatley. Also IDE support, especially with autocompletion is often much more easy to configure when using plain php.
just my 2c. 2) This is already handled by the PHP framework that does MVC. 3) Already handled by the framework. most view files in PHP are almost 80% html 4) These are not quick hack but might be extensive widgets. If not there's still javascript. 5) PHP has been around for 20 years so it's really well support. Again 90% of a view file is HTML.
@@lionelthetechlead8839 You used 80% then 90% for the same statistic. One thing you forget is that these templating libraries can save you from XSS and simplifies things greatly. Before you go "but X framework solves that" I want to mention that not everyone uses one such framework, some might have their own minimal frameworks as well due to performance reasons, Symfony and Laravel aren't exactly speed demons with how much they do internally, so that simply means you've completely missed the point. Another reason to use something like Twig is that you don't have to go in and out of PHP context, you do not need to worry about some idiot using echo for HTML, you can limit the scope of what's possible, reducing the amount of possible footguns, etc. As for whether it's necessary to use something different, not really. But as a tech lead, you should also know that your responsibility is to ensure the developer team has a good toolset with as robust guardrails as possible in order to not break things. If you let someone do stupid shit, they will do stupid shit. If you haven't seen someone establish a database connection and fetch data in-between some HTML, then you clearly have lived a far too sheltered life, which is the only reason I could see you have these opinions.
Hi, i do agree. After many tries with heavy template engines, i've finally decided to code mine using only pure PHP. The engine runs in just one class and has no other syntax to learn. It's called PhpEcho. Give it a try and tell me. Anyway thanks for the explanation
Thank you for you Video, i want to add just 2 ct from my side. Yes Template engines are overloaded especiall twig or blade because you can even call classes within the template engine. But there are logicless template engines like Mustache/Handlebar.js which can be extended with logic but you have to it by yourself. But i would not say that you should stop using template engine for several reasons 1) it is not true that you have just to replace {{ with
All you need to do is use a framework like Yii and it'll handle all the validation hard work. I think the only area where you maybe should use a template engine is where the user is designing the templates.
@@lionelthetechlead8839 this is not true, even Yii recommend on their Docs that you should use a template engine. Without a template engine there is a chance that a variable will not be escaped or code which does not belong into a template engine will land there. the reason where you might go well without a template engine is if you work alone without a team and you have years of experience and know what XSS is and you know what is View Logic and what is Controller Logic.
@@VitalijMik actually thats not entirely correct. Yii 1 did recommend a template engine because it was developed in the earlier versions of PHP. In yii2 PHP is the default template engine but it does allow the easy use of templating engines. Rasmus himself said he was surprised since PHP was already a templating language so he worked on other parts till 7 where the focus was on the embeded features that allow you to work PHP neatly into the html. Also the development of mvc frameworks did a good job separating out logic and view so less skills developers can work on certain parts.
@@lionelthetechlead8839 AS i told. You can skip the template engine if you know what you do. But i would never recommend this to a junior Developer, he will forget to call the escape method or he will call Controller within Template because he can
@@lionelthetechlead8839 it's not about something being correct. it's about who pays for what. if you as product owner have a system running with twig you get yourself people working with twig. the end. didn't say I disagree with you but in reality you often face old environments. that's just the nature of it.
@@japetsaberon5061 Ok I spent about 5 minutes looking thru. Here's a few points. It is heavily dependent on Laravel, that's a bad thing if you want to work on hybrid or just without a laravel. 2. The syntex is a little older. Vue is already using @click which is a lot cleaner. To me this looks a lot like meteor which is neither great at front or back. The last thing is the community is small and laravel vue is more mainstream.
man, learn what u want, alpine js substitutes vuesjs easily and is more clean, which is a good combination with livewire, bc livewire works with ajax at the server side, dont let just a random opinion decide what ur going to learn@@japetsaberon5061
i cant give a thumb to this video. biggets reason is that, most frameworks use template engines to better the code and make developer less writing as not to mix too much backend to the front part. if u tell us not to use it ! thus awkward. it may some jeolus or anyelse but twig and blade are my fave.
A better title for this video would be "Why I do not use PHP Template Engines". Although I technically agree that you can do the job with PHP itself, I am using for example Twig to take away the hassle of programming all the bits and pieces in PHP, where I can keep the HTML kind of layout in tact with Twig and exchange some literals with variables and add a loop here and there. This is a very simplistic presentation of how to use Twig, but I think you get the point. On the complexity and what you do with Twig is part of the design. If you put a lot of logic in Twig than I think you are doing something wrong. A bit like, if you need a lot of jQuery to put your HTML straight, you are also doing something wrong. Although I have the skills to put all the templating in PHP itself, I can't imagine see me doing it. So I keep on using Twig (or Blade or Smarty whenever a customer requires this).
I see this issue at work (ecommerce) where we have a bunch of values being evaluated all over the place in the template just to see if the product can be purchased. The information the template should have regarding that is a single value, isBuyable, or is_buyable if you're a heretic. This will greatly simplify the template, because logic is now extremely minimal in the template. You could even take it a step further and send the templates regarding whether you can purchase the product (or render a different template) to reflect the parts of the product page which will be affected. Logic in templates is a design flaw and a massive skill issue, not a templating issue.
i think your statement is a little broader than you present. Your argument suggests not to use views in the back end. not just template engines, not just php. i could agree with that statement, it's what i prefer anyways but how about emails. I still find it very useful to utilize blade for email templates and i sure as hell cannot use vue js on client side in that case. I don't like using php as a template engine because it's a lot less readable and either i'll need to cache my views anyway or i have so much time that the bulkiness won't bother me.
@@lionelthetechlead8839 So Yii2 employs a template engine approach to generating its output, which is exactly what your video title says not to do? You've just pushed the thing you discourage further down the tech stack, you're still using a templating engine, but one wrapped in a more capable framework. I think you've caught yourself coming and going in your own argument, if stated more clearly I could appreciate your point. I think you're trying to say that we shouldn't write our own PHP code that directly employs a basic templating engine like Twig etc when generating HTML for serving to the browser. That's a good point. It avoids cases where one has a good reason to use these templating systems to generate content in other situations, which can be quite diverse especially in a system that happens not to be running in your preferred Yii2 framework, there are lots of legacy PHP applications out there in that scenario. Two simple examples that jump to mind are email content generation (as said by others here) and 3rd party sales platform content generation such as eBay, Amazon etc, that your PHP code base may be generating. There are some absolutely weird statements you make in this video also, such as "no longer needed to separate PHP and code". Maybe script your videos next time, your points will hopefully come over better. And please, the clickbait titles, they burn.
Yes. It looks somewhat like vue js adding more power into the html tags itself. I like vue.js as a front-end engine to do more of the work as you get the full power of js.
@@TheInimicus Twig in combination with symfony automatically escapes variables. But yeah, if a templating engine requires you to manually escape stuff, then don't use it.
No offense but the title kinda likes an order not suggestion. It would be great if its like a suggestion so people have their own point of view. IMO, you can't expect people will do anything you told them to, BUT if its a suggestion, they will save it for later preferences.
I'm a web developer and use PHP daily, template engines weren't designed for us. I include twig in most of my sites so that the designer and users can customize their sites without having to learn PHP.
Actually they still have to {% %} symbols which just doesn't make sense for the designers to do the markups. I actually give them a 20 min video on how to make out tags because sooner or later they will have to do some logic on the frontend.
what with Laravel @section @endofsection directives?Doesnt it simplify my html?Doesn't it make my html page less or make my section peace t9 be used everywhere trough all htmls and multiple times. I thing this side of Blade is most powefull. You dont have a need to scroll those endless htmls. But yes would it be php embedding or blade's it looks dirty on page. You can commit all logic in function and then pass variables to the page. It does the same as blade.
unnecessary bulk, unnecessary complications. and when template engines allow logic, it defeats the whole solution of the problem it's trying to solve in the first place.
@@lionelthetechlead8839 Say you have a comment form that is protected with a CSRF token. The anti-CSRF mechanism prevents an attacker from submitting comments on behalf of another user who is currently logged in on your site. However, when you render the comment page in your PHP script, you still have to HTML-encode it like so . Otherwise, an attacker could submit malicious content like alert('pwned'); which would get executed in the browsers of anyone who views the comments page. The problem with PHP as a templating language is that it does not HTML-encode your variables by default. You have to manually call htmlentities each and every time. If you forget to do this only once, you might sell out the user's of your website and possible even the whole web application.
This makes hell a lot of sense. If you want to use templating engines for the sake of "Separation of Concerns", then why not just define the variables and require a php template file.
I don't agree with what you say. A template engine set limit functionalities to front developer. If you let the front developer use PHP, he can do things that he shouldn't be able to do.
Too shallow view on templating engines and some plain wrong views. For very small projects: Yes you may not need a separate template engine, for everything else its a good advice. Performance with them is not a problem. And saying: You dont need a templating Engine since you can do stuff in JS ist just very weird ... Sorry, but thats not a good video at all. A few years ago i was questioning the use of templating engines myself, until i saw all the wonderfull benefits, especially in bigger projects and while working with teammates. Its about maintaining code, separation of elements, security and strongly not having business logic in templates. But there is much more to like on template engines. Yes php started as a sort of templating engine with some extra bits on it, but its now grown up into someting else - which is good! But its cool that you can still use it as a templating engine. That does not mean you allways should. If you using Laravel or some other Framework: Your Project is definitely big enough to use a real templating engine!
Agree. I can't imagine my huge Laravel projects without blade. This guy is a dumb fake tech lead. In case OP wants to prove himself... bring us real life examples, and show us why we don't need template engines!
Came here thinking: is he insane? got out: yeah makes sense for a lot of API first applications. But old systems, and the good old fashion client/server all in PHP, template engines are still a good option, perhaps not for the future, but it has it's uses.
its easy to say dont use them, as you are not going to develope or write my codes, , why dont you come with examples and tutorials in phps own templating engine
So, let's review: 1. "PHP is a templating engine". First, no it's not! So, your solution is to have echos everywhere and I guess you will also need some loops, from time-to-time, so basically you create your own template engine - that needs to take care of sanitization, has a lot of copy-paste (no-plugins), mixed logic and you get cataract when you read it. Cool! 2. "Templating engines are too bulky". You don't have to marry them, just use what you need. There is no speed issue, most of the template engines will convert into regular PHP code. Having business logic inside front-end is up to you, has nothing to do with tools. 3. "Better ways to do it". If you want to create a SPA you don't need a templating engine, of course. However, you will use one inside the JavaScript framework, just changed the technology. How many dislikes do you have? :)
I am a developer for almost 40 years and I think there always room for improvement. I can't imagine that those 23 years has put you to a standstill in adopting new things to improve your habits. 23 years ago internet was a "modem" event, including that cracking noise, now you are talking hi-speed internet. Tools have become so much better and development so much quicker. So tell me, how does 23 years relate to you agreeing on this subject, where I state that my almost 40 years are totally irrelevant to adopt new things like I started yesterday (sort of speak)?
@@johannesvandemerwe oh you are absolutely right, from the day i made my first functional code and this day, many things changed. I am constantly learning better ways and to improve my skills, in fact i NEVER made a website that was similar to the previous in terms of technology, i always tried to do it better and better. My view on the subject, that templating engines are overkill and that you should use native php to do things, but do it in a clean way, STILL STANDS! In fact, i am not just talking words, my entire work is based on custom code that is far more maintainable and clean than using templates, and is orders of magnitude smaller and hundreds of times faster than horrible things such as wordpress (yeah i know this is not a talk about wordpress, but its the best example of how horrible wrong this direction can get). I have websites running from 2005, based on custom code, that are still valid and functional with minimal updates due to php version changes. Templating systems are only good in team work where you get the designer that has no clue about coding, but can do minimal html, then you can let him/her do the job..yes thats true and still stands, but for solitary projects doing templates just means you are incapable of writing clean and minimalist code. I respect your 40yrs of experience, i can not imagine where that puts you as a start, considering that when i started internet was just starting to move.. and i am sure that from your point of view you consider learning new templating engines is the needed thing to do, but look at the big picture, over time, none of the old templating systems remained standing, they are all more or less niche, and each web app eventually makes its own variation. However, native (vanilla) php will always remain strong, and if you can code cleanly and organized directly like this, you do not need anything else. As a benchmark, i make webs that have millions of visitors, and every 10ms speed improvement is crucial, because it gets multiplied by millions, so in the end, its only raw php that can win, speed-wise ..think of that. Of course that if you do it wrong, its not important what engine you use, ..writing fast code and keep it easy maintainable is a philosophy of life.
What do you mean with "you don't see any PHP appearing in the Frontend"? What's you definition of "Frontend"? PHP is and was never in a Frontend software. I guess you should move to a modern software development approach.
nonsense. Apart the fact that the template engine has functions and logic tuned to frontend specifically which speeds up the frontend work the app logic should be decoupled from the frontend as much as possible. Using PHP as a template language naturally encourages programmer to do the app logic in the template. Look on Wordpress native template system.. it is a mess. That is what you stand for.
wordpress was developed almost 20 years ago. Not many things you own are 20 years old and still going strong. So that's not a good example to use. I've got a new video where I came across a clients twig template that is as messy and complicated as I've seen and then people can look at it and make their own decision.
@@lionelthetechlead8839 Twig/Timber is awesome and way more sustainable and mature system/language for templating work than the bare PHP. The fact that people might screw things up even with good tools is yet another story. Symphony has Twig for a good reason, Laravel Blade for the same reason and the list goes on. The native messy Wordpress templating system is beginners friendly as beginners are messy by nature. That was one of the reasons (not the only one) what made Wordpress an ideal choice for so many tinkers not necessarily programmers.
Nonsense statements from incompetent person. Template engines are created for reason and specific use case. Try to not use template engine in projects with thousands of files and you will create video with "Please Use PHP Template Engines".
Наука
Backend rendering is still the best solution for rendering content based website especially for SEO.
That's a good point.
This does have nothing to do with PHP template engines
@@airaction6423 google bots fails to read the javascript codes.
I couldn’t stop looking at your books on the shelf, about to fall right any moment
Irrelevant but hilarious 🤣
I love twig its so easy to learn and saves many hours of labor.
I just discovered your channel the other day and each time ibwatch a video things i know about php (from experience since 2007) is just validated. The simple truth is that many non-php devs and beginner php devs have no clue how php works and especially how it all started. I appreciate you and your content
Thanks! I just hate it when they hate on something they don't know. Welcome on board team PHP.
Templating engines make your code easy to maintain and reuse. Any performance benefits you might get by not using them will be minimal or insignificant and heavily outweighed by the benefits of using a template engine.
For example, blade essentially has zero overhead with the templates being complied into plain php code and cached until you edit them again. Basically, it's your loss if you don't use them.
But what's the point? If you separete your view from your logic, you're going to include simple variables into the view anyway. Why would I use blade, if I can use use PHP template system like the guy in the video said? What's the adventage?
@@TheInimicus Blade is much easier to use, has cleaner code, automatically escapes, and is much easier reuse. Let me ask, why don't you use blade?
@@william254 In my opinion, if you render your view correctly; and in my opinion that means that the view only in fact has view logic in it; then blade and php-templates don't differ that much. Actually, in my applications the onlly difference would be
@@TheInimicus I think you're trying to argue that PHP templating is just as good as, e.g blade, and that by itself, should be a reason not to use blade.
In my opinion, blade is better than php templating. Pretty much everything you mentioned that php templating can do, blade can do too, as well as adding some benefits on top.
You can have logic-less views in blade, you can even write plain php if you don't want to use blade syntax. It offers you quite a bit of freedom.
You argue that in promotes bad architecture with @if, but that's just the same with php templating. If someone adds @if on blade they just as likely to add *if* when templating with php.
We can generally agree that blade is easier too, especially if you're just beginning. Blade is easier for both amateurs and experienced. The same can't be said about php templating.
Cleaner code is just my opinion. I think loops and @if look better and are more readable, especially if there a designer in the team and they're are not familiar with php. The {{ $var }} is also easier to write.
You make valid point about being able to switch a templating engine. But I also think that proper preparation should minimize the chance that you'll need. Besides, the need to change from php templating to a templating engine might occur too.
If there were performance hits for using blade, then I'd seriously consider using php. But I don't think there are and even there are, they would likely be insignificant.
@@william254 I think you misunderstand me.
I'm not saying "Don't ever use blade". Blade as a templating engine is fine. And I do agree, that it is slightly better than php-templating, it automatically escapes strings, has slightly cleaner syntax with {{, yes. If you compare just the CAPABILITIES of blade vs CAPABILITIES PHP, then blade is more capable than PHP, I agree.
But!
The cleaner your architecture becomes, the more blade and php-templating starts to look alike. In other words, the closer your application gets to having logicless-view, then more their source-codes will look alike. At the extreme, if you have view with 0 variables, 0 fors, 0 ifs, then blade and php-templating are the same file, exactly identical, wouldn't you agree? :) Plain HTML in both blade and PHP-template. (of course there's not many of such views, but I think you know what I mean - if the views are really simple, then blade and php source codes are very similar and their differences start to blend, you can't compare one against the other easily, if they're so similar). Of course, that's in well designed application. If your application has views for 3000 lines, of course blade will come on top, because it will stop you from doing stupid things, like accessing database in view; but that doesn't concern us, since we strive for well written application.
So, the better your application, the adventages of blade start to disappear, as the application gets better and more mature.
However, the cost of adding blade to your project (actually, any dependency for that matter) grows as the application develops. Ask any architect and they will tell you, adding libraries to your project is called "adding DEPENDENCIES" for a reason, if you add a dependency, your project starts to DEPEND on it.
Examples of cost of dependencies:
- if blade gets abandoned (won't be supported), we're screwed (that's what happened to faker library, for example). Yes, you can make a fork and maintain it yourself, but it's not easy and way more costly.
- if there's a bug in blade, you can't fix it. Unless you fix it, and wait for the maintainer to include it, or you start maintaining it yourself
- if there's a feature you use, that gets deprecated, you can't easily update blade, unless you update your code.
- if there are two incompatible features in a library, and you want to use both of them at the same time, you're sqrewed.
- if there are missing features in blade you need, you need to add custom logic to it - blade is actually pretty flexible, but other dependencies or other templating engines are not.
- if you're customizing the engine, you can't really be sure if you don't break something
- if there's a security error, but it gets fixed in the next version that's incompatbile with your current code base, you're screwed.
- if blade and your application use a shared dependency (like maybe symphony polyfills) in different versions, you either try to get them to work; or downgrade blade (or try to upgrade, if it's compatible with your usage of it). if you can't downgrade or upgrade, you're sqrewed.
- if blade uses an extension not supported by your PHP installation, you're sqrewed (maybe important on certain hostings)
Please, keep in mind - that's not a list of reasons against blade, no! It's just a list of potential costs that might come with adding more dependencies. The list goes on, I just listed the most frequent one. The bigger your application gets, and the more dependencies you have, the more chance you'll come into one of them. So, to me, adding dependencies is a huge risk! Huge! And the adventages of blade that you listed just aren't worth it for me, only to have {{ instead of
What does your view look like? How does 'product' get into it, when the template is in an seperate file? You can not do this without some extra code in the view, right?
the MVC handles it for me. It's a bunch of variables in the view.
Do you thing it is good idea to go deep into JavaScript, Typescript React/Vue and NodeJS path in 2021?
Check the job market where you live , where I live, they are asking for angular, .net, django, php, node, typescript, aws, MySQL.
You're going to need JS regardless of the backend. I like Vue.js
Template Engines are simply another abstraction layer.
When using a proper IDE and plugins you can speed up development time using template engines very well.
I dont take your advice, as it's like saying do not write OOP PHP, you can do everything in functions. That is as well another abstraction layer to separate code. Therefor a template engine does as well clean up your code and makes everything more readable.
Sidenote: I dont use template engines.
Why learn another abstraction layer when the first one is sufficient? That's like programming with python and php.
@@lionelthetechlead8839 because the learning curve is very small compared to the advantages they give...
How about a case when I need to allow CMS user to use templating engine in text editor. You think that allowing PHP code in text is a good idea?
Depends. Will the user be allowed to use logic operation like if else and transformations? If its complex and can assure no hacking you can prob opt for a template engine. But if its just html i would just use str replace vars.
@@lionelthetechlead8839 So there is a scenario where you recommend using temp engines afterall :) Thus vid title is a bit missleading.
@@zledwon There's always tail edge cases. Like would you use angular if the client offered 100 Bitcoins. Going deeper into the issue. 1) would they need complex logic 2) would they know what variables to use, how the variable is structured 3) would they need more functionality with the power of PHP later on. At the end of the day, I might again recommend doing PHP files.
wordpress
That's really a different story and requires a separet topic.
I'm looking for a super simple way to make simple php web apps using the basics ...html,css,PHP, JavaScript without over complicating things..I come from the old school days of building websites with a text editor...any suggestions?
I would suggest just learning the yii2 framework. It will cost you a week but you don't want to learn an something under powered and then have to re-learn something else and you want to do it in a scalable long term way.
@@lionelthetechlead8839 I'll take a look.. also interested in Vue.. there are so many options these days for languages, frameworks etc it is quite overwhelming... I still find php to be my favorite
@@CoconutPete for a simple page, I would not recommend js, because of the async way that JS works makes things more complicated, you have to know what call backs and real time works like
Which framework to use then to organise the code and build applications on the MVC pattern?
Yii2 of course!
@@lionelthetechlead8839 so Yii2 doesn't use templating engine?. I've not used Yii2 so I don't know myself. And if not what does your view template looks like
I have never used a templating engine. PHP is a templating language and for presentation of dynamic data, it does it too well. I know there are reasons for using templating engines but PHP works fine.
My codebase is properly structured with the MVC approach to use the minimum required PHP for presentation of the front-end view data.
That's correct. Rasmus himself actually setup PHP as a templating language. But was confused when people started their own templating language on top of a templating language.
Hmm. I think template engines can be good, because it restricts developers from putting backend logic into frontend which keeps your project more clean. Yes you can do some if statements and loop stuff in template engines, but it doesn't go any further than that.
Have you seen the logic with template engines. They've got for loops with conditional statements and event transformations. Don't forget you can still screw up your project with javascript.
Do you like restrictions? I like when I'm able to choose
@@airaction6423 yeah lets use PDO statements within my templates because i do not like restrctions. lets call every class a helper class and put it everywhere inside the template.
With every template engine you can actually choose. per default everything is disabled and you add those features which are really required in your template. those features which are needed for your template
@@lionelthetechlead8839 yes but it gets rendered before it gets parsed in the request right? the user never gets any of the logic on his machine.
Display logic is not the same as putting app logic into the template. I would agree a template engine encourages to keep the separation as if you see plain php you can think again in where you put it.
Do you have a video giving an example of what the correct way would be?
check out my code like a pro video
I had the same oppinion 10 years ago, but since then i have changed my mind. Mainly because of:
1. Requests to webserver should never go past CDN after first request to same url, so there are no overhead in having separate template libraries. This can very easily also be pre-cached.
2. One can argue it breaks SOLID design patterns to mix response and request logic or presentation layer and business logic.
3. Its easier for a human brain to see small pieces of code and allows to focus on the real job.
4. Why reinvent the wheel? There always comes a set of functions related to only php templates that very likley will be quick-hacks that can be avoided by using a template language that is properly maintained. Examples are to override either your own or others views in third party applications.
5. Its easier for code quality control tools to analyze the code if its split up so html can be analyzed separatley and php separatley. Also IDE support, especially with autocompletion is often much more easy to configure when using plain php.
just my 2c. 2) This is already handled by the PHP framework that does MVC. 3) Already handled by the framework. most view files in PHP are almost 80% html 4) These are not quick hack but might be extensive widgets. If not there's still javascript. 5) PHP has been around for 20 years so it's really well support. Again 90% of a view file is HTML.
Why reinvent the wheel? The inventor of the squared wheel used to chant this mantra to everyone...just think where we would be if people had listened!
@@lionelthetechlead8839 You used 80% then 90% for the same statistic.
One thing you forget is that these templating libraries can save you from XSS and simplifies things greatly.
Before you go "but X framework solves that" I want to mention that not everyone uses one such framework, some might have their own minimal frameworks as well due to performance reasons, Symfony and Laravel aren't exactly speed demons with how much they do internally, so that simply means you've completely missed the point.
Another reason to use something like Twig is that you don't have to go in and out of PHP context, you do not need to worry about some idiot using echo for HTML, you can limit the scope of what's possible, reducing the amount of possible footguns, etc.
As for whether it's necessary to use something different, not really. But as a tech lead, you should also know that your responsibility is to ensure the developer team has a good toolset with as robust guardrails as possible in order to not break things.
If you let someone do stupid shit, they will do stupid shit. If you haven't seen someone establish a database connection and fetch data in-between some HTML, then you clearly have lived a far too sheltered life, which is the only reason I could see you have these opinions.
Hi, i do agree. After many tries with heavy template engines, i've finally decided to code mine using only pure PHP. The engine runs in just one class and has no other syntax to learn. It's called PhpEcho. Give it a try and tell me. Anyway thanks for the explanation
Link
Link 🖇️
you got the link?
@@lionelthetechlead8839 no
Thank you for you Video, i want to add just 2 ct from my side. Yes Template engines are overloaded especiall twig or blade because you can even call classes within the template engine. But there are logicless template engines like Mustache/Handlebar.js which can be extended with logic but you have to it by yourself.
But i would not say that you should stop using template engine for several reasons
1) it is not true that you have just to replace {{ with
All you need to do is use a framework like Yii and it'll handle all the validation hard work. I think the only area where you maybe should use a template engine is where the user is designing the templates.
@@lionelthetechlead8839 this is not true, even Yii recommend on their Docs that you should use a template engine. Without a template engine there is a chance that a variable will not be escaped or code which does not belong into a template engine will land there.
the reason where you might go well without a template engine is if you work alone without a team and you have years of experience and know what XSS is and you know what is View Logic and what is Controller Logic.
@@VitalijMik actually thats not entirely correct. Yii 1 did recommend a template engine because it was developed in the earlier versions of PHP. In yii2 PHP is the default template engine but it does allow the easy use of templating engines. Rasmus himself said he was surprised since PHP was already a templating language so he worked on other parts till 7 where the focus was on the embeded features that allow you to work PHP neatly into the html. Also the development of mvc frameworks did a good job separating out logic and view so less skills developers can work on certain parts.
@@lionelthetechlead8839 AS i told. You can skip the template engine if you know what you do. But i would never recommend this to a junior Developer, he will forget to call the escape method or he will call Controller within Template because he can
I cloud not find render function can you give example
yeah well thing is there is lots of projects oyu eventually have to work on using twig. should I refer to your video every time? XD
Of course. Just because something is widespread doesn't make it correct.
@@lionelthetechlead8839 it's not about something being correct. it's about who pays for what. if you as product owner have a system running with twig you get yourself people working with twig. the end. didn't say I disagree with you but in reality you often face old environments. that's just the nature of it.
What are you inputs about livewire?
Never heard of it. Then again, almost 10 frameworks a month appear all the time.
@@lionelthetechlead8839 livewire is like vue but in php I don't know if it is only works with laravel
@@japetsaberon5061 Ok I spent about 5 minutes looking thru. Here's a few points. It is heavily dependent on Laravel, that's a bad thing if you want to work on hybrid or just without a laravel. 2. The syntex is a little older. Vue is already using @click which is a lot cleaner. To me this looks a lot like meteor which is neither great at front or back. The last thing is the community is small and laravel vue is more mainstream.
@@lionelthetechlead8839 thank you sir for the info. Im looking forward to learn more in php
man, learn what u want, alpine js substitutes vuesjs easily and is more clean, which is a good combination with livewire, bc livewire works with ajax at the server side, dont let just a random opinion decide what ur going to learn@@japetsaberon5061
Thank u, I was actually searching for blade template tutorial but i stumbled on this first.
Blade is so PHP 5. Some of the comments is of using a template engine is like Using a bicycle because you are afraid of speeding in your car.
Thanks a lot for the explication.
You got a point. I worked with someone in one laravel application and blade can be damned. Most of the time we use js framework for frontends.
Exactly. You have to at least have some js so why bother learning a third sudo language called the template engine.
Hi , what is php e2 ?
i cant give a thumb to this video. biggets reason is that, most frameworks use template engines to better the code and make developer less writing as not to mix too much backend to the front part. if u tell us not to use it ! thus awkward. it may some jeolus or anyelse but twig and blade are my fave.
A better title for this video would be "Why I do not use PHP Template Engines". Although I technically agree that you can do the job with PHP itself, I am using for example Twig to take away the hassle of programming all the bits and pieces in PHP, where I can keep the HTML kind of layout in tact with Twig and exchange some literals with variables and add a loop here and there.
This is a very simplistic presentation of how to use Twig, but I think you get the point. On the complexity and what you do with Twig is part of the design. If you put a lot of logic in Twig than I think you are doing something wrong. A bit like, if you need a lot of jQuery to put your HTML straight, you are also doing something wrong.
Although I have the skills to put all the templating in PHP itself, I can't imagine see me doing it. So I keep on using Twig (or Blade or Smarty whenever a customer requires this).
I see this issue at work (ecommerce) where we have a bunch of values being evaluated all over the place in the template just to see if the product can be purchased. The information the template should have regarding that is a single value, isBuyable, or is_buyable if you're a heretic. This will greatly simplify the template, because logic is now extremely minimal in the template. You could even take it a step further and send the templates regarding whether you can purchase the product (or render a different template) to reflect the parts of the product page which will be affected.
Logic in templates is a design flaw and a massive skill issue, not a templating issue.
i think your statement is a little broader than you present. Your argument suggests not to use views in the back end. not just template engines, not just php. i could agree with that statement, it's what i prefer anyways but how about emails. I still find it very useful to utilize blade for email templates and i sure as hell cannot use vue js on client side in that case. I don't like using php as a template engine because it's a lot less readable and either i'll need to cache my views anyway or i have so much time that the bulkiness won't bother me.
I use the yii2 email template and all it has is if you keep it just to var replacements.
@@lionelthetechlead8839 So Yii2 employs a template engine approach to generating its output, which is exactly what your video title says not to do? You've just pushed the thing you discourage further down the tech stack, you're still using a templating engine, but one wrapped in a more capable framework. I think you've caught yourself coming and going in your own argument, if stated more clearly I could appreciate your point. I think you're trying to say that we shouldn't write our own PHP code that directly employs a basic templating engine like Twig etc when generating HTML for serving to the browser. That's a good point. It avoids cases where one has a good reason to use these templating systems to generate content in other situations, which can be quite diverse especially in a system that happens not to be running in your preferred Yii2 framework, there are lots of legacy PHP applications out there in that scenario. Two simple examples that jump to mind are email content generation (as said by others here) and 3rd party sales platform content generation such as eBay, Amazon etc, that your PHP code base may be generating. There are some absolutely weird statements you make in this video also, such as "no longer needed to separate PHP and code". Maybe script your videos next time, your points will hopefully come over better. And please, the clickbait titles, they burn.
Have you heard about the miracle of htmx?
Yes. It looks somewhat like vue js adding more power into the html tags itself. I like vue.js as a front-end engine to do more of the work as you get the full power of js.
"Just use
Twig and smarty doesn't escape anything by default. Only blade do it.
@@TheInimicus Twig in combination with symfony automatically escapes variables. But yeah, if a templating engine requires you to manually escape stuff, then don't use it.
When I Find a way to do @yield / @section with pure PHP I won't use blade anymore
hum... very interesting challenge. Send me an example and I'll think of a video to replace them.
No offense but the title kinda likes an order not suggestion. It would be great if its like a suggestion so people have their own point of view. IMO, you can't expect people will do anything you told them to, BUT if its a suggestion, they will save it for later preferences.
Bottomline, its what it is: because the tech lead said so!
I'm a web developer and use PHP daily, template engines weren't designed for us. I include twig in most of my sites so that the designer and users can customize their sites without having to learn PHP.
Actually they still have to {% %} symbols which just doesn't make sense for the designers to do the markups. I actually give them a 20 min video on how to make out tags because sooner or later they will have to do some logic on the frontend.
what with Laravel @section @endofsection directives?Doesnt it simplify my html?Doesn't it make my html page less or make my section peace t9 be used everywhere trough all htmls and multiple times. I thing this side of Blade is most powefull. You dont have a need to scroll those endless htmls. But yes would it be php embedding or blade's it looks dirty on page. You can commit all logic in function and then pass variables to the page. It does the same as blade.
You can do that with render partials in a framework
@@lionelthetechlead8839 i ve made little google exploring. Say in Laravel you cannot do that w/o ajax.. And i found it expensive for the server
I totally agree. PHP gives you much more options than any template engine. Excellent point Lionel. Keep up the good work!
That's correct. You get all the power of the backend language and you do not have to learn a second 'quasi' language.
@@lionelthetechlead8839 Hi. Make a PHP 8 review.
@@ojsojs6004 actually looking at it now!
You do not point out any actual downside to template engines, do you?
unnecessary bulk, unnecessary complications. and when template engines allow logic, it defeats the whole solution of the problem it's trying to solve in the first place.
couldn't have said it better myself!
I doubt that many (template) designers are aware of the potential XSS issues.
How do you ensure that no one creates XSS vulnerabilities?
Just use a php framework. LIke yii2 has built int CSFR on the form posts that protect it from XSS. Also try to use post more than get.
@@lionelthetechlead8839 Anti-CSRF measures do not prevent XSS.
@@hbgl8889 give me an example.
@@lionelthetechlead8839 Say you have a comment form that is protected with a CSRF token. The anti-CSRF mechanism prevents an attacker from submitting comments on behalf of another user who is currently logged in on your site. However, when you render the comment page in your PHP script, you still have to HTML-encode it like so . Otherwise, an attacker could submit malicious content like alert('pwned'); which would get executed in the browsers of anyone who views the comments page.
The problem with PHP as a templating language is that it does not HTML-encode your variables by default. You have to manually call htmlentities each and every time. If you forget to do this only once, you might sell out the user's of your website and possible even the whole web application.
tell this to Laravel , they use everything at once
This makes hell a lot of sense. If you want to use templating engines for the sake of "Separation of Concerns", then why not just define the variables and require a php template file.
In fact the frameworks already do this
SSR is still king.
I don't agree with what you say. A template engine set limit functionalities to front developer.
If you let the front developer use PHP, he can do things that he shouldn't be able to do.
like setup a form that sends your data to a third party api? redirect the page to a porn site?
@@lionelthetechlead8839 no. Others things. Use PHP functions that can put the system at risk.
bro, you're flipped!
Too shallow view on templating engines and some plain wrong views. For very small projects: Yes you may not need a separate template engine, for everything else its a good advice. Performance with them is not a problem. And saying: You dont need a templating Engine since you can do stuff in JS ist just very weird ... Sorry, but thats not a good video at all.
A few years ago i was questioning the use of templating engines myself, until i saw all the wonderfull benefits, especially in bigger projects and while working with teammates. Its about maintaining code, separation of elements, security and strongly not having business logic in templates. But there is much more to like on template engines.
Yes php started as a sort of templating engine with some extra bits on it, but its now grown up into someting else - which is good! But its cool that you can still use it as a templating engine. That does not mean you allways should. If you using Laravel or some other Framework: Your Project is definitely big enough to use a real templating engine!
Agree. I can't imagine my huge Laravel projects without blade. This guy is a dumb fake tech lead. In case OP wants to prove himself... bring us real life examples, and show us why we don't need template engines!
Use anything that works for you. Periodt.
You couldn’t be more right! Thanks for pointing this out.
You bet!
Rasmus said: 'don't use frameworks. Because it is heavy and reaches the same result when you use the programming directly'
He also doesn't believe in collar shirts. I think he just didn't want to start a civil war
Came here thinking: is he insane? got out: yeah makes sense for a lot of API first applications.
But old systems, and the good old fashion client/server all in PHP, template engines are still a good option, perhaps not for the future, but it has it's uses.
Going by the developments, Template engines are slowly going out of style compared to just backend or the frontend with js frameworks.
its easy to say dont use them, as you are not going to develope or write my codes, , why dont you come with examples and tutorials in phps own templating engine
Check this example how I cut the code ruclips.net/video/tHcijydtSJw/видео.html
So, let's review:
1. "PHP is a templating engine". First, no it's not! So, your solution is to have echos everywhere and I guess you will also need some loops, from time-to-time, so basically you create your own template engine - that needs to take care of sanitization, has a lot of copy-paste (no-plugins), mixed logic and you get cataract when you read it. Cool!
2. "Templating engines are too bulky". You don't have to marry them, just use what you need. There is no speed issue, most of the template engines will convert into regular PHP code. Having business logic inside front-end is up to you, has nothing to do with tools.
3. "Better ways to do it". If you want to create a SPA you don't need a templating engine, of course. However, you will use one inside the JavaScript framework, just changed the technology.
How many dislikes do you have? :)
Getting better!
@@lionelthetechlead8839 I don’t agree with this video but I like that you keep PHP alive, best of luck!
My OCD is in overdrive because your shirt is inside out.....
Thumb up just by reading the video title.
Always remember, one can never wake a person who pretends to be asleep.
True!
i am a developer for 23 years, and i totally agreeeeee with you man, you so right
I am a developer for almost 40 years and I think there always room for improvement. I can't imagine that those 23 years has put you to a standstill in adopting new things to improve
your habits. 23 years ago internet was a "modem" event, including that cracking noise, now you are talking hi-speed internet. Tools have become so much better and development
so much quicker. So tell me, how does 23 years relate to you agreeing on this subject, where I state that my almost 40 years are totally irrelevant to adopt new things like I started yesterday (sort of speak)?
@@johannesvandemerwe oh you are absolutely right, from the day i made my first functional code and this day, many things changed. I am constantly learning better ways and to improve my skills, in fact i NEVER made a website that was similar to the previous in terms of technology, i always tried to do it better and better. My view on the subject, that templating engines are overkill and that you should use native php to do things, but do it in a clean way, STILL STANDS! In fact, i am not just talking words, my entire work is based on custom code that is far more maintainable and clean than using templates, and is orders of magnitude smaller and hundreds of times faster than horrible things such as wordpress (yeah i know this is not a talk about wordpress, but its the best example of how horrible wrong this direction can get). I have websites running from 2005, based on custom code, that are still valid and functional with minimal updates due to php version changes.
Templating systems are only good in team work where you get the designer that has no clue about coding, but can do minimal html, then you can let him/her do the job..yes thats true and still stands, but for solitary projects doing templates just means you are incapable of writing clean and minimalist code.
I respect your 40yrs of experience, i can not imagine where that puts you as a start, considering that when i started internet was just starting to move.. and i am sure that from your point of view you consider learning new templating engines is the needed thing to do, but look at the big picture, over time, none of the old templating systems remained standing, they are all more or less niche, and each web app eventually makes its own variation. However, native (vanilla) php will always remain strong, and if you can code cleanly and organized directly like this, you do not need anything else.
As a benchmark, i make webs that have millions of visitors, and every 10ms speed improvement is crucial, because it gets multiplied by millions, so in the end, its only raw php that can win, speed-wise ..think of that. Of course that if you do it wrong, its not important what engine you use, ..writing fast code and keep it easy maintainable is a philosophy of life.
what is the use of DESIGN PATTERN lol HAHAHAHAHA
What do you mean with "you don't see any PHP appearing in the Frontend"? What's you definition of "Frontend"? PHP is and was never in a Frontend software.
I guess you should move to a modern software development approach.
Frontend is used for presentation. If I echo html that's frontend php.
Nice video
nonsense. Apart the fact that the template engine has functions and logic tuned to frontend specifically which speeds up the frontend work the app logic should be decoupled from the frontend as much as possible. Using PHP as a template language naturally encourages programmer to do the app logic in the template. Look on Wordpress native template system.. it is a mess. That is what you stand for.
wordpress was developed almost 20 years ago. Not many things you own are 20 years old and still going strong. So that's not a good example to use. I've got a new video where I came across a clients twig template that is as messy and complicated as I've seen and then people can look at it and make their own decision.
@@lionelthetechlead8839 Twig/Timber is awesome and way more sustainable and mature system/language for templating work than the bare PHP. The fact that people might screw things up even with good tools is yet another story. Symphony has Twig for a good reason, Laravel Blade for the same reason and the list goes on.
The native messy Wordpress templating system is beginners friendly as beginners are messy by nature. That was one of the reasons (not the only one) what made Wordpress an ideal choice for so many tinkers not necessarily programmers.
Nonsense statements from incompetent person.
Template engines are created for reason and specific use case. Try to not use template engine in projects with thousands of files and you will create video with "Please Use PHP Template Engines".
Do it everyday!
I agree 100%. Still betting on Vanilla PHP.