So its apples and oranges really. As this discussion and this forum is not talking about the current version of the software or the current theme. We are talking about how to handle the next version and a completely new theme. I just wanted to make sure that was clear. Now I understand your points and while I agree that choosing to use a framework to solve one or two things is not a good idea. If the core concept, structure, and approach are what you are after, and how you want everything to work as your standard, then your points are really not an issue. That is what this topic is really about. determining if VueJs is answering just that. I am not saying should we just use it because it allows us to do this one cool thing easier. If you are familiar with the progress of the new theme you will know that I am wrote from scratch our own custom framework for handling the CSS. To do that I sat down analyzed all that was out there and outlined what we needed and how I wanted everything to work. I determined that nothing really was a framework and meet our needs, so I went the custom route. This requires a lot of research and thought.
This topic is just a starting point to help me in making all of the decisions for and gameplan for how we are going to handle all of the JS code in the new theme which is what I am currently working on as the next step in my progress with it. I am intimately familiar with all the CSS side of things. I am not with everything in js as it's in a transitional state lately and it seems every day there is something that is flip it on its head, cause let's face it JS is volatile
[NEW THEME] 4. JS frameworks & approach
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.
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.
Re: [NEW THEME] 4. JS frameworks & approach
I'm an advocate for these sort of things, it makes me feel like I'm maintaining elegance while allowing them to work for non js users.
Re: [NEW THEME] 4. JS frameworks & approach
Hang On js menus are a nessecary evil. CSS is not currently capable of handling menus properly alone as they do not have control over things like state and position across responsive designs let alone the ability to adapt to mobile interactions.
Re: [NEW THEME] 4. JS frameworks & approach
Ok, all I have put together two examples of the same component one using jquery to handle everything and the other using Vue.
essentially it's a simple modal display toggle event that is triggerable from the toggle button, mask, and action buttons.
Vue:
https://codepen.io/hanakin/pen/EeYbWa
jQuery:
https://codepen.io/hanakin/pen/xaZEZe?editors=1010
On the Vue component, you will notice the different HTML, this is because Vue uses directives that are applied in the HTML to accomplish the interactivity. You will also notice that to apply transitions in Vue it works a little different as well as it has its own transition HTML element wrapper. This is used to animate between states cleanly without having to style your CSS components default state to off. In essence with Vue everything is on when JS is disabled and with jQuery everything is off.
essentially it's a simple modal display toggle event that is triggerable from the toggle button, mask, and action buttons.
Vue:
https://codepen.io/hanakin/pen/EeYbWa
jQuery:
https://codepen.io/hanakin/pen/xaZEZe?editors=1010
On the Vue component, you will notice the different HTML, this is because Vue uses directives that are applied in the HTML to accomplish the interactivity. You will also notice that to apply transitions in Vue it works a little different as well as it has its own transition HTML element wrapper. This is used to animate between states cleanly without having to style your CSS components default state to off. In essence with Vue everything is on when JS is disabled and with jQuery everything is off.
Re: [NEW THEME] 4. JS frameworks & approach
I’ve been frustrated recently by trying to theme over the prosilver templates in phpBB 3.2, so I actually came to this board just to see if the phpBB team was working on a replacement modern theme. I am glad to see that there is a shared interest, and I have some feedback.
For a very brief background, since you don’t know me, and I’m going to say a few things, and there have been some accusations of people not being sufficiently experienced to weigh in on this thread :-): I’ve been developing for the web for 18 years and specialised in cross-platform web application & open-source software development for about 10 years. Not that this really means very much, but I hope my feedback can be understood better with this added context.
First, a couple of quick technical corrections:
For drop-downs, JS is usually needed only to size and position a drop-down according to free space in the viewport, and to perform certain types of transitions, but phpBB already isn’t doing these things anyway. Responsive design/mobile interaction should not be relevant either since the adjustments you need to make for a small screen are modifications to layout in CSS. I’m super curious about what you think JS needs to exist for mobile interactions.
When I was working on jQuery Core (back in 2010–2011) we were just starting to see the result of efforts to uplift its API features into the DOM standard. This work is why
In this context, the question of backwards compatibility becomes much more relevant than the question of whether jQuery still has value over native web APIs (it mostly doesn’t).
Now, onto the main thing.
What I see stated repeatedly by the phpBB team on this ticket, and what I think ought to be the decider on what to do, is the time problem.
If it takes five months for the person advocating this change to the architecture of phpBB to demonstrate one example of a modal, how is the team going to successfully implement this new tech across all of phpBB in a way which is not, at best, adding an extra layer of complexity on top of other existing complexity layers? I am genuinely interested to know how you, the phpBB team, would foresee this approach working in concrete terms.
Do you have any more detailed planning document than this thread? A hypothetical task breakdown? User stories? A list of specific problems which exist in phpBB and which Vue solves that Twig+vanilla JS or Twig+jQuery don’t? Again, I don’t know the answers, and am genuinely asking so I can learn from you. All I know is that phpBB is not an SPA, its backend is not written in JS, and there’s no data API for UI components to use, so it makes no sense to me that a JS-based view system designed for data-driven apps would be selected here.
I know it’s not very glamorous, but as a consumer of phpBB with a custom theme, all I want is: (1) fix the templates to enable full use of Twig features like inheritance and blocks, so I don’t have to copy and rewrite templates every major phpBB release; (2) remove all the inline styles and scripts, so I can theme things and extend functionality without hacks (and enable CSP!); (3) delete old code and markup which was needed only for ancient browsers which are no longer supported. This seems to me to be a much more achievable goal because it adds no new technologies and can mostly be approached in an evolutionary manner.
Finally, as a consumer of phpBB, a hard requirement for end users to have JS would be an upgrade blocker since we have community members who are security conscious and won’t be willing to enable scripting in order to use the forum. So there’s that.
Thanks for listening! I hope this feedback has been helpful and helps you make a more informed decision on direction. Please let me know if you have any specific questions I might be able to answer.
For a very brief background, since you don’t know me, and I’m going to say a few things, and there have been some accusations of people not being sufficiently experienced to weigh in on this thread :-): I’ve been developing for the web for 18 years and specialised in cross-platform web application & open-source software development for about 10 years. Not that this really means very much, but I hope my feedback can be understood better with this added context.
First, a couple of quick technical corrections:
This isn’t correct. You can use CSS pseudo-selectors and invisible form elements to trivially create drop-downs with “state” without JS. There are a few slightly different approaches; here’s one as an example.
For drop-downs, JS is usually needed only to size and position a drop-down according to free space in the viewport, and to perform certain types of transitions, but phpBB already isn’t doing these things anyway. Responsive design/mobile interaction should not be relevant either since the adjustments you need to make for a small screen are modifications to layout in CSS. I’m super curious about what you think JS needs to exist for mobile interactions.
The other person’s point, as I understood it, was that all the functionality phpBB needs today can be done very simply in 2018 with vanilla JS, and don’t seem to warrant the introduction of a new JS library. I agree with this assessment. An AJAX request with retries took 30 lines 8 years ago because it had to use the XMLHttpRequest API. It takes one line today in all modern browsers:hanakin wrote:3. Why yes you can add in some simple Ajax functionality with holy crap 30 lines that’s a lot! Should not take more than 10-15 these days.
fetch(url).then(function (data) { /* … */ }, function (error) { /* maybe retry */ })
.When I was working on jQuery Core (back in 2010–2011) we were just starting to see the result of efforts to uplift its API features into the DOM standard. This work is why
Element#querySelectorAll
, Element#matches
, Element#closest
, etc. exist now as part of the core web APIs, and it’s why jQuery has, intentionally, become less relevant over time.In this context, the question of backwards compatibility becomes much more relevant than the question of whether jQuery still has value over native web APIs (it mostly doesn’t).
Now, onto the main thing.
What I see stated repeatedly by the phpBB team on this ticket, and what I think ought to be the decider on what to do, is the time problem.
CHItA wrote:What is stopping us is having the free time to do it.
DavidIQ wrote:Also there isn't a dedicated person for this that doesn't have an actual job. We're all volunteers so this sort of thing takes time.
If I could impart any wisdom from my own experience, it would be to think about how you can make the biggest impact with the limited time you have to spend on phpBB. Don’t get me wrong: I love the optimism and enthusiasm for radical improvements, but I don’t like seeing anyone setting themselves up for failure—or worse, burnout—because I’ve been there before, and it is not fun.hanakin wrote:It’s on my todo list I’m just extremely busy with other things.
If it takes five months for the person advocating this change to the architecture of phpBB to demonstrate one example of a modal, how is the team going to successfully implement this new tech across all of phpBB in a way which is not, at best, adding an extra layer of complexity on top of other existing complexity layers? I am genuinely interested to know how you, the phpBB team, would foresee this approach working in concrete terms.
Do you have any more detailed planning document than this thread? A hypothetical task breakdown? User stories? A list of specific problems which exist in phpBB and which Vue solves that Twig+vanilla JS or Twig+jQuery don’t? Again, I don’t know the answers, and am genuinely asking so I can learn from you. All I know is that phpBB is not an SPA, its backend is not written in JS, and there’s no data API for UI components to use, so it makes no sense to me that a JS-based view system designed for data-driven apps would be selected here.
I know it’s not very glamorous, but as a consumer of phpBB with a custom theme, all I want is: (1) fix the templates to enable full use of Twig features like inheritance and blocks, so I don’t have to copy and rewrite templates every major phpBB release; (2) remove all the inline styles and scripts, so I can theme things and extend functionality without hacks (and enable CSP!); (3) delete old code and markup which was needed only for ancient browsers which are no longer supported. This seems to me to be a much more achievable goal because it adds no new technologies and can mostly be approached in an evolutionary manner.
Finally, as a consumer of phpBB, a hard requirement for end users to have JS would be an upgrade blocker since we have community members who are security conscious and won’t be willing to enable scripting in order to use the forum. So there’s that.
Thanks for listening! I hope this feedback has been helpful and helps you make a more informed decision on direction. Please let me know if you have any specific questions I might be able to answer.
Re: [NEW THEME] 4. JS frameworks & approach
If you want to get more familiar with some of the concepts, then there is a summary topic, some of the dev docs have been updated and also you can refer to the blog post for some examples and component mockups etc.
Re: [NEW THEME] 4. JS frameworks & approach
Thanks, CHItA. I didn’t check every single component mockup, but as far as I can see those mockups don’t use Vue (except for the one modal) and don’t do anything which I could identify as needing a client-side view system like Vue, so for the moment, I don’t see anything to convince me to change my position. I’m also not seeing answers to the planning questions I raised. I only see a CSS style guide, a blog post soliciting help, and a GitHub repository with no issues—which is a really great start, but not quite what I was expecting. What am I missing?
Re: [NEW THEME] 4. JS frameworks & approach
Hi,
thanks for your lengthy response. Let me first provide you with some background on where we are coming from. I myself am a front-designer and have been for nearly 2 decades as yourself. The rest of the team is made up of back-end developers. So we have no dedicated Javascript developers on the team.
Things come up or out of nowhere so a lot of times not all the work or discussion make it onto these forums. Personally, I get a few hours a week on average to dedicated to working on the project and my time needs to be managed have a look at the new themes post on .com to see where my time is at the moment is focused https://www.phpbb.com/community/viewtop ... &t=2485796
With that being said I hope none of this come across negatively towards you if it does I am sorry that is not my intention. It is a lot to get through and I am just trying to inform you of our current stances. If you would like to help us it is surely welcome.
With that said let me try to answer some of your questions. The dropdown, not to sound confrontational but the use case you linked while can work somewhat is not without its flaws and problems. One being extra markup necessary in the HTML. All be it that is a very minor issue. It's one that can lead to problems in an ecosystem such as ours where the entire front-end is customizable. It's also not perfect across all browsers, it is sort of stubborn on mobile. Lastly, which you even sort of pointed out that position is an issue which is the biggest problem. You need to account for the location of the menu in relation to the edges of the screen. This is simply not fully possible with CSS when you are talking about different devices at least not cleanly. It requires a lot of painful manual testing and placement of differentiating classes or attributes every place you put a menu, which is not very scaleable at all.
Your assessment that we are not an SPA is accurate but you seem to be saying that the use-case is only for SPA? This is 100% not true. There are many benefits to using something like VueJS, Angular, React. Would you say that Facebook is an SPA?
As for the jQuery/Vue/Vanilla discussion while I agree that vanilla is getting better and making good progress like fetch. The argument from AmigoJack was that we should not use any third-party code/frameworks and do everything ourselves. He was not just referring to our use of jQuery but also our use of any third party code.
This is not something that the team or any development project any of us have ever worked on can or would get behind. Our current stance is that we use what makes sense for the situation if that is Vanilla JS then we can use Vanilla JS if that happens to be jQuery then that's what we would use, and if its something like VueJS then we will consider it. Regardless if we decide to code everything in Vanilla we would still have to ship with jQuery to support all the extensions. The other added benefit to using any framework, not just jQuery is also readability. Sometimes it comes down to a simple case of the amount of code or the legibility of the code. As you state Vanilla is catching up maybe in those aspects to jQuery and other libraries, but still is not there, especially given the unsupported features still by the browsers. It may be marginally lengthier I will give you that but there is no argument that when it comes to writing a block of code that its far easier sometimes to understand in jQuery to a beginner than vanilla. We also have to consider this as again we are building for the novice user to be able to modify things. We still do not have a concrete idea going forward how the split of code will work. Do we maintain the core.js where it is or relocate it downstream closer to the theme in all folder? Does the coding style for the core js have to be the same for the theme specific js? Is there a need for any theme-specific js? We do not know these answers yet until we get to that stage of development.
1. Even if prosilver were converted to twig which it will be in the next minor release you would still have countless things to fix every release until we are able to decouple the business logic and rework the file structure, which is a very daunting task.
2. The inline *beep* could be removed, please, by all means, submit a pr and I personally will be happy to merge it, but it's very little gain for us to focus on that over working on a new theme which solves everything you pointed out.
3. Deleting old code is not possible due to the *beep* job over the years patching and tweaking and modifying a *beep* theme from the beginning.
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.
thanks for your lengthy response. Let me first provide you with some background on where we are coming from. I myself am a front-designer and have been for nearly 2 decades as yourself. The rest of the team is made up of back-end developers. So we have no dedicated Javascript developers on the team.
Things come up or out of nowhere so a lot of times not all the work or discussion make it onto these forums. Personally, I get a few hours a week on average to dedicated to working on the project and my time needs to be managed have a look at the new themes post on .com to see where my time is at the moment is focused https://www.phpbb.com/community/viewtop ... &t=2485796
With that being said I hope none of this come across negatively towards you if it does I am sorry that is not my intention. It is a lot to get through and I am just trying to inform you of our current stances. If you would like to help us it is surely welcome.
With that said let me try to answer some of your questions. The dropdown, not to sound confrontational but the use case you linked while can work somewhat is not without its flaws and problems. One being extra markup necessary in the HTML. All be it that is a very minor issue. It's one that can lead to problems in an ecosystem such as ours where the entire front-end is customizable. It's also not perfect across all browsers, it is sort of stubborn on mobile. Lastly, which you even sort of pointed out that position is an issue which is the biggest problem. You need to account for the location of the menu in relation to the edges of the screen. This is simply not fully possible with CSS when you are talking about different devices at least not cleanly. It requires a lot of painful manual testing and placement of differentiating classes or attributes every place you put a menu, which is not very scaleable at all.
No, we have nothing concrete yet this was just the start of the discussions. Like with the front-end I am working on a plan for the JS so we can start tackling it. One thing the team has determined is holding us back though compared to some of our direct competition is the fact that we do not have a data-driven API. Firstly this would greatly benefit our effort to decouple the business logic in our app from bleeding into the front-end. Which would, in turn, make the themes a lot easier to maintain. So this is something that we aim to fix going forward.snover wrote: ↑Tue Sep 18, 2018 3:53 am Do you have any more detailed planning document than this thread? A hypothetical task breakdown? User stories? A list of specific problems which exist in phpBB and which Vue solves that Twig+vanilla JS or Twig+jQuery don’t? Again, I don’t know the answers and am genuinely asking so I can learn from you. All I know is that phpBB is not an SPA, its backend is not written in JS, and there’s no data API for UI components to use, so it makes no sense to me that a JS-based view system designed for data-driven apps would be selected here.
Your assessment that we are not an SPA is accurate but you seem to be saying that the use-case is only for SPA? This is 100% not true. There are many benefits to using something like VueJS, Angular, React. Would you say that Facebook is an SPA?
As for the jQuery/Vue/Vanilla discussion while I agree that vanilla is getting better and making good progress like fetch. The argument from AmigoJack was that we should not use any third-party code/frameworks and do everything ourselves. He was not just referring to our use of jQuery but also our use of any third party code.
This is not something that the team or any development project any of us have ever worked on can or would get behind. Our current stance is that we use what makes sense for the situation if that is Vanilla JS then we can use Vanilla JS if that happens to be jQuery then that's what we would use, and if its something like VueJS then we will consider it. Regardless if we decide to code everything in Vanilla we would still have to ship with jQuery to support all the extensions. The other added benefit to using any framework, not just jQuery is also readability. Sometimes it comes down to a simple case of the amount of code or the legibility of the code. As you state Vanilla is catching up maybe in those aspects to jQuery and other libraries, but still is not there, especially given the unsupported features still by the browsers. It may be marginally lengthier I will give you that but there is no argument that when it comes to writing a block of code that its far easier sometimes to understand in jQuery to a beginner than vanilla. We also have to consider this as again we are building for the novice user to be able to modify things. We still do not have a concrete idea going forward how the split of code will work. Do we maintain the core.js where it is or relocate it downstream closer to the theme in all folder? Does the coding style for the core js have to be the same for the theme specific js? Is there a need for any theme-specific js? We do not know these answers yet until we get to that stage of development.
Yes but all of this is far more complicated than you may understand.snover wrote: ↑Tue Sep 18, 2018 3:53 am all I want is: (1) fix the templates to enable full use of Twig features like inheritance and blocks, so I don’t have to copy and rewrite templates every major phpBB release; (2) remove all the inline styles and scripts, so I can theme things and extend functionality without hacks (and enable CSP!); (3) delete old code and markup which was needed only for ancient browsers which are no longer supported. This seems to me to be a much more achievable goal because it adds no new technologies and can mostly be approached in an evolutionary manner.
1. Even if prosilver were converted to twig which it will be in the next minor release you would still have countless things to fix every release until we are able to decouple the business logic and rework the file structure, which is a very daunting task.
2. The inline *beep* could be removed, please, by all means, submit a pr and I personally will be happy to merge it, but it's very little gain for us to focus on that over working on a new theme which solves everything you pointed out.
3. Deleting old code is not possible due to the *beep* job over the years patching and tweaking and modifying a *beep* theme from the beginning.
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.
Yes, sorry to hear this but they are becoming a minority, we actually get far more complaints and requests for features that are JS rich and it's hard to provide fallbacks for some of these so it's a double-edged sword especially in today's ecosystem. In fact, as it is right now the most asked for features are mentions and wysiwyg editors which both have no fallbacks.
- AmigoJack
- Registered User
- Posts: 110
- Joined: Wed May 04, 2011 7:47 pm
- Location: グリーン ヒル ゾーン
- Contact:
Re: [NEW THEME] 4. JS frameworks & approach
Double standards - likewise the 8 year old code could omit linebreaks as well and easily be merged into 1 line. I see your argument, but anonymous functions or not - both can't be defined in one line unless readibility is ignored.
Security wise every (additional) framework is added complexity. It might help developers and contributers to achieve things faster, but it comes with the cost of all potential attack vectors. Then you have to wait for the maintainers to fix the issue, just then to realize you have to come up with a fix in your software because of their fix (broken feature/scope/workflow/etc. or discontinued support for something). For both: JS and PHP.
That's why I advocate writing it all yourself - this also sharpens your senses to avoid effects that would break in different internet browsers instead of relying on the framework showcases which could break with every major internet browser engine change. If the CSS menu is still a problem for mobile devices then use a different approach instead of declaring it as a milestone. For executables I don't rely on specific OS versions or libraries by compiling it statically - I always use dynamic linking and fallbacks to make sure most portions can still be used (i.e. compilations from WinXPx32 or even Win7x32 run on both Win10x64 and Win2000). Robustness comes from effort.
Re: [NEW THEME] 4. JS frameworks & approach
hanakin,
I have some specific things you’ve said which I would like to respond to individually, but before I do that I want to make sure I understand your overall thinking on direction. Based on the things you have said, it sounds like you may want the phpBB UI to eventually be a pure client-side JS application and the backend would be just a pure data API. Is this correct?
I have some specific things you’ve said which I would like to respond to individually, but before I do that I want to make sure I understand your overall thinking on direction. Based on the things you have said, it sounds like you may want the phpBB UI to eventually be a pure client-side JS application and the backend would be just a pure data API. Is this correct?