In my previous post about javascript maintainership,
I stated that If
core JS doesn’t get in your way, as far as I’m concerned,
I did my job
. While true, it’s pretty much Level 0 of my ambition. I
do have an overreaching Evil plan1 2
and first I want to talk about where it comes from.
Backstory
I started contributing to Drupal in 2011, I’d been using it for a couple of years but didn’t really run into problems. Then I got a job to work on a website for a pretty big brand and with some fairly complex mapping functionalities. They needed to draw lines on a map so I used the OpenaLayer module and a ton of custom code. The Drupal integration of the OpenLayers library does some pretty wierd stuff and I wasn’t really happy about it so I send a few patches and eventually became maintainer of the module — and found out that it’s hard to maintain a big module with lots of users.
Those maps were showing up in views, ajax views (it looks broken, probably is, no idea). I ran into various javascript bugs of the ctools module. Sent patches. Thankfully most of them made it in so I didn’t have to worry about a patched ctools. The jQuery UI patch for ctools modal was the most fun, had a solution that monkey-patched the JS all over the place.
At that point I was pretty horrified by the quality of javascript code
in contrib and there were a number of problems I would see in pretty much
every contrib module I’d use. So I looked into core javascript — originally
to understand why is OpenLayers recursively calling
Drupal.attachBehaviors — it became
obvious that all the modules copy pasted some piece of core JS and tweaked it.
To fix contrib, core had to be fixed.
Evil plan
Drupal powers some huge sites out there so improving Drupal actually improves the web. My real ambition is to use Drupal to make the web a better place and stop seeing horrible javascript everywhere.
Originally the plan was for Drupal 9 because there was a huge amount of work. That’s until my first big clean-up patch was committed by Dries 14 days after I opened the issue. Seeing how quickly that got in, there was hope and the plan was put in motion.
Achieve Good
The very first thing is to gain people’s trust, and the best way to do that in Drupal is to fix critical bugs and write change notices. Recruit a minion and make him work on a complex major performance bug, refresh the aging JS and get it to follow best practices or help out a review-starved team so they owe you — don’t worry they know how to “Friendly blackmail” too.
Plant Evil
Now you have some opportunities to push for and use trojan patches[^3]:
- The very first standalone JS script,
look Ma! no jQuery! and very soon a no-jQuery script will be available to
add the
activeclass on links. - Replace collapsible fieldsets with the
<details>element and use that to take out the horribly annoying javascript animation of collapsible fieldsets in our polyfill because after all, Chrome doesn’t animate<details>. It was also causing a bug in this case.
New world order
In the end, what does it mean for contrib? Here is what I hope contrib authors will do:
- run JSHint and fix every. single. error.
there is not 2., I know you guys are just as lazy as me. JSHint will
find bugs and it will make you a better JS developer. I’m not shooting for
perfect, I only wish that one day I’ll be able to say Drupal javascript?
It’s not just good, it’s good enough!
. For the smartypants™ that already
run JSHint, there is a follow-up post talking about jQuery,
Vanilla JS and what you can do if you have time to spare.
Run JSHint. If you don’t know how to fix a JSHint error, ping me.
Help Drupal make the web a better place, thank you.