Title: Moving to something like Handlebars (after 2.1)
Post by: Arantor on October 08, 2017, 09:27:04 AM
Post by: Arantor on October 08, 2017, 09:27:04 AM
So, anyone up for moving to a proper template system after 2.1? Maybe Handlebars. Maybe Twig. Maybe Blade... just something that makes it easier for themers to do their thing without having to master PHP. And making it *tons* easier for people to add in snippets of code without breaking things.
It's a lot of work. I think it'd be worth it.
It's a lot of work. I think it'd be worth it.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: d3vcho on October 08, 2017, 10:16:48 AM
Post by: d3vcho on October 08, 2017, 10:16:48 AM
Sounds interesting 8)
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Antes on October 08, 2017, 10:49:04 AM
Post by: Antes on October 08, 2017, 10:49:04 AM
I was opposing the idea when it first introduced by Suki. I'm still opposing it. I don't think SMF requires any framework inside it apart from (maybe) source framework. I think for next version maybe SMF can introduce something like loadSnip(), which in theory does the same thing.
I'm not opposing to frameworks in general, what I'm against is using frameworks in SMF. The uniqueness of the software will blow away with usage of frameworks (my opinion not the fact). If we are starting this, why stop there lets use Laravel (or something) Twig (or something), Bootstrap, Font-Awesome and enhance them with 100% jQuery (no native JS).
I'm not opposing to frameworks in general, what I'm against is using frameworks in SMF. The uniqueness of the software will blow away with usage of frameworks (my opinion not the fact). If we are starting this, why stop there lets use Laravel (or something) Twig (or something), Bootstrap, Font-Awesome and enhance them with 100% jQuery (no native JS).
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Arantor on October 08, 2017, 10:52:36 AM
Post by: Arantor on October 08, 2017, 10:52:36 AM
Awesome, you totally missed the point.
None of what I suggested was a *framework*. I was quite careful to be specific - I didn't say Laravel, I said Blade. I didn't say Symfony, I said Twig. I wasn't proposing using a framework, merely using something so that instead of templates being full of PHP, you could give them to themers without them having to learn PHP.
For example, which is someone more likely to be able to reskin, index.template.php, or:
Because *that* is what I am proposing. Notice how new people now don't have to figure out quoting syntax. Themers don't have to care about template layers or intermashing into PHP. It's just HTML with some nice placeholders to show them where content goes.
None of what I suggested was a *framework*. I was quite careful to be specific - I didn't say Laravel, I said Blade. I didn't say Symfony, I said Twig. I wasn't proposing using a framework, merely using something so that instead of templates being full of PHP, you could give them to themers without them having to learn PHP.
For example, which is someone more likely to be able to reskin, index.template.php, or:
Code Select
<!DOCTYPE html>
<html {{#if context.right_to_left}}dir="rtl" {{/if}}{{#if txt.lang_locale}} lang="{{locale txt.lang_locale}}"{{/if}}>
<head>
<meta charset="UTF-8">
{{#each context.css_files}}
<link rel="stylesheet" href="{{fileUrl}}">
{{/each}}
{{{javascript deferred=0}}}
<title>{{context.page_title_html_safe}}</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
{{#each context.meta_tags}}
<meta {{#if name}}name="{{name}}"{{else}}property="{{property}}"{{/if}} content="{{content}}">
{{/each}}
<!-- Theme color; feel free to override -->
<meta name="theme-color" content="#557EA0">
{{#if context.robot_no_index}}<meta name="robots" content="noindex">{{/if}}
{{#if context.canonical_url}}<link rel="canonical" href="{{context.canonical_url}}">{{/if}}
<link rel="help" href="{{scripturl}}?action=help">
<link rel="contents" href="{{scripturl}}">
{{#if context.allow_search}}<link rel="search" href="{{scripturl}}?action=search">{{/if}}
<link rel="alternate feed" type="application/rss+xml" title="{{context.forum_name_html_safe}} - {{txt.rss}}" href="{{scripturl}}?action=.xml;type=rss2{{#if context.current_board}};board={{context.current_board}}{{/if}}">
<link rel="alternate feed" type="application/atom+xml" title="{{context.forum_name_html_safe}} - {{txt.atom}}" href="{{scripturl}}?action=.xml;type=atom{{#if context.current_board}};board={{context.current_board}}{{/if}}">
{{#if context.links.next}}<link rel="next" href="{{context.links.next}}">{{/if}}
{{#if context.links.prev}}<link rel="perv" href="{{context.links.prev}}">{{/if}}
{{#if context.current_board}}<link rel="index" href="{{scripturl}}?board={{context.current_board}}.0">{{/if}}
{{{context.html_headers}}}
</head>
{{!--
I apologise for the next line. -Yami
--}}
<body id="{{context.browser_body_id}}" class="action_{{#if context.current_action}}{{context.current_action}}{{else}}{{#if context.current_board}}messageindex{{else}}{{#if context.current_topic}}display{{else}}home{{/if}}{{/if}}{{/if}}{{#if context.current_board}}board_{{context.current_board}}{{/if}}">
<div id="footerfix">
<div id="top_section">
{{#if context.user.is_logged}}
<ul class="floatleft" id="top_info">
<li>
<a href="{{scripturl}}?action=profile" {{#if context.self_profile}} class="active"{{/if}} id="profile_menu_top" onclick="return false;">
{{#if context.user.avatar}}{{{context.user.avatar.image}}}{{/if}}
{{context.user.name}}</a>
<div id="profile_menu" class="top_menu"></div>
</li>
<li>
<a href="{{scripturl}}?action=profile;area=characters" id="characters_menu_top" onclick="return false;">
{{textTemplate txt.posting_as user_info.character_name}} ▼</a>
<div id="characters_menu" class="top_menu"></div>
</li>
{{#if context.allow_pm}}
<li>
<a href="{{scripturl}}?action=pm" {{#if context.self_pm}}class="active"{{/if}} id="pm_menu_top">{{txt.pm_short}} {{#if context.user.unread_messages}}<span class="amt"> {{context.user.unread_messages}}{{/if}}</span></a>
<div id="pm_menu" class="top_menu scrollable"></div>
</li>
{{/if}}
<li>
<a href="{{scripturl}}?action=profile;area=showalerts;u={{context.user.id}}"{{#if context.self_alerts}}class="active"{{/if}} id="alerts_menu_top">{{txt.alerts}}{{#if context.user.alerts}}<span class="amt">{{context.user.alerts}}</span>{{/if}}</a>
<div id="alerts_menu" class="top_menu scrollable"></div>
</li>
</ul>
{{else}}
{{#if maintenance}}
<ul class="floatleft welcome">
<li>{{login_helper txt.welcome_guest txt.guest_title context.forum_name_html_safe scripturl txt.login}}</li>
</ul>
{{else}}
<ul class="floatleft welcome">
<li>{{#if context.can_register}}{{login_helper txt.welcome_guest_register txt.guest_title context.forum_name_html_safe scripturl txt.login}}{{else}}{{login_helper txt.welcome_guest txt.guest_title context.forum_name_html_safe scripturl txt.login}}{{/if}}</li>
</ul>
{{/if}}
{{/if}}
{{#if modSettings.userLanguage}}
{{#if context.languages}}
<form id="languages_form" method="get" class="floatright">
<select id="language_select" name="language" onchange="this.form.submit()">
{{#each context.languages}}
<option value="{{filename}}"{{isSelected context.user.language filename}}>{{name}}</option>
{{/each}}
</select>
<noscript>
<input type="submit" value="{{txt.quick_mod_go}}" />
</noscript>
</form>
{{/if}}
{{/if}}
{{#if context.allow_search}}
<form id="search_form" class="floatright" action="{{scripturl}}?action=search2" method="post" accept-charset="UTF-8">
<input type="search" name="search" value="" class="input_text">
<select name="search_selection">
<option value="all">{{txt.search_entireforum}}</option>
{{#if context.current_topic}}<option value="topic" selected="selected">{{txt.search_thistopic}}</option>{{/if}}
{{#if context.current_board}}<option value="board" selected="selected">{{txt.search_thisbrd}}</option>{{/if}}
{{#if context.allow_memberlist}}<option value="members">{{txt.search_members}}</option>{{/if}}
</select>
{{#if context.current_topic}}<input type="hidden" name="sd_topic" value="{{context.current_topic}}">{{/if}}
{{#if context.current_board}}<input type="hidden" name="sd_brd" value="{{context.current_board}}">{{/if}}
<input type="submit" name="search2" value="{{txt.search}}" class="button_submit">
<input type="hidden" name="advanced" value="0">
</form>
{{/if}}
</div>
<div id="header">
<h1 class="forumtitle">
<a id="top" href="{{scripturl}}">{{#if context.header_logo_url_html_safe}}<img src="{{context.header_logo_url_html_safe}}" alt="{{context.forum_name_html_safe}}">{{else}}{{context.forum_name_html_safe}}{{/if}}</a>
</h1>
{{#if settings.site_slogan}}<div id="siteslogan" class="floatright">{{settings.site_slogan}}</div>{{else}}<img id="smflogo" src="{{settings.images_url}}/smflogo.png" alt="Simple Machines Forum" title="Simple Machines Forum">{{/if}}
</div>
<div id="wrapper">
<div id="upper_section">
<div id="inner_section">
<div id="inner_wrap">
<div class="user">
{{context.current_time}}
</div>
<div class="news">
<h2>{{txt.news}}:</h2>
<p>{{context.random_news_line}}</p>
</div>
<hr class="clear">
</div>
<a class="menu_icon mobile_user_menu"></a>
<div id="mobile_user_menu" class="popup_container">
<div class="popup_window description">
<div class="popup_heading">{{txt.mobile_user_menu}}
<a href="javascript:void(0);" class="generic_icons hide_popup"></a></div>
{{>menu}}
</div>
</div>
<div id="main_menu">{{>menu}}</div>
{{#if context.linktree}}
<div class="navigate_section">
<ul>
{{#if context.user.is_logged}}
<li class="unread_links">
<a href="{{scripturl}}?action=unread" title="{{txt.unread_since_visit}}">{{txt.view_unread_category}}</a>
<a href="{{scripturl}}?action=unreadreplies" title="{{txt.show_unread_replies}}">{{txt.unread_replies}}</a>
</li>
{{/if}}
{{#each context.linktree}}
<li {{#if @last}}class="last"{{/if}}>
{{#unless @first}}<span class="dividers">{{#if context.right_to_left}}◄{{else}}►{{/if}} </span>{{/unless}}
{{{extra_before}}}
{{#if url}}
<a href="{{url}}"><span>{{{name}}}</span></a>
{{else}}
<span>{{{name}}}</span>
{{/if}}
{{{extra_after}}}
</li>
{{/each}}
</ul>
</div>
{{/if}}
</div>
</div>
<div id="content_section">
<div id="main_content_section">
{{#if (and context.in_maintenance context.user.is_admin)}}
<div class="errorbox">
<dl>
<dt>
<strong id="error_serious">{{txt.forum_in_maintenance}}</strong>
</dt>
<dd class="error" id="error_list">
{{{textTemplate txt.maintenance_page (concat scripturl '?action=admin;area=serversettings;' context.session_var '=' context.session_id)}}}
</dd>
</dl>
</div>
{{/if}}
{{>status_messages}}
{{{content}}}
</div>
</div>
</div>
</div>
<div id="footer">
<ul>
<li class="floatright">
<a href="{{scripturl}}?action=help">{{txt.help}}</a>
{{#if modSettings.requireAgreement}}| <a href="{{scripturl}}?action=help;sa=rules">{{txt.terms_and_rules}}</a>{{/if}}
| <a href="#top_section">{{txt.go_up}} ▲</a>
</li>
<li class="copyright">{{{copyright}}}</li>
</ul>
{{#if context.show_load_time}}
<p>{{loadtime}}</p>
{{/if}}
</div>
{{{javascript deferred=1}}}
</body>
</html>
Because *that* is what I am proposing. Notice how new people now don't have to figure out quoting syntax. Themers don't have to care about template layers or intermashing into PHP. It's just HTML with some nice placeholders to show them where content goes.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Antes on October 08, 2017, 10:59:25 AM
Post by: Antes on October 08, 2017, 10:59:25 AM
Excuse me if I made a mistake in there but I think "twig" is a Template Framework ? (no sarcasm). If I have misknowledge please ignore my comment above.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Arantor on October 08, 2017, 11:08:02 AM
Post by: Arantor on October 08, 2017, 11:08:02 AM
You're way too hung up on what a framework is. A framework is a structure for doing something, nothing more, though often it means a structure for setting up a platform so you don't have to.
Twig is not generally considered a 'framework' because it doesn't do anything beyond template processing - it's part of Symfony and Symfony is the underlying framework for everything else.
Not that I was evangelising Twig specifically, it was used as an example, in the same way I suggested the Blade part of Laravel. Or Smarty. Or Handlebars. Or Mustache. Or LightnCandy. Or indeed anything that means users don't have to write actual PHP in order to customise it and generally get protected against having to do actual PHP.
Twig is not generally considered a 'framework' because it doesn't do anything beyond template processing - it's part of Symfony and Symfony is the underlying framework for everything else.
Not that I was evangelising Twig specifically, it was used as an example, in the same way I suggested the Blade part of Laravel. Or Smarty. Or Handlebars. Or Mustache. Or LightnCandy. Or indeed anything that means users don't have to write actual PHP in order to customise it and generally get protected against having to do actual PHP.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Gwenwyfar on October 08, 2017, 11:13:12 AM
Post by: Gwenwyfar on October 08, 2017, 11:13:12 AM
Twig seems the most interesting out of the three, but... I don't see what difference it makes, you're just switching one syntax for another (which in my opinion is even harder to read when you have so many ifs and etc). Wouldn't you be able to achieve the same thing by just altering the existing php to a different format? Or maybe I'm missing something here.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Arantor on October 08, 2017, 11:36:27 AM
Post by: Arantor on October 08, 2017, 11:36:27 AM
QuoteWouldn't you be able to achieve the same thing by just altering the existing php to a different format?
That's exactly what I'm proposing.
How many support issues come from users who want to insert a piece of JavaScript but get hung up on getting the quotes *just* right to put inside the PHP echo statement? With what I'm proposing, that goes away.
How many themers have walked away from SMF because they're not really PHP people but can wrangle HTML/CSS just fine? I've spoken to at least a dozen over the years - and I've worked with people who do WP themes, Drupal themes, even Moodle themes.
Take it further, this also simplifies matters for modders if implemented correctly because they don't have to wrangle over PHP+HTML syntax nearly so much.
Consider also that literally every other forum software does some variation of this process now, except SMF. Because they all recognise that doing it has benefits that SMF's approach does not. They don't all do it the same way, but they do do it.
I'm normally the last one to point at 'because they do it' as an argument, intellectually it's one of the last refuges of someone without an actual argument, but MyBB (https://github.com/mybb/mybb/blob/feature/install/resources/mybb_theme.xml), phpBB (https://github.com/phpbb/phpbb/blob/master/phpBB/styles/prosilver/template/index_body.html), XenForo (https://xenforo.com/help/html-templates/), vBulletin (https://www.vbulletin.com/docs/html/stylemanager_edit_templates), NodeBB (https://nodebb.readthedocs.io/en/latest/themes/templates.html), Discourse (https://github.com/discourse/discourse/blob/master/app/assets/javascripts/discourse/templates/topic.hbs), Flarum (https://github.com/flarum/core/blob/master/views/discussion.blade.php) (even if they do have raw PHP in their templates, it's solely to help simplify the view logic) - they ALL do it. Note that there are non-PHP forum packages on that list, and even there the premise applies.
Why? Because it separates viewing logic from underlying logic (good engineering practice), and it allows non-PHP people to modify themes without the hassle.
Even WordPress does more like this than SMF does - and SMF isn't trail-blazing a better path here. Its approach was common-sensical and bordering on best practice back in 2003-4. Things have moved on, the industry has figured out better best-practice approaches for application development.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: digger on October 08, 2017, 01:01:15 PM
Post by: digger on October 08, 2017, 01:01:15 PM
Quote from: Arantor on October 08, 2017, 11:36:27 AMSMF templates is a hell for themers. It's a mess of php code and html tags. There is no ability to use any tools or editors to work with this mess.
How many themers have walked away from SMF because they're not really PHP people but can wrangle HTML/CSS just fine? I've spoken to at least a dozen over the years - and I've worked with people who do WP themes, Drupal themes, even Moodle themes.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Gwenwyfar on October 08, 2017, 01:04:32 PM
Post by: Gwenwyfar on October 08, 2017, 01:04:32 PM
I agree that there is a lot of room for improvement in the templates, some of them are very convoluted. They could do with improvements. What I meant to say is to change how the templates are organized, simplify them using PHP syntax to achieve similar results; a better formatting practice, change the way some of them get things done. The different syntax was not the only change made in your example and I do not think that change alone fixes anything.
And if someone can't even understand simple quotes (or get an editor that will make them all easily visible), are we really losing much by that person leaving? I am very skeptic of someone that supposedly knows all about HTML/CSS not being able to do something so simple. Even CSS/HTML itself has its own brackets and quotes, it shouldn't be any alien concept. For JS it only makes the case look even worse, since it involves similar concepts as PHP...
I do work as a webdeveloper, and the amount of people (even designers) that do amazingly poor (paid) work is incredible. Wordpress is full of them, so it doesn't really help on the case of them knowing what they're up to just because they work on it. It's down to a level I hardly ever accept any job that involves editing existing code, because I'd just be pulling my hairs out wanting to scrap everything and start over. If someone really knows what they are doing, it should not be complicated to edit a piece of HTML or JS inside quotes. To be fair, it does help to have the HTML properly highlighted outside of quotes, that'd be one of the upsides of these systems, but (at least with those three in particular), you're sacrificing the entire PHP readability/syntax just to not have to do echo quotes, and I don't think that is a good trade.
That said, there could be a way to get the best out of both worlds out here, I'm not saying we shouldn't look into it. I'm saying I don't see any benefit of these syntaxes in particular, by themselves, unless I'm missing something.
Well, just because everyone is doing something, does not make it right or better. Even more so in today's world where all sorts of bad ideas gain popularity. Really no argument there at all - sorry :P
And if someone can't even understand simple quotes (or get an editor that will make them all easily visible), are we really losing much by that person leaving? I am very skeptic of someone that supposedly knows all about HTML/CSS not being able to do something so simple. Even CSS/HTML itself has its own brackets and quotes, it shouldn't be any alien concept. For JS it only makes the case look even worse, since it involves similar concepts as PHP...
I do work as a webdeveloper, and the amount of people (even designers) that do amazingly poor (paid) work is incredible. Wordpress is full of them, so it doesn't really help on the case of them knowing what they're up to just because they work on it. It's down to a level I hardly ever accept any job that involves editing existing code, because I'd just be pulling my hairs out wanting to scrap everything and start over. If someone really knows what they are doing, it should not be complicated to edit a piece of HTML or JS inside quotes. To be fair, it does help to have the HTML properly highlighted outside of quotes, that'd be one of the upsides of these systems, but (at least with those three in particular), you're sacrificing the entire PHP readability/syntax just to not have to do echo quotes, and I don't think that is a good trade.
That said, there could be a way to get the best out of both worlds out here, I'm not saying we shouldn't look into it. I'm saying I don't see any benefit of these syntaxes in particular, by themselves, unless I'm missing something.
Well, just because everyone is doing something, does not make it right or better. Even more so in today's world where all sorts of bad ideas gain popularity. Really no argument there at all - sorry :P
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Arantor on October 08, 2017, 01:17:47 PM
Post by: Arantor on October 08, 2017, 01:17:47 PM
Quotesimplify them using PHP syntax to achieve similar results
Honestly that would be akin to shuffling the deckchairs on the Titanic, it doesn't fix the underlying problem.
QuoteThe different syntax was not the only change made in your example and I do not think that change alone fixes anything.
Considering that it was taken from 2.1's index.template.php, flattened and converted to Handlebars, it's completely demonstrates what I'm getting at. It's also not a theoretical example.
QuoteAnd if someone can't even understand simple quotes (or get an editor that will make them all easily visible),
Let me know when someone invents an editor that can correctly highlight HTML inside a PHP string.
Meanwhile I'll be over here writing templates that my editor can highlight for me without any headaches. (See attached. This is a part of ManageNews.template.php. Except it's actually readable.)
QuoteI am very skeptic of someone that supposedly knows all about HTML/CSS not being able to do something so simple.
Go look at the number of people who tried to add Google Analytics on their site and just copy-pasted the snippet, and see how many of them broke.
QuoteI do work as a webdeveloper, and the amount of people (even designers) that do amazingly poor (paid) work is incredible.
Sturgeon's Law is a thing here too. However, if you make it easier for people to do the right thing, people shockingly tend towards doing the right thing.
QuoteIf someone really knows what they are doing, it should not be complicated to edit a piece of HTML or JS inside quotes.
That's the problem. I work with some people who do amazing things with HTML and CSS - but can't write PHP to save their lives and get fed up trying to wrangle it inside PHP. These are the people that can, and do, successfully work with something like these templates but couldn't work with SMF.
Quotebut (at least with those three in particular), you're sacrificing the entire PHP readability/syntax just to not have to do echo quotes, and I don't think that is a good trade.
Considering that I get actual syntax highlighting (which I don't with SMF) and I get proper separation of logic (which I don't with SMF)...
QuoteThat said, there could be a way to get the best out of both worlds out here
Ah, so you think that you actually lose something in the translation. You don't. I am currently porting SMF's theme to something like this and other than untangling SMF's convolutions, I have yet to find anything I've actually lost. I have, however, found a number of things I have gained.
QuoteWell, just because everyone is doing something, does not make it right or better. Even more so in today's world where all sorts of bad ideas gain popularity. Really no argument there at all - sorry
You can't out-devil's advocate someone who already made the devil's advocate argument. I'm well aware that because everyone is doing it doesn't make it right. I believe I even stated that. However, the fact that all of those, plus existing platforms that started out life much as SMF did (and in some cases, that pre-date SMF, e.g. Moodle) are moving towards it because it gives all the benefits and surprisingly few of the downsides (because in reality the supposed flexibility doesn't actually exist nearly as much as people think)
Oh, and trying to preserve the status quo out of a belief in its current values and assuming everything else is a compromise is just as much an intellectual dishonesty. It's also one of the reasons I quit the team back in 2014 when every 'hey maybe we should do this' always resulted in pointing out the apparent downsides without realising that the downsides don't really exist, don't have to exist or invariably end up better than the situation that is supposedly a compromise.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: lurkalot on October 08, 2017, 01:29:12 PM
Post by: lurkalot on October 08, 2017, 01:29:12 PM
Anything that makes things easier for the end user gets my vote. If that means being able to modify the looks, build themes without having to learn php can only be a good thing.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Gwenwyfar on October 08, 2017, 03:08:02 PM
Post by: Gwenwyfar on October 08, 2017, 03:08:02 PM
QuoteHonestly that would be akin to shuffling the deckchairs on the Titanic, it doesn't fix the underlying problem.Which is?
QuoteConsidering that it was taken from 2.1's index.template.php, flattened and converted to Handlebars, it's completely demonstrates what I'm getting at. It's also not a theoretical example.And what exactly in that example requires the different syntax? What in it can't be done using PHP syntax?
QuoteLet me know when someone invents an editor that can correctly highlight HTML inside a PHP string.I'd love that as well, but highlighting open/end quotes of the echo itself work perfectly well for most of them, which is what you mentioned that what I was referring to.
Meanwhile I'll be over here writing templates that my editor can highlight for me without any headaches. (See attached. This is a part of ManageNews.template.php. Except it's actually readable.)
QuoteGo look at the number of people who tried to add Google Analytics on their site and just copy-pasted the snippet, and see how many of them broke.And what does that have to do with people who should know HTML? How many of those people actually knew what they were doing?
QuoteSturgeon's Law is a thing here too. However, if you make it easier for people to do the right thing, people shockingly tend towards doing the right thing.Sure, if you could flip a switch to make echos better and leave everything else the same I'd be all for it, but it isn't this simple. If only heredoc didn't mess up the whole indentation, it would be one way.
QuoteThat's the problem. I work with some people who do amazing things with HTML and CSS - but can't write PHP to save their lives and get fed up trying to wrangle it inside PHP. These are the people that can, and do, successfully work with something like these templates but couldn't work with SMF.I'd love to see how their code looks like, doing something that looks nice and it actually being good code are often two very different things.
QuoteAh, so you think that you actually lose something in the translation. You don't. I am currently porting SMF's theme to something like this and other than untangling SMF's convolutions, I have yet to find anything I've actually lost. I have, however, found a number of things I have gained.Which means it is still PHP, just using a different syntax. So you could technically change the current templates to use it, and it would still have most of the same problems. Or if that's not how it works, then how does it?
Since you're being ranty...
Downplaying the downsides just for the sake of change is also intelectually dishonest. Not only that, it's also desperate.
Simplifying the system for the sake of lowering the barrier of entry has another name, and it's called "dumbing down". While the problem of overcomplexity you describe is very real, dumbing down the whole system is not the answer.
Dumbing down for the sake of a lower barrier of entry does increase activity and diversity on short terms, simply because there are more people working and creating. But it does so at the expense of performance. Dumbing down very quickly develops to slippery slopes of bloat and decreasing quality of output. On long term, it creates situations where you have a bunch of self-proclaimed "mechanics" who don't have any idea how a car actually works.
Overcomplexity and lack of organization is a very real issue but I believe there are better ways of solving the issue than taking the low effort shortcut everyone else is taking.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Arantor on October 08, 2017, 03:33:07 PM
Post by: Arantor on October 08, 2017, 03:33:07 PM
QuoteAnd what exactly in that example requires the different syntax? What in it can't be done using PHP syntax?
The part where you're still mangling stuff in PHP. The whole point is that you *separate away the PHP from actual stuff*.
QuoteI'd love that as well, but highlighting open/end quotes of the echo itself work perfectly well for most of them, which is what you mentioned that what I was referring to.
That only gives you the echo. It doesn't give you highlighting of the contents. I *have* highlighted templates.
QuoteAnd what does that have to do with people who should know HTML? How many of those people actually knew what they were doing?
The people that need to know HTML don't need to know PHP as well. Which is great if you happen to be a theme designer.
QuoteSure, if you could flip a switch to make echos better and leave everything else the same I'd be all for it, but it isn't this simple. If only heredoc didn't mess up the whole indentation, it would be one way.
Heredocs give you a different problem. You actually make it worse, not better, because you can't have any inline logic whatsoever in a heredoc. It's simply a string. I can have inline logic if I want, I can have partial templates that embed with no extra effort.
QuoteI'd love to see how their code looks like, doing something that looks nice and it actually being good code are often two very different things.
This is why you separate them.
QuoteWhich means it is still PHP, just using a different syntax.
Except it isn't. You can't insert PHP into those files and still expect it to work - because it won't. It's physically a separate language that's converted to PHP on demand.
QuoteDownplaying the downsides just for the sake of change is also intelectually dishonest. Not only that, it's also desperate.
You seem to assume it's my problem. It's not. I'm already doing the changes myself in my fork of SMF (which has things that should not go back upstream like intentional multi-accounting). I just thought I'd share the benefits of what we've been doing as 'hey look, we've been doing this thing, give it a whirl)
QuoteSimplifying the system for the sake of lowering the barrier of entry has another name, and it's called "dumbing down". While the problem of overcomplexity you describe is very real, dumbing down the whole system is not the answer.
Nothing's dumbed down at the level you think it is. I have literally converted most of SMF's templates to use this type of logic already. The generic list was a pain, as was the richtext editor. I haven't quite braved the mess that is the admin settings one yet. And yet it all works and none of it is a problem.
And then I can give it to people who don't know what PHP is and let them play with it. Maybe they work with Ruby. Maybe they work with Drupal. Or Moodle. Or any system not this one and can understand how to style it.
QuoteBut it does so at the expense of performance.
Compile the templates to PHP, the performance difference is barely negligible and a rounding error compared to, say, the overheads of the database. I could provide actual numbers if anyone were interested, wouldn't be hard to run XDebug in profile mode comparing the two (or at least it wouldn't once I finished making the compilation process work seamlessly)
QuoteI believe there are better ways of solving the issue than taking the low effort shortcut everyone else is taking.
I'm sorry you feel that way. Have fun.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Gwenwyfar on October 08, 2017, 05:23:32 PM
Post by: Gwenwyfar on October 08, 2017, 05:23:32 PM
QuoteThe part where you're still mangling stuff in PHP. The whole point is that you *separate away the PHP from actual stuff*.That doesn't explain much... Your example is doing two things, one is that the template was rewritten, and the other is that it is using a different syntax. And you didn't answer my previous question.
QuoteThat only gives you the echo. It doesn't give you highlighting of the contents. I *have* highlighted templates.Yep, and that is exactly why I said:
Quote from: GwenwyfarTo be fair, it does help to have the HTML properly highlighted outside of quotes, that'd be one of the upsides of these systems, but (at least with those three in particular), you're sacrificing the entire PHP readability/syntax just to not have to do echo quotes, and I don't think that is a good trade.and
Quoteif you could flip a switch to make echos better and leave everything else the same I'd be all for it, but it isn't this simple
QuoteThe people that need to know HTML don't need to know PHP as well. Which is great if you happen to be a theme designer.Sure. And the only relevant thing getting in the way of this is the highlighting, the rest doesn't really make any difference in the end, besides make it worse for those who already know PHP having to learn one more syntax. But god forbid the people editing the HTML learn how the system they are dealing with works.
QuoteHeredocs give you a different problem. You actually make it worse, not better, because you can't have any inline logic whatsoever in a heredoc. It's simply a string. I can have inline logic if I want, I can have partial templates that embed with no extra effort.Oh, I see. I kinda skimped over it as the indentation is a dealbreaker over other methods. Still, it would be great if there was something that worked similarly.
QuoteThis is why you separate them.You can't separate them if you have to both write the code and make said code look nice :P
QuoteExcept it isn't. You can't insert PHP into those files and still expect it to work - because it won't. It's physically a separate language that's converted to PHP on demand.Note the "with a different syntax". If it merely gets converted into PHP then it really is no different in the way it works, you just write it differently. If there is something else it does besides this, you've yet to say what.
QuoteYou seem to assume it's my problem. It's not. I'm already doing the changes myself in my fork of SMF (which has things that should not go back upstream like intentional multi-accounting). I just thought I'd share the benefits of what we've been doing as 'hey look, we've been doing this thing, give it a whirl)I'm not asssuming anything, I'm discussing the issue on its own merits, regardless if it's your problem or somebody else's.
QuoteNothing's dumbed down at the level you think it is. I have literally converted most of SMF's templates to use this type of logic already. The generic list was a pain, as was the richtext editor. I haven't quite braved the mess that is the admin settings one yet. And yet it all works and none of it is a problem.You don't seem to understand the issues with not properly lowering the barrier of entry. It's about how it affects the culture around the system after it has been in place, which boggles down to curation, the quality level from the median average output. You lower the barrier of entry, you let the inner workings of the system more distant from the developer. People will develop on top of it without really having the tools for appropriate debugging on the system nor understad its inner workings to properly optimize their work. Like mechanics who don't understand how the car they are working on actually works. You end up with a lot newly developed objects who simply don't fit they system they are working upon. Just look at any mobile app development or the overuse of frameworks to understand what I'm talking about. The same kind of bloated, uneficient coding culture exists around the likes of Wordpress, Shopify, Tumblr, Bootstrap etc. Lots of sleek modern themes, none of them runs well.
And then I can give it to people who don't know what PHP is and let them play with it. Maybe they work with Ruby. Maybe they work with Drupal. Or Moodle. Or any system not this one and can understand how to style it.
QuoteI'm sorry you feel that way. Have fun.I repeat what I said:
"[...] there could be a way to get the best out of both worlds out here, I'm not saying we shouldn't look into it. I'm saying I don't see any benefit of these syntaxes in particular, by themselves [...]"
But if you think there is no other way to do the same (after all, the main problem at hand that using a different syntax would solve is the highlighting, which I already said I agree on, depending on how it is done), then I will indeed have fun looking for alternatives, specially since this will benefit everyone equally, from the beginners to the pros :)
Now, rewriting the templates, by all that has been said so far, is a separate matter, and surely one that can be addressed independently from the syntax used.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: 青山 素子 on October 11, 2017, 04:51:13 PM
Post by: 青山 素子 on October 11, 2017, 04:51:13 PM
I like the idea of using a proper templating engine for SMF themes. Rather than write one from scratch, using a popular library means that the work is offloaded a bit. I'm a fan of Twig personally, but any sane thing would be great. (Note that Smarty is not sane.) Don't think of it as "still PHP" because it's not. It's more a Domain-specific language (https://en.wikipedia.org/wiki/Domain-specific_language) just for templating.
As a bonus, that means you don't need to be a PHP master to create or modify a design. This is a huge benefit as it means that core developers don't need to waste time helping a design-focused contributor on making changes. For the most part, you can even load the raw template in the browser and since you don't have a ton of PHP in it, but rather placeholder tags, it will display fine without needing a whole SMF install.
Some specific responses to the latest points:
When you're focused solely on design, does it matter to know that you're having a plain PHP echo, or just to know that certain text goes in a place? I'd argue that anyone focused on design would be happy to not have to remember a bunch of PHP echo quoting rules and would rather just have a placeholder they knew would contain some text.
Well, there is the short open tags option, but that often isn't enabled and can interfere with other legitimate tag usage.
Most of the templating languages like Twig and handlebars are pretty quick to pick up. Also, if you're worried about having to learn multiple languages why are you not concerned about PHP coders having to learn CSS and JS?
As for learning how the system works, most mature things aren't so involved. I don't have to know how a CPU works at the component level to operate one. I don't have to understand crankshafts to drive a car. I certainly don't have to know how thermisters work to adjust the darkness level on my toaster. Why should I have to learn structural engineering to paint my house walls a new color?
Templating engines like Twig are the answer. No worrying about jumping in and out of logic code. No worrying about proper escaping syntax. Just write my HTML, stick in the placeholder tags and go.
You most certainly can separate them and make the code look nice. The backend code makes the effort to pick the right template files, get the processing done, and set all the strings up for use. Then it calls the templating engine to combine the strings and the design. Both sides look very clean and there's a good separation of the logic and the design.
Well, it's PHP internally. It's not like it's pre-processed into PHP that you'd work on or anything (well, kinda, but that's not relevant for this discussion). The something else it does is cleanly separate the controller logic from the view. It makes both parts easier to code and read.
Are you actually trying to gatekeep? Are you actually saying "unless you know PHP at an expert level, we don't want your kind"?
As for "appropriate debugging", if the template is cleanly separated, there shouldn't be any fancy tools needed for that. It should work just fine as all you're doing is creating a design and dropping placeholders into the appropriate areas. There shouldn't be any optimzation needed on the logic side, that's all handled by the SMF PHP that shouldn't need to be touched.
As for themes that don't work well, that's more the problem of the HTML/CSS/JS the theme author used than an issue with a templating engine. If the author loads down a theme with a ton of poorly-written JS and a lot of third party JS libraries, and then adds broken HTML on top of that, it's going to run awful no matter if it's expressed in a template engine or in the PHP mess of logic and design. In fact, it just might be worse in the current SMF style because of all the access to the raw PHP that can be abused.
The MVC concept in which having a separate clean template layer exists has been around since the late 1970s. The use of that pattern in web development exploded in the late 1990s and early 2000s after it became clear that it was a good model. It can speed development because the people working on the UI don't need to wait for back-end work to be complete and the back-end coders don't need to wait for the UI to expose new values. It can let you easily have different templates for different views without having to change a bunch of inline PHP code. Make a mobile-friendly template without having to change the executed PHP. Anything that makes SMF development faster and makes it easier to contribute to SMF is a big win in my opinion.
As a bonus, that means you don't need to be a PHP master to create or modify a design. This is a huge benefit as it means that core developers don't need to waste time helping a design-focused contributor on making changes. For the most part, you can even load the raw template in the browser and since you don't have a ton of PHP in it, but rather placeholder tags, it will display fine without needing a whole SMF install.
Some specific responses to the latest points:
Quote from: Gwenwyfar on October 08, 2017, 05:23:32 PMQuote from: GwenwyfarTo be fair, it does help to have the HTML properly highlighted outside of quotes, that'd be one of the upsides of these systems, but (at least with those three in particular), you're sacrificing the entire PHP readability/syntax just to not have to do echo quotes, and I don't think that is a good trade.
When you're focused solely on design, does it matter to know that you're having a plain PHP echo, or just to know that certain text goes in a place? I'd argue that anyone focused on design would be happy to not have to remember a bunch of PHP echo quoting rules and would rather just have a placeholder they knew would contain some text.
Quote from: Gwenwyfar on October 08, 2017, 05:23:32 PMQuoteif you could flip a switch to make echos better and leave everything else the same I'd be all for it, but it isn't this simple
Well, there is the short open tags option, but that often isn't enabled and can interfere with other legitimate tag usage.
Quote from: Gwenwyfar on October 08, 2017, 05:23:32 PMQuoteThe people that need to know HTML don't need to know PHP as well. Which is great if you happen to be a theme designer.Sure. And the only relevant thing getting in the way of this is the highlighting, the rest doesn't really make any difference in the end, besides make it worse for those who already know PHP having to learn one more syntax. But god forbid the people editing the HTML learn how the system they are dealing with works.
Most of the templating languages like Twig and handlebars are pretty quick to pick up. Also, if you're worried about having to learn multiple languages why are you not concerned about PHP coders having to learn CSS and JS?
As for learning how the system works, most mature things aren't so involved. I don't have to know how a CPU works at the component level to operate one. I don't have to understand crankshafts to drive a car. I certainly don't have to know how thermisters work to adjust the darkness level on my toaster. Why should I have to learn structural engineering to paint my house walls a new color?
Quote from: Gwenwyfar on October 08, 2017, 05:23:32 PMQuoteHeredocs give you a different problem. You actually make it worse, not better, because you can't have any inline logic whatsoever in a heredoc. It's simply a string. I can have inline logic if I want, I can have partial templates that embed with no extra effort.Oh, I see. I kinda skimped over it as the indentation is a dealbreaker over other methods. Still, it would be great if there was something that worked similarly.
Templating engines like Twig are the answer. No worrying about jumping in and out of logic code. No worrying about proper escaping syntax. Just write my HTML, stick in the placeholder tags and go.
Quote from: Gwenwyfar on October 08, 2017, 05:23:32 PMQuoteThis is why you separate them.You can't separate them if you have to both write the code and make said code look nice :P
You most certainly can separate them and make the code look nice. The backend code makes the effort to pick the right template files, get the processing done, and set all the strings up for use. Then it calls the templating engine to combine the strings and the design. Both sides look very clean and there's a good separation of the logic and the design.
Quote from: Gwenwyfar on October 08, 2017, 05:23:32 PMQuoteExcept it isn't. You can't insert PHP into those files and still expect it to work - because it won't. It's physically a separate language that's converted to PHP on demand.Note the "with a different syntax". If it merely gets converted into PHP then it really is no different in the way it works, you just write it differently. If there is something else it does besides this, you've yet to say what.
Well, it's PHP internally. It's not like it's pre-processed into PHP that you'd work on or anything (well, kinda, but that's not relevant for this discussion). The something else it does is cleanly separate the controller logic from the view. It makes both parts easier to code and read.
Quote from: Gwenwyfar on October 08, 2017, 05:23:32 PM
You don't seem to understand the issues with not properly lowering the barrier of entry. It's about how it affects the culture around the system after it has been in place, which boggles down to curation, the quality level from the median average output. You lower the barrier of entry, you let the inner workings of the system more distant from the developer. People will develop on top of it without really having the tools for appropriate debugging on the system nor understad its inner workings to properly optimize their work. Like mechanics who don't understand how the car they are working on actually works. You end up with a lot newly developed objects who simply don't fit they system they are working upon. Just look at any mobile app development or the overuse of frameworks to understand what I'm talking about. The same kind of bloated, uneficient coding culture exists around the likes of Wordpress, Shopify, Tumblr, Bootstrap etc. Lots of sleek modern themes, none of them runs well.
Are you actually trying to gatekeep? Are you actually saying "unless you know PHP at an expert level, we don't want your kind"?
As for "appropriate debugging", if the template is cleanly separated, there shouldn't be any fancy tools needed for that. It should work just fine as all you're doing is creating a design and dropping placeholders into the appropriate areas. There shouldn't be any optimzation needed on the logic side, that's all handled by the SMF PHP that shouldn't need to be touched.
As for themes that don't work well, that's more the problem of the HTML/CSS/JS the theme author used than an issue with a templating engine. If the author loads down a theme with a ton of poorly-written JS and a lot of third party JS libraries, and then adds broken HTML on top of that, it's going to run awful no matter if it's expressed in a template engine or in the PHP mess of logic and design. In fact, it just might be worse in the current SMF style because of all the access to the raw PHP that can be abused.
Quote from: Gwenwyfar on October 08, 2017, 05:23:32 PM
But if you think there is no other way to do the same (after all, the main problem at hand that using a different syntax would solve is the highlighting, which I already said I agree on, depending on how it is done), then I will indeed have fun looking for alternatives, specially since this will benefit everyone equally, from the beginners to the pros :)
The MVC concept in which having a separate clean template layer exists has been around since the late 1970s. The use of that pattern in web development exploded in the late 1990s and early 2000s after it became clear that it was a good model. It can speed development because the people working on the UI don't need to wait for back-end work to be complete and the back-end coders don't need to wait for the UI to expose new values. It can let you easily have different templates for different views without having to change a bunch of inline PHP code. Make a mobile-friendly template without having to change the executed PHP. Anything that makes SMF development faster and makes it easier to contribute to SMF is a big win in my opinion.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Suki on October 11, 2017, 06:03:40 PM
Post by: Suki on October 11, 2017, 06:03:40 PM
As the one championing the idea yes, I'm very much in favor of using a proper template system.
Over the years I tried a few different aproaches, from XML based (FatFree, dunno the name of the template engine), quasi raw php (lithium, again dunno whats the name of the engine) to twig and blade.
I'll be more inclined for either twig or blade, followed by the xml structure fatfree provides which takes time to get used to but its surprisingly easy after you get over the learning curve.
On the other hand I rather prefer to stay away from engines that uses raw php (ala codeigniter) or an even weirder way to use php opening tags as token separators (lithium).
In fact, I have a bunch of other ideas, dunno where to post them or if I will have the time to do a proper post for each but I would like to at least express them to see if theres enough interest.
Over the years I tried a few different aproaches, from XML based (FatFree, dunno the name of the template engine), quasi raw php (lithium, again dunno whats the name of the engine) to twig and blade.
I'll be more inclined for either twig or blade, followed by the xml structure fatfree provides which takes time to get used to but its surprisingly easy after you get over the learning curve.
On the other hand I rather prefer to stay away from engines that uses raw php (ala codeigniter) or an even weirder way to use php opening tags as token separators (lithium).
In fact, I have a bunch of other ideas, dunno where to post them or if I will have the time to do a proper post for each but I would like to at least express them to see if theres enough interest.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: 青山 素子 on October 11, 2017, 07:51:16 PM
Post by: 青山 素子 on October 11, 2017, 07:51:16 PM
Quote from: Suki on October 11, 2017, 06:03:40 PM
I'll be more inclined for either twig or blade, followed by the xml structure fatfree provides which takes time to get used to but its surprisingly easy after you get over the learning curve.
On the other hand I rather prefer to stay away from engines that uses raw php (ala codeigniter) or an even weirder way to use php opening tags as token separators (lithium).
Agreed on using something like twig or blade. Not sure I'd want something so different that there's an odd learning curve. BTW, it looks like Lithium is now named li₃ (or li3).
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Suki on October 12, 2017, 11:09:12 AM
Post by: Suki on October 12, 2017, 11:09:12 AM
Yeah, I love fatfree and its template engine but its heavily geared towards developers and thus, it wouldn't fit with SMF's current needs.
Although Laravel has gained a lot of popularity these past couple of years I would prefer Twig solely because its more recognized by designers. I don't know if blade has been used outside Laravel projects.
Although Laravel has gained a lot of popularity these past couple of years I would prefer Twig solely because its more recognized by designers. I don't know if blade has been used outside Laravel projects.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Suki on October 12, 2017, 12:05:23 PM
Post by: Suki on October 12, 2017, 12:05:23 PM
Didn't had the chance of reading previous entries.
About "dumbing down". This is actually something a few very vocal SMF themers have always ranted about. How SMF is all backend no frontend and things like that. If using a proper template engine doesn't make them happy, nothing will.
I personally don't see it as "dumbing down" or simplifying. I see it strictly as separation of concerns. This has nothing to do with "lowering the barrier" or other similar thoughts, it has to do with keeping logic away from presentation and viceversa. Both front and back are equally important, separating them allows us to give them both enough care and focus.
These days the "performance" card cannot really be used anymore. PHP 7.0 improvements over 5.0 says so categorically. Besides, any good template engine parses templates and store them as raw php file, meaning theres really no difference between a parsed, cached twig/blade template and current SMF template files except when the parsed template is been generated and lets be honest, how many times will you do that on a production enviroment.
That doesn't mean we shouldn't keep an eye on how those templates are parsed and rendered but its not something crucial to the overall performance of a forum page.
About "dumbing down". This is actually something a few very vocal SMF themers have always ranted about. How SMF is all backend no frontend and things like that. If using a proper template engine doesn't make them happy, nothing will.
I personally don't see it as "dumbing down" or simplifying. I see it strictly as separation of concerns. This has nothing to do with "lowering the barrier" or other similar thoughts, it has to do with keeping logic away from presentation and viceversa. Both front and back are equally important, separating them allows us to give them both enough care and focus.
These days the "performance" card cannot really be used anymore. PHP 7.0 improvements over 5.0 says so categorically. Besides, any good template engine parses templates and store them as raw php file, meaning theres really no difference between a parsed, cached twig/blade template and current SMF template files except when the parsed template is been generated and lets be honest, how many times will you do that on a production enviroment.
That doesn't mean we shouldn't keep an eye on how those templates are parsed and rendered but its not something crucial to the overall performance of a forum page.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Gwenwyfar on October 12, 2017, 02:14:56 PM
Post by: Gwenwyfar on October 12, 2017, 02:14:56 PM
I'll respond most of your points at once as this will explain things better:
No, you shouldn't need to be a PHP master to edit templates, but regardless of the choice used for templates, you still need to know the basics (variables, conditional statements, some functions, etc). That won't change even if you are using a template system. If you have to deal with a templating system, you'll have to learn one more language/syntax anyway, with the downside that the new syntax will only work in one specific situation for one specific purpose while shielding you even from tangential learning. It's like trying to learn a new language by starting with its many frameworks. It's just bad coding hygiene. By going straight to the source language for the template language to learn the simple basics required for templating you have the same learning curve than learning the syntax for a template engine, with the upside that this knowledge is much more useful, for it's non specific. It's useful tangential learning that will help the coder to understand the system better and code better. It's much more useful knowledge for everyone, on the same effort level.
If you're starting from point 0 (you only know HTML/CSS), there is not going to be much difference between learning to use
or
or
or
(I actually meant to say Blade seems the most interesting in my first post. I don't even know how the last example would look like for Twig, so it would be one more needless learning curve)
And if you already know some other language before you start, you should already be familiar with the concepts involved (even JS has them), and you only need to get used to PHP syntax. Then it will be one more tool you can throw in your pocket, even if you learn just enough to handle the templates.
You say it is pretty easy to pick up these languages, so why would it be any different for picking up the basics of PHP, when they are so similar? True, most people dealing only with themes and templates are not interested in learning actual programming, or being PHP masters, and that is fine, but they should still put some effort into learning the bits that they have to deal with. Remember, we are talking about people who will be editing or building templates (maybe even changing or adding functions) for a complex forum software, by default, this is not something for everyone. If someone is not willing to learn these basics to be able to build themes, why should that be any of our concern? Nothing stops those with less knowledge on sticking with simple edits and css only, but if you are going to dwelve into the templates, you have to know more than that.
The main problem in PHP for templates is that there is no native support to a decent way of printing HTML. Yes, echo/print syntax are bad for templates. Heredocs comes close, but still has it's drawbacks. I find it odd that there doesn't seem to be any plans to fix that, I spent some days looking into this and not even syntax packages for some popular editors exist to ammenize the problem (highlight content inside strings), despite numerous requests. People go for alternate syntaxes/templating tools instead, as a "fix". Using the shorthand <? ?> tags is a very popular alternative, but unless you have very little PHP to use, it only makes things even worse.
But just like some of these templating tools themselves do, there is nothing in the way of just building something to fix that. And it doesn't need to change the entire system just to fix one problem. Just go straight at the source of it.
Some further specific responses:
"I'd love to see how their code looks like, doing something that looks nice and it actually being good code are often two very different things."
You can't separate HTML/CSS(in some cases JS) from the end result.
And regarding alternatives, this is what I have found so far:
Conditional statements are not supported inside heredocs, but you can still use them with a simple function defined beforehand. According to what I saw this should work fine on any php > 5.3. Alongside the rest of heredoc syntax, you would be able to do something such as:
This also properly highlights HTML (or JS) in most editors, but still has the problem of heredoc ugliness. It would be better than many convoluted echos, but not ideal. You could run a script/function to simply fix the indentation (at least one already exists), so you can do:
Or, if you're already going to need to process it anyway, change it to something such as:
(Side note: Do they accept new function suggestions over in the PHP development? I'm surprised a language supposedly focused towards web development still has nothing of the sort)
Maybe there is some limitation to this that I'm not aware of (after all I'm no PHP master either), but even if there is you should be able to use the normal echo syntax in the final code instead. This would also cut down on all the conversion work needed with other systems (though I don't know if this would mean more or less work at the end of the day).
These last examples would also need a language package for editors to highlight properly, but even this isn't too complicated to do. I have already gotten some success trying to highlight strings in sublime:
Again, I could be missing something here, but so far I still see no reason to use a complete templating system such as the ones proposed.
No, you shouldn't need to be a PHP master to edit templates, but regardless of the choice used for templates, you still need to know the basics (variables, conditional statements, some functions, etc). That won't change even if you are using a template system. If you have to deal with a templating system, you'll have to learn one more language/syntax anyway, with the downside that the new syntax will only work in one specific situation for one specific purpose while shielding you even from tangential learning. It's like trying to learn a new language by starting with its many frameworks. It's just bad coding hygiene. By going straight to the source language for the template language to learn the simple basics required for templating you have the same learning curve than learning the syntax for a template engine, with the upside that this knowledge is much more useful, for it's non specific. It's useful tangential learning that will help the coder to understand the system better and code better. It's much more useful knowledge for everyone, on the same effort level.
If you're starting from point 0 (you only know HTML/CSS), there is not going to be much difference between learning to use
Code Select
if (count($records) === 1)
I have one record!
elseif (count($records) > 1)
I have multiple records!
else
I don't have any records!
for ($i = 0; $i < 10; $i++)
The current value is {{ $i }}
or
Code Select
if (count($records) === 1):
I have one record!
elseif (count($records) > 1):
I have multiple records!
else
I don't have any records!
endif;
for ($i = 0; $i < 10; $i++):
The current value is {{ $i }}
endfor;
or
Code Select
@if (count($records) === 1)
I have one record!
@elseif (count($records) > 1)
I have multiple records!
@else
I don't have any records!
@endif
@for ($i = 0; $i < 10; $i++)
The current value is {{ $i }}
@endfor
or
Code Select
{% if 'Fabien' starts with 'F' %}
{% endif %}
{% if 'Fabien' ends with 'n' %}
{% endif %}
{% for box in boxes %}
{{ include('render_box.html') }}
{% endfor %}
(I actually meant to say Blade seems the most interesting in my first post. I don't even know how the last example would look like for Twig, so it would be one more needless learning curve)
And if you already know some other language before you start, you should already be familiar with the concepts involved (even JS has them), and you only need to get used to PHP syntax. Then it will be one more tool you can throw in your pocket, even if you learn just enough to handle the templates.
You say it is pretty easy to pick up these languages, so why would it be any different for picking up the basics of PHP, when they are so similar? True, most people dealing only with themes and templates are not interested in learning actual programming, or being PHP masters, and that is fine, but they should still put some effort into learning the bits that they have to deal with. Remember, we are talking about people who will be editing or building templates (maybe even changing or adding functions) for a complex forum software, by default, this is not something for everyone. If someone is not willing to learn these basics to be able to build themes, why should that be any of our concern? Nothing stops those with less knowledge on sticking with simple edits and css only, but if you are going to dwelve into the templates, you have to know more than that.
The main problem in PHP for templates is that there is no native support to a decent way of printing HTML. Yes, echo/print syntax are bad for templates. Heredocs comes close, but still has it's drawbacks. I find it odd that there doesn't seem to be any plans to fix that, I spent some days looking into this and not even syntax packages for some popular editors exist to ammenize the problem (highlight content inside strings), despite numerous requests. People go for alternate syntaxes/templating tools instead, as a "fix". Using the shorthand <? ?> tags is a very popular alternative, but unless you have very little PHP to use, it only makes things even worse.
But just like some of these templating tools themselves do, there is nothing in the way of just building something to fix that. And it doesn't need to change the entire system just to fix one problem. Just go straight at the source of it.
Some further specific responses:
Quote from: 青山 素子As for learning how the system works, most mature things aren't so involved. I don't have to know how a CPU works at the component level to operate one. I don't have to understand crankshafts to drive a car. I certainly don't have to know how thermisters work to adjust the darkness level on my toaster. Why should I have to learn structural engineering to paint my house walls a new color?Reductio ad absurdum. I'm not asking template makers to know how the database or all of the forum's back end works.
Quote from: 青山 素子That particular comment you quoted was referring to:Quote from: Gwenwyfar on October 08, 2017, 05:23:32 PMYou most certainly can separate them and make the code look nice. The backend code makes the effort to pick the right template files, get the processing done, and set all the strings up for use. Then it calls the templating engine to combine the strings and the design. Both sides look very clean and there's a good separation of the logic and the design.QuoteThis is why you separate them.You can't separate them if you have to both write the code and make said code look nice :P
"I'd love to see how their code looks like, doing something that looks nice and it actually being good code are often two very different things."
You can't separate HTML/CSS(in some cases JS) from the end result.
Quote from: 青山 素子Are you actually trying to gatekeep? Are you actually saying "unless you know PHP at an expert level, we don't want your kind"?Not at all, as explained above. Do note that I'm in favor of supporting sass in the next SMF version, because it both adds more tools to themers who know it (or are willing to learn), allows those who don't to continue writing plain css, and helps your average user to edit the themes themselves by simply editing variables. Not everyone has to know everything, but if you are going to build something, you should know about said thing.
Quote from: 青山 素子Also, if you're worried about having to learn multiple languages why are you not concerned about PHP coders having to learn CSS and JS?You miss the point if you think so.
Quote from: 青山 素子As for themes that don't work well, that's more the problem of the HTML/CSS/JS the theme author used than an issue with a templating engine. If the author loads down a theme with a ton of poorly-written JS and a lot of third party JS libraries, and then adds broken HTML on top of that, it's going to run awful no matter if it's expressed in a template engine or in the PHP mess of logic and design. In fact, it just might be worse in the current SMF style because of all the access to the raw PHP that can be abused.And the reason there are there so many sites with bloated JS/Jquery in the first place is because no one is willing to put any effort into doing it the correct way, for so many of these features that may not even need JS at all. Or they don't even bother learning proper JS and make a mess out of it, by just throwing a lot of frameworks into the mix of poor code.
Quote from: 青山 素子The MVC concept in which having a separate clean template layer exists has been around since the late 1970s. The use of that pattern in web development exploded in the late 1990s and early 2000s after it became clear that it was a good model. It can speed development because the people working on the UI don't need to wait for back-end work to be complete and the back-end coders don't need to wait for the UI to expose new values. It can let you easily have different templates for different views without having to change a bunch of inline PHP code. Make a mobile-friendly template without having to change the executed PHP. Anything that makes SMF development faster and makes it easier to contribute to SMF is a big win in my opinion.That just goes back to the point: What can these templating systems do that can't be done in plain PHP? What in PHP stops you from keeping things separate and organized? How is using the templating systems (without any other changes) going to fix this?
And regarding alternatives, this is what I have found so far:
Conditional statements are not supported inside heredocs, but you can still use them with a simple function defined beforehand. According to what I saw this should work fine on any php > 5.3. Alongside the rest of heredoc syntax, you would be able to do something such as:
Code Select
echo <<<HTML
<body id="{$id}">
$if(!empty($island), $island, 'No land in sight, lads!')
</body>
HTML;
This also properly highlights HTML (or JS) in most editors, but still has the problem of heredoc ugliness. It would be better than many convoluted echos, but not ideal. You could run a script/function to simply fix the indentation (at least one already exists), so you can do:
Code Select
echo <<<HTML
<body id="{$id}">
$if(!empty($island), $island, 'No land in sight, lads!')
</body>
HTML;
Or, if you're already going to need to process it anyway, change it to something such as:
Code Select
echo {
<body id="{$id}">
$if(!empty($island), $island, 'No land in sight, lads!')
</body>
};
(Side note: Do they accept new function suggestions over in the PHP development? I'm surprised a language supposedly focused towards web development still has nothing of the sort)
Maybe there is some limitation to this that I'm not aware of (after all I'm no PHP master either), but even if there is you should be able to use the normal echo syntax in the final code instead. This would also cut down on all the conversion work needed with other systems (though I don't know if this would mean more or less work at the end of the day).
These last examples would also need a language package for editors to highlight properly, but even this isn't too complicated to do. I have already gotten some success trying to highlight strings in sublime:
Again, I could be missing something here, but so far I still see no reason to use a complete templating system such as the ones proposed.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Suki on October 12, 2017, 03:04:53 PM
Post by: Suki on October 12, 2017, 03:04:53 PM
Quote
Again, I could be missing something here, but so far I still see no reason to use a complete templating system such as the ones proposed.
The huge list of template engines (not only in PHP) obeys to this and only this reason: Themers.
Themers are as stubborn as they can get. Some actively refuse to learn anything that remotely resembles backend. Some truly believe frontend is everything and should be above everything else. When someone is forced to deal with this kind of narrow minded approach, a new template engine is born :P
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Gwenwyfar on October 12, 2017, 03:09:57 PM
Post by: Gwenwyfar on October 12, 2017, 03:09:57 PM
Quote from: Suki on October 12, 2017, 03:04:53 PMWell, it's their loss. I don't think it's a mentality we should be fostering around here.Quote
Again, I could be missing something here, but so far I still see no reason to use a complete templating system such as the ones proposed.
The huge list of template engines (not only in PHP) obeys to this and only this reason: Themers.
Themers are as stubborn as they can get. Some actively refuse to learn anything that remotely resembles backend. Some truly believe frontend is everything and should be above everything else. When someone is forced to deal with this kind of narrow minded approach, a new template engine is born :P
Also: who makes said template engines and everything else they use? ;D
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Suki on October 12, 2017, 03:17:50 PM
Post by: Suki on October 12, 2017, 03:17:50 PM
Quote from: Gwenwyfar on October 12, 2017, 03:09:57 PM
I don't think it's a mentality we should be fostering around here.
Me neither. But I do want to help out those themers who want to keep on improving themselves and a template engine does make the learning curve easier for them. Yes, they will still have to learn a lot of logic and syntax but a token system is more friendly for them than hitting them with a pure php file.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Gwenwyfar on October 12, 2017, 03:47:29 PM
Post by: Gwenwyfar on October 12, 2017, 03:47:29 PM
Quote from: Suki on October 12, 2017, 03:17:50 PMI agree, the templates do need to be more friendly overall, but I believe that can be done without these templating systems. I don't think they add any more value to what can be done without them. In the end you have people who already know PHP having to learn another language that is not very useful, while those that do not, miss out on learning something much more beneficial/useful.Quote from: Gwenwyfar on October 12, 2017, 03:09:57 PMMe neither. But I do want to help out those themers who want to keep on improving themselves and a template engine does make the learning curve easier for them. Yes, they will still have to learn a lot of logic and syntax but a token system is more friendly for them than hitting them with a pure php file.
I don't think it's a mentality we should be fostering around here.
Ex: Reorganize all of the templates (including rewriting some so they don't repeat the same piece of html multiple times), document/comment all the files, move any overly complex PHP that is not related to the presentation outside of them (many of those very long if statements come to mind, they could be elsewhere and send the simplified result), etc.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Suki on October 12, 2017, 05:19:01 PM
Post by: Suki on October 12, 2017, 05:19:01 PM
Yep, reorganize the templates, re use components, extend them, this all are wonderful ideas we should implement :)
Besides helping themers theres also some plus about using a template, twig for example, using it will automatically give us all the improvements we need plus opening to the large pool of themers/designers that are already familiar with twig and could potentially create some good themes for SMF.
Combine that with some other benefits:
As a modder: more tools to play with. less file edits, less support.
As an SMF dev: not having to write a template engine (or re-do the current one) means more time to do/focus on other stuff.
As an SMF team member: more people will use SMF
As an SMF themer: themes will be easier to make
As a complete extranger to the SMF ecosystem: having a familiar face (twig) will make it easier for me to jump in and colaborate.
So, in overall, and I do mean looking at the whole big picture, a template engine makes sense.
I forgot to mention, an SMF themer learning twig/blade/whatever template means s/he will be able to theme for other platforms since the logic remains the same no matter what backend its ben used.
Besides helping themers theres also some plus about using a template, twig for example, using it will automatically give us all the improvements we need plus opening to the large pool of themers/designers that are already familiar with twig and could potentially create some good themes for SMF.
Combine that with some other benefits:
As a modder: more tools to play with. less file edits, less support.
As an SMF dev: not having to write a template engine (or re-do the current one) means more time to do/focus on other stuff.
As an SMF team member: more people will use SMF
As an SMF themer: themes will be easier to make
As a complete extranger to the SMF ecosystem: having a familiar face (twig) will make it easier for me to jump in and colaborate.
So, in overall, and I do mean looking at the whole big picture, a template engine makes sense.
I forgot to mention, an SMF themer learning twig/blade/whatever template means s/he will be able to theme for other platforms since the logic remains the same no matter what backend its ben used.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Gwenwyfar on October 16, 2017, 06:34:21 AM
Post by: Gwenwyfar on October 16, 2017, 06:34:21 AM
If you need to convert the whole thing and change all of the templates, how would that be automatic? Someone will also need to convert the entire thing, so it may not exactly be a time saver either.
I maintain my previous points for everything else. Having more people just for the sake of more diversity/popularity is not the way to do. This would be akin to just adding a lot of popular backend frameworks "because a lot of people use them and they are easy to manage".
I maintain my previous points for everything else. Having more people just for the sake of more diversity/popularity is not the way to do. This would be akin to just adding a lot of popular backend frameworks "because a lot of people use them and they are easy to manage".
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Suki on October 16, 2017, 11:53:50 AM
Post by: Suki on October 16, 2017, 11:53:50 AM
You're not thinking fourth-dimensionally!" Marty :P
The version after 2.1 is going to be around for a long time, we need to think at long term and, as already pointed out, this decision involves much more things than just back and frontend.
As a dev, core dev, pm or whatever label you want to wear, you need to take all these angles into account. And there are quite a few.
Yes, the current template will have to be converted. That will still happen regardless of what template engine SMF uses. So, if the current template are still going to be changed, why not go for a real template engine? same work, lots of advantages.
Besides, I can guarantee you that if SMF choses to re-do the current template system it will end up pretty similar to current already available ones. With the disadvantage of taking a lot more time, resources and work to do it. Time and resources are pretty value stuff in SMF ;)
And no, a lot of people happen to make the mistake of using a framework for the sake of using it. They don't really care whats behind it, why and/or how it do the things it does. Thats a terrible mistake.
For a framework to really be usable you need to first understand whats behind it, adapt it to your needs and use it like it is, a tool.
So no, a template engine is not going to be used for the sake of using it or because lots of other people uses it, those are perks that come with it but aren't the main points behind it.
The first time I proposed a framework for SMF I saw some resistant, mainly because it was assumed a framework will "eat out" SMF completely, when in fact a framework is nothing more than a tool you bend and use to your needs, not the other way around.
I don't want to sound cocky or bragging about it but after spending quite a bit of time around here I know the ins and outs of SMF, not only the code but its structure and environment too, all the things I had proposed in the past are a direct result of all those years. Same applies for Arantor.
BTW, I fully understand your point about "doing the right way" and under other circunstances I would had agreed with you.
The version after 2.1 is going to be around for a long time, we need to think at long term and, as already pointed out, this decision involves much more things than just back and frontend.
As a dev, core dev, pm or whatever label you want to wear, you need to take all these angles into account. And there are quite a few.
Yes, the current template will have to be converted. That will still happen regardless of what template engine SMF uses. So, if the current template are still going to be changed, why not go for a real template engine? same work, lots of advantages.
Besides, I can guarantee you that if SMF choses to re-do the current template system it will end up pretty similar to current already available ones. With the disadvantage of taking a lot more time, resources and work to do it. Time and resources are pretty value stuff in SMF ;)
And no, a lot of people happen to make the mistake of using a framework for the sake of using it. They don't really care whats behind it, why and/or how it do the things it does. Thats a terrible mistake.
For a framework to really be usable you need to first understand whats behind it, adapt it to your needs and use it like it is, a tool.
So no, a template engine is not going to be used for the sake of using it or because lots of other people uses it, those are perks that come with it but aren't the main points behind it.
The first time I proposed a framework for SMF I saw some resistant, mainly because it was assumed a framework will "eat out" SMF completely, when in fact a framework is nothing more than a tool you bend and use to your needs, not the other way around.
I don't want to sound cocky or bragging about it but after spending quite a bit of time around here I know the ins and outs of SMF, not only the code but its structure and environment too, all the things I had proposed in the past are a direct result of all those years. Same applies for Arantor.
BTW, I fully understand your point about "doing the right way" and under other circunstances I would had agreed with you.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Gwenwyfar on October 16, 2017, 05:15:45 PM
Post by: Gwenwyfar on October 16, 2017, 05:15:45 PM
The whole problem is that these "advantages" are not really true advantages and some are even disadvantages. Using a templating engine does not come without consequences.
QuoteBesides, I can guarantee you that if SMF choses to re-do the current template system it will end up pretty similar to current already available ones.If it gets too similar it will just have the same problems, except you also have to build it. From that standpoint, you are right that it is not worth it to build one, if it ends up being just as bad.
QuoteSo no, a template engine is not going to be used for the sake of using it or because lots of other people uses it, those are perks that come with it but aren't the main points behind it.What is the main point, then? We're just going in circles here, my main points are still there and still haven't been addressed, just avoided.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Kindred on October 16, 2017, 05:42:56 PM
Post by: Kindred on October 16, 2017, 05:42:56 PM
I think that your points were actually addressed you just don't happen to agree with the statements they made to address them. Both Arantor and Suki have valid points about a core system and a templating system being an improvement and it's not an issue of using a system for the sake of having a system but as pointed out using a system as a new core and being able to build around it and take the bits you need from it without having to rebuild from scratch
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Arantor on October 16, 2017, 06:04:22 PM
Post by: Arantor on October 16, 2017, 06:04:22 PM
Instead of talking in hypotheticals, let's talk in actuals.
I have a fork of SMF. Anyone who cared to look this up on GitHub would see this. This is fine, it has a very different purpose to SMF and has absolutely no plans to go in any way mainstream.
Pretty much the first major thing we did was start to tear out the template system as it currently is.
Why? Because the majority of people aren't PHP people. They're people who come from Node land, and are used to Handlebars templates. They even did a fair amount of the conversions away from PHP to Handlebars - and this is not perfect right now, but the bulk of it is done.
It means we simplify all the logic around templates as far as users are concerned. Modding gets simpler, because you can target the mod code so much more easily should you want to, because instead of navigating around the PHP syntax, you can just handle the HTML itself - which would have solved a lot of the 2.0.14 login problem without resorting to buffer manipulations had it been available.
We can and do reuse code without having to remember which template it's in and whether it's already been loaded. We're also going to refactor all the language stuff away so that's also easier to use.
And you know what helped? I work with Handlebars at work when I write Moodle stuff. You make the argument that it's all just PHP - but honestly, the minute you start intermixing JavaScript behaviours with it, you really want to simplify the logic. Templates with a real template engine help with that - and I got to reuse what I'd learned about writing templates for Moodle in my own stuff.
Rigidly sticking to the mindset of 'what we have is good enough' is a guarantee for stagnation. It *may* be true that what you have is best, but every argument I've seen here is deflection.
Why not actually *try* it? Why not actually play with a system that does templating this way and get a feel for how well it works or doesn't work, rather than writing it off based on hypothetical costs?
Yes, the conversion is a cost. It's also largely a one time cost you pay whenever the version after 2.1 is done, if it's done for that (which I'd recommend)
Your repeated arguments about barrier to entry are logical fallacies for one, elitist and arrogant for two, and for a third, I think you misunderstand the user base.
The average SMF admin isn't you. They're not developers. Scraping by on HTML is possibly the upper edge of the average admin's skill set. Making them jump through 1.5 languages (HTML/Handlebars) is definitely nicer than juggling PHP/HTML, and the reality is that you actually don't have to lose any flexibility if you don't want to.
I have a fork of SMF. Anyone who cared to look this up on GitHub would see this. This is fine, it has a very different purpose to SMF and has absolutely no plans to go in any way mainstream.
Pretty much the first major thing we did was start to tear out the template system as it currently is.
Why? Because the majority of people aren't PHP people. They're people who come from Node land, and are used to Handlebars templates. They even did a fair amount of the conversions away from PHP to Handlebars - and this is not perfect right now, but the bulk of it is done.
It means we simplify all the logic around templates as far as users are concerned. Modding gets simpler, because you can target the mod code so much more easily should you want to, because instead of navigating around the PHP syntax, you can just handle the HTML itself - which would have solved a lot of the 2.0.14 login problem without resorting to buffer manipulations had it been available.
We can and do reuse code without having to remember which template it's in and whether it's already been loaded. We're also going to refactor all the language stuff away so that's also easier to use.
And you know what helped? I work with Handlebars at work when I write Moodle stuff. You make the argument that it's all just PHP - but honestly, the minute you start intermixing JavaScript behaviours with it, you really want to simplify the logic. Templates with a real template engine help with that - and I got to reuse what I'd learned about writing templates for Moodle in my own stuff.
Rigidly sticking to the mindset of 'what we have is good enough' is a guarantee for stagnation. It *may* be true that what you have is best, but every argument I've seen here is deflection.
Why not actually *try* it? Why not actually play with a system that does templating this way and get a feel for how well it works or doesn't work, rather than writing it off based on hypothetical costs?
Yes, the conversion is a cost. It's also largely a one time cost you pay whenever the version after 2.1 is done, if it's done for that (which I'd recommend)
Your repeated arguments about barrier to entry are logical fallacies for one, elitist and arrogant for two, and for a third, I think you misunderstand the user base.
The average SMF admin isn't you. They're not developers. Scraping by on HTML is possibly the upper edge of the average admin's skill set. Making them jump through 1.5 languages (HTML/Handlebars) is definitely nicer than juggling PHP/HTML, and the reality is that you actually don't have to lose any flexibility if you don't want to.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Suki on October 16, 2017, 06:29:50 PM
Post by: Suki on October 16, 2017, 06:29:50 PM
Quote
What is the main point, then? We're just going in circles here, my main points are still there and still haven't been addressed, just avoided.
I already told you but you still chose to focus solely on one aspect of the whole thing.
This goes beyond all of that. WE are talking about the next mayor SMF version. we are talking about 10, 20 years into the future. needs planning, serious planning. Needs vision, needs doing actual software architecture (https://en.wikipedia.org/wiki/Software_architecture).
Thats reason enough to completely discard the whole raw PHP approach.
Some more reasons:
As a former dev I can tell you raw PHP is more difficult to maintain. No matter how structured you think you can do it.
As a former PM I can tell you raw PHP makes the software more difficult to coordinate. In all aspects, from themes to I18n, upgrades, updates. Etc.
As a former modder, having to modify template files is a real pain in the posterior, both build and support.
AS a former support specialists I can tell you a good chunk of support questions comes from people wanting to directly modify the template files but cannot do so because they are scared away by having to look at raw PHP vars. This are plain regular users, not themers.
As a freelancer who has actually used and implemented template engines on a few projects, they indeed helped me to built better code, faster.
So really, belive us when we tell you using a template engine is whats best for SMF. :)
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Gwenwyfar on October 16, 2017, 06:56:09 PM
Post by: Gwenwyfar on October 16, 2017, 06:56:09 PM
Quote from: Kindred on October 16, 2017, 05:42:56 PMNope, they haven't.
I think that your points were actually addressed you just don't happen to agree with the statements they made to address them. Both Arantor and Suki have valid points about a core system and a templating system being an improvement and it's not an issue of using a system for the sake of having a system but as pointed out using a system as a new core and being able to build around it and take the bits you need from it without having to rebuild from scratch
@Arantor: I could just repeat my above post here, it seems you too, miss the point. I could also once again ask the same question: Where is a templating system a requirement for most of these things you say are better with it?
But if it helps at all to put things differently, imagine if we were talking about back end instead, and add all your same arguments there.
Also, since we're going to start pulling the cheap rhetorical Experience Card, I have been on the front-end field for over 7 years, many of which professionally. I have seen up close how "great" these systems are and what kind of community they create, and that is exactly the reason I have decided to partipate on SMF and exactly why I don't want it to follow the same fate. SMF community and code is golden compared to most things I see out there. I'm not talking out of my ass.
QuoteSo now we are talking about average admins? That is quite a long distance from themers.
The average SMF admin isn't you. They're not developers. Scraping by on HTML is possibly the upper edge of the average admin's skill set. Making them jump through 1.5 languages (HTML/Handlebars) is definitely nicer than juggling PHP/HTML, and the reality is that you actually don't have to lose any flexibility if you don't want to.
Do you hear yourselves on what you're all suggesting? You're speaking about removing basic PHP knowledge and handling on theming a PHP Forum. "Why?", "Well it's easier and everyone else is doing it too". It's is getting to the point of absurdity.
Next, we should make sure everyone can edit the back end code with ease, knowing the code for the area you are dealing with is overrated.
QuoteYour repeated arguments about barrier to entry are logical fallacies for one, elitist and arrogant for two, and for a third, I think you misunderstand the user base.Curiously unnamed fallacies so far. And probably very stretched ones.
On a side note, for most people who have been here for a long time, you complaining about elitism and arrogance looks like the kettle speaking ill of the pot.
For a man who seemed to live on the mantra of quality over quantity, you seem quite desperate on this point.
@Suki
Raw PHP is what makes the forum work. You're not overwriting it, you're just putting a shiny cover over it. Framework like setups makes it easier to code and read, while sacrificing debugging and efficiency. It's why all softwares are getting more bloated by the minute everywhere. Antes' point is also valid here, if you are going to start adding frameworks, then why stop there? Why not go and use all of the ones that "can be useful"? And from there you just become the same as everyone else, since, again, why stop there? Just go and become "one more forum doing frameworks and whatnot".
And for everyone who thinks I'm being too aggressive... I tried to be calm and everyone avoided addressing my points or even answering genuine questions, so I'm just doing the same.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Suki on October 16, 2017, 07:24:02 PM
Post by: Suki on October 16, 2017, 07:24:02 PM
Quote
Raw PHP is what makes the forum work. You're not overwriting it, you're just putting a shiny cover over it
Following your logic, SMF is just a shiny cover over PHP... and PHP is just a shiny cover over C... and C is just a shiny cover over machine code... we shouldn't be using GUIs since they are just shiny covers for terminals... we shouldn't be using OSs as they are just shiny covers for binary code...
What you don't understand is that PHP isn't remotely the baseline, its merely a tool another tool uses to communicate with more tools...
Quote
Framework like setups makes it easier to code and read, while sacrificing debugging and efficiency.
Absolutely no. This statemant right here tell me you haven't really tried a framework before. A well structured code under a framework is way more easy to debug than what we currently have. AS a live example, my personal site is a combination of a blog and a forum, took 3 months to build from the ground and I'm currently implementing unit test to the whole site. Something I can't do with SMF.
Some frameworks DO actually help with performance, take a look at phalcon, a PHP framework writting in C.
Also, and this is something you also don't seem to understand, SMF IS a framework in itself.
Quote
Antes' point is also valid here, if you are going to start adding frameworks, then why stop there? Why not go and use all of the ones that "can be useful"? And from there you just become the same as everyone else, since, again, why stop there? Just go and become "one more forum doing frameworks and whatnot".
This statement tells me you really haven't read all the things I've been saying.
No, like I already told you and Antes before you, using a framework doesn't mean you will become "just like everyone else" A framework is just a tool.
Lets use a practical example, a hammer, a hammer is a tool you can use to build a house. Does that mean all the houses built with a hammer are equal? NO you use the tool as you see it fits and nothing else.
SMF won't lose anything that makes it what it is.
But hey! everything I write seems to fall on deaf ears, you aren't actually reading anything we have been saying. I can write actual movie quotes and you will still focus on what you think you know and nothing else. Unless you truly want to have a proper argument, one were you actually accept the other side point of view, it is futilie to keep on with this.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Gwenwyfar on October 16, 2017, 10:32:17 PM
Post by: Gwenwyfar on October 16, 2017, 10:32:17 PM
QuoteFollowing your logic, SMF is just a shiny cover over PHP... and PHP is just a shiny cover over C... and C is just a shiny cover over machine code... we shouldn't be using GUIs since they are just shiny covers for terminals... we shouldn't be using OSs as they are just shiny covers for binary code...Quite the assumptions you make on my own knowledge there.
What you don't understand is that PHP isn't remotely the baseline, its merely a tool another tool uses to communicate with more tools...
The ruling principle over language levels is simple: "the higher the level of abstraction, the lower the performance." The choice between one level of abstraction or another are always dependant on what kind of sacriffices you want to make on performance, debugging, control over portability, easiness to write and read. It's a question of balance.
Yes, PHP is already on an level of abstraction above C since it is an interpreter language. Why put one more level abstraction on top of that? It's quite efficient at what it does while even granting you control over its low level (you can actually code Assembly in PHP by making a C Extension for it, for example. If you want to sacrifice portability even further, you can actually move bits around using C bit operators).
My whole point is that by putting one more level of abstraction over PHP on the front end you will actually have a worse coder culture around it since fewer and fewer people will bother to know what is going on under the hood, and on long term you will have increasingly bad code because of it. That's what happens when you introduce a higher level of abstraction in critical sections of your code in a large scale. We already have to deal with stupid WYSIWYG front-end code, you put one more level of abstraction on top of that and the amount of dumb codes will just ten fold as time goes on.
QuoteAbsolutely no. This statemant right here tell me you haven't really tried a framework before. A well structured code under a framework is way more easy to debug than what we currently have. AS a live example, my personal site is a combination of a blog and a forum, took 3 months to build from the ground and I'm currently implementing unit test to the whole site. Something I can't do with SMF.Stretching the concept of frameworks quit a bit aren't we? Frameworks started as simple custom user libraries for one given language, a common occurrence when one language can have many uses in completely different fields... So you make custom functions made specifically to work efficiently in a given task for a given field. That's what frameworks were originally meant to be and that's its efficient use.
Some frameworks DO actually help with performance, take a look at phalcon, a PHP framework writting in C.
Also, and this is something you also don't seem to understand, SMF IS a framework in itself.
What we have today however is a complete change of syntax for calling "jack of all trades, master of none" functions so the functions can be used in as many diffferent fields as possible, adding layer upon layer of abstraction to the point of becoming a different language (Which it should have been to begin with). The framework focus is completely reversed from efficient handcrafted specific functions to just one more layer of abstraction for easiness to write and read. Making the work of developer easier by making him even more distant from the actual code while making the life of the user worse (on long term, bugs start stacking up and performance gradually goes down).
So far, none of these concerns have been addressed, all the answers were on the lines of "Well, yeah, but... highlights/less work/popular/everyone is doing it/you're too elitist!"
QuoteBut hey! everything I write seems to fall on deaf ears, you aren't actually reading anything we have been saying. I can write actual movie quotes and you will still focus on what you think you know and nothing else. Unless you truly want to have a proper argument, one were you actually accept the other side point of view, it is futilie to keep on with this.Sorry to disappoint, but I don't watch too many movies and have no idea where your quote comes from.
So you answer my entire post with three lines, multiple direct questions go ignored, but I'm the one to blame for deaf ears? Funny that.
So far only 青山 素子 actually tried to address my points (thanks for that).
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Arantor on October 17, 2017, 03:55:27 AM
Post by: Arantor on October 17, 2017, 03:55:27 AM
The reason that I 'change my argument' is so that I can try to find some way to make it relatable since at every turn you've thrown back strawman arguments, though I doubt you realise they are strawmen.
The thing that kills me, though, is that you're actually becoming me at a faster rate than I hoped for. Don't be like me.
Breakdown of logical fallacies:
* slippery slope: if we adopt x, why shouldn't we also adopt y, z, a? Especially not what was suggested, let alone on the table. Though I do know use of Symfony was discussed for 3.0 some time ago. As pointed out, SMF is a framework in its own right because the definition of framework is very nebulous at this point. Sure, you can have SMF without a framework, it just won't do anything.
* slippery slope: barrier to entry. The assertion that it will lower quality of work. Maybe it will. Maybe it won't. People will always find ways to do stupid things. But you know what is worse than a platform that enables people to do things? A platform no-one cares about because everyone else has made it easier for them to do things.
* ad-hominem: attacking me rather than attacking my arguments (I later merely started reflecting what I saw)
* slippery slope: layers of abstraction. Yes, as a general rule fewer layers of abstraction make it faster, but the opposite argument stands: if performance is a consideration, maybe Asm32 (https://asm32.info/fossil/repo/asmbb/index) should be the platform of choice. Ditto for customisation - after all, there's absolutely no levels of abstraction involved there, you have the power to literally do anything the machine can do. Except this is also a slippery slope in itself, elitist yada yada yada.
* strawman: templating system is not a framework, it is a component, and every argument about using components vs frameworks is targeting the overall framework vs current platform as framework.
Yes, there's a performance consideration, however modern template engines are the product of quite a few years of meta programming at this point and most of the time, they end up compiling to something very similar to what the hand rolled PHP might look like, especially if the time has been taken to simplify the template in the first place. Right now with the templating system work we've done in StoryBB, the templates that are cached run approximately 0.02% slower than the original PHP forms. In reality I've taken a much larger hit in StoryBB with the subaccounts system we have.
Yes, there's a potential quality impact. But looking at what has actually happened out in the real world in the use of these systems, themers and modders haven't made anything worse than they would already have made in PHP, just they had to work harder at it to make PHP.
Yes, there's a possible flexibility issue. Or at least, there is if you're assuming how templating systems work and you're trying to fit SMF's code directly into a templating engine without thinking it through. There are lots of weird things SMF does in its templates that shouldn't be in the templates, and there are things it does that should be in the templates but aren't. This is the result of not abstracting things away in a higher level plan fashion, partially because at the time it was built, abstractions were a luxury that couldn't really be afforded the way they can now. You can make the argument about performance here too, but there are things that exist in the ecosystem now that didn't exist then that largely mitigate that angle too (and out of the box, actually made worse by SMF's behaviour than not, e.g. template eval which not only hurts debugging everywhere, it also rules out any use of the opcode cache)
Yes, I could even be behind the fact that there can be a debugging issue. Is the issue with the template engine or is it with the template? Every time I've asked this question, I've found the problem is not the engine, but me trying to use it incorrectly to do something clever rather than doing it the logical, simpler way. And the times it's been an issue e.g. I've forgotten a brace somewhere, the engine I picked doesn't help me as much as I'd like. But this is a symptom of picking a specific implementation of an engine that isn't as friendly as it could be, not a symptom of the whole problem. It's also one that I haven't seen much in practice across the various ecosystems I haven't seen. And in reality it's a variation on the 'fun' of programming in PHP in templates where I use a comma instead of a period between things because of operator precedence in echo statements (because that's not easy to get into in practice when you're doing inline ternaries), or I mismatch braces.
The 'one syntax for another' argument is interesting. Let me reframe the situation, maybe it'll help you understand my perspective: why does TypeScript exist? what about CoffeeScript? These things literally do nothing that JavaScript can't do (because they compile down to JavaScript), but people like them because they abstract away some of the really annoying things in the underlying language. That's all that's going on here, really.
The kicker though, is that this debate reminds me of me. Everything I see in this debate echoes me, and this isn't a good thing. It makes me begin to question how much of a force I personally have been for good in this environment, and makes me think that my naive idealisms over the years have encouraged others to do the same - and I'm not convinced in some of those positions of argument that I was right. There was certainly a time when I argued against frameworks as a whole, and certainly a time when I argued against template engines, too. I find a lot of the same old issues, though, an over-cautious conservatism at a time when the entire fleet of platforms in the forum space are routinely castigated for failure to innovate, and it's harder to drive innovation on any level when the platform decides it wants a barrier to entry for even modest things like putting something to the screen. It's the same reason we don't use C to build a forum, we like having the abstractions. I'm just arguing for one more abstraction because it feels like it benefits everyone.
The key things I was trying to address, and I appear to have confused people in trying to explain:
* people who are admins who want to do simple customisations of their own - these people aren't programmers, they just want to insert the bit of JavaScript for Google Analytics by copy and paste like GA tells them to, except surprise, they have to figure out quoting syntax. Or the people who just want to tweak a little bit like the header. They're then dealing with what amounts to mostly HTML and CSS, as opposed to PHP, actual HTML and CSS - and all evidence suggests that people find this easier to do simple changes. There's a reason people like the theme stuff in XenForo and IPB - it lets them make little changes without any hassle. They feel empowered, they feel like they can own something even though they're not technical. Not every SMF admin is a programmer or a designer.
* people who are theme people get to play with something closer to what they normally use rather than stepping through hoops. Yes, it means people can do stupid things more easily - but at the same time, it lets people who know the tools do so without having to remember to escape quotes. And people will always do stupid things, this shouldn't be a barrier to making tools easier for non-stupid use cases.
* when I build Moodle plugins, even though I'm not even required to use the template system because Moodle doesn't mandate it (because Moodle doesn't use it itself for most of its plugins for historical reasons), most clients are requesting it so they can have a designer customise it without knowing Moodle's code innards. And Moodle certainly has PHP 'templates' in its core in the renderer system. Though that's a level of mind-killer with its many classes and layers of abstraction that I wouldn't impose upon anyone. But I digress - designers are the people who would like this.
Also, on an ironic note, this debate somehow ended up talking about C. Who remembers the doomed project smflib, that reimplemented bits of SMF as C so they would be PHP extensions for the really really big forums? I do...
The thing that kills me, though, is that you're actually becoming me at a faster rate than I hoped for. Don't be like me.
Breakdown of logical fallacies:
* slippery slope: if we adopt x, why shouldn't we also adopt y, z, a? Especially not what was suggested, let alone on the table. Though I do know use of Symfony was discussed for 3.0 some time ago. As pointed out, SMF is a framework in its own right because the definition of framework is very nebulous at this point. Sure, you can have SMF without a framework, it just won't do anything.
* slippery slope: barrier to entry. The assertion that it will lower quality of work. Maybe it will. Maybe it won't. People will always find ways to do stupid things. But you know what is worse than a platform that enables people to do things? A platform no-one cares about because everyone else has made it easier for them to do things.
* ad-hominem: attacking me rather than attacking my arguments (I later merely started reflecting what I saw)
* slippery slope: layers of abstraction. Yes, as a general rule fewer layers of abstraction make it faster, but the opposite argument stands: if performance is a consideration, maybe Asm32 (https://asm32.info/fossil/repo/asmbb/index) should be the platform of choice. Ditto for customisation - after all, there's absolutely no levels of abstraction involved there, you have the power to literally do anything the machine can do. Except this is also a slippery slope in itself, elitist yada yada yada.
* strawman: templating system is not a framework, it is a component, and every argument about using components vs frameworks is targeting the overall framework vs current platform as framework.
Yes, there's a performance consideration, however modern template engines are the product of quite a few years of meta programming at this point and most of the time, they end up compiling to something very similar to what the hand rolled PHP might look like, especially if the time has been taken to simplify the template in the first place. Right now with the templating system work we've done in StoryBB, the templates that are cached run approximately 0.02% slower than the original PHP forms. In reality I've taken a much larger hit in StoryBB with the subaccounts system we have.
Yes, there's a potential quality impact. But looking at what has actually happened out in the real world in the use of these systems, themers and modders haven't made anything worse than they would already have made in PHP, just they had to work harder at it to make PHP.
Yes, there's a possible flexibility issue. Or at least, there is if you're assuming how templating systems work and you're trying to fit SMF's code directly into a templating engine without thinking it through. There are lots of weird things SMF does in its templates that shouldn't be in the templates, and there are things it does that should be in the templates but aren't. This is the result of not abstracting things away in a higher level plan fashion, partially because at the time it was built, abstractions were a luxury that couldn't really be afforded the way they can now. You can make the argument about performance here too, but there are things that exist in the ecosystem now that didn't exist then that largely mitigate that angle too (and out of the box, actually made worse by SMF's behaviour than not, e.g. template eval which not only hurts debugging everywhere, it also rules out any use of the opcode cache)
Yes, I could even be behind the fact that there can be a debugging issue. Is the issue with the template engine or is it with the template? Every time I've asked this question, I've found the problem is not the engine, but me trying to use it incorrectly to do something clever rather than doing it the logical, simpler way. And the times it's been an issue e.g. I've forgotten a brace somewhere, the engine I picked doesn't help me as much as I'd like. But this is a symptom of picking a specific implementation of an engine that isn't as friendly as it could be, not a symptom of the whole problem. It's also one that I haven't seen much in practice across the various ecosystems I haven't seen. And in reality it's a variation on the 'fun' of programming in PHP in templates where I use a comma instead of a period between things because of operator precedence in echo statements (because that's not easy to get into in practice when you're doing inline ternaries), or I mismatch braces.
The 'one syntax for another' argument is interesting. Let me reframe the situation, maybe it'll help you understand my perspective: why does TypeScript exist? what about CoffeeScript? These things literally do nothing that JavaScript can't do (because they compile down to JavaScript), but people like them because they abstract away some of the really annoying things in the underlying language. That's all that's going on here, really.
The kicker though, is that this debate reminds me of me. Everything I see in this debate echoes me, and this isn't a good thing. It makes me begin to question how much of a force I personally have been for good in this environment, and makes me think that my naive idealisms over the years have encouraged others to do the same - and I'm not convinced in some of those positions of argument that I was right. There was certainly a time when I argued against frameworks as a whole, and certainly a time when I argued against template engines, too. I find a lot of the same old issues, though, an over-cautious conservatism at a time when the entire fleet of platforms in the forum space are routinely castigated for failure to innovate, and it's harder to drive innovation on any level when the platform decides it wants a barrier to entry for even modest things like putting something to the screen. It's the same reason we don't use C to build a forum, we like having the abstractions. I'm just arguing for one more abstraction because it feels like it benefits everyone.
The key things I was trying to address, and I appear to have confused people in trying to explain:
* people who are admins who want to do simple customisations of their own - these people aren't programmers, they just want to insert the bit of JavaScript for Google Analytics by copy and paste like GA tells them to, except surprise, they have to figure out quoting syntax. Or the people who just want to tweak a little bit like the header. They're then dealing with what amounts to mostly HTML and CSS, as opposed to PHP, actual HTML and CSS - and all evidence suggests that people find this easier to do simple changes. There's a reason people like the theme stuff in XenForo and IPB - it lets them make little changes without any hassle. They feel empowered, they feel like they can own something even though they're not technical. Not every SMF admin is a programmer or a designer.
* people who are theme people get to play with something closer to what they normally use rather than stepping through hoops. Yes, it means people can do stupid things more easily - but at the same time, it lets people who know the tools do so without having to remember to escape quotes. And people will always do stupid things, this shouldn't be a barrier to making tools easier for non-stupid use cases.
* when I build Moodle plugins, even though I'm not even required to use the template system because Moodle doesn't mandate it (because Moodle doesn't use it itself for most of its plugins for historical reasons), most clients are requesting it so they can have a designer customise it without knowing Moodle's code innards. And Moodle certainly has PHP 'templates' in its core in the renderer system. Though that's a level of mind-killer with its many classes and layers of abstraction that I wouldn't impose upon anyone. But I digress - designers are the people who would like this.
Also, on an ironic note, this debate somehow ended up talking about C. Who remembers the doomed project smflib, that reimplemented bits of SMF as C so they would be PHP extensions for the really really big forums? I do...
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Suki on October 17, 2017, 08:55:04 AM
Post by: Suki on October 17, 2017, 08:55:04 AM
meh... you keep on focus on a single thing and conveniently avoid anything else:
Even though multiple reasons were exposed, you chose to focus solely on this point. You haven't addressed any point about helping development, for example.
There have been arguments about helping themers and helping regular users, you decided each was a separate argument which is not, as I have been saying, this thing AFFECTS everyone, not just you, not just themers.
They aren't assumptions. It is quite clear you haven't used a template engine. It is quite clear you haven't worked on a big project either. All the arguments you try to make were already made a few years ago. Really sorry to say this to you but get on with the times ;)
Yeah... as if it were that simple... this reminds me of those glorious and naive college years when I thought everything was easily solvable and everyone else was wrong.
Thats just theory darling, in the real world things are more complicated that that. This is what I've been trying to say and I will say it again, this stuff is MORE complicated than just frontend and backend.
Have you ever considered the fact that we already took into account balance, performance and abstraction? Again, the chose for using a template engine comes from measuring all those aspects (and others who aren't directly related to programming) and based on all that info we decided a template engine is the best choice.
Absolutely wrong and again this tells me you actually haven't tried a template engine before.
By definition, an engine will keep presentation away from logic, this means heavy logic CANT be performed on a theme file. This actually prevents doing dumb stuff.
Also, you seem to forget what SMF target is..... plain regular users......
Can you please get off your high horse and try to see SMF with the eyes of a regular user? they don't give a fliyin rat ass about how many levels of abstraction we have, they want something easy to use to post their stuff online, thats it.
You aren't the only one who will uses SMF.
You aren't the only one who will theme SMF.
You aren't the only one.
This is yet another thing you conveniently ignore. Whoever gets in charge of building the next version has to take into account all the different types of people who are going to use SMF. From devs to themers to admins to users to hostings.
Yay for missing the point. I was saying I could reply with random text and you will still focus on your ideas. This whole thing was been a big waste of time since you don't really want to have a discussion, all you want to do is showing you are right.
Anyway, back to 2017. It will be good for use to discuss what aspects of X engine can be beneficial for SMF. What engine suits bests. I haven't tried Handlebars, will take a look at it.
And since we are tossing ideas for the next version, what about using Vue components? or React? not talking about using it on the entire codebase but I think using it on key aspects will be a good thing. New topic?
Quote from: Gwenwyfar on October 16, 2017, 10:32:17 PM
So far, none of these concerns have been addressed, all the answers were on the lines of "Well, yeah, but... highlights/less work/popular/everyone is doing it/you're too elitist!"
Even though multiple reasons were exposed, you chose to focus solely on this point. You haven't addressed any point about helping development, for example.
There have been arguments about helping themers and helping regular users, you decided each was a separate argument which is not, as I have been saying, this thing AFFECTS everyone, not just you, not just themers.
Quote from: Gwenwyfar on October 16, 2017, 10:32:17 PM
Following your logic, SMF is just a shiny cover over PHP... and PHP is just a shiny cover over C... and C is just a shiny Quite the assumptions you make on my own knowledge there.
They aren't assumptions. It is quite clear you haven't used a template engine. It is quite clear you haven't worked on a big project either. All the arguments you try to make were already made a few years ago. Really sorry to say this to you but get on with the times ;)
Quote from: Gwenwyfar on October 16, 2017, 10:32:17 PM
The ruling principle over language levels is simple: "the higher the level of abstraction, the lower the performance." The choice between one level of abstraction or another are always dependant on what kind of sacriffices you want to make on performance, debugging, control over portability, easiness to write and read. It's a question of balance.
Yeah... as if it were that simple... this reminds me of those glorious and naive college years when I thought everything was easily solvable and everyone else was wrong.
Thats just theory darling, in the real world things are more complicated that that. This is what I've been trying to say and I will say it again, this stuff is MORE complicated than just frontend and backend.
Have you ever considered the fact that we already took into account balance, performance and abstraction? Again, the chose for using a template engine comes from measuring all those aspects (and others who aren't directly related to programming) and based on all that info we decided a template engine is the best choice.
Quote from: Gwenwyfar on October 16, 2017, 10:32:17 PM
My whole point is that by putting one more level of abstraction over PHP on the front end you will actually have a worse coder culture around it since fewer and fewer people will bother to know what is going on under the hood, and on long term you will have increasingly bad code because of it. That's what happens when you introduce a higher level of abstraction in critical sections of your code in a large scale. We already have to deal with stupid WYSIWYG front-end code, you put one more level of abstraction on top of that and the amount of dumb codes will just ten fold as time goes on.
Absolutely wrong and again this tells me you actually haven't tried a template engine before.
By definition, an engine will keep presentation away from logic, this means heavy logic CANT be performed on a theme file. This actually prevents doing dumb stuff.
Also, you seem to forget what SMF target is..... plain regular users......
Can you please get off your high horse and try to see SMF with the eyes of a regular user? they don't give a fliyin rat ass about how many levels of abstraction we have, they want something easy to use to post their stuff online, thats it.
You aren't the only one who will uses SMF.
You aren't the only one who will theme SMF.
You aren't the only one.
This is yet another thing you conveniently ignore. Whoever gets in charge of building the next version has to take into account all the different types of people who are going to use SMF. From devs to themers to admins to users to hostings.
Quote from: Gwenwyfar on October 16, 2017, 10:32:17 PM
Sorry to disappoint, but I don't watch too many movies and have no idea where your quote comes from.
So you answer my entire post with three lines, multiple direct questions go ignored, but I'm the one to blame for deaf ears? Funny that.
Yay for missing the point. I was saying I could reply with random text and you will still focus on your ideas. This whole thing was been a big waste of time since you don't really want to have a discussion, all you want to do is showing you are right.
Anyway, back to 2017. It will be good for use to discuss what aspects of X engine can be beneficial for SMF. What engine suits bests. I haven't tried Handlebars, will take a look at it.
And since we are tossing ideas for the next version, what about using Vue components? or React? not talking about using it on the entire codebase but I think using it on key aspects will be a good thing. New topic?
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Arantor on October 17, 2017, 10:30:22 AM
Post by: Arantor on October 17, 2017, 10:30:22 AM
Handlebars in its purest form has no inline logic beyond 'this value exists' and 'this value doesn't exist' (while retaining logical support for 'this is an array and I will iterate over it')
We went with Lightncandy which is Handlebars based but can do funky stuff with helpers that Handlebars in its purest form can't (and should't) because we came from SMF where there's a *lot* of inline logic in templates and it's already enough of a job to do something with that. Feel free to take a look at what's going on at GitHub; I certainly wouldn't suggest it's the 'most perfect way' but it's one route to it. (Short version: the key logical components were reimplemented using LnC helpers, to facilitate the most common operations we needed to do. Likely we'll streamline and refine this as time goes on.)
Twig is nice but I find it isn't quite as hands-off syntactically as Handlebars-like things are, which is definitely a thing we wanted.
We went with Lightncandy which is Handlebars based but can do funky stuff with helpers that Handlebars in its purest form can't (and should't) because we came from SMF where there's a *lot* of inline logic in templates and it's already enough of a job to do something with that. Feel free to take a look at what's going on at GitHub; I certainly wouldn't suggest it's the 'most perfect way' but it's one route to it. (Short version: the key logical components were reimplemented using LnC helpers, to facilitate the most common operations we needed to do. Likely we'll streamline and refine this as time goes on.)
Twig is nice but I find it isn't quite as hands-off syntactically as Handlebars-like things are, which is definitely a thing we wanted.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: ziycon on October 17, 2017, 10:40:36 AM
Post by: ziycon on October 17, 2017, 10:40:36 AM
I have to agree that twig would be a great idea (or something simmilar), I use twig for all templating work I do on any projects, makes life much easier.
Another question, how would it be integrated....composer....
Another question, how would it be integrated....composer....
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Arantor on October 17, 2017, 10:54:46 AM
Post by: Arantor on October 17, 2017, 10:54:46 AM
Composer would be the expected route, yes, the plan would be that you'd declare all your dependencies and then composer-install them as part of the build package process.
Or you bundle it outright in the repository which has other pros/cons.
Or you bundle it outright in the repository which has other pros/cons.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Antes on October 17, 2017, 10:58:23 AM
Post by: Antes on October 17, 2017, 10:58:23 AM
Well, I was reading the nice conversation. I decided to support the idea, it seems far better compared to current system. So, lets do this for next version. But unfortunately, I won't be much help in the process considering my lack of knowledge related to situation (I don't want to call it template).
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Suki on October 17, 2017, 11:04:45 AM
Post by: Suki on October 17, 2017, 11:04:45 AM
Yep, composer or git-submodules. I like composer more.
This will be a dealbreaker in the sense that users won't be able to just get a copy of the files on github and install SMF. I honestly don't know if thats a good or a bad thing.
Theres also the thing about modifications, how would they be able to add their own dependencies to an already composer-locked package. I didn't find a good and reliable way to do that.
This will be a dealbreaker in the sense that users won't be able to just get a copy of the files on github and install SMF. I honestly don't know if thats a good or a bad thing.
Theres also the thing about modifications, how would they be able to add their own dependencies to an already composer-locked package. I didn't find a good and reliable way to do that.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Arantor on October 17, 2017, 11:23:31 AM
Post by: Arantor on October 17, 2017, 11:23:31 AM
The really fun part is when you tell Composer to grab something and you end up getting a git submodule anyway ;)
I don't think there is a good way to solve dependencies via Composer without embedding Composer, which is definitely not recommended.
I don't think there is a good way to solve dependencies via Composer without embedding Composer, which is definitely not recommended.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Suki on October 17, 2017, 11:39:32 AM
Post by: Suki on October 17, 2017, 11:39:32 AM
Ah yes, I've seen weird cases like that. Theres also the thing about dependencies been fetched with their entire set of tests/tools and their .git folder too. Its annoying but the composer guys still refuses to adress it. I suppose that can be deal with on nightly builds.
I think the only reasonable thing to do about modifications is for them to have their own register and autoload thing, one that can be re-do whenever a mod with a dependency is been installed. Nothing fancy, something like what 2.1 already have combined with a libraries folder.
I think the only reasonable thing to do about modifications is for them to have their own register and autoload thing, one that can be re-do whenever a mod with a dependency is been installed. Nothing fancy, something like what 2.1 already have combined with a libraries folder.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Arantor on October 17, 2017, 12:42:53 PM
Post by: Arantor on October 17, 2017, 12:42:53 PM
Random fact, did you know the creator of Composer is also one of the phpBB devs? The same one that, incidentally, in the official Sphinx plugin decided the best way to tell the Sphinx search daemon to update was to kill -9 it and restart it every 15 minutes? Anyway, I digress.
Big fan of having an autoloader (been trying to argue that one for years), and if it's PSR-0/4 compliant you can just use it even for core classes (like XF does) and then only have Composer handle dependencies. (Ideally PSR-4 but that also implies namespacing)
Big fan of having an autoloader (been trying to argue that one for years), and if it's PSR-0/4 compliant you can just use it even for core classes (like XF does) and then only have Composer handle dependencies. (Ideally PSR-4 but that also implies namespacing)
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Suki on October 17, 2017, 03:59:35 PM
Post by: Suki on October 17, 2017, 03:59:35 PM
I was aware about composer and phpBB but have no idea about Sphinx. I can't find the github issue where they discuss adding something to stop fetching tests but I do remember their arguments againts it were hilarious.
Yes, use composer to fetch and build and let SMF handle the registration and autoload. Namespaces can be applied in a light approach, (aka Model\MyModel) just so we can autoload all the stuff under a single standard.
For my mods I blatanly stole composer autoload and used a modsettings var to register the dependencies, its not ideal but this allowed me to not worry about multiple mods trying to register and overwritting themselves. A similar approach can be done. You register your dependencies somewhere (db, env file, raw php, dunno) and let SMF do the autoloading stuff for you.
What about ruting? if we move somewhere else all the stuff that doesn't belong in index.php I actually like and am OK with the current approach. Its quite simple, works and it doesn't hardcode words like current routing systems, good for i18n. Or go with a routing and have some more control over routes, grouping, apply some low level permissions, middlewares, etc.
Yes, use composer to fetch and build and let SMF handle the registration and autoload. Namespaces can be applied in a light approach, (aka Model\MyModel) just so we can autoload all the stuff under a single standard.
For my mods I blatanly stole composer autoload and used a modsettings var to register the dependencies, its not ideal but this allowed me to not worry about multiple mods trying to register and overwritting themselves. A similar approach can be done. You register your dependencies somewhere (db, env file, raw php, dunno) and let SMF do the autoloading stuff for you.
What about ruting? if we move somewhere else all the stuff that doesn't belong in index.php I actually like and am OK with the current approach. Its quite simple, works and it doesn't hardcode words like current routing systems, good for i18n. Or go with a routing and have some more control over routes, grouping, apply some low level permissions, middlewares, etc.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Arantor on October 17, 2017, 04:10:49 PM
Post by: Arantor on October 17, 2017, 04:10:49 PM
Whenever I've built autoloaders, I've been very unsubtle about it. LevGal has an autoloader that IIRC just checks that the requested class is in the LevGal namespace and if so just tries to map directly to filesystem. Other times I've literally just played map to filesystem.
The thing about routing is complicated because while you can adjust routing, it really needs to be a wider thing - because all the links in templates etc. also need to be rewritten if you're going to have translated or changeable route names. Some kind of link builder that is aware of the route rewriting needs to be used throughout (which is ideal fodder for a template engine), so it can rewrite the links spat out in the HTML (because this is 2017, doing it with a buffer rewrite isn't clever)
The great thing about routing is that you don't have to explicitly tie anything to a path if you don't want to - but it's worth considering.
The thing about routing is complicated because while you can adjust routing, it really needs to be a wider thing - because all the links in templates etc. also need to be rewritten if you're going to have translated or changeable route names. Some kind of link builder that is aware of the route rewriting needs to be used throughout (which is ideal fodder for a template engine), so it can rewrite the links spat out in the HTML (because this is 2017, doing it with a buffer rewrite isn't clever)
The great thing about routing is that you don't have to explicitly tie anything to a path if you don't want to - but it's worth considering.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Suki on October 17, 2017, 05:28:07 PM
Post by: Suki on October 17, 2017, 05:28:07 PM
Translating and/or allow to change route names sounds like a real pain in the posterior. This is why I didn't cheerfully rooted for using a proper routing system.
I was thinking more in the lines of Laravel middlewares, define your route and tell SMF, hey this route needs X, Y and Z applied before calling the actual route. Perhaps it also needs A B and C after the route has been called.
Organize/group routes, stuff that belongs to admin, to user, to posting, things like that.
I was thinking more in the lines of Laravel middlewares, define your route and tell SMF, hey this route needs X, Y and Z applied before calling the actual route. Perhaps it also needs A B and C after the route has been called.
Organize/group routes, stuff that belongs to admin, to user, to posting, things like that.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Arantor on October 17, 2017, 05:52:51 PM
Post by: Arantor on October 17, 2017, 05:52:51 PM
But you'd still have to do it even if you left it with the SMF methodology... All you're proposing is changing the implementation, not the workload it has to do.
Even if you made it Laravel middleware, that still doesn't solve the issue of translated route names, for which you still need all the infrastructure on both sides to cope with it.
Even if you made it Laravel middleware, that still doesn't solve the issue of translated route names, for which you still need all the infrastructure on both sides to cope with it.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Suki on October 17, 2017, 10:45:30 PM
Post by: Suki on October 17, 2017, 10:45:30 PM
No no, forget about translatable routes. That wasn't my intention. Keep the current approach, just beef it up a bit. I'm more interested in applying pre and post logic everytime an action is called. Say if an action requires the user to be logged in, add an auth middle ware to automatically send the user to the login page if it hasn't logged in. Same for permissions
If an action is going to respond a json object automatically send the correct headers. Things like that.
If an action is going to respond a json object automatically send the correct headers. Things like that.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Arantor on October 18, 2017, 05:39:19 AM
Post by: Arantor on October 18, 2017, 05:39:19 AM
Setting headers is not something that should be handled at the routing level, that's something that the route itself manages as per PSR-7.
As for translating routes, you said i18n, so I assumed that's what you wanted to be able to do... Some mileage would be gotten out of looking at existing platforms that can do this (XF certainly can do this with its route filters stuff)
As for translating routes, you said i18n, so I assumed that's what you wanted to be able to do... Some mileage would be gotten out of looking at existing platforms that can do this (XF certainly can do this with its route filters stuff)
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Suki on October 18, 2017, 10:48:05 AM
Post by: Suki on October 18, 2017, 10:48:05 AM
Yeah my wording wasn't the best, I mean the current approach action=profile;u=1 is somehow better for i18n than a full (English hardcoded) route like /profile/user/chuck_norris.
I wouldn't dare to try translatable routes for all the things you pointed out, besides, this means the user will have to have their prefered language on install, something that rarely happens unless we find a reliable way to download their language on install or something like that.
By setting headers I mean something like this:
action=profile;u=1;xml
action=profile;u=1;json
action=profile;u=1;yaml
SMF will detect that last bit and will respond accordingly without having the set the response in the controller or the route (besides setting the actual data to send of course). Of course this will be an option rather then the default thing to do.
This will be useful for controller getters that directly communicate with some model to get some data. Combiend with a good ORM and you will have an easy and modular way to fetch data.
Of course I know not everything is going to be handle that way and that part of the charm of SMF resides on how we retreive data, thats def something that should remain.
I wouldn't dare to try translatable routes for all the things you pointed out, besides, this means the user will have to have their prefered language on install, something that rarely happens unless we find a reliable way to download their language on install or something like that.
By setting headers I mean something like this:
action=profile;u=1;xml
action=profile;u=1;json
action=profile;u=1;yaml
SMF will detect that last bit and will respond accordingly without having the set the response in the controller or the route (besides setting the actual data to send of course). Of course this will be an option rather then the default thing to do.
This will be useful for controller getters that directly communicate with some model to get some data. Combiend with a good ORM and you will have an easy and modular way to fetch data.
Of course I know not everything is going to be handle that way and that part of the charm of SMF resides on how we retreive data, thats def something that should remain.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Gwenwyfar on October 20, 2017, 02:43:44 PM
Post by: Gwenwyfar on October 20, 2017, 02:43:44 PM
I'm stealing China's Wall. Ignore all their demands to give it back ;D
@Arantor:
Finally, a genuine reply.
First, as I imagined you are stretching the definitions for a logical fallacy. Slippery Slopes are a moot point for one simple reason:
Slippery Slopes are not Logical Fallacies.
It's a myth, a misconception by the skeptic community. Probably because doomsday sayers make much use of Slippery Slopes in their antics, slippery slopes which never come true. But here is the thing: they never come true because the slippery slopes they describe are filled with actual logical fallacies, so the logic doesn't follow, so they never materialize, but not because Slippery Slopes aren't real. They are a real thing, even on sheer logic they are a real thing, they can even be mathematically described as systems of redundant exponential growths.
They are even more real if you're working with a non-logical system, a system where human behavior is a dominant factor. For human behavior is arbitrary, is not bound by the rules of logic, it has great potential for redundant growth. That's why the concept is taken so seriously in fields such as Law Making or Social Engineering.
You can't refute an argument by simply calling it a slippery slope, you have to refute the underlying logic inside the Slippery Slope, why the events don't follow, why the slippery slope will not happen. So far, all you have pointed is that opposite forces happen as well, which is a pretty obvious point, but you never say which of them end up dominant on the long term, which is my point.
As for strawmanning, I would like to know where. This is about Template Engines, something which greatly affects theme developers. It's about the upsides and downsides such engines will have on theme development. If the discussion went somewhere else... it's a thing discussions do, they wander far to give points, give examples, makes connections, make analogies to better explain, to make the idea clearer in everyone's mind... the focus has never been lost however.
Same for Ad Hominem. By the Law of First Aggression I know I wasn't the first to attack directly the person professing an idea rather than the idea itself. Actually, so far in this whole discussion you have been the only one to say I'm being an "arrogant and elitist" rather than deal with the idea itself.
My probing on your behavior is not an attack. You were behaving against everything you have professed so far. Either you changed your mind about some of your beliefs or you're being a hypocrite. Good to know it's the first, shows good character :)
As for your other points:
Performance considerations are not just about how fast the instructions will happen, most of the time these are negligible. It's mostly about scalability, debugging and what kind of code such philosophies attract. As you use more and more of these higher layers, the small losses on performance starts to stack up to become greater losses, for a variety of reasons, from lack of control, to bloat, to improper form. So you end with the famous 90% of the time will be spent on 10% of your code. And chunks of that 10% will be all spread over the bloat generated by the higher abstractions, in small chunks of 0,5% there, 0,7% some 500 lines down the code... 2,5% at most, that's one of the reasons it becomes a debugging hell. And all that is even assuming you're using the engines smartly. Dumb code will be even worse.
And yes, dumb code happens everywhere, it's just statistics, but by removing basic PHP requirement you are giving it MORE room for it to happen. It's not about whether it happens or not, but at which scale they will start to happen.
Something similar (based on this kind of philosophy) has already affected the status quo of css. Bootstrapping is one of the most popular tools out there, and it was one of the worst things that ever happened to the Front-End Industry. It has gotten to the point that the browser has to ignore 90% of the code generated by such tools. 90% of the code is just sheer bloat. 90% of the lines are meaningless. Completely meaningless, wasteful and useless. This is not hyperbolic, just one of the latest work I did, to convert some code to be accepted under certain limitations, went from JS + html + css files totaling 158kb to html + css files at 6kb. Even the links were a sort of JS button, I suppose adding an <a> is too complicated. Bad JS like this is no news, but you see the same effect in css. I get so many jobs where what has been achieved in 3000 lines of code could be achieved with 300, on better user performance at that. Many times it's just better to scrap everything to the trash and start over, because it's such a ball of knots impossible to untangle, it's a waste of time to try to debug it, it's better to just start over. The saddest part of it all is this sort of thing is very widespread in the industry, so it's not just one or another code that does this, it's most of them.
And then on top of this people build tools to "clean the css", "clean that other piece of code", and are amazed to see "how well it works" when it reduces the files from 120kb to measly 15kb (which it should have been all along). And now in most people's mind, if you build a site without bootstrap or similar, its because you don't know what you are doing, when it should be the exact opposite.
Why all that? Most bootstrappers would answer you: "Dealing with CSS is too much work, it takes too long...". It would be akin to backend developers saying CGIs or databases are too complicated, too much of a hassle to deal with. It's absurd.
Users vs themers: They are miles apart, starting at the basics (one should know, at the very least, HTML/CSS and the other will possibly not even know what that is), and I think that should be a separate discussion to see what can be done to make user life easier. One of the common things they want to edit can already be helped by adding sass variables (if by the time we do this, css variables are not already usable by themselves, but progress in new css functions is slow as always).
As for what this particular discussion reflects on the common user, I do not think whatever choice is made (to use a template engine or not) will make much difference to them. You could even say using plain PHP would benefit common users slightly more than anything else, based on the fact all code editors highlight php files properly by default (which many, if not most, common users will not even have), while other file types are often a downloadable package, that surely, they won't even know they have to get, or how. For most users, a template engine's code is just as greek as PHP, it's just an incomprehensible block of text-code.
I have been in the position of denying frameworks as a whole in the past too, it is the case that you mistake the erroneous usage with the thing itself. Yes, frameworks have their place. Maybe even bootstrap could have a useful use case somewhere, but it would be so specific it almost doesn't justify it's existence. It is however something to be very careful with to not fall into the same trap that most have fallen. You need to choose well what you will use and where, even more so when you can't rely on what most people are doing being right, since so often it is quite the opposite. When the Status Quo bar is so low, following it should be decided on much caution.
Also, refer to the user vs themers above for the rest, and my reply to Suki below on the same subject.
@Suki:
I'm not criticizing it for the sake of criticizing it, I'm trying to give better solutions.
"Get on with the times" is a bull****** argument. It's pure rhetorics. It implies that whatever is "new and popular" is always better. It's a progressive misconception. Mankind doesn't always go forward, there are many new ideas and concepts that are crap, many popular customs that are wrong. It's a terrible argument.
Just FYI, I have worked from Real State companies to Financial Data companies. I know how big projects look like, I know how they behave. It's a myth you need frameworks or huge teams to work on them. On the contrary, a small smart team working hard and close to the big bosses produce better output than huge teams divided by many hierarchies of command, working on "easy to write and read" languages as frameworks. These kind of projects tend to develop to bloated debugging hells, when the project doesn't fall so far off the rails where you have to simply scrap everything and start over, losing millions in the process (or, as is most often the case, they just keep going while patching it over with even more bloat).
I have also met with people who are actual low level coders who work on huge projects with no more than a dozen teammates. The army, for one, still uses assembly coding for everything, from simple trajectory calculating algorithms to whole missile guiding system. Not because they deal with too many hardware input, you can code around hardware input even on higher levels as it happens with car's softwares, but different than car's softwares, bloated bugged code means dead people for the army, so they have to set the bar higher.
My point here is: You don't know me and it's possible to do work well without crutches, without frameworks and layers upon layers of higher abstractions, even on big projects. PHP + HTML/CSS is fine, it's on a fine balanced level of performance and abstractions. You're making assumptions.
Reducing the tools available is also a two-edged sword. We are talking about something that theme makers will use, we should not be removing options from them. Developers need profiling and precision tools, not cradles and playgrounds so he doesn't hurt or learn anything.
Themers are not users. Themers are developers, for they develop themes for users to use. They're Front-end developers, not Users. It's their job to know basic PHP to develop themes for a PHP Forum, because they're developers, not users. Otherwise you'll have developers who have no idea where they are developing upon and that makes for bad development process. It's good form to require basic PHP knowledge to develop a theme for a PHP Forum. By removing such requirements you do gain popularity, you do gain all those developers who don't care about PHP (and somehow, are perfectly fine learning a templating engine that will have much of the same stuff), but at the expense of losing good form. Now you have more room for bad form, and such system will invariably attract bad form sooner or later, it's what has happened in all similar systems.
What are you essentially arguing is that every user should have the option to be a developer, therefore we should simplify developer tools for developers so users can develop as well. That's why I call it dumbing it down.
This shouldn't be about forum users, this should be about developers, because it affects their work much more than the common user, be it a member or an admin.
I'm pressing the same key because you are making light of it and avoiding it so far.
And again, the one that has ignored most of what has been argued is you. I have already replied to all your points (and if there is one you believe I have not addressed, then please point it out and I will do so). If you wish to have a fair discussion, maybe you should start debunking the given arguments and answering the questions instead of avoiding them and lowering the level down to rhetorics.
It's actually dumbfounding that you come in all grandeur about your experience as PM and then tell me to get off my high horse.
As a general note, I'll say this again, since there seems to have been some confusion in this regard:
I am against the use of the proposed templating engines (or similar ones). I am not against making the templates better. I am also not against trying to find a better alternative to fixing the aforementioned problems with echoes either, while keeping the downsides to a minimum. I'm following the old engineering mantra: "There's a better way to do this". We should be making it easier for budding developers to learn basic PHP, not replace its learning curve entirely with something else. You do not need to use a complete template engine to do any of the above, doing that just brings more problems than it solves. I don't believe the immediate gains in popularity such engines bring is worth all the headaches they will cause down the road.
@Arantor:
Finally, a genuine reply.
First, as I imagined you are stretching the definitions for a logical fallacy. Slippery Slopes are a moot point for one simple reason:
Slippery Slopes are not Logical Fallacies.
It's a myth, a misconception by the skeptic community. Probably because doomsday sayers make much use of Slippery Slopes in their antics, slippery slopes which never come true. But here is the thing: they never come true because the slippery slopes they describe are filled with actual logical fallacies, so the logic doesn't follow, so they never materialize, but not because Slippery Slopes aren't real. They are a real thing, even on sheer logic they are a real thing, they can even be mathematically described as systems of redundant exponential growths.
They are even more real if you're working with a non-logical system, a system where human behavior is a dominant factor. For human behavior is arbitrary, is not bound by the rules of logic, it has great potential for redundant growth. That's why the concept is taken so seriously in fields such as Law Making or Social Engineering.
You can't refute an argument by simply calling it a slippery slope, you have to refute the underlying logic inside the Slippery Slope, why the events don't follow, why the slippery slope will not happen. So far, all you have pointed is that opposite forces happen as well, which is a pretty obvious point, but you never say which of them end up dominant on the long term, which is my point.
As for strawmanning, I would like to know where. This is about Template Engines, something which greatly affects theme developers. It's about the upsides and downsides such engines will have on theme development. If the discussion went somewhere else... it's a thing discussions do, they wander far to give points, give examples, makes connections, make analogies to better explain, to make the idea clearer in everyone's mind... the focus has never been lost however.
Same for Ad Hominem. By the Law of First Aggression I know I wasn't the first to attack directly the person professing an idea rather than the idea itself. Actually, so far in this whole discussion you have been the only one to say I'm being an "arrogant and elitist" rather than deal with the idea itself.
My probing on your behavior is not an attack. You were behaving against everything you have professed so far. Either you changed your mind about some of your beliefs or you're being a hypocrite. Good to know it's the first, shows good character :)
As for your other points:
Performance considerations are not just about how fast the instructions will happen, most of the time these are negligible. It's mostly about scalability, debugging and what kind of code such philosophies attract. As you use more and more of these higher layers, the small losses on performance starts to stack up to become greater losses, for a variety of reasons, from lack of control, to bloat, to improper form. So you end with the famous 90% of the time will be spent on 10% of your code. And chunks of that 10% will be all spread over the bloat generated by the higher abstractions, in small chunks of 0,5% there, 0,7% some 500 lines down the code... 2,5% at most, that's one of the reasons it becomes a debugging hell. And all that is even assuming you're using the engines smartly. Dumb code will be even worse.
And yes, dumb code happens everywhere, it's just statistics, but by removing basic PHP requirement you are giving it MORE room for it to happen. It's not about whether it happens or not, but at which scale they will start to happen.
Something similar (based on this kind of philosophy) has already affected the status quo of css. Bootstrapping is one of the most popular tools out there, and it was one of the worst things that ever happened to the Front-End Industry. It has gotten to the point that the browser has to ignore 90% of the code generated by such tools. 90% of the code is just sheer bloat. 90% of the lines are meaningless. Completely meaningless, wasteful and useless. This is not hyperbolic, just one of the latest work I did, to convert some code to be accepted under certain limitations, went from JS + html + css files totaling 158kb to html + css files at 6kb. Even the links were a sort of JS button, I suppose adding an <a> is too complicated. Bad JS like this is no news, but you see the same effect in css. I get so many jobs where what has been achieved in 3000 lines of code could be achieved with 300, on better user performance at that. Many times it's just better to scrap everything to the trash and start over, because it's such a ball of knots impossible to untangle, it's a waste of time to try to debug it, it's better to just start over. The saddest part of it all is this sort of thing is very widespread in the industry, so it's not just one or another code that does this, it's most of them.
And then on top of this people build tools to "clean the css", "clean that other piece of code", and are amazed to see "how well it works" when it reduces the files from 120kb to measly 15kb (which it should have been all along). And now in most people's mind, if you build a site without bootstrap or similar, its because you don't know what you are doing, when it should be the exact opposite.
Why all that? Most bootstrappers would answer you: "Dealing with CSS is too much work, it takes too long...". It would be akin to backend developers saying CGIs or databases are too complicated, too much of a hassle to deal with. It's absurd.
Users vs themers: They are miles apart, starting at the basics (one should know, at the very least, HTML/CSS and the other will possibly not even know what that is), and I think that should be a separate discussion to see what can be done to make user life easier. One of the common things they want to edit can already be helped by adding sass variables (if by the time we do this, css variables are not already usable by themselves, but progress in new css functions is slow as always).
As for what this particular discussion reflects on the common user, I do not think whatever choice is made (to use a template engine or not) will make much difference to them. You could even say using plain PHP would benefit common users slightly more than anything else, based on the fact all code editors highlight php files properly by default (which many, if not most, common users will not even have), while other file types are often a downloadable package, that surely, they won't even know they have to get, or how. For most users, a template engine's code is just as greek as PHP, it's just an incomprehensible block of text-code.
QuoteThe 'one syntax for another' argument is interesting. Let me reframe the situation, maybe it'll help you understand my perspective: why does TypeScript exist? what about CoffeeScript? These things literally do nothing that JavaScript can't do (because they compile down to JavaScript), but people like them because they abstract away some of the really annoying things in the underlying language. That's all that's going on here, really.I do not know about TypeScript, but Coffescript doesn't seem to be a equivalent comparison. There could be cases in which such changes make sense, for example if you are dealing with a language that has terrible syntax to begin with, but this is not the case for PHP. The only really bad aspect of it in it are the echoes for HTML, and it is overkill to change everything else just to make this one part better. And, frankly, some (not all) of these templating engines manage to make the rest of the syntax even worse. If the idea is to have the templates redone and simplified to have less PHP in them, there is not going to be much difference in question of learning/usage curve when all you are doing is replace one way to write an if or a variable with a different one. It becomes simply unnecessary for something that does not come consequence-free. There simply isn't enough value in this change.
QuoteThe kicker though, is that this debate reminds me of me. Everything I see in this debate echoes me, and this isn't a good thing. It makes me begin to question how much of a force I personally have been for good in this environment, and makes me think that my naive idealisms over the years have encouraged others to do the same - and I'm not convinced in some of those positions of argument that I was right. There was certainly a time when I argued against frameworks as a whole, and certainly a time when I argued against template engines, too. I find a lot of the same old issues, though, an over-cautious conservatism at a time when the entire fleet of platforms in the forum space are routinely castigated for failure to innovate, and it's harder to drive innovation on any level when the platform decides it wants a barrier to entry for even modest things like putting something to the screen. It's the same reason we don't use C to build a forum, we like having the abstractions. I'm just arguing for one more abstraction because it feels like it benefits everyone.The wonders of growing older and noting the ****** you did before :D
I have been in the position of denying frameworks as a whole in the past too, it is the case that you mistake the erroneous usage with the thing itself. Yes, frameworks have their place. Maybe even bootstrap could have a useful use case somewhere, but it would be so specific it almost doesn't justify it's existence. It is however something to be very careful with to not fall into the same trap that most have fallen. You need to choose well what you will use and where, even more so when you can't rely on what most people are doing being right, since so often it is quite the opposite. When the Status Quo bar is so low, following it should be decided on much caution.
Quote* people who are admins who want to do simple customisations of their own - these people aren't programmers, they just want to insert the bit of JavaScript for Google Analytics by copy and paste like GA tells them to, except surprise, they have to figure out quoting syntax. Or the people who just want to tweak a little bit like the header. They're then dealing with what amounts to mostly HTML and CSS, as opposed to PHP, actual HTML and CSS - and all evidence suggests that people find this easier to do simple changes. There's a reason people like the theme stuff in XenForo and IPB - it lets them make little changes without any hassle. They feel empowered, they feel like they can own something even though they're not technical. Not every SMF admin is a programmer or a designer.Yes, that is nothing I disagree on, but this again goes back to the example I gave here (https://www.simplemachines.org/community/index.php?topic=556516.msg3944785#msg3944785), you don't need to use one of these templating engines to fix that. I'm all for improving admins customizations features, but it should not do so at the expense of developer tools, they're different things.
Also, refer to the user vs themers above for the rest, and my reply to Suki below on the same subject.
Quote* people who are theme people get to play with something closer to what they normally use rather than stepping through hoops. Yes, it means people can do stupid things more easily - but at the same time, it lets people who know the tools do so without having to remember to escape quotes. And people will always do stupid things, this shouldn't be a barrier to making tools easier for non-stupid use cases.Again, same as above. Yes, things could be better. But why these templating engines over other methods?
Quote* when I build Moodle plugins, even though I'm not even required to use the template system because Moodle doesn't mandate it (because Moodle doesn't use it itself for most of its plugins for historical reasons), most clients are requesting it so they can have a designer customise it without knowing Moodle's code innards. And Moodle certainly has PHP 'templates' in its core in the renderer system. Though that's a level of mind-killer with its many classes and layers of abstraction that I wouldn't impose upon anyone. But I digress - designers are the people who would like this.Just as what happens anywhere, you have good and bad professionals, and those focused in a multitude of areas. You'll also find many designers who refuse to work without bootstrap or other css frameworks, that doesn't mean we should do as they say. You will never be able to please everyone, and I believe we should focus on getting good themers into SMF, not pleasing as many people as possible just for the sake of it.
QuoteAlso, on an ironic note, this debate somehow ended up talking about C. Who remembers the doomed project smflib, that reimplemented bits of SMF as C so they would be PHP extensions for the really really big forums? I do...This is the first time I hear about this. This seems interesting to see, in the least :D
@Suki:
QuoteEven though multiple reasons were exposed, you chose to focus solely on this point. You haven't addressed any point about helping development, for example.You just showed you clearly haven't given proper attention to my posts then.
There have been arguments about helping themers and helping regular users, you decided each was a separate argument which is not, as I have been saying, this thing AFFECTS everyone, not just you, not just themers.
I'm not criticizing it for the sake of criticizing it, I'm trying to give better solutions.
QuoteThey aren't assumptions. It is quite clear you haven't used a template engine. It is quite clear you haven't worked on a big project either. All the arguments you try to make were already made a few years ago. Really sorry to say this to you but get on with the timesThey are assumptions for you don't know me. You don't know my history, you don't know the projects I have worked on, you don't know the people I know.
"Get on with the times" is a bull****** argument. It's pure rhetorics. It implies that whatever is "new and popular" is always better. It's a progressive misconception. Mankind doesn't always go forward, there are many new ideas and concepts that are crap, many popular customs that are wrong. It's a terrible argument.
Just FYI, I have worked from Real State companies to Financial Data companies. I know how big projects look like, I know how they behave. It's a myth you need frameworks or huge teams to work on them. On the contrary, a small smart team working hard and close to the big bosses produce better output than huge teams divided by many hierarchies of command, working on "easy to write and read" languages as frameworks. These kind of projects tend to develop to bloated debugging hells, when the project doesn't fall so far off the rails where you have to simply scrap everything and start over, losing millions in the process (or, as is most often the case, they just keep going while patching it over with even more bloat).
I have also met with people who are actual low level coders who work on huge projects with no more than a dozen teammates. The army, for one, still uses assembly coding for everything, from simple trajectory calculating algorithms to whole missile guiding system. Not because they deal with too many hardware input, you can code around hardware input even on higher levels as it happens with car's softwares, but different than car's softwares, bloated bugged code means dead people for the army, so they have to set the bar higher.
My point here is: You don't know me and it's possible to do work well without crutches, without frameworks and layers upon layers of higher abstractions, even on big projects. PHP + HTML/CSS is fine, it's on a fine balanced level of performance and abstractions. You're making assumptions.
QuoteAgain, the chose for using a template engine comes from measuring all those aspects (and others who aren't directly related to programming) and based on all that info we decided a template engine is the best choice.And I'm saying they are a bad choice and saying why I think so. Or are you above making bad choices and decisions?
QuoteBy definition, an engine will keep presentation away from logic, this means heavy logic CANT be performed on a theme file. This actually prevents doing dumb stuff.Of course, the engine itself will do the dumb stuff for the developer. They just hide the logic from the developer but there still an underlying logic working in there for which the developer loses control, and in many situations the standard engine logic will not fit the best requirements for one situation, that's why high abstractions will always lose efficiency sooner or later. The engines will try to fit a ball in a square shaped hole sooner or later and the developer, most of the time, will have no knowledge about it, let alone control over it.
Reducing the tools available is also a two-edged sword. We are talking about something that theme makers will use, we should not be removing options from them. Developers need profiling and precision tools, not cradles and playgrounds so he doesn't hurt or learn anything.
QuoteThis is yet another thing you conveniently ignore. Whoever gets in charge of building the next version has to take into account all the different types of people who are going to use SMF. From devs to themers to admins to users to hostings.Ignore my ass. So far this discussion started on and is focused around Themers, because they are the ones who will have to work with the Template Engine. And here's the thing you don't seem to understand:
Themers are not users. Themers are developers, for they develop themes for users to use. They're Front-end developers, not Users. It's their job to know basic PHP to develop themes for a PHP Forum, because they're developers, not users. Otherwise you'll have developers who have no idea where they are developing upon and that makes for bad development process. It's good form to require basic PHP knowledge to develop a theme for a PHP Forum. By removing such requirements you do gain popularity, you do gain all those developers who don't care about PHP (and somehow, are perfectly fine learning a templating engine that will have much of the same stuff), but at the expense of losing good form. Now you have more room for bad form, and such system will invariably attract bad form sooner or later, it's what has happened in all similar systems.
What are you essentially arguing is that every user should have the option to be a developer, therefore we should simplify developer tools for developers so users can develop as well. That's why I call it dumbing it down.
This shouldn't be about forum users, this should be about developers, because it affects their work much more than the common user, be it a member or an admin.
QuoteI was saying I could reply with random text and you will still focus on your ideas. This whole thing was been a big waste of time since you don't really want to have a discussion, all you want to do is showing you are right.So you would rather have me focus on random text unrelated to the discussion than the discussion itself then? Because otherwise that is a useless point.
I'm pressing the same key because you are making light of it and avoiding it so far.
And again, the one that has ignored most of what has been argued is you. I have already replied to all your points (and if there is one you believe I have not addressed, then please point it out and I will do so). If you wish to have a fair discussion, maybe you should start debunking the given arguments and answering the questions instead of avoiding them and lowering the level down to rhetorics.
It's actually dumbfounding that you come in all grandeur about your experience as PM and then tell me to get off my high horse.
As a general note, I'll say this again, since there seems to have been some confusion in this regard:
I am against the use of the proposed templating engines (or similar ones). I am not against making the templates better. I am also not against trying to find a better alternative to fixing the aforementioned problems with echoes either, while keeping the downsides to a minimum. I'm following the old engineering mantra: "There's a better way to do this". We should be making it easier for budding developers to learn basic PHP, not replace its learning curve entirely with something else. You do not need to use a complete template engine to do any of the above, doing that just brings more problems than it solves. I don't believe the immediate gains in popularity such engines bring is worth all the headaches they will cause down the road.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Arantor on October 20, 2017, 04:12:34 PM
Post by: Arantor on October 20, 2017, 04:12:34 PM
I was going to rebut the various points, but I realised there wasn't any real point to it, we can just continue talking past each other, stubbornly clinging on to our world views.
All I'll say is, 3 years ago I was you. I'm... really not that now.
I should stop suggesting things, it only ends up being a waste of everyone's time.
All I'll say is, 3 years ago I was you. I'm... really not that now.
I should stop suggesting things, it only ends up being a waste of everyone's time.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Gwenwyfar on October 20, 2017, 04:41:00 PM
Post by: Gwenwyfar on October 20, 2017, 04:41:00 PM
I'm sorry you feel that way.
And by the way, a note that somehow escaped in there about "It makes me begin to question how much of a force I personally have been for good in this environment":
Maybe I'm not the right person to say this, but at least for me it seems like much of it was :)
And by the way, a note that somehow escaped in there about "It makes me begin to question how much of a force I personally have been for good in this environment":
Maybe I'm not the right person to say this, but at least for me it seems like much of it was :)
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: shawnb61 on October 20, 2017, 04:47:00 PM
Post by: shawnb61 on October 20, 2017, 04:47:00 PM
Yes, an excellent discussion. I learned a lot.
Developers disagree. It's what they're best at...
Developers disagree. It's what they're best at...
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Suki on October 20, 2017, 04:52:38 PM
Post by: Suki on October 20, 2017, 04:52:38 PM
You know, I kinda wonder where are all those noisy themers who were very vocal about how terrible SMF themming system is and how much weight we gave to backend instead of frontend... here we are, a few years later actually defending their case :laugh:
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Arantor on October 20, 2017, 05:30:37 PM
Post by: Arantor on October 20, 2017, 05:30:37 PM
Quote from: Suki on October 20, 2017, 04:52:38 PM
You know, I kinda wonder where are all those noisy themers who were very vocal about how terrible SMF themming system is and how much weight we gave to backend instead of frontend... here we are, a few years later actually defending their case :laugh:
They all left already for other platforms where theming isn't so hard.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: 青山 素子 on October 20, 2017, 11:17:11 PM
Post by: 青山 素子 on October 20, 2017, 11:17:11 PM
Quote from: Arantor on October 20, 2017, 05:30:37 PM
They all left already for other platforms where theming isn't so hard.
Exactly this.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: AllanD on November 12, 2017, 07:35:32 PM
Post by: AllanD on November 12, 2017, 07:35:32 PM
I am a self theme maker, meaning I make themes for myself most of the time. There are occasions that I have released some on other platforms. I wanted to say having any type of template system would be great, I am not saying saying something like Xenforo v2 I understand many do this here just to help out, but having a system would improve the act of making themes. I am not a coder by any standards but it is mush easier to add css or a html then edit php.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Diego Andrés on March 21, 2018, 12:55:00 PM
Post by: Diego Andrés on March 21, 2018, 12:55:00 PM
Quote from: Suki on October 20, 2017, 04:52:38 PM
You know, I kinda wonder where are all those noisy themers who were very vocal about how terrible SMF themming system is and how much weight we gave to backend instead of frontend... here we are, a few years later actually defending their case :laugh:
Would be nice to meet them since I got started in css and php making themes, at it was very easy.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Suki on March 21, 2018, 02:17:33 PM
Post by: Suki on March 21, 2018, 02:17:33 PM
Speaking of template systems I've recently been toying and very much likening EJS (http://www.embeddedjs.com) and Erubis (http://www.kuwata-lab.com/erubis/)
Of course if we took this further I very much like the way Vue (https://vuejs.org) is heading.
Of course if we took this further I very much like the way Vue (https://vuejs.org) is heading.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: landyvlad on April 09, 2018, 01:52:11 AM
Post by: landyvlad on April 09, 2018, 01:52:11 AM
While a bit of the stuff in this thread is above my head / knowledge I entirely agree with this statement
Of course (IMHO) the best means would be a graphical front end where you can make changes and then review them in near real-time such as in wordpress. Heaps good, and probably almost impossible to achieve. Such a thing, were it offered by any forum software, would drag many new users away from SMF (and others) in droves.
Why new users? Well I think many are initially far more concerned with looks rather than function.
Quote from: lurkalot on October 08, 2017, 01:29:12 PM
Anything that makes things easier for the end user gets my vote. If that means being able to modify the looks, build themes without having to learn php can only be a good thing.
Of course (IMHO) the best means would be a graphical front end where you can make changes and then review them in near real-time such as in wordpress. Heaps good, and probably almost impossible to achieve. Such a thing, were it offered by any forum software, would drag many new users away from SMF (and others) in droves.
Why new users? Well I think many are initially far more concerned with looks rather than function.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Gwenwyfar on April 17, 2018, 10:39:28 PM
Post by: Gwenwyfar on April 17, 2018, 10:39:28 PM
This is not a feature to help (or that would truly help) users/admins. It would "help" those making the themes, two very different things. If the subject is making things easier for admins/users there's other things that would be much more useful and would not even involve changing how the templates work. Your graphical interface example is one such thing, it would be a nice feature.
Title: Re: Moving to something like Handlebars (after 2.1)
Post by: Arantor on June 15, 2018, 07:10:06 AM
Post by: Arantor on June 15, 2018, 07:10:06 AM
The thing about Handlebars is that it strongly encourages splitting templates into small pieces and including them.
Means admins can find things easier as to changing them. At least that's been our experience having now converted the entirety of the templates.
Means admins can find things easier as to changing them. At least that's been our experience having now converted the entirety of the templates.