Advertisement:
« previous next »
Pages: [1] 2 3 4   Go Down

Author Topic: Moving to something like Handlebars (after 2.1)  (Read 91154 times)

Offline Arantor

  • Resident Overthinker
  • SMF Friend
  • SMF Legend
  • *
  • Posts: 68,361
    • Arantor on GitHub
Moving to something like Handlebars (after 2.1)
« 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.
Logged
To assume is to hope that those who came before had the presence of mind and capacity to implement the dreams of those who would come after.

You either die a hero or live long enough to see yourself become the villain. It seems you have chosen which, and now I must do the same.

Online d3vcho(void)

  • Localizer
  • SMF Hero
  • *
  • Posts: 2,493
  • Gender: Male
  • Be prepared for hell
    • d3vcho on GitHub
    • @SMF_ES on Twitter
Re: Moving to something like Handlebars (after 2.1)
« Reply #1 on: October 08, 2017, 10:16:48 AM »
Sounds interesting 8)
Logged

Offline Antes

  • Evil Black Cat
  • SMF Friend
  • SMF Hero
  • *
  • Posts: 8,693
  • Gender: Male
  • Black cat rulz!
    • Antes on GitHub
    • merta on LinkedIn
    • @XinYenFon on Twitter
    • Lunarfall
Re: Moving to something like Handlebars (after 2.1)
« Reply #2 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).
Logged
T..s sig..t..e is ce..or.d by S.F T... w..ho.t an ex..an...on.

Past Project(s): [ ezPortal ]

Offline Arantor

  • Resident Overthinker
  • SMF Friend
  • SMF Legend
  • *
  • Posts: 68,361
    • Arantor on GitHub
Re: Moving to something like Handlebars (after 2.1)
« Reply #3 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:

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">&nbsp;
                <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.
Logged
To assume is to hope that those who came before had the presence of mind and capacity to implement the dreams of those who would come after.

You either die a hero or live long enough to see yourself become the villain. It seems you have chosen which, and now I must do the same.

Offline Antes

  • Evil Black Cat
  • SMF Friend
  • SMF Hero
  • *
  • Posts: 8,693
  • Gender: Male
  • Black cat rulz!
    • Antes on GitHub
    • merta on LinkedIn
    • @XinYenFon on Twitter
    • Lunarfall
Re: Moving to something like Handlebars (after 2.1)
« Reply #4 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.
Logged
T..s sig..t..e is ce..or.d by S.F T... w..ho.t an ex..an...on.

Past Project(s): [ ezPortal ]

Offline Arantor

  • Resident Overthinker
  • SMF Friend
  • SMF Legend
  • *
  • Posts: 68,361
    • Arantor on GitHub
Re: Moving to something like Handlebars (after 2.1)
« Reply #5 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.
Logged
To assume is to hope that those who came before had the presence of mind and capacity to implement the dreams of those who would come after.

You either die a hero or live long enough to see yourself become the villain. It seems you have chosen which, and now I must do the same.

Offline Gwenwyfar

  • Customizer
  • Sophist Member
  • *
  • Posts: 1,025
  • Gender: Female
    • Gwenwyfar on GitHub
Re: Moving to something like Handlebars (after 2.1)
« Reply #6 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.
Logged

Offline Arantor

  • Resident Overthinker
  • SMF Friend
  • SMF Legend
  • *
  • Posts: 68,361
    • Arantor on GitHub
Re: Moving to something like Handlebars (after 2.1)
« Reply #7 on: October 08, 2017, 11:36:27 AM »
Quote
Wouldn'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, phpBB, XenForo, vBulletin, NodeBB, Discourse, Flarum (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.
Logged
To assume is to hope that those who came before had the presence of mind and capacity to implement the dreams of those who would come after.

You either die a hero or live long enough to see yourself become the villain. It seems you have chosen which, and now I must do the same.

Offline digger

  • Sr. Member
  • ****
  • Posts: 723
  • Gender: Male
    • realdigger on GitHub
    • SMF Russian Community
Re: Moving to something like Handlebars (after 2.1)
« Reply #8 on: October 08, 2017, 01:01:15 PM »
Quote from: Arantor on October 08, 2017, 11:36:27 AM
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.
SMF 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.
Logged

Offline Gwenwyfar

  • Customizer
  • Sophist Member
  • *
  • Posts: 1,025
  • Gender: Female
    • Gwenwyfar on GitHub
Re: Moving to something like Handlebars (after 2.1)
« Reply #9 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
Logged

Offline Arantor

  • Resident Overthinker
  • SMF Friend
  • SMF Legend
  • *
  • Posts: 68,361
    • Arantor on GitHub
Re: Moving to something like Handlebars (after 2.1)
« Reply #10 on: October 08, 2017, 01:17:47 PM »
Quote
simplify 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.

Quote
The 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.

Quote
And 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.)

Quote
I 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.

Quote
I 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.

Quote
If 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.

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

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

Quote
That 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.

Quote
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

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.
Logged
To assume is to hope that those who came before had the presence of mind and capacity to implement the dreams of those who would come after.

You either die a hero or live long enough to see yourself become the villain. It seems you have chosen which, and now I must do the same.

Offline lurkalot

  • Sophist Member
  • *****
  • Posts: 1,057
  • Gender: Male
  • Tinyportal Support
    • guitaristguild on Facebook
    • Tinyportal on GitHub
    • @GuitaristGuild on Twitter
    • Guitarist Guild
Re: Moving to something like Handlebars (after 2.1)
« Reply #11 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.

Logged

Offline Gwenwyfar

  • Customizer
  • Sophist Member
  • *
  • Posts: 1,025
  • Gender: Female
    • Gwenwyfar on GitHub
Re: Moving to something like Handlebars (after 2.1)
« Reply #12 on: October 08, 2017, 03:08:02 PM »
Quote
Honestly that would be akin to shuffling the deckchairs on the Titanic, it doesn't fix the underlying problem.
Which is?

Quote
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.
And what exactly in that example requires the different syntax? What in it can't be done using PHP syntax?

Quote
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.)
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.

Quote
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.
And what does that have to do with people who should know HTML? How many of those people actually knew what they were doing?

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

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

Quote
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.
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.
Logged

Offline Arantor

  • Resident Overthinker
  • SMF Friend
  • SMF Legend
  • *
  • Posts: 68,361
    • Arantor on GitHub
Re: Moving to something like Handlebars (after 2.1)
« Reply #13 on: October 08, 2017, 03:33:07 PM »
Quote
And 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*.

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

That only gives you the echo. It doesn't give you highlighting of the contents. I *have* highlighted templates.

Quote
And 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.

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

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.

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

This is why you separate them.

Quote
Which 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.

Quote
Downplaying 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)

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

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.

Quote
But 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)

Quote
I 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.
Logged
To assume is to hope that those who came before had the presence of mind and capacity to implement the dreams of those who would come after.

You either die a hero or live long enough to see yourself become the villain. It seems you have chosen which, and now I must do the same.

Offline Gwenwyfar

  • Customizer
  • Sophist Member
  • *
  • Posts: 1,025
  • Gender: Female
    • Gwenwyfar on GitHub
Re: Moving to something like Handlebars (after 2.1)
« Reply #14 on: October 08, 2017, 05:23:32 PM »
Quote
The 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.

Quote
That 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: Gwenwyfar
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.
and
Quote
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

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

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

Quote
This 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

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

Quote
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)
I'm not asssuming anything, I'm discussing the issue on its own merits, regardless if it's your problem or somebody else's.

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

Quote
I'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.
Logged

Offline 青山 素子

  • Server Team
  • SMF Super Hero
  • *
  • Posts: 17,029
  • 戦場ヶ原、蕩れ!
    • srvrguy on GitHub
    • @motokochan on Twitter
    • Nekomusume Moe
Re: Moving to something like Handlebars (after 2.1)
« Reply #15 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 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:

Quote from: Gwenwyfar on October 08, 2017, 05:23:32 PM
Quote from: Gwenwyfar
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.

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 PM
Quote
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

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 PM
Quote
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.
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 PM
Quote
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.
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 PM
Quote
This 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 PM
Quote
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.
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.
Logged
Motoko-chan
Director, Simple Machines

Just because it's pouring down doesn't mean we're gonna drown. There's a time when all you can say is let it rain - Mat Kearney (Let It Rain)

Note: Unless otherwise stated, my posts are not representative of any official position or opinion of Simple Machines.

Offline Suki

  • Developer
  • SMF Super Hero
  • *
  • Posts: 15,199
  • Kaizoku Jotei
    • MissAllSunday on GitHub
    • SMF mods
Re: Moving to something like Handlebars (after 2.1)
« Reply #16 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.

Logged
Disclaimer: unless otherwise stated, all my posts are personal and does not represent any views or opinions held by Simple Machines.

Look at them. They're just asking for it. Maybe the human race deserves to be wiped out.

Offline 青山 素子

  • Server Team
  • SMF Super Hero
  • *
  • Posts: 17,029
  • 戦場ヶ原、蕩れ!
    • srvrguy on GitHub
    • @motokochan on Twitter
    • Nekomusume Moe
Re: Moving to something like Handlebars (after 2.1)
« Reply #17 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).
Logged
Motoko-chan
Director, Simple Machines

Just because it's pouring down doesn't mean we're gonna drown. There's a time when all you can say is let it rain - Mat Kearney (Let It Rain)

Note: Unless otherwise stated, my posts are not representative of any official position or opinion of Simple Machines.

Offline Suki

  • Developer
  • SMF Super Hero
  • *
  • Posts: 15,199
  • Kaizoku Jotei
    • MissAllSunday on GitHub
    • SMF mods
Re: Moving to something like Handlebars (after 2.1)
« Reply #18 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.
Logged
Disclaimer: unless otherwise stated, all my posts are personal and does not represent any views or opinions held by Simple Machines.

Look at them. They're just asking for it. Maybe the human race deserves to be wiped out.

Offline Suki

  • Developer
  • SMF Super Hero
  • *
  • Posts: 15,199
  • Kaizoku Jotei
    • MissAllSunday on GitHub
    • SMF mods
Re: Moving to something like Handlebars (after 2.1)
« Reply #19 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.
Logged
Disclaimer: unless otherwise stated, all my posts are personal and does not represent any views or opinions held by Simple Machines.

Look at them. They're just asking for it. Maybe the human race deserves to be wiped out.
Pages: [1] 2 3 4   Go Up
« previous next »