Advertisement:

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

Online Gwenwyfar

  • Customizer
  • Full Member
  • *
  • Posts: 678
  • Gender: Female
    • Gwenwyfar on GitHub
Re: Moving to something like Handlebars (after 2.1)
« Reply #20 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
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: 青山 素子
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.
That particular comment you quoted was referring to:
"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.
« Last Edit: October 12, 2017, 02:26:55 PM by Gwenwyfar »

Offline Suki

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


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

Online Gwenwyfar

  • Customizer
  • Full Member
  • *
  • Posts: 678
  • Gender: Female
    • Gwenwyfar on GitHub
Re: Moving to something like Handlebars (after 2.1)
« Reply #22 on: October 12, 2017, 03:09:57 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
Well, it's their loss. I don't think it's a mentality we should be fostering around here.

Also: who makes said template engines and everything else they use? ;D

Offline Suki

  • Customizer
  • SMF Super Hero
  • *
  • Posts: 15,083
  • Kaizoku Jotei
    • MissAllSunday on GitHub
    • SMF mods
Re: Moving to something like Handlebars (after 2.1)
« Reply #23 on: October 12, 2017, 03:17:50 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.

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

Online Gwenwyfar

  • Customizer
  • Full Member
  • *
  • Posts: 678
  • Gender: Female
    • Gwenwyfar on GitHub
Re: Moving to something like Handlebars (after 2.1)
« Reply #24 on: October 12, 2017, 03:47:29 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.
I 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.

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.
« Last Edit: October 12, 2017, 04:42:30 PM by Gwenwyfar »

Offline Suki

  • Customizer
  • SMF Super Hero
  • *
  • Posts: 15,083
  • Kaizoku Jotei
    • MissAllSunday on GitHub
    • SMF mods
Re: Moving to something like Handlebars (after 2.1)
« Reply #25 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.
« Last Edit: October 12, 2017, 05:34:53 PM by Suki »
Look at them. They're just asking for it. Maybe the human race deserves to be wiped out.

Online Gwenwyfar

  • Customizer
  • Full Member
  • *
  • Posts: 678
  • Gender: Female
    • Gwenwyfar on GitHub
Re: Moving to something like Handlebars (after 2.1)
« Reply #26 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".

Offline Suki

  • Customizer
  • SMF Super Hero
  • *
  • Posts: 15,083
  • Kaizoku Jotei
    • MissAllSunday on GitHub
    • SMF mods
Re: Moving to something like Handlebars (after 2.1)
« Reply #27 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.
Look at them. They're just asking for it. Maybe the human race deserves to be wiped out.

Online Gwenwyfar

  • Customizer
  • Full Member
  • *
  • Posts: 678
  • Gender: Female
    • Gwenwyfar on GitHub
Re: Moving to something like Handlebars (after 2.1)
« Reply #28 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.

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

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

Offline Kindred

  • The Mean One
  • Support Specialist
  • SMF Legend
  • *
  • Posts: 55,098
  • Gender: Male
    • Kindred-999 on GitHub
Re: Moving to something like Handlebars (after 2.1)
« Reply #29 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
Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

Offline Arantor

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

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

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

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

Online Gwenwyfar

  • Customizer
  • Full Member
  • *
  • Posts: 678
  • Gender: Female
    • Gwenwyfar on GitHub
Re: Moving to something like Handlebars (after 2.1)
« Reply #32 on: October 16, 2017, 06:56:09 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
Nope, they haven't.

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

Quote
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.
So now we are talking about average admins? That is quite a long distance from themers.

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.

Quote
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.
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.
« Last Edit: October 16, 2017, 07:13:09 PM by Gwenwyfar »

Offline Suki

  • Customizer
  • SMF Super Hero
  • *
  • Posts: 15,083
  • Kaizoku Jotei
    • MissAllSunday on GitHub
    • SMF mods
Re: Moving to something like Handlebars (after 2.1)
« Reply #33 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.
Look at them. They're just asking for it. Maybe the human race deserves to be wiped out.

Online Gwenwyfar

  • Customizer
  • Full Member
  • *
  • Posts: 678
  • Gender: Female
    • Gwenwyfar on GitHub
Re: Moving to something like Handlebars (after 2.1)
« Reply #34 on: October 16, 2017, 10:32:17 PM »
Quote
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...
Quite the assumptions you make on my own knowledge there.

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.

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

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!"

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

Offline Arantor

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

  • Customizer
  • SMF Super Hero
  • *
  • Posts: 15,083
  • Kaizoku Jotei
    • MissAllSunday on GitHub
    • SMF mods
Re: Moving to something like Handlebars (after 2.1)
« Reply #36 on: October 17, 2017, 08:55:04 AM »
meh... you keep on focus on a single thing and conveniently avoid anything else:

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.


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


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.

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.

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?
Look at them. They're just asking for it. Maybe the human race deserves to be wiped out.

Offline Arantor

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

  • Support Specialist
  • SMF Hero
  • *
  • Posts: 2,667
  • Gender: Male
Re: Moving to something like Handlebars (after 2.1)
« Reply #38 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....

Offline Arantor

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