I wrote this post from scratch about 7 times over the last few months, and I’m not getting anywhere so I’ll write up something, it’s not perfect, I took a few shortcuts but having a discussion going is more important than a perfect post.
Situation
JavaScript development went from widget-based add-ons for functional HTML pages to being responsible for HTML page assembly and even basic browser interactions (such as navigation, form submission, etc.)
In the first case, the JS files are standalone-ish, they usually depend on a bigger library (like jQuery) and sticking them on the page with a script tag is enough for things to work. Makes it easy to assemble pages at runtime based on the original JS source. Additional processing can be done on the JS file to minify or gzip it but it doesn’t go much further than this. This is what Drupal and most other CMSs that have been around for a while do very well.
This worked well until the push for better UX shifted more and more responsibilities to the frontend. More responsibilities translate to more code sent, minification wasn’t enough and JS libraries got bigger and became frameworks with smarter tools, we began to see an optimization or build step to transform development code into running code. This is around the time where CMSs started to get left behind I’d say.
Fast forward to now where the whole site/application is in JavaScript and the framework needs to build the application before it can even be loaded. It’s not really possible to add or remove functionality at runtime, if there is a change in the application, the whole application needs to be built again. On top of this frameworks are now competing in server side rendering capabilities.
Problem
How to accommodate JS as it is written today with the CMSs way of consuming it?
Drupal
Essentially, transform a monolithic JS application in a set of files that are optional and can be loaded at runtime without the need of a build step. One partially successful example of this is how CKEditor 5 has been integrated into Drupal by using the relatively new Webpack DllPlugin, instead of building a single JS file with all the WYSIWYG tools, each tool is packaged in it’s own file that can be loaded at runtime without fuss. This solution still needs a build step but at least the result of the build step can be used dynamically.
Wordpress
In the case of Wordpress they solved the problem simply by going all JS with Gutenberg: a whole new repo, only JS/React code, very little PHP in sight, and a great opportunity to generate engagement by creating a new way of doing things. It seems to be working well for them.
Symfony
Symfony went with a Yaml API around nodejs tooling with Webpack Encore. Still need nodejs installed and all it comes with.
Another way?
Personally I would like to explore an alternative path before considering to move all-in on the JS way of doing things, and require nodejs for hosting a Drupal website, a path that can help mitigate some of the pain of JS tooling. There is no reason for JS tooling to be written only in JS, there is already a bunch of tools written in rust, as long as you can read the file, you can make the same transformations in any language.
I’d like to see a set of PHP-based tools that helps manage JS, in a way that the build step is actually handled by the CMS so that people writing Drupal code do not need to care about nodejs, tooling, package updates, etc. For example I would love to write JavaScript modules and have the dependencies automatically picked up and declared in Drupal and at the same time, have Drupal aggregate all those modules in a single file. Something that is surprisingly impossible to do natively for now hopefully. Until then I’m itching to use peast to transform JS from PHP and start making tools that remove problems for PHP developers.
What do you think?
As as said in the beginning this post is a bit messy, I’m not comparing the same things or define what it is that the build step should be doing or not doing, but I’m happy to just talk about the topic and see what others think.