this isn't really an issue with JavaScript - our problem is really the opposite that it gets stagnant in core.
I would add that when there is a momentum it is very easily stopped (for various reasons) and "simple" tasks end up taking years to complete. The situation with how JS is handled as a whole in core today is not simply frustrating, it is not sustainable.
Problem/Motivation
- It takes too much effort to get JS changes reviewed and committed
- The amount of effort necessary to keep momentum going on large JS issues is hard to justify for volunteers
We can see that for the last few years, all "large" JS contribution/feature/refactoring have been from paid/sponsored contributors while other important issues are stalled because they are not the priority of the entities paying contributors.
The maturity of PHP and JS is very different in Drupal and while on the PHP side there has been a reckoning and people grew together over the years to get better it has not been the case for JS. The problem is that now the same expectations of maturity apply to JS without all the growth and people (core js folks is still pretty much the same volunteers for a number of years and 1 or 2 person from Acquia drupal acceleration team).
The following topics are pain points and resolving them would make maintaining JS in Drupal more sustainable and help us make sure it's still possible to contribute meaningfully to core JS as a volunteer:
The heart of the issue for me is that we can't seem to keep any momentum on JS work. The topics listed above would help reduce friction for people to contribute and would help getting more contribution in the queue, that doesn't mean we'll get more things committed.
Proposed resolution
We need more committers with a "hands-on" approach on JS issues, there are some very big changes necessary to remove jQuery, open up Drupal to the larger JS community and I don't see how it'll be possible to do that in the current situation.
What would help:
- Add 1 or 2 core committers dedicated to JS (they need to be "hands on" to some extend, taking part, and initiating topics)
- Have a much higher commit frequency (help work going on smaller JS issues to get more people or remotivate existing contributors)
- Reduce expectations for JS patches on the short term (to increase commit rate and have more people involved) and raise expectations progressively (we'll need to define and advertise the different milestones)
Reducing expectations would possibly add more bugs, but higher commit rate can help mitigate that problem, also it would give an opportunity for novice by having smaller high impact bugs that help onboard and hook new people. I think the memories of ViewsUI breaking after JS patches can explain some of the aversion to JS changes, but we need to find a way past this. The situation is different, and what we need to do to keep Drupal relevant requires significant changes.
Comments
Comment #2
nod_Comment #3
nod_Another issue is the fact that we have 2 versions of every js file in the source code of Drupal. It keeps tripping up new contributors and discourage others.
Speaking about maturity, we could take inspiration from Neos (CMS based on Typo3 with a ReactJS admin, formerly using emberjs): they have a repository for compiled assets neos-ui-compiled exposed as a composer package and that package is depended on by the package neos-ui with the source of the JS/CSS files. That compiled package is updated automatically and sites are depending on it directly.
All this to say that having 2 versions of js files in the source and expecting contributors to know which ones to update is a significant barrier to contribution (I don't see many people reading the warning on top of compiled js files).
Comment #4
bnjmnmNow that you mention it, I recall experiencing this when I got started on Drupal 8. Some reasons I was thrown off:
Comment #5
nod_For the record I'm all for writing "modern" js and compile down to an arbitrary version. It's just that we finally introduced it, and left it alone. Things around didn't go the way I though/hoped, and now it's hurting more than it's helping. In any case I reworked the summary and opened #3179415: Improve contribution workflow, build, and management of JS files to discuss the topic and keep this one as a meta.
Comment #6
nod_Comment #7
nod_Comment #8
pasqualleI think the Symfony UX initiative is relevant here:
https://symfony.com/blog/new-in-symfony-the-ux-initiative-a-new-javascri...
Also the 2 free videos from SymfonyWorld 2020
https://live.symfony.com/account/replay/videos/2020-world
Comment #14
quietone commentedThere are 3 proposals in the issue summary
1. Adding committers
Core governance allows committers can be added at any time, once they are identified. Currently, the JavaScript APIs are the responsibility of the Frontend Framework Managers. My question here is this point about finding people or about changing governance?
2. Have a much higher commit frequency (help work going on smaller JS issues to get more people or remotivate existing contributors).
This seems to be about issue scope. This needs more detail so that reviewers and maintainers understand how to scope JavaScript issues?
3. Reduce expectations for JS patches on the short term (to increase commit rate and have more people involved) and raise expectations progressively (we'll need to define and advertise the different milestones)
Similar to #2 This needs more detail.
Changing to PMNMI for answers to these questions.