Remove jQuery

[jankapunkt]

This has been mentioned from time to time and I'd like to bring this up to seriously discuss it.

Removing jQuery brings some big advantages

• people tend to avoid Blaze, simply because it's the only dependency to jQuery
• reduce bundle size by around 70-90 kb
• do not rely to fix security issues that come with jQuery
• use browser-builtin standards do not introduce new dependencies or complex custom implementations

There are also some caveits:

• the DOMBackend basically relies on jquery to parse HTML although this might seem to not be that hard to replace, this still needs a lot of testing and especially integration testing, since this is basically the backbone of Blaze IMO
• we should first merge Faster fragment parsing #334
• we need to preserve API, because there are some builtins that heavily work similar to jQuery (like templateInstance.$)

Also there is the question of versioning and if the jQuery removal would really have a breaking impact, which would force us towards a major bump.

What do you think?

[StorytellerCZ]

Yes, I agree with this move and think that it can be done due to the advancement in JS. I also think that major version bump will be needed and welcomed for this.

[jankapunkt]

Maybe adding to 2.6 a warning that jquery will be removed soon in 3.0.0 or something

[StorytellerCZ]

We could highlight that in changelog and posts on the forums and so on. I would be against adding it into the code as people seem to be allergic about those kind of warnings (even though that is sometimes the only way to get their attention).

[harryadel]

I looked into this and actually it might be better to keep it. While some jQuery functions are used here and there like: parseHTML, on, off and jQuery selector which can all be easily replaced with some of the alternatives presented here.

But I believe the main point of using jQuery was to solve this problem which explained in this stackoverflow answer. It's all about browser compatibility so even if we forcibly attempt to remove jQuery we'd end up sacrificing some users since some of the modern browser APIs aren't present in IE8 or IE8 and we'd also need to solve the same problems writing more code which is going to be error prone so why not use something ready and battle tested?

We shouldn't fix what's not broken. If you think about it for a sec, jQuery being used within Blaze doesn't present any real problems at all and it's just our love for new shiny jQuery-less, front-end, frameworks like React and others is what's motivating us for this change so unless there're immediate problems that'd be fixed by removing jQuery it's best to keep it.

[StorytellerCZ]

I think IE8 is no longer a concern as that one has been discontinued for a while. IE11, finishes this (2022) summer from what I remember, so soon IE won't be a blocker at all. Which means that query selectors can be then used everywhere. As for the other functionality, we will have to weight if it is better to import all of jQuery versus just copying those specific functions.

[jankapunkt]

The question is, if we can solve this in a way, that we can have jQuery as a drop-in or weak dependency so users, who still really really need this backwards compatibility can still use jQuery.

Also @harryadel I checked some time ago the code for parseHTML and this is actually easily replacable. However, I agree with you, that the event removal is for older browsers an issue and I would also favor to implement a clean event removal (and not rely on the browser in such cases) at template destroy stage.

[distalx]

If we remove the jQuery completely. How would it affect the current usage? i.e. this.$ inside the template API like onRendered and other places. And what would the migration path look like for them when they decide to upgrade to the newer version of the blaze?

[jankapunkt]

I would argue that modern browsers have stable and proven replacements like queryselector.

Handling Dom Element classes, props and events are also now much easier than in the old days.

Maybe we first create a full list of affected functionality and potential replacements to see if this whole idea is even feasible (referring to @harryadel 's comment)

[harryadel]

Yeah you right too. Maybe we should revisit this later on when the code quality improves and we get more comfortable with code.

…

On Fri, 7 Jan 2022, 1:28 pm Jan Küster, ***@***.***> wrote: The question is, if we can solve this in a way, that we can have jQuery as a drop-in or weak dependency so users, who still really really need this backwards compatibility can still use jQuery. Also @harryadel <https://github.com/harryadel> I checked some time ago the code for parseHTML and this is actually easily replacable. However, I agree with you, that the event removal is for older browsers an issue and I would also favor to implement a clean event removal (and not rely on the browser in such cases) at template destroy stage. — Reply to this email directly, view it on GitHub <#353 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSWGQK7I26ZM53AWLN5MMDUU3E6RANCNFSM5FGGZ2XQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[harryadel]

On a side note, I'm close to wrapping https://github.com/harryadel/blastjs The express example works fine it's the meteor and webpack that needs some work.

…

On Sat, 8 Jan 2022, 11:41 am Jan Küster, ***@***.***> wrote: I would argue that modern browsers have stable and proven replacements like queryselector. Handling Dom Element classes, props and events are also now much easier than in the old days. Maybe we first create a full list of affected functionality and potential replacements to see if this whole idea is even feasible (referring to @harryadel <https://github.com/harryadel> 's comment) — Reply to this email directly, view it on GitHub <#353 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSWGQMEEMUGMKYVBQJ5MO3UVABFLANCNFSM5FGGZ2XQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[harryadel]

From my research, all are easily removable except for the template destruction part. You'd find the issue mentioned in the comment not even resolved afaik. jquery/jquery#1736 Also, unless we copy the jquery implementation of some of the functions we drop older versions of IE. So it depends, how much of IE we want to support.

…

On Sat, 8 Jan 2022, 11:41 am Jan Küster, ***@***.***> wrote: I would argue that modern browsers have stable and proven replacements like queryselector. Handling Dom Element classes, props and events are also now much easier than in the old days. Maybe we first create a full list of affected functionality and potential replacements to see if this whole idea is even feasible (referring to @harryadel <https://github.com/harryadel> 's comment) — Reply to this email directly, view it on GitHub <#353 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSWGQMEEMUGMKYVBQJ5MO3UVABFLANCNFSM5FGGZ2XQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[faburem]

Is this still planned for the 3.0 release? I have a decent blaze code base for testing and would be happy to help make this happen!

[StorytellerCZ]

Yes, this is still planned, though it will probably be a while before we get there.

[jankapunkt]

@faburem this will likely to be breaking in case you use the template-level jQuery selectors, like this.$ in onRendered or inside events. We may replace these with native query selectors but we won't be able to preserve the rest of the jquery api

[faburem]

yes I am fully aware that this is a breaking change! In my project we are using a lot of template-level jQuery selectors so I think it would be a good candidate for testing.
Is there anything I could help you guys with?