SMF 2.1.4 has been released! Take it for a spin! Read more.

Main Menu

Moving to something like Handlebars (after 2.1)

Started by Arantor, October 08, 2017, 09:27:04 AM

Previous topic - Next topic


Well, I was reading the nice conversation. I decided to support the idea, it seems far better compared to current system. So, lets do this for next version. But unfortunately, I won't be much help in the process considering my lack of knowledge related to situation (I don't want to call it template).


Yep, composer or git-submodules. I like composer more.

This will be a dealbreaker in the sense that users won't be able to just get a copy of the files on github and install SMF. I honestly don't know if thats a good or a bad thing.

Theres also the thing about modifications, how would they be able to add their own dependencies to an already composer-locked package. I didn't find a good and reliable way to do that.
Disclaimer: unless otherwise stated, all my posts are personal and does not represent any views or opinions held by Simple Machines.


The really fun part is when you tell Composer to grab something and you end up getting a git submodule anyway ;)

I don't think there is a good way to solve dependencies via Composer without embedding Composer, which is definitely not recommended.


Ah yes, I've seen weird cases like that. Theres also the thing about dependencies been fetched with their entire set of tests/tools and their .git folder too. Its annoying but the composer guys still refuses to adress it. I suppose that can be deal with on nightly builds.

I think the only reasonable thing to do about modifications is for them to have their own register and autoload thing, one that can be re-do whenever a mod with a dependency is been installed. Nothing fancy, something like what 2.1 already have combined with a libraries folder.
Disclaimer: unless otherwise stated, all my posts are personal and does not represent any views or opinions held by Simple Machines.


Random fact, did you know the creator of Composer is also one of the phpBB devs? The same one that, incidentally, in the official Sphinx plugin decided the best way to tell the Sphinx search daemon to update was to kill -9 it and restart it every 15 minutes? Anyway, I digress.

Big fan of having an autoloader (been trying to argue that one for years), and if it's PSR-0/4 compliant you can just use it even for core classes (like XF does) and then only have Composer handle dependencies. (Ideally PSR-4 but that also implies namespacing)


I was aware about composer and phpBB but have no idea about Sphinx.  I can't find the github issue where they discuss adding something to stop fetching tests but I do remember their arguments againts it were hilarious.

Yes, use composer to fetch and build and let SMF handle the registration and autoload. Namespaces can be applied in a light approach, (aka Model\MyModel) just so we can autoload all the stuff under a single standard.

For my mods I blatanly stole composer autoload and used a modsettings var to register the dependencies, its not ideal but this allowed me to not worry about multiple mods trying to register and overwritting themselves. A similar approach can be done. You register your dependencies somewhere (db, env file, raw php, dunno) and let SMF do the autoloading stuff for you.

What about ruting? if we move somewhere else all the stuff that doesn't belong in index.php I actually like and am OK with the current approach. Its quite simple, works and it doesn't hardcode words like current routing systems, good for i18n. Or go with a routing  and have some more control over routes, grouping, apply some low level permissions, middlewares, etc.
Disclaimer: unless otherwise stated, all my posts are personal and does not represent any views or opinions held by Simple Machines.


Whenever I've built autoloaders, I've been very unsubtle about it. LevGal has an autoloader that IIRC just checks that the requested class is in the LevGal namespace and if so just tries to map directly to filesystem. Other times I've literally just played map to filesystem.

The thing about routing is complicated because while you can adjust routing, it really needs to be a wider thing - because all the links in templates etc. also need to be rewritten if you're going to have translated or changeable route names. Some kind of link builder that is aware of the route rewriting needs to be used throughout (which is ideal fodder for a template engine), so it can rewrite the links spat out in the HTML (because this is 2017, doing it with a buffer rewrite isn't clever)

The great thing about routing is that you don't have to explicitly tie anything to a path if you don't want to - but it's worth considering.


Translating and/or allow to change route names sounds like a real pain in the posterior. This is why I didn't cheerfully rooted for using a proper routing system.

I was thinking more in the lines of Laravel middlewares, define your route and tell SMF, hey this route needs X, Y and Z applied before calling the actual route. Perhaps it also needs A B and C after the route has been called.

Organize/group routes, stuff that belongs to admin, to user, to posting, things like that.
Disclaimer: unless otherwise stated, all my posts are personal and does not represent any views or opinions held by Simple Machines.


But you'd still have to do it even if you left it with the SMF methodology... All you're proposing is changing the implementation, not the workload it has to do.

Even if you made it Laravel middleware, that still doesn't solve the issue of translated route names, for which you still need all the infrastructure on both sides to cope with it.


No no, forget about translatable routes. That wasn't my intention.   Keep the current approach, just beef it up a bit. I'm more interested in applying pre and post logic everytime an action is called. Say if an action requires the user to be logged in, add an auth middle ware to automatically send the user to the login page if it hasn't logged in. Same for permissions

If an action is going to respond a json object automatically send the correct headers. Things like that.
Disclaimer: unless otherwise stated, all my posts are personal and does not represent any views or opinions held by Simple Machines.


Setting headers is not something that should be handled at the routing level, that's something that the route itself manages as per PSR-7.

As for translating routes, you said i18n, so I assumed that's what you wanted to be able to do... Some mileage would be gotten out of looking at existing platforms that can do this (XF certainly can do this with its route filters stuff)


Yeah my wording wasn't the best, I mean the current approach action=profile;u=1 is somehow better for i18n than a full (English hardcoded) route like /profile/user/chuck_norris.

I wouldn't dare to try translatable routes for all the things you pointed out, besides, this means the user will have to have their prefered language on install, something that rarely happens unless we find a reliable way to download their language on install or something like that.

By setting headers I mean something like this:


SMF will detect that last bit and will respond accordingly without having the set the response in the controller or the route (besides setting the actual data to send of course).  Of course this will be an option rather then the default thing to do.

This will be useful for controller getters that directly communicate with some model to get some data. Combiend with a good ORM and you will have an easy and modular way to fetch data.

Of course I know not everything is going to be handle that way and that part of the charm of SMF resides on how we retreive data, thats def something that should remain.
Disclaimer: unless otherwise stated, all my posts are personal and does not represent any views or opinions held by Simple Machines.


I'm stealing China's Wall. Ignore all their demands to give it back ;D


Finally, a genuine reply.

First, as I imagined you are stretching the definitions for a logical fallacy. Slippery Slopes are a moot point for one simple reason:

Slippery Slopes are not Logical Fallacies.

It's a myth, a misconception by the skeptic community. Probably because doomsday sayers make much use of Slippery Slopes in their antics, slippery slopes which never come true. But here is the thing: they never come true because the slippery slopes they describe are filled with actual logical fallacies, so the logic doesn't follow, so they never materialize, but not because Slippery Slopes aren't real. They are a real thing, even on sheer logic they are a real thing, they can even be mathematically described as systems of redundant exponential growths.

They are even more real if you're working with a non-logical system, a system where human behavior is a dominant factor. For human behavior is arbitrary, is not bound by the rules of logic, it has great potential for redundant growth. That's why the concept is taken so seriously in fields such as Law Making or Social Engineering.

You can't refute an argument by simply calling it a slippery slope, you have to refute the underlying logic inside the Slippery Slope, why the events don't follow, why the slippery slope will not happen. So far, all you have pointed is that opposite forces happen as well, which is a pretty obvious point, but you never say which of them end up dominant on the long term, which is my point.

As for strawmanning, I would like to know where. This is about Template Engines, something which greatly affects theme developers. It's about the upsides and downsides such engines will have on theme development. If the discussion went somewhere else... it's a thing discussions do, they wander far to give points, give examples, makes connections, make analogies to better explain, to make the idea clearer in everyone's mind... the focus has never been lost however.

Same for Ad Hominem. By the Law of First Aggression I know I wasn't the first to attack directly the person professing an idea rather than the idea itself. Actually, so far in this whole discussion you have been the only one to say I'm being an "arrogant and elitist" rather than deal with the idea itself.

My probing on your behavior is not an attack. You were behaving against everything you have professed so far. Either you changed your mind about some of your beliefs or you're being a hypocrite. Good to know it's the first, shows good character :)

As for your other points:

Performance considerations are not just about how fast the instructions will happen, most of the time these are negligible. It's mostly about scalability, debugging and what kind of code such philosophies attract. As you use more and more of these higher layers, the small losses on performance starts to stack up to become greater losses, for a variety of reasons, from lack of control, to bloat, to improper form. So you end with the famous 90% of the time will be spent on 10% of your code. And chunks of that 10% will be all spread over  the bloat generated by the higher abstractions, in small chunks of 0,5% there, 0,7% some 500 lines down the code... 2,5% at most, that's one of the reasons it becomes a debugging hell. And all that is even assuming you're using the engines smartly. Dumb code will be even worse.

And yes, dumb code happens everywhere, it's just statistics, but by removing basic PHP requirement you are giving it MORE room for it to happen. It's not about whether it happens or not, but at which scale they will start to happen.

Something similar (based on this kind of philosophy) has already affected the status quo of css. Bootstrapping is one of the most popular tools out there, and it was one of the worst things that ever happened to the Front-End Industry. It has gotten to the point that the browser has to ignore 90% of the code generated by such tools. 90% of the code is just sheer bloat. 90% of the lines are meaningless. Completely meaningless, wasteful and useless. This is not hyperbolic, just one of the latest work I did, to convert some code to be accepted under certain limitations, went from JS + html + css files totaling 158kb to html + css files at 6kb. Even the links were a sort of JS button, I suppose adding an <a> is too complicated. Bad JS like this is no news, but you see the same effect in css. I get so many jobs where what has been achieved in 3000 lines of code could be achieved with 300, on better user performance at that. Many times it's just better to scrap everything to the trash and start over, because it's such a ball of knots impossible to untangle, it's a waste of time to try to debug it, it's better to just start over. The saddest part of it all is this sort of thing is very widespread in the industry, so it's not just one or another code that does this, it's most of them.

And then on top of this people build tools to "clean the css", "clean that other piece of code", and are amazed to see "how well it works" when it reduces the files from 120kb to measly 15kb (which it should have been all along). And now in most people's mind, if you build a site without bootstrap or similar, its because you don't know what you are doing, when it should be the exact opposite.

Why all that? Most bootstrappers would answer you: "Dealing with CSS is too much work, it takes too long...". It would be akin to backend developers saying CGIs or databases are too complicated, too much of a hassle to deal with. It's absurd.

Users vs themers: They are miles apart, starting at the basics (one should know, at the very least, HTML/CSS and the other will possibly not even know what that is), and I think that should be a separate discussion to see what can be done to make user life easier. One of the common things they want to edit can already be helped by adding sass variables (if by the time we do this, css variables are not already usable by themselves, but progress in new css functions is slow as always).

As for what this particular discussion reflects on the common user, I do not think whatever choice is made (to use a template engine or not) will make much difference to them. You could even say using plain PHP would benefit common users slightly more than anything else, based on the fact all code editors highlight php files properly by default (which many, if not most, common users will not even have), while other file types are often a downloadable package, that surely, they won't even know they have to get, or how. For most users, a template engine's code is just as greek as PHP, it's just an incomprehensible block of text-code.

QuoteThe 'one syntax for another' argument is interesting. Let me reframe the situation, maybe it'll help you understand my perspective: why does TypeScript exist? what about CoffeeScript? These things literally do nothing that JavaScript can't do (because they compile down to JavaScript), but people like them because they abstract away some of the really annoying things in the underlying language. That's all that's going on here, really.
I do not know about TypeScript, but Coffescript doesn't seem to be a equivalent comparison. There could be cases in which such changes make sense, for example if you are dealing with a language that has terrible syntax to begin with, but this is not the case for PHP. The only really bad aspect of it in it are the echoes for HTML, and it is overkill to change everything else just to make this one part better. And, frankly, some (not all) of these templating engines manage to make the rest of the syntax even worse. If the idea is to have the templates redone and simplified to have less PHP in them, there is not going to be much difference in question of learning/usage curve when all you are doing is replace one way to write an if or a variable with a different one. It becomes simply unnecessary for something that does not come consequence-free. There simply isn't enough value in this change.

QuoteThe kicker though, is that this debate reminds me of me. Everything I see in this debate echoes me, and this isn't a good thing. It makes me begin to question how much of a force I personally have been for good in this environment, and makes me think that my naive idealisms over the years have encouraged others to do the same - and I'm not convinced in some of those positions of argument that I was right. There was certainly a time when I argued against frameworks as a whole, and certainly a time when I argued against template engines, too. I find a lot of the same old issues, though, an over-cautious conservatism at a time when the entire fleet of platforms in the forum space are routinely castigated for failure to innovate, and it's harder to drive innovation on any level when the platform decides it wants a barrier to entry for even modest things like putting something to the screen. It's the same reason we don't use C to build a forum, we like having the abstractions. I'm just arguing for one more abstraction because it feels like it benefits everyone.
The wonders of growing older and noting the ****** you did before :D

I have been in the position of denying frameworks as a whole in the past too, it is the case that you mistake the erroneous usage with the thing itself. Yes, frameworks have their place. Maybe even bootstrap could have a useful use case somewhere, but it would be so specific it almost doesn't justify it's existence. It is however something to be very careful with to not fall into the same trap that most have fallen. You need to choose well what you will use and where, even more so when you can't rely on what most people are doing being right, since so often it is quite the opposite. When the Status Quo bar is so low, following it should be decided on much caution.

Quote* people who are admins who want to do simple customisations of their own - these people aren't programmers, they just want to insert the bit of JavaScript for Google Analytics by copy and paste like GA tells them to, except surprise, they have to figure out quoting syntax. Or the people who just want to tweak a little bit like the header. They're then dealing with what amounts to mostly HTML and CSS, as opposed to PHP, actual HTML and CSS - and all evidence suggests that people find this easier to do simple changes. There's a reason people like the theme stuff in XenForo and IPB - it lets them make little changes without any hassle. They feel empowered, they feel like they can own something even though they're not technical. Not every SMF admin is a programmer or a designer.
Yes, that is nothing I disagree on, but this again goes back to the example I gave here, you don't need to use one of these templating engines to fix that. I'm all for improving admins customizations features, but it should not do so at the expense of developer tools, they're different things.

Also, refer to the user vs themers above for the rest, and my reply to Suki below on the same subject.

Quote* people who are theme people get to play with something closer to what they normally use rather than stepping through hoops. Yes, it means people can do stupid things more easily - but at the same time, it lets people who know the tools do so without having to remember to escape quotes. And people will always do stupid things, this shouldn't be a barrier to making tools easier for non-stupid use cases.
Again, same as above. Yes, things could be better. But why these templating engines over other methods?

Quote* when I build Moodle plugins, even though I'm not even required to use the template system because Moodle doesn't mandate it (because Moodle doesn't use it itself for most of its plugins for historical reasons), most clients are requesting it so they can have a designer customise it without knowing Moodle's code innards. And Moodle certainly has PHP 'templates' in its core in the renderer system. Though that's a level of mind-killer with its many classes and layers of abstraction that I wouldn't impose upon anyone. But I digress - designers are the people who would like this.
Just as what happens anywhere, you have good and bad professionals, and those focused in a multitude of areas. You'll also find many designers who refuse to work without bootstrap or other css frameworks, that doesn't mean we should do as they say. You will never be able to please everyone, and I believe we should focus on getting good themers into SMF, not pleasing as many people as possible just for the sake of it.

QuoteAlso, on an ironic note, this debate somehow ended up talking about C. Who remembers the doomed project smflib, that reimplemented bits of SMF as C so they would be PHP extensions for the really really big forums? I do...
This is the first time I hear about this. This seems interesting to see, in the least :D


QuoteEven though multiple reasons were exposed, you chose to focus solely on this point.  You haven't addressed any point about helping development, for example.

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.
You just showed you clearly haven't given proper attention to my posts then.

I'm not criticizing it for the sake of criticizing it, I'm trying to give better solutions.

QuoteThey aren't assumptions. It is quite clear you haven't used a template engine. It is quite clear you haven't worked on a big project either. All the arguments you try to make were already made a few years ago. Really sorry to say this to you but get on with the times
They are assumptions for you don't know me. You don't know my history, you don't know the projects I have worked on, you don't know the people I know.

"Get on with the times" is a bull****** argument. It's pure rhetorics. It implies that whatever is "new and popular" is always better. It's a progressive misconception. Mankind doesn't always go forward, there are many new ideas and concepts that are crap, many popular customs that are wrong. It's a terrible argument.

Just FYI, I have worked from Real State companies to Financial Data companies. I know how big projects look like, I know how they behave. It's a myth you need frameworks or huge teams to work on them. On the contrary, a small smart team working hard and close to the big bosses produce better output than huge teams divided by many hierarchies of command, working on "easy to write and read" languages as frameworks. These kind of projects tend to develop to bloated debugging hells, when the project doesn't fall so far off the rails where you have to simply scrap everything and start over, losing millions in the process (or, as is most often the case, they just keep going while patching it over with even more bloat).

I have also met with people who are actual low level coders who work on huge projects with no more than a dozen teammates. The army, for one, still uses assembly coding for everything, from simple trajectory calculating algorithms to whole missile guiding system. Not because they deal with too many hardware input, you can code around hardware input even on higher levels as it happens with car's softwares, but different than car's softwares, bloated bugged code means dead people for the army, so they have to set the bar higher.

My point here is: You don't know me and it's possible to do work well without crutches, without frameworks and layers upon layers of higher abstractions, even on big projects. PHP + HTML/CSS is fine, it's on a fine balanced level of performance and abstractions. You're making assumptions.

QuoteAgain, the chose for using a template engine comes from measuring all those aspects (and others who aren't directly related to programming) and based on all that info we decided a template engine is the best choice.
And I'm saying they are a bad choice and saying why I think so. Or are you above making bad choices and decisions?

QuoteBy definition, an engine will keep presentation away from logic, this means heavy logic CANT be performed on a theme file. This actually prevents doing dumb stuff.
Of course, the engine itself will do the dumb stuff for the developer. They just hide the logic from the developer but there still an underlying logic working in there for which the developer loses control, and in many situations the standard engine logic will not fit the best requirements for one situation, that's why high abstractions will always lose efficiency sooner or later. The engines will try to fit a ball in a square shaped hole sooner or later and the developer, most of the time, will have no knowledge about it, let alone control over it.

Reducing the tools available is also a two-edged sword. We are talking about something that theme makers will use, we should not be removing options from them. Developers need profiling and precision tools, not cradles and playgrounds so he doesn't hurt or learn anything.

QuoteThis is yet another thing you conveniently ignore. Whoever gets in charge of building the next version has to take into account all the different types of people who are going to use SMF. From devs to themers to admins to users to hostings.
Ignore my ass. So far this discussion started on and is focused around Themers, because they are the ones who will have to work with the Template Engine. And here's the thing you don't seem to understand:

Themers are not users. Themers are developers, for they develop themes for users to use. They're Front-end developers, not Users. It's their job to know basic PHP to develop themes for a PHP Forum, because they're developers, not users. Otherwise you'll have developers who have no idea where they are developing upon and that makes for bad development process. It's good form to require basic PHP knowledge to develop a theme for a PHP Forum. By removing such requirements you do gain popularity, you do gain all those developers who don't care about PHP (and somehow, are perfectly fine learning a templating engine that will have much of the same stuff), but at the expense of losing good form. Now you have more room for bad form, and such system will invariably attract bad form sooner or later, it's what has happened in all similar systems.

What are you essentially arguing is that every user should have the option to be a developer, therefore we should simplify developer tools for developers so users can develop as well. That's why I call it dumbing it down.

This shouldn't be about forum users, this should be about developers, because it affects their work much more than the common user, be it a member or an admin.

QuoteI was saying I could reply with random text and you will still focus on your ideas. This whole thing was been a big waste of time since you don't really want to have a discussion, all you want to do is showing you are right.
So you would rather have me focus on random text unrelated to the discussion than the discussion itself then? Because otherwise that is a useless point.

I'm pressing the same key because you are making light of it and avoiding it so far.

And again, the one that has ignored most of what has been argued is you. I have already replied to all your points (and if there is one you believe I have not addressed, then please point it out and I will do so). If you wish to have a fair discussion, maybe you should start debunking the given arguments and answering the questions instead of avoiding them and lowering the level down to rhetorics.

It's actually dumbfounding that you come in all grandeur about your experience as PM and then tell me to get off my high horse.

As a general note, I'll say this again, since there seems to have been some confusion in this regard:

I am against the use of the proposed templating engines (or similar ones). I am not against making the templates better. I am also not against trying to find a better alternative to fixing the aforementioned problems with echoes either, while keeping the downsides to a minimum. I'm following the old engineering mantra: "There's a better way to do this". We should be making it easier for budding developers to learn basic PHP, not replace its learning curve entirely with something else. You do not need to use a complete template engine to do any of the above, doing that just brings more problems than it solves. I don't believe the immediate gains in popularity such engines bring is worth all the headaches they will cause down the road.
"It is impossible to communicate with one that does not wish to communicate"


I was going to rebut the various points, but I realised there wasn't any real point to it, we can just continue talking past each other, stubbornly clinging on to our world views.

All I'll say is, 3 years ago I was you. I'm... really not that now.

I should stop suggesting things, it only ends up being a waste of everyone's time.


I'm sorry you feel that way.

And by the way, a note that somehow escaped in there about "It makes me begin to question how much of a force I personally have been for good in this environment":

Maybe I'm not the right person to say this, but at least for me it seems like much of it was :)
"It is impossible to communicate with one that does not wish to communicate"


Yes, an excellent discussion.    I learned a lot.

Developers disagree.   It's what they're best at...
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp


You know, I kinda wonder where are all those noisy themers who were very vocal about how terrible SMF themming system is and how much weight we gave to backend instead of frontend...  here we are, a few years later actually defending their case  :laugh:
Disclaimer: unless otherwise stated, all my posts are personal and does not represent any views or opinions held by Simple Machines.


Quote from: Suki on October 20, 2017, 04:52:38 PM
You know, I kinda wonder where are all those noisy themers who were very vocal about how terrible SMF themming system is and how much weight we gave to backend instead of frontend...  here we are, a few years later actually defending their case  :laugh:

They all left already for other platforms where theming isn't so hard.

青山 素子

Quote from: Arantor on October 20, 2017, 05:30:37 PM
They all left already for other platforms where theming isn't so hard.

Exactly this.
Director, Simple Machines

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


I am a self theme maker, meaning I make themes for myself most of the time. There are occasions that I have released some on other platforms. I wanted to say having any type of template system would be great, I am not saying saying something like Xenforo v2 I understand many do this here just to help out, but having a system would improve the act of making themes. I am not a coder by any standards but it is mush easier to add css or a html then edit php.
Check out this great sites.
KnD Hosting