search

meteor / blaze

:fire: Meteor Blaze is a powerful library for creating live-updating user interfaces
http://blazejs.org/
Other
528 stars 115 forks source link

Remove jQuery #353

Open jankapunkt opened 3 years ago

jankapunkt commented 3 years ago

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

There are also some caveits:

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 commented 3 years ago

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 commented 3 years ago

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

StorytellerCZ commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 https://github.com/meteor/blaze/issues/353#issuecomment-1007336226, 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 commented 2 years ago

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 https://github.com/meteor/blaze/issues/353#issuecomment-1007930630, 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 commented 2 years ago

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. https://github.com/jquery/jquery/issues/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 https://github.com/meteor/blaze/issues/353#issuecomment-1007930630, 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 commented 2 years ago

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 commented 2 years ago

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

jankapunkt commented 2 years ago

@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 commented 2 years ago

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?