[NEW THEME] 4. JS frameworks & approach

Discuss requests for comments/changes posted in the Issue Tracker for the development of phpBB's style.
Forum rules
Please do not post support questions regarding installing, updating, or upgrading phpBB or modifying styles of released phpBB versions. If you need support for phpBB please visit the Support Forums on phpbb.com.

If you have questions regarding creating styles please post in Styles Support & Discussion to receive proper guidance from our staff and community.
Post Reply
User avatar
hanakin
Infrastructure Team
Infrastructure Team
Posts: 873
Joined: Sat Dec 25, 2010 9:02 pm
Contact:

Re: [NEW THEME] 4. JS frameworks & approach

Post by hanakin » Sun Sep 30, 2018 11:26 pm

Well sort of we are not nessecarily looking to make everything js. We just want to completely move to an api driven backend to ensure we have separate concerns. As it stands right now there is a lot of front-end in the backend do to a lot of old functionality in the core. This limits a lot of the interface design as it means that we have to recode whole core features to make certain changes to the front-end. For example currently the ucp/mcp are all hard coded in the way they function meaning that we can not load certain aspects with an Ajax request. It also means they are completely scoped in there accessibility. That is to say you can not link directly to a specific section of the ucp from outside the ucp! This is what we truly aim to solve. Do not get me wrong certain aspect could truly benefit from Ajax via an api as well which is a huge advantage not just for core but for extensions

User avatar
Ger
Registered User
Posts: 293
Joined: Mon Jul 26, 2010 1:55 pm
Location: 192.168.1.100
Contact:

Re: [NEW THEME] 4. JS frameworks & approach

Post by Ger » Mon Oct 01, 2018 8:24 am

hanakin wrote:
Sun Sep 30, 2018 11:26 pm
This is what we truly aim to solve. Do not get me wrong certain aspect could truly benefit from Ajax via an api as well which is a huge advantage not just for core but for extensions
Agreed. As an extension author, I have more than once settled for a suboptimal approach or even had to skip functionality because of this.
Above message may contain errors in grammar, spelling or wrongly chosen words. This is because I'm not a native speaker. My apologies in advance.

User avatar
snover
Registered User
Posts: 4
Joined: Tue Sep 18, 2018 12:16 am

Re: [NEW THEME] 4. JS frameworks & approach

Post by snover » Thu Oct 04, 2018 5:49 pm

hanakin wrote:
Sun Sep 30, 2018 11:26 pm
We just want to completely move to an api driven backend to ensure we have separate concerns.
Are you talking about implementing a server-side MVC architecture? Are you talking about rewriting phpBB as a set of microservices? Are you talking about reimplementing the back end as a REST/GraphQL/SOAP/etc. service instead of a web page generator? Are you talking about converting procedural code inside the viewtopic.php/viewforum.php/etc. files to object-oriented code? Something else? An API is just a defined set of functions and data structures, so this could mean just about anything.
hanakin wrote:As it stands right now there is a lot of front-end in the backend do to a lot of old functionality in the core.
How are you defining “front-end” and “backend” in this sentence? In client–server development, “front end” usually refers to the client-side code (so on the web, the HTML/CSS/JS that is executed by the browser), and “back end” refers to the code which runs on the server, but it doesn’t seem like that is how you are using these terms here. Are you really talking about presentation logic versus business logic? Are you talking about whatever is in the “styles” directory versus the rest of phpBB code? Something else?
hanakin wrote:Well sort of we are not nessecarily looking to make everything js […]
[…] it is sort of stubborn on mobile […]
There are many benefits […]
I am having a lot of trouble with the level of vagueness that I feel keeps being brought to this conversation. My goal in saying this is not to be mean or make anyone feel bad, but rather, to explain a serious barrier I am having in achieving an understanding of your thinking and being able to provide useful feedback to you. I feel like I am always having to guess or read between the lines in order to interpret intent. I cannot confirm or refute many of your points because the claims being made are too ambiguous to respond to. I would appreciate it if you could use more specificity—what specific problems exist with current thing X, what specific benefits you think exist with new thing Y, what specific design pattern you are wanting to implement for this next development sprint/phase/whatever—so I can actually respond to what you are thinking.
hanakin wrote:Prosilver is a nightmare to maintain for the devs and its the one thing holding back the application from moving forward. It has to go. It's not possible to understand what is necessary and what is not due to how badly it was coded most times.
Either you know what is necessary, in which case you can clean things up, or you don’t know, in which case you can’t make a new theme because you can’t know what needs to be in the new theme either. Could you please explain this apparent contradiction?
hanakin wrote:The dropdown, not to sound confrontational but the use case you linked while can work somewhat is not without its flaws and problems.
My goal was merely to point out that it is not impossible to implement this kind of basic UI control without JS, as had been claimed. The approach I demonstrated is also not the only approach—using <details> instead of a checkbox is more semantically valid and requires no extra markup, so long as you don’t care about using a polyfill for IE and current versions of Edge.
hanakin wrote:In fact, as it is right now the most asked for features are mentions and wysiwyg editors which both have no fallbacks.
The fallbacks for these features are simply to continue to deliver a plain HTML form, as exists today, rather than doing something like building an editor in Vue which won’t function at all without JS.

It seems like there is a shared understanding that there’s a mess right now where HTML exists everywhere, even in the language dictionaries; where HTML and other strings get pre-generated and passed directly to views (templates) instead of raw data; and where views don’t have access to a controller to request data that phpBB didn’t think to assign in advance. Fixing that mess is orthogonal to whether phpBB should add some JS view framework, though.

As this conversation continues I feel more confused about why a discussion of JS frameworks is even happening now. Unless the goal is to dump server-side rendering—which it sounds like is not the case (and would be a terrible idea since it would harm the user experience, prevent security-conscious users from using phpBB, and damage SEO)—it feels very premature. I can only reaffirm my opinion that the best approach for this current phase of development is to incrementally clean up and leverage what exists currently without introducing new technology.

CHItA
Development Team
Development Team
Posts: 156
Joined: Thu Mar 12, 2015 1:43 pm
Location: Budapest, Hungary

Re: [NEW THEME] 4. JS frameworks & approach

Post by CHItA » Thu Oct 04, 2018 9:14 pm

snover wrote:
Thu Oct 04, 2018 5:49 pm
Are you talking about implementing a server-side MVC architecture? Are you talking about rewriting phpBB as a set of microservices? Are you talking about reimplementing the back end as a REST/GraphQL/SOAP/etc. service instead of a web page generator? Are you talking about converting procedural code inside the viewtopic.php/viewforum.php/etc. files to object-oriented code? Something else? An API is just a defined set of functions and data structures, so this could mean just about anything.
All of the above is planed to some extent, except microservices. I think he was talking about a REST API here, which would support having AJAX functionality where it makes sense.
snover wrote:
Thu Oct 04, 2018 5:49 pm
How are you defining “front-end” and “backend” in this sentence? In client–server development, “front end” usually refers to the client-side code (so on the web, the HTML/CSS/JS that is executed by the browser), and “back end” refers to the code which runs on the server, but it doesn’t seem like that is how you are using these terms here. Are you really talking about presentation logic versus business logic? Are you talking about whatever is in the “styles” directory versus the rest of phpBB code? Something else?
It was mostly about what you also mentioned at the end of your post:
snover wrote:
Thu Oct 04, 2018 5:49 pm
It seems like there is a shared understanding that there’s a mess right now where HTML exists everywhere, even in the language dictionaries; where HTML and other strings get pre-generated and passed directly to views (templates) instead of raw data; and where views don’t have access to a controller to request data that phpBB didn’t think to assign in advance.
snover wrote:
Thu Oct 04, 2018 5:49 pm
Either you know what is necessary, in which case you can clean things up, or you don’t know, in which case you can’t make a new theme because you can’t know what needs to be in the new theme either. Could you please explain this apparent contradiction?
Well, my understanding is that we came to the conclusion that it is easier to clean things up if we redesign the HTML/CSS/JS than to clean things up (I assume you talk about refactoring the code here). prosilver has a lot of added functionality to it which were not considered when it was designed. That is one of the main problems, as to refactor it to a state that we would like to achieve would probably mean rewriting everything. We would also have to touch all files anyway to for example convert them to the twig syntax, so I don't think it that the additional effort (if there is any) needed to recreate the default style outweighs the benefits of doing so.
snover wrote:
Thu Oct 04, 2018 5:49 pm
My goal was merely to point out that it is not impossible to implement this kind of basic UI control without JS, as had been claimed. The approach I demonstrated is also not the only approach—using <details> instead of a checkbox is more semantically valid and requires no extra markup, so long as you don’t care about using a polyfill for IE and current versions of Edge.
I'm all for making as many things work without JS as possible, however, it all comes down to where you draw the line (what browsers you want to support etc). I would also like to note, that nobody is forced to use the default style, so if your community is afraid of JS, I'm sure someone will create a style that will work without any.
snover wrote:
Thu Oct 04, 2018 5:49 pm
The fallbacks for these features are simply to continue to deliver a plain HTML form, as exists today, rather than doing something like building an editor in Vue which won’t function at all without JS.
There are no such plans, I guess the point was that most of our users would use have JS enabled.
snover wrote:
Thu Oct 04, 2018 5:49 pm
As this conversation continues I feel more confused about why a discussion of JS frameworks is even happening now. Unless the goal is to dump server-side rendering—which it sounds like is not the case (and would be a terrible idea since it would harm the user experience, prevent security-conscious users from using phpBB, and damage SEO)—it feels very premature. I can only reaffirm my opinion that the best approach for this current phase of development is to incrementally clean up and leverage what exists currently without introducing new technology.
Well, I think I mostly answered these points to the best of my knowledge. I would like the add that we do not want to get rid of everything, it is not really the goal to rewrite code so we can attend a Vue conference or something. We would keep code that works, and rewrite/refactor things that don't. Most of what can be cleaned up is the JS, as we think that we need to do some markup changes and we would like to use a new approach to our CSS to solve some problems that seem to come up over and over (I know it is not super specific but it would just take up too much time to look up the relevant PRs and filter out the best examples to demonstrate this).

As for why we have this topic is to get the communities input on what they would like to see and on how to architect the code, and what frameworks or libraries to use if any. On the topic of using or not using Vue, I guess you are right in that we should provide some examples on what features actually need the features that it could provide (as I have no idea at the moment).

User avatar
AmigoJack
Registered User
Posts: 103
Joined: Wed May 04, 2011 7:47 pm
Location: グリーン ヒル ゾーン
Contact:

Re: [NEW THEME] 4. JS frameworks & approach

Post by AmigoJack » Sat Oct 06, 2018 10:55 am

CHItA wrote:
Thu Oct 04, 2018 9:14 pm
I think he was talking about a REST API here, which would support having AJAX functionality where it makes sense.
AJAX is also only requesting resources - the output of a PHP document can be anything: HTML and JSON - one could even switch template files for this as it is already an abstraction layer (recognition can be based on something as simple as a parameter in the URI). Has anyone even considered trying this?

CHItA wrote:
Thu Oct 04, 2018 9:14 pm
it is easier to clean things up [...] than to clean things up
:roll:

CHItA wrote:
Thu Oct 04, 2018 9:14 pm
nobody is forced to use the default style, so if your community is afraid of JS, I'm sure someone will create a style that will work without any.
From 2010 to today I got a far different experience: on all installations I ever used having different styles I sooner or later found a style bug, so I always chose proSilver where available. Why should the future change and style authors would suddenly support their work over many years, let alone update within days after a new phpBB version has been released?

CHItA wrote:
Thu Oct 04, 2018 9:14 pm
most of our users would use have JS enabled
Most of the users have no disabilities either - let's stop minding them, too. Elsewhere this kind of thinking/assuming is called living in an echo chamber and prone to loosing even more users/customers instead of reaching more.

CHItA wrote:
Thu Oct 04, 2018 9:14 pm
get the communities input on what they would like to see and on how to architect the code, and what frameworks or libraries to use if any
Oh good, then you already had mine and snover's input. Glad I could help.

User avatar
hanakin
Infrastructure Team
Infrastructure Team
Posts: 873
Joined: Sat Dec 25, 2010 9:02 pm
Contact:

Re: [NEW THEME] 4. JS frameworks & approach

Post by hanakin » Sat Oct 06, 2018 5:30 pm

Ok, so this discussion is starting to get off topic and venture into areas that deserve their own topics so Let me try to clear up some things. First Let me state that I get very limited time to work on the application and responding to lengthy discussions let alone providing very specific and in-depth responses is very time consuming which is why I do not go into full detail. This will not change I am sorry but if you require more detail then keep you comments short and to a single topic which will make it easier to respond. Second I am not going to respond to everything that has been discussed previously as there is just too much to respond to and get to at this point.

What CHItA said is accurate. Front-end always means HTML/CSS/JS not sure where the confusion lies maybe in relation to phpBB, which then It means all of it the core and the theme. The majority of themes are poor because prosilver is so poorly coded and full of bugs. A better default theme will certainly fix this not to mention attract actual professional developers! Also, there will be a StyleGuide editor down the road to help with this. Now back to topic!

The point of this topic is a simple feeler. phpBB is a very customizable app which means that we need to reach a balance between maintainability from our side and easy of customization on the admin side with simple extendability/themeability from the extension/style author side. This is very challenging. To me, it sounds like neither of you have much experience working with theme development which is where all of your comments seem to be failing. Currently, there are very few style authors who are front-end professionals. They tend to be hobiests or novices which means that it is very difficult for them to work in the current ecosystem of prosilver. The theme is as stated several times, is very hard to maintain which you would see if you understand how CSS inheritance works. This gets more problematic when you realize that most of the responsive nature is hacked on very nastily via *beep* JS hacks that are hard to understand. Its further complicated by a lack of control over several features that are hardcode via php and js. Then consider the scope of the theme as well which is massive not to mention the *beep* structure of the files.

All of this is what we need to fix and why this topic exists. Simply put what is the best way to address the interactivity? We need to completely separate concerns and in such a way that all you need to really know is HTML/CSS as our core userbase does not know JS. This is why I asked the question as VueJS seems very novice friendly as it achieves the separation of CSS and JS completely and is readable while self-documenting the HMTL DOM. when you think as a novice what is simpler to understand

Code: Select all

var $modalToggle = '[data-toggle="modal"]';
var $modal = '[data-container="modal"]';

$($modalToggle).click(function(e) {
	e.preventDefault();
	e.stopPropagation();
	$($modal).toggleClass("is-active");
});
or something like this

Code: Select all

	<div class="o-modal-mask" key="front" @click="active = false" v-show="active">
In its simplest terms that is the question, I am posing...This was not a full discussion on the JS despite how much you might want it to be. Instead, we are trying to framework an approach to the interactivity that is simple enough that can be easily conveyed to a novice going forward with minimal HTML editing and no CSS. If you have suggestions of this nature then by all means.

User avatar
rubencm
Development Team
Development Team
Posts: 26
Joined: Sun Mar 12, 2017 8:30 pm
Location: h[b]ell[/b]o

Re: [NEW THEME] 4. JS frameworks & approach

Post by rubencm » Sat Oct 06, 2018 7:28 pm

I like VueJS

CHItA
Development Team
Development Team
Posts: 156
Joined: Thu Mar 12, 2015 1:43 pm
Location: Budapest, Hungary

Re: [NEW THEME] 4. JS frameworks & approach

Post by CHItA » Mon Oct 08, 2018 6:00 am

hanakin wrote:
Sat Oct 06, 2018 5:30 pm
[...] When you think as a novice what is simpler to understand

Code: Select all

var $modalToggle = '[data-toggle="modal"]';
var $modal = '[data-container="modal"]';

$($modalToggle).click(function(e) {
	e.preventDefault();
	e.stopPropagation();
	$($modal).toggleClass("is-active");
});
or something like this

Code: Select all

	<div class="o-modal-mask" key="front" @click="active = false" v-show="active">
IMHO, if you don't understand JS it doesn't really matter as long as it is documented. E.g. the HTML/CSS in the first case shouldn't really be more complicated than in the second one.

User avatar
hanakin
Infrastructure Team
Infrastructure Team
Posts: 873
Joined: Sat Dec 25, 2010 9:02 pm
Contact:

Re: [NEW THEME] 4. JS frameworks & approach

Post by hanakin » Mon Oct 08, 2018 5:51 pm

But there is no js in the second one other than the framework

CHItA
Development Team
Development Team
Posts: 156
Joined: Thu Mar 12, 2015 1:43 pm
Location: Budapest, Hungary

Re: [NEW THEME] 4. JS frameworks & approach

Post by CHItA » Mon Oct 08, 2018 5:55 pm

Sure, however, either way you need to document it in some form how to create a modal or any other component. If we don't use Vue it would be

Code: Select all

<div class="whatever" data-container="modal">your content</div>

Which is not a considerably more difficult concept to understand IMO.

Post Reply