Weekly update – 9 February 2024

[ryan]

Like last week, this week the focus has been on adding feature requests from our processwire-requests repository. Though I'd like to give it another week before bumping up the version number. Rather than repeating all that was added here, please see the dev branch commit log, which covers them all, several with more detailed notes in the commits. The biggest added feature request was likely the API updates for getting/setting multi-language values, but there are several others as well. 

I was excited to see the new jQuery 4.0.0 release this week, which we'll no doubt be upgrading soon (or once out of beta). Here's a quote from the intro of their new post: 

Quote

jQuery 4.0.0 has been in the works for a long time, but it is now ready for a beta release! There’s a lot to cover, and the team is excited to see it released. We’ve got bug fixes, performance improvements, and some breaking changes. We removed support for IE<11 after all! Still, we expect disruption to be minimal. 

Some parts of ProcessWire's API were originally inspired by jQuery. It's always nice to see progress there with new versions, especially a new major version. Thanks for reading and have a great weekend!

[cb2004]

Nice work as always. I upgraded 2 sites in development this week to jQuery 4 and everything worked just fine. Scripts we had made, Swiper, Splide, Fancybox and a few other go to scripts all worked fine. I think it's about 10% lighter as well, maybe more which is always welcome. 

Nice to see one of my request hit the commits.

Have a great weekend. 

[teppo]

Makes sense to update to jQuery 4 once it's available and stable, but I must admit that when I read that article my first thought was "holy crap, they are still going on?" 🙊

Serious question to @ryan: what's your take on jQuery these days, do you still see it as something we will be, or should be, relying going forward?

I'm not trying to push any agenda here, but I am wondering if you'd be open to perhaps starting to migrate more of ProcessWire's core code to vanilla JavaScript. I'm also not going to go into the "but what about Vue / React / Alpine / HTMX / insert-name-of-any-other-library-or-framework-here" topic at this point; that's a whole different subject. Also: all modern libraries are advocating the use of native JavaScript API's instead of "framework specific magic" anyway, so vanilla JS would be a good first step towards something new.

In my opinion (which I've probably voiced here on the forums a few times already) jQuery is now largely obsolete. And I'm saying this as a former fan — it was amazing back in the days when native JS API's were very crude and lacking. Today it's more of a problem. For those that don't know what I'm speaking about, one example is the way jQuery handles events: the API is nice, but also hacky and non-standard, leading to the fact that in order to combine (standard) JS events with jQuery events you essentially need yet another library.

(And vendor lock-in, intentional or not, is not a good thing.)

Personally I find myself reaching for jQuery in pretty much one specific case: many third party plugins/libraries still rely on jQuery. This is less of an issue every year as devs keep moving forward, but there are still many popular plugins that do require jQuery. For every need there is a non-jQuery solution, but it can take a bit of work to find / migrate to.

Some things are admittedly more difficult to replace, and one of those is jQuery UI. But since jQuery UI is already in "maintenace updates only" mode, replacing it is likely something that has to be done at some point.

(Also... form serialization. That is something they did really well. And no, vanilla JS FormData is not a direct replacement 😅)

Sorry for the long rant, but I just felt that this needed a bit of context. I for one would be happy to submit PR's etc. that would move us towards fewer dependencies for jQuery if that's something that'd be beneficial for the project. I believe it would be, but that's just me 🙂

[monollonom]

2 hours ago, teppo said:

you'd be open to perhaps starting to migrate more of ProcessWire's core code to vanilla JavaScript

Maybe then the version would finally bump from 3.0.x to 4.0.0...

😬

[Robin S]

3 hours ago, teppo said:

when I read that article my first thought was "holy crap, they are still going on?"

If I was the vendor of a product that currently has 77% market penetration I think I would keep going on. It is the most popular JavaScript library by a staggering margin:

With so many happy customers it's fantastic news that jQuery continues to be updated and supported, and I don't see how its use in the PW core disadvantages users in any way.

[cb2004]

6 hours ago, Robin S said:

With so many happy customers it's fantastic news that jQuery continues to be updated and supported, and I don't see how its use in the PW core disadvantages users in any way.

This. 

[teppo]

7 hours ago, Robin S said:

I don't see how its use in the PW core disadvantages users in any way.

It doesn't. Most users probably don't mind as long as it works. In that regard it is indeed great news that they are still going on.

But does it mean that it is a good idea to keep relying on jQuery? Is it a good idea to use a framework that doesn't really add much to the mix anymore? I don't think so, but perhaps I'm wrong 🙂

The point I'm trying to make here is that yes, jQuery used to be important, but these days it's just another dependency that you can pile on top of your stack if you so choose. It essentially does the same thing as native API's, just with a slightly different (and non-standard) syntax. To me that doesn't seem like a great thing.

If the general opinion is that jQuery is indeed the future and we should keep relying on it, then sure, let's keep it going. I'm just not sure what the actual benefit is, apart from the fact that it's what folks are used to 🙂

[ryan]

I've always enjoyed PHP, but never really enjoyed Javascript until I started using jQuery. I continue to enjoy using jQuery much more than vanilla Javascript. Using jQuery has not always been about filling in a gap of Javascript so much as it has been about preferring and even enjoying the interface. It’s fun to use, and Vanilla JS not as much, at least to me. PW has some of its API inspired by jQuery, and together they have always felt just right. When it comes to open source stuff, I like to focus on tools that I enjoy using, as that's what keeps me interested and keeps me going. If we were to take jQuery out of the admin, it would be a huge amount of work, and then leave something that would be less interesting to maintain. So I’m not so enthusiastic about taking jQuery out of the admin. 

Where I would be enthusiastic about it is with front-end modules that might currently be using on jQuery and don’t necessarily need to. Take FormBuilder and LoginRegisterPro as  examples (though there are many  more). Perhaps those modules don’t need to require jQuery unless one of the Inputfield modules in use requires it. That way, modules like that aren’t introducing jQuery in an environment where it might not otherwise be in use. And maybe there are some Inputfield modules that currently use jQuery and don't need to. Since Inputfield modules can be either admin or front-end, it makes sense to use vanilla JS when possible with those. So yes, I'm all for reducing or removing the use of jQuery in spots, but not so interested in removing it from the admin.

[szabesz]

I am also still a fan of jQuery for similar reasons that Ryan enjoys using it. After all, its size is smaller than any decent images a page might contain. So, why use vanilla JavaScript's inconsistently developed methods when one can use jQuery, which was always developed with consistency in mind?

I am also a big fan of Unpoly, which (to me) IS "ProcessWire" but in the JavaScript world. If I were to modernize ProcessWire's JavaScript code, I would certainly choose Unpoly while also keeping jQuery. They can complement each other instead of conflicting in terms of concurrency.

[cb2004]

@ryan summed it up really nicely. I mentioned earlier about Swiper, and Splide etc, completly forgetting they have moved to ES6 some time ago. Front end modules would be advantageous to remove jQuery I agree (if we are thinking very long term) but why remove it in the backend. I also hate vanilla JS, always have always will (not as much as I hated Flash), so I will continue to champion jQuery. It has such little overhead (especially the slim build) that it makes it strange to me that Lighthouse complains about Google Fonts, YouTube embeds, Analytics and lots of other things but not jQuery. They are already talking about what will be in jQuery 5 so it's here to stay I think. 

[teppo]

Thanks, Ryan; I see your point. I don't necessarily agree with all of it (apart from the front-end facing modules part, that I fully agree with), but I appreciate you taking the time to explain your view! Also, I'm clearly in the minority here with my opinions 🙂

One last point, though:

When I hear someone describe vanilla JS as not fun or inconsistent, I do wonder if they might be, perhaps, remembering JS as it was a long time ago. Modern JS is at least as far apart from JS of 2006 (when jQuery was released) as PHP 8 is from PHP 4 (also from 2006). After being a heavy jQuery user for years I've been getting more into vanilla JS these past few years, and I must say that my impression of it has changed a lot.

Anyway, just saying that if you've been on the jQuery side of things for a long time, giving vanilla JS a try may be a positive surprise. Of course if you're super into the jQuery syntax any difference may be a dealbreaker — and that's fine too 🙂

[LostKobrakai]

Jquery still being a dependency to so many higher level js tools is what keeps it alive much more than jquery by itself being a useful tool nowadays. With modern JS you can do many things natively, which made jquery so appealing years ago. E.g. the $(…), which made jquery famous is just document.querySelector or document.querySelectorAll in native JS. Ajax used to be verbose in native js, but fetch is way better. The only real benefit I still see for building new stuff on top of it would be some of its included normalization of certain behaviours across browsers. 4.0 also at least fixed my largest issue with jquery in modern codebases of not having been a native esm package before.

[Gideon So]

21 hours ago, szabesz said:

I am also a big fan of Unpoly, which (to me) IS "ProcessWire" but in the JavaScript world.

Me too. Very good description to Unpoly which is grestbfun to use.

Gideon

[markus_blue_tomato]

I've made the same experiences as @teppo. In the world of frontend development - nobody would use jQuery for a new project since now vanilla JS can handle most of jQuery's advantages from back in the 00's. For some specific things you would use libraries which not depend jQuery. Main reasons are also JS-Bundle size and performance.

I think if jQuery continues development/maintenance Processwire can still use jQuery in the Admin Panel. Otherwise I would recommend to migrate frontend modules like FormBuilder away from jQuery to vanilla or smaller js libraries.

 

[cwsoft]

I don‘t use jQuery in the frontend, unless I want/need to use a third party plugin, which uses jQuery as dependency. One of those repeating plugins I use quite often on the frontend for convenience is DataTables. Whenever I output structured data as data table on the frontend with more than 20 row (tr), I almost always make this table sortable by columns and filterable (only show matching rows) via this plugin. Simply to give the frontend user some intuitive options to quickly narrow down the relevant data. DataTables is powerful, well customizable and well tested. Of course I could implement that stuff with vanilla JS myself. However my next customer needs another feature I would need to manually add, where with DataTables I just switch of stuff I don‘t need for a specific customer via a simple config array (e.g. disable pagination, sorting, filtering, showing detail infos etc.). 

Same is for font awesome, CSS grids and so on. If I only need a handfull icons, I just go with png files or UTF8 code points instead of the full blown fa-suite. If I just want to collapse some paragraphs like an accordion, I normally go with some handmade vanilla TS/JS and SASS/CSS3.

But if I need to spend lot‘s of time writing TS/JS for more serious work already supported by a jQuery plugin like DataTables, I don‘t spend too much time to reinvent the wheel and just go with the jQuery Plugin. Image sliders, hero headers etc. would be examples for using jQuery too.

The best part of ProcessWire is, that Ryan give us all the freedom and options to use whatever we would like to use for a specific project in the Frontend with no predefined framework (like Bootstrap) one would need to use by design.

[MarkE]

On 2/11/2024 at 6:41 PM, szabesz said:

I am also a big fan of Unpoly, which (to me) IS "ProcessWire" but in the JavaScript world. If I were to modernize ProcessWire's JavaScript code, I would certainly choose Unpoly while also keeping jQuery. They can complement each other instead of conflicting in terms of concurrency.

Prompted by this, I tried using Unpoly in the back end, to achieve a bit more customisation than with pw-modal. It looks nice but loading a page edit content in an overlay seems to lose all the tabbing.

[szabesz]

1 hour ago, MarkE said:

It looks nice but loading a page edit content in an overlay seems to lose all the tabbing.

I think integrating Unpoly into the PW admin would require refactoring the fundamentals of the currently used JavaScript codebase. So I didn't consider suggesting it as an additional tool, but rather as a completely new foundation for the admin's JavaScript.

[markus_blue_tomato]

On 2/9/2024 at 9:23 PM, ryan said:

The biggest added feature request was likely the API updates for getting/setting multi-language values, but there are several others as well. 

 

Nice! Would be cool to find the new APIs in the https://processwire.com/docs/ ....