search

laravel / ideas

Issues board used for Laravel internals discussions.
939 stars 28 forks source link

[Question] Why not embrace a modern template engine? #1179

Open norman784 opened 6 years ago

norman784 commented 6 years ago

I just come to php since a few years of working with other languages (node, ruby) and most of the frameworks of those lang uses (what I call) modern template engines, I always hated twig because it doesn't add anything that I cannot do in plain php, just complexity and a learning curve.

Whats my point? Well html is hard to read, I'm used to it but is hard, because you need to seek the start and the end of each tag, etc, and with template engines like pug, haml, etc you don't, just indent and its very easy to follow it, also I think the point of a template engine is to accelerate the development and I find to write html with some "sugar" is not really useful, why I need to use {{ $someVar }}, isn't just easy to use plain php/html in this case? (i.e. <?=$someVar?>) Really I don't see the difference between using or not this kind of template engine.

Just to give an example:

<!doctype html>
<html>
<head>
    @include('includes.head')
</head>
<body>
<div class="container">

    <header class="row">
        @include('includes.header')
    </header>

    <div id="main" class="row">

        <!-- sidebar content -->
        <div id="sidebar" class="col-md-4">
            @include('includes.sidebar')
        </div>

        <!-- main content -->
        <div id="content" class="col-md-8">
            @yield('content')
        </div>

    </div>

    <footer class="row">
        @include('includes.footer')
    </footer>

</div>
</body>
</html>

vs

doctype html
html
  head
    @include('includes.head')
  body
    header.row
      @include('includes.header')
   #main.row
      #sidebar.col-md-4
         @include('includes.sidebar')
      #content.col-md-8
         @yield('content')
     footer.row

This last is a pseudo pug code mixed with laravel template, just to illustrate my main idea. I'm curious why this kind of template isn't supported by the core team.

Regards

PD: I want to discuss this topic :)

Miguel-Serejo commented 6 years ago

Whats my point? Well html is hard to read

This is extremely subjective. I find HTML much easier to read than most "modern template" files. Indentation is much harder to read than open/close tags. It's also harder to identify a misaligned block than to identify a missing end tag, for example.

From your example, What does #main mean and why does main get the # sign before it but header doesn't? More importantly, why is it not aligned with the header if it's supposed to be on the same level? What html element is even being used for these? Does #sidebar mean you create a <sidebar> element or is it a div with and id of sidebar?

Reading through this type of template is hardly ever a pleasant experience when you need to understand what is actually being printed.

why I need to use {{ $someVar }}

You don't. That's the whole point of blade. You don't need to use anything other than plain php if you don't want to. The {{}} syntax is just sugar to make it easier to echo escaped values. Most blade directives are also just shortcuts to make the php code in your templates less verbose, while adding some utility functionality, such as the $loop variable in the @foreach directive.

I always hated twig because it doesn't add anything that I cannot do in plain php,

As opposed to what template engine that lets you transcend the language for which it is written?

norman784 commented 6 years ago

Well if the indentation is not correct is because I write it right in the comment box, I cannot use tab to indent and so used space. Also the tab thing is subjective, in this kind of template engines it force you to follow a convention (python like, where tab indicates the hierarchy) and with pure html is up to the user, and most users doesn’t use it correctly and write some tags in the same line, so it could add a heache to other developers (when maintaining others code), also (don’t know about blade) but pug/haml has a cache so they compile it to html and you could select prettify or compressed html to output, so you could gain a bit of performance removing the end of lines and extra spaces in the final result.

The # and the . means the same as css, if you know css you will understand it quickly, you use this way even with que js query selector :).

Also each line starts with the name of the tag, if the tag is omitted and started with an #id or .class (css like) then is a div, for the parameters of the tag you just write in the same way but between () instead of <>, and you have the normal stuff if, for, while, etc.

The first time I saw this tooksme just a few hours to understand and being used to this kind of templates (yea haml is uglier that pug because the tags starts with %) but is not hard to learn, and the frontend developers will no have hard time to understand even, because is mostly css selectors that you use.

Besides all of that, you use some modern template system (or language if you want to call so) using sass, less, stylus, but why use an old system that uses just plain html (and you know that is old markup language, even check why xml is being replace with json when possible, for the sake of readability) and the “modern” template engines is just like this, add simplicity and extra layer of readability to an old markup language, I know that will be people arguing this forever, but you need to embrace new trends also, not sticking with legacy stuff.

About the html tag why you ask why is there? you even have that in pure html that tag.

So you are ok with pure html, but you find hard to read the pug like templates after my explanation?

Miguel-Serejo commented 6 years ago

Well if the indentation is not correct is because I write it right in the comment box, I cannot use tab to indent and so used space.

And this is just one of the problems of indentation-based templates. If your blade example was misaligned, there would have been no added confusion. It would be a simple, obvious, and easily correctable mistake. In your pseudo-template language, if something is misaligned by one space, there is no way of knowing if the mistake was over-indentation or under-indentation.

As a side note, in your transfer to the pseudo-template, you didn't transfer the comments. That's a pretty big deal for some larger/more complex templates.

Also the tab thing is subjective,

That was exactly my point. All of this is very subjective. I'll take function over form any day. I want my templates to be as close to pure HTML as possible, because ultimately, HTML is what you're serving your clients. To me, Blade does a great job at letting me inject server-side data into my HTML templates without completely changing their form. I also don't need to waste time translating my designer's templates, or teaching them a new template language. I just extract partials, inject my variables, and that's it.

most users doesn’t use it correctly and write some tags in the same line, so it could add a heache to other developers (when maintaining others code)

I'd like to see where you're getting your statistics from. I rarely see HTML that I can't understand. Also, writing more than one tag per line is not always an error or a mistake. For example, <h1><span class="color-red">THIS</span> is important</h1> is a snippet that makes a lot more sense when read in one line than split in several lines.

also (don’t know about blade)

I suggest you read up on how blade functions before dismissing it. Your views are compiled into pure php files and cached that way for performance. This is also what allows you to weave pure php into the template files. We don't need to rely on the template engine to generate HTML, that's what PHP is for.

Also each line starts with the name of the tag, if the tag is omitted and started with an #id or .class (css like) then is a div,

This is exactly the kind of magic behavior I don't want to see in my templates. Especially when your example is a template that uses valid tag names as ids for magically-appearing divs. My point wasn't so much that I wanted to understand your pseudo-template, but the fact that I had to ask in the first place shows it's a poor template engine. Increasing cognitive load by requiring the user to parse a template into HTML in their heads is not a good idea.

Besides all of that, you use (...) sass, less, stylus,

None of these are template engines, they're CSS pre-processors.

but why use an old system that uses just plain html

The system ultimately compiles down to plain HTML, just like any HTML template language, but is not plain HTML. It uses the same element structure, just like PHP does,

(and you know that is old markup language, even check why xml is being replace with json when possible, for the sake of readability)

This is completely unrelated to the topic at hand. Even still, I'll just point out that xml and json are not always interchangeable as some people would like to think. JSON is very good for transmitting data between applications that know the data structure and how to treat it. XML allows more versatility. For example, data can be commented and include instructions on how to treat it.

About the html tag why you ask why is there? you even have that in pure html that tag.

I didn't ask about the HTML tag?

So you are ok with pure html, but you find hard to read the pug like templates after my explanation?

Yes. HTML is purely and entirely descriptive. You never have to guess what a tag means. It's also a lot easier to identify misplaced tags in deeply-nested structures than it is to count tabs.

Again, this is all subjective. If you'd like to use a different templating engine, feel free to open a PR to add support for it, or make a package for it. Nobody's stopping you, but don't be surprised if people who like using blade decide to continue using blade instead of switching to your preferred template.

sisve commented 6 years ago

As opposed to what template engine that lets you transcend the language for which it is written?

@36864 You have forgotten the ways of the Great Savior XSLT, Lord of all that is Markup.

[...] in this kind of template engines it force you to follow a convention [...] and with pure html is up to the user, and most users doesn’t use it correctly and write some tags in the same line [...]

@norman784 What you describe here is a technical solution to a human problem. The real solution would be education, education and education. There will always be users that focus on proof-of-concepts and minimum-viable-products, while others are thinking long-term maintenance. And there will be a few that has just learned about <font size="+1">.

[...] most users doesn’t use it correctly and write some tags in the same line [...]

This is required when you want to avoid the whitespace inserted by the html parser/render/something. It's not a bug, it's a workaround. Whitespaces can cause harm in html. (Harm in this case is in the eye of the designer, not the functionality of the page. Designer eyes harm easily.)

[...] but pug/haml has a cache so they compile it to html [...]

Blade does this already.

[...] and you could select prettify or compressed html to output [...]

You can use https://github.com/HTMLMin/Laravel-HTMLMin for this.

[...] could gain a bit of performance removing the end of lines and extra spaces in the final result.

This sounds like a weasel phrase where the main word is "could". It's true that you could save some bytes, but is that really where your application's slowness is coming from?

The first time I saw this tooks me just a few hours to understand and being used to this kind of templates [...]

Let's assume it took you four hours. There's 7.8 million downloads of laravel/laravel. Let's just make up that only a tenth of those are actual new sites for development and the rest are people testing the installer or something. That would be 4 hours for every 0.78 million installations, which becomes 3,12 million hours. That's almost 356 years of developer hours of time. (Imagine how many new javascript frameworks that could be written in that time.)

[...] the frontend developers will no have hard time to understand even, because is mostly css selectors that you use.

I believe that the term "frontend developers" already includes html knowledge. What you're telling these guys is that their knowledge is no longer valid, and they need to learn something new.

Are you arguing that we should let in those that only knows css into writing views? It could perhaps work, but you would still know html to understand what your template was generated into. There's no way to debug it, or even inspect it, without knowing html. So it wouldn't help those people either.

[...] why use an old system that uses just plain html [...]

Because everyone knows it.

[...] and you know that is old markup language, even check why xml is being replace with json when possible, for the sake of readability [...]

Seriously, you need to start adding some sources to your claims. Json cannot differ between attributes and elements. Json does not support a datetime data type. Json does not have namespaces. Json cannot contain comments. And in some cases json realizes what it is missing, and are now in process of implementing a json schema support (still in draft) because validating data documents can be important.

Xml is old. Html is old. But they are both old and in use. They have survived this long because people know them, and they get the work done. And in some cases they support things that json/your-favorite-template-language doesn't.

I believe that people around you, whose decisions you've seen and based your arguments on, have based their decisions on their choices on "what is really easy to parse in Javascript, because I am building Javascript right now". And there's the really important context; it's easier to work with json in javascript than it is to work with xml in javascript.

Here's the end of a json file I have. I will not attempt to argue that json is easier to read.

                                }
                            }
                        ]
                    }
                ]
            }
        }
    }
]

On a side note, we should all switch to visual basic because it's easier to read "End If" than it's to differ if that } is for the if clause or anything else in the vicinity.

[...] but you need to embrace new trends also, not sticking with legacy stuff.

You need to understand that you're basically telling us that what we know and what we've learned in our professional careers is wrong, and you have the answer to our problem, and it somehow is a new template engine. And the main argument is that what we've done for many years, and earned money with for many years, is old. Not wrong, just old.

I wonder what's next; are we no longer allowed to use jQuery because there's something newer now? All my gifs and jpegs should now be png? (Is there perhaps an even newer image format?)

Here's my recommendation to you. Just a recommendation.

  1. Don't attempt to replace the default view engine in Laravel.
  2. Build your own view engine in a separate package, and document it, and let people opt-in to use it.

I feel like an XSLT view engine is a good thing to link here. https://github.com/krowinski/laravel-xslt

Garbee commented 6 years ago

You can embrace a "modern template engine" on your own using an existing plugin which is also referenced in the readme of the very project you mention using for your template system.

Now onto your opinions and why they aren't that important to make a decision for based on a mass framework.

HTML is hard (to read)

This is... what? Using words like "hard" or "difficult" just gives you too much wiggle-room to say you're right somehow. Instead, show what's wrong with HTML. Oh that's right, it works just fine so you can't. Having an issue "seeking" anything is a signal of poorly written markup. That's not HTML's problem as a markup structure, it's developers not having set styles for how to write consistently structured documents.

Template engines for development speed

So two big issues on this point. First, you then need to teach the template system to new devs. Houses tend to just "use the default." So if a "modern template engine" is added in the mix, that then is yet-another-thing to teach. Which, ends up slowing down the initial development process. Then after that, yea you're doing good for a bit. Until, the second issue, late-stage larger projects. Having an HTML abstraction on larger/more complex problems becomes a hindrance to development. Since you're then adding the cognitive overhead of needing to convert the source into markup in your mind as you work.

Limited Uses

"Modern template engines", as you put it, have a much smaller surface area of production benefits. What you may not see as much, is how much larger figures/companies end up going back to raw CSS from Sass, or HTML from these engines, or JS itself from Coffeescript/etc. since using the native features and learning how to use and maintain it well make your company and people far more productive than all these abstractions.

Education

As @sisve mentioned, this all comes down to better education. If you're finding anything hard, what you should do is educate yourself further in how you can make it more maintainable. How you can add tools to lint as you work to keep yourself straight using them. How you can write markup in an easier to maintain way. The issue isn't, HTML is bad so let's abstract it. The true issue is, recognizing you don't understand how to do it well enough and working to address that.

norman784 commented 6 years ago

Ok, that pseudo template is something similar to pug, I write speudo template just to illustrate the difference, not to implement exactly how is there, also you point me that I need to read the docs of blade (and I should) I want you also to read, at least quickly pug/slim docs, don’t be so closed mind, is not that you need to stick forever with something, you need to evolve and also the frameworks, yes you point that everyone knows html (in web development ) but wheres the harm to learn something new that today you used 4 hours to learn but in the future could save you time.

About less, sass, etc, you could argue you that is a css pre-processor (I referred them as a template engine, ok, im was not aware about that, but to me is something similar) they help you adding new syntax to enhance the css development, so why you support them (even when they add also extra learning curve and waste of development time? you could use the same formula that you used to calculate the wasted time in learning a new template engine) and you see that in the long term people use them because they help them, and I want you to look in the same way what I asked, why not embrace a new template engine that is simple to read (even if for you html is easier for you, just see this opinion from other perspective), besides it will take some extra work (don’t know how much) to develop the parser for the new template engine, your argument is based on your experience and my on my experience, obviously whe differ and thats why I want to discuss this.

May I ask if you have tried other languages with different template engines (appart from html-ish like), if not I just ask if don’t mind just to try it, even if a kind of hello world and then tell me what do you think about it. Why I would ask you this? because I tried both worlds (html-ish and minimalist/newer syntax template engines).

Miguel-Serejo commented 6 years ago

I did not mean to criticize your pseudo-template, I criticized the philosophy behind it and any similar templates. In my previous post I suggested you should implement the template engines you need as a package, completely unaware that there already are packages out there that let you use the template engine you seem to like.

In light of the existence of these packages, I don't really understand you goal here. What you want is available. All you have to do is use it.

I am not arguing against your usage of these templates, I'm simply arguing for my use of the Blade engine. In retrospect, the appropriate answer to your original post would have been simply "Because I like Blade."

[...] why not embrace a new template engine that is simple to read (even if for you html is easier for you [...]

Allow me to flip that question around. Why don't you embrace Blade, even if pug is easier for you?

To satisfy your curiosity, yes, I have used other template engines. Heck, I'm using one right now as I type this comment into a markdown-enabled text box. They tend to become unusable if your templates have any complexity to them. I'm not saying they don't have uses, I'm saying I prefer to work as close to HTML as I can. I'm also not saying you should embrace Blade as the be-all-end-all template engine. It has its flaws, sure. Pretty much every template engine has flaws (except XSLT of course).

On a final note, if your question is "why does laravel use blade instead of pug", you'd have to ask Taylor, but I'd be willing to bet the answer is something along the lines of "I didn't like any of the available template engines so I just built my own and now people like it.". If you're asking users of Blade in general why they use blade instead of another templating engine, I would guess the answers would be something along the lines of "Because I like Blade." or "Because I haven't found anything better yet."

Garbee commented 6 years ago

but wheres the harm to learn something new that today you used 4 hours to learn but in the future could save you time.

Did I not already address this point before? Oh yea, here is the quote:

Until, the second issue, late-stage larger projects. Having an HTML abstraction on larger/more complex problems becomes a hindrance to development. Since you're then adding the cognitive overhead of needing to convert the source into markup in your mind as you work.

The issue is when your system becomes large or more complex and you end up digging yourself out of the whole the abstraction put you in. Or you put yourself in because you didn't realize what the abstraction is doing.

don’t be so closed mind

Please don't assume things about other people. It only muddies things in your own mind making conversation more difficult.

May I ask if you have tried other languages with different template engines (appart from html-ish like), if not I just ask if don’t mind just to try it, even if a kind of hello world and then tell me what do you think about it. Why I would ask you this? because I tried both worlds (html-ish and minimalist/newer syntax template engines).

So before you were stating as a fact I was closed minded. And only now you wish to know if I've had any experience with these alternatives. Interesting order to go in.

Anyways, I have fooled around with them before. They're pretty mundane. However, when it comes to building complex, rich, user-focused applications, HTML abstractions only get in your way. And you won't realize it until you're stuck raising yourself out of the ditch you dug for yourself.

How many large complex applications have you built using one of these markup abstraction systems? What was a problem you came across that it handled very well? What was the alternative in normal markup to solve that task?

Instead of saying, "It works for small 'Hello World!' demonstrations so it must be good for large apps." provide data to support your claim it helps with sizable apps. It's so easy to assume things must be fine, it's harder to provide supportive data to provide a foundation to your claims.

Garbee commented 6 years ago

"why does laravel use blade instead of pug", you'd have to ask Taylor, but I'd be willing to bet the answer is something along the lines of "I didn't like any of the available template engines so I just built my own and now people like it.".

I'm fairly certain this was discussed in one of the podcasts before. It basically came down to it, as I recall Taylor saying it... He didn't like anything around at the time. And what he did like was kinda cumbersome. So he wrote his own minimal system that also provided a razor-like syntax from the C# world he was more used to. (Razor blade, get it?) So, blade exists.

donnysim commented 6 years ago

Honestly, it all comes down in a circle. I tried/used a lot of templating engines, css-preprocessors etc. in the company I work, but after some time (not a short time, probably 2-3 year), you realize that everything just makes your life more difficult.

SCSS is great, you can nest it, use functions to generate code etc. 3 years later, we still use SCSS, but we try to limit ourself to 1 depth selectors with allowed state modifiers inside, and variables - why? because css nesting just makes things horrible and difficult to read.

Twig - just gets horrible and got slower than blade very fast. In addition you have so much work to do to use something in template.

Pug - at first it's an ok. Then you get a template for your project (that includes dashboard and frontend) and you realize this is not going to work. Instead of copying parts of html into your js code or blade, now you have to convert it. And then complex templates, conditional classes, yeah... was removed in a blink of an eye.

In my opinion, blade is the best template engine I worked with so far that doesn't get in your way.

norman784 commented 6 years ago

I need to check his podcast, where did he upload them?

I never find myself with that issue, but I’m not always working on web, also on mobile, and tend to use different platforms for the backend/frontend but mostly rails and sometimes php.

Garbee commented 6 years ago

I don't recall the exact podcast. This was years ago. That snippet is literally the entire relevant context for this discussion.

Now, about that data on your personal experience building large and/or complex applications with an abstraction later. Are you capable of providing any insight? Or have you only built basic little sites without any real complexity so you feel that applies to everyone else as well?

johnpaulmedina commented 6 years ago

How about supporting which ever template engine the developer wants to use. Have the original be blade but allow the user to configure alternatives?

Isn't that the point of modular development in the first place?

just looking briefly it can't be that difficult to do it yourself when you do a search for blade on the framework not too much is returned and you can see the implementation and how blade compiler is registered.

CompilerEngine extends PhpEngine

Garbee commented 6 years ago

How about supporting which ever template engine the developer wants to use. Have the original be blade but allow the user to configure alternatives?

This is exactly what is already allowed. For example, as previously mentioned, the pug blade extension. It allows you to write in pug, pipe that into blade and then get the final HTML for users.

The discussion isn't about being capable to use an abstraction layer. It's attempting to make any given one a default baked into Laravel itself. Which isn't a good idea. Developers should absolutely chose to opt-in to any HTML abstraction layers. They aren't something that should just be used "because it is the default it must be good."

johnpaulmedina commented 6 years ago

@Garbee I'd take that as question answered. --- UPDATE--- Just re-read the last portion you wrote. I think as developers we like what we like. Some always want the new and some like consistency and of course as mentioned above the matter of personal preference. Why change it if you can extend it? Makes no difference what is default or what we put into it.