Please DO NOT do this. A huge amount of code, especially in top 1 million websites, relies on a LOT of these event shorthands. The reason .load() was deprecated was because it was ambiguous. Not only these remaining shorthand have no ambiguity but is actually much cleaner code. Do not fix something that is not broken.

A good example: We would have to change $("#div1").focus() to $("#div1").trigger("focus");
$("#div1").focus(function(){ DoSomething() }) to $("#div1").on(""focus",function(){ DoSomething() }));

Please do not break such important shorthands just because one person complained about it. The biggest reason to continue to use any library is its backward compatibility. If it keeps breaking stuff for ZERO apparent gain, then many users will either seriously consider moving to different library or stay with older version. I am guessing jquery does not want that.

In addition, there are millions of jquery plugins which uses these shorthand and there is no way every single one of them would be updated. This would break the entire jquery ecosystem.

I hope you guys see the magnitude of this change. Not only do users not gain from this; but it will break lots of stuff for no reason.

I'm +1 on deprecating, -1 on ever removing from the default build. It's already easy to exclude in a custom build, but the deprecation is a good signal to developers that they should aim to not use them.

I'm not a fan of deprecating something we don't plan on removing. Considering that, I might be a -1 on deprecating these. They're just too prevalent to remove, and I don't see the downside of using them if you like them. I prefer .on too, but I have no disadvantages in mind to back up a harangue for using an alias.

The reason I'm in favor of deprecating, but not removing is that it will encourage plugin developers to support users who want to exclude the event alias module. This is the only module, besides the deprecated module, that we support excluding with jQuery UI.

I've also personally disliked these methods for many years because they operate in the reverse order of what's expected for the trigger scenario (the primary action is firing an event, not taking an action like the native equivalents). The result is close enough to the expected, native behavior that most developers don't notice, but it's definitely been a source of pain for a long time.

The Bootstrap team has a similar thought to @scottgonzalez in twbs/bootstrap#20203 and are planning to use the slim build. Obviously most consumers of Bootstrap will be using the full build but it's nice for end-developers that a plugin doesn't unnecessarily force them to use a full build.

I'm fine with deprecating but not ever removing. Slightly more complicated, we can not deprecate it and come up with another term and use that in the API docs to define APIs that plugins should avoid. It's already possible to exclude event-alias in a custom build, but without some signal to plugin writers about what to avoid that isn't going to help much.

To @john2014's concern, even if we removed event aliases in the core library we have always provided plenty of compatibility helpers to make the transition easier. If someone is moving from jQuery 3 to a hypothetical jQuery 4 without event aliases, they would just add jQuery Migrate 4 at the time they changed to jQuery 4 and it would report the things to fix.

To add to the above points, deprecating these shorthands will mean the slim
build won't contain them which, in turn, may serve as an incentive to
plugin authors to stop relying on them and at the same time will not block
people from upgrading to a newer jQuery since the full build will continue
to work.

Michał Gołębiowski

It's also interesting that Bootstrap actively disables aliases in their unit tests so they won't accidentally be used. They could have used a custom build of course but this way their tests generate a clear error message if one is used accidentally.

I agree with @john2014 that the tradefoff is not worth it (saving few lines of code vs breaking a lot of user code + lots of jquery plugins - maintained or unmaintained; but actively used).

@john2014's concern, even if we removed event aliases in the core library we have always provided plenty of compatibility helpers to make the transition easier. If someone is moving from jQuery 3 to a hypothetical jQuery 4 without event aliases, they would just add jQuery Migrate 4 at the time they changed to jQuery 4 and it would report the things to fix.

The most important point is backward compatibility. Users should not have to keep modifying their code (and every jquery plugins they used), everytime a new jquery major version is released.

Note: Jquery migrate will certainly solve that "newly created" problem. But that will involve users having to add two javascript sources instead of one. Many users may not even be aware that Jquery migrate exists. I dont think saving few lines of code is worth breaking lots of code.

As you may know, Jquery is already less than 34 KB when you load it from Google CDN and its permanently cached. Reducing files size to 33 KB (or even 29 KB) isnt going to make much difference. A single image on Facebook is more than 60 KB. So filesize should not be an important criteria. IMHO, the most important criteria should be backwards compatibility and adding new features to continue to make Jquery a great library.

@BillJones50 @john2014 I think the whole core team agrees that these should not be removed. Some would like to warn against their use, though, and deprecation might be the best way to do that.

However, I still think the word "deprecation" will give the wrong signal. That is, some people will believe jQuery intends to remove them down the line (as is evidenced by @BillJones50's comment), and we don't.

Thank you @timmywil

I forgot to add that using shorthand not only saves significant coding time, but also reduces end user filesize (since there is less code). Using shorthand is a win-win for developers.

I forgot to add that using shorthand not only saves significant coding time, but also reduces end user filesize (since there is less code). Using shorthand is a win-win for developers.

Both are a lie.

You don't save significant coding time with any shorthands like this. The time it takes to type a few characters is negligible, even over an entire year's worth of coding. Even the time you spend typing in general while coding is fairly small. Keystrokes are not where you get significant gains in development time.

As for end user file size, I assume you're referring to the number of bytes transferred, not the number of bytes in the cached file on the user's drive. The number of bytes you think you're saving during transfer (bandwidth) disappears when the code runs through gzip prior to the transfer.

You do realize that not everyone uses Gzip on their server.

In addition gzipping (compression) increases server loads (it has to compress every single time unique visitor requests javascript files) and is not suitable for all situations. If we can compress codes (using shorthands) before the gzip process, its lot more useful.

I am not sure why you think providing quick shorthand is a problem. Shorthands (called symbolic links) in Linux OS is very widely used and is a feature that should be advertised for saving time/money and not something to be hidden from users.

The most important point is backward compatibility. Users should not have to keep modifying their code (and every jquery plugins they used), everytime a new jquery major version is released.

Breaking backwards compatibility is precisely the reason for releasing a new major version. Not every user will have to modify code, but it is a guarantee that at least some will. So please consider this a strong suggestion to avoid event shorthand methods in all new code.

I think there is confusion about term "deprecating".

Let's go to the wikipedia page for the definition -

Deprecation is the discouragement of use of some feature, design or practice, typically because it has been superseded or is no longer considered safe, without (at least for the time being) removing it from the system of which it is a part or prohibiting its use.

without removing - purpose of tickets like that is only to discourage use of it. Nothing more. For example, DOM method window.unescape is deprecated, but it is not removed until browser vendors will be sure (based on their usage stats) that no one is no longer using it aka "Not to break a web" principle.

We could use same rule - not remove those widely used methods until no one uses them with newer version of jQuery, meanwhile, if we unfavor this practise we should show it. That's all it is.

Not the first time i see this misconception which really sadness me, i urge everyone to see formal limitations of this term.

Can we move it to 3.2.0? 3.1.0 is almost ready (in fact, I moved all issues previously assigned to 3.1.0 to 3.2.0).

@markelog A formal definition has little bearing on the popular connotations associated with a term, which is why dictionaries change with time. Your point does not change my belief that "deprecation" implies eventual removal, at least to some. I wish there was a way we could say that we recommend avoiding a particular API, which is different than saying we recommend avoiding it and it may be removed in a future version.

@timmywil How about if we changed the name of the deprecated module to discouraged and moved there stuff that we don't want to remove due to widespread usage but we still recommend to avoid? This module would be then excluded from the slim build which may urge library creators to avoid those APIs for real.

Yeah if we're not going to use Deprecated for these then we should come up with another term. We've got quite a few of these "Deprecate X" issues open and they seem to be blocked on coming to an agreement about this.

@timmywil

Your point does not change my belief that "deprecation" implies eventual removal, at least to some

It does imply that to some because it is a first step in removal process, there isn't any other way really, we can call any way we prefer - discouraged, abandoned or expecto patronum or something.

It wouldn't change the meaning of what we are doing which is discouraging people from using it, so it still would be the first step in removal process

I actually don't think deprecation must mean plans to remove in the nearby future. I would say, though, that deprecating sth means we discourage using it and we'd love to remove it but who knows if and when the removal will be possible. If we don't want to remove it not due to widespread usage but just because we think this API should continue to exist then why would we discourage using it? Those two things don't really go hand in hand with each other.

Applying that to this ticket, I'd say that since we want to discourage it, we should deprecate it even if we can only remove it in 5 or 10 years.

That's exactly what i'm trying to say, thank you

There is some precedent for long deprecation. We deprecated jQuery.browser in 1.3 but didn't remove it until 1.9. In that case we also got a lot of complaints about the deprecation.

The main issue here is that the longer we wait to send the signal "this isn't best practice anymore" using whatever word, the longer it will take for people to change their code because they're not aware of it. Just like jQuery.browser there will be people who disagree with whether something is good practice or not, and there may be a lot of code out there using it. That can affect when we remove it.

Is there a particular reason some Jquery members want to actively discourage using shorthands?

The only reason I can think of is reducing file size (by eventually removing it - whenever that would be).

So I did actual calculations and after minify+Gzip, it only saves around 400 bytes. Is there any other reason?

Is there any other reason?

#3214 (comment)

That does not seem right. Why should plugin developer have to worry about which slim build the user has selected. The user could have excluded lots of things in their slim build. That should not mean that plugin developer should code around that. This is why software solutions have dependencies. If you want to use particular version, just add this dependency and in this case its only 400 bytes (jquery only have to be loaded once and is cached permanently in your browser).

The main point is, plugin developer should tell user on what is needed to run their program and not the other way around. Or am I missing something obvious here?

The main point is, plugin developer should tell user on what is needed to run their program and not the other way around. Or am I missing something obvious here?

A considerate plugin developer shouldn't force a user to pull in more code than needed.

That does not seem right. Why should plugin developer have to worry about which slim build the user has selected. The user could have excluded lots of things in their slim build.

They could, but it's super simple for plugin developers to support this one specific thing.

This is why software solutions have dependencies.

You literally can't define this dependency as a plugin developer.

If you want to use particular version, just add this dependency and in this case its only 400 bytes.

That's not an option for the plugin developer. That's an option for the application developer. If the plugin could actually define the dependency, that would be a different story.

jquery only have to be loaded once and is cached permanently in your browser

This is far from true.

I think there is some mixup happening.

A considerate plugin developer shouldn't force a user to pull in more code than needed.

I agree completely.. However shorthands are not obscure code. Shorthands maybe some of the most used features (especially click, onmouseover, onmouseout, etc). So for many plugin developers it may not be unreasonable to expect its presence in core code (this point is where opinions maybe divided).

They could, but it's super simple for plugin developers to support this one specific thing.

I am looking at a more global view. Users can exclude anything in their slim build. So we cannot reasonably expect plugin developers to (a) today support this one specific thing (b) tomorrow to support another specific thing and so on. Again we are asking plugin developers (today) to support users with particular slim build (who have chosen to exclude shorthands). Tomorrow would we ask plugin developer to support users who have another slim build? Its down the rabbit hole.

You literally can't define this dependency as a plugin developer.

You literally can. You can add this in the download page as an important note. Jquery UI already does this exact dependency. Example if you want draggable widget, you need to have atleast 3 UI core (Core, Widget, Mouse).

That's not an option for the plugin developer. That's an option for the application developer. If the plugin could actually define the dependency, that would be a different story.

Plugin cannot actually define dependency inside the code (because it is pure javascript). But if you add this dependency note in download page, any reasonable person would understand it. If they don't add dependency suggested by plugin devs, the plugin will simply not work (see draggable widget example above).

This is far from true.

If you load the full build from Google CDN or any well know CDN, it is 100% true. If you load the full/custom build from your server, then you need to setup caching on your server to cache static content.

Finally I would like to add that IMHO, Jquery is one of the best javascript library out there. And I am thankful to all of you for your hard work in making this happen. I apologize if I came across as something opposite.

The only reason I chimed in is because I think this "bug" will have a major impact on existing user code + (probably) most of jquery plugin. I would like more people to use this library (but if it breaks lot of existing code, it may have an adverse effect). Shorthand is safe (no bugs), is easy to learn/code/maintain, and has tiny file size (0.4 KB).

If you guys do decide to remove the shorthand, I am sure the Jquery community will adjust (simply because they wont have a choice :))

Users can exclude anything in their slim build.

Custom build, not slim. The slim build has concrete meaning now: https://code.jquery.com/jquery-3.0.0.slim.js. See also the 3.0.0 blog post (section "Slim build"). Since the slim build doesn't include deprecated APIs, if we deprecated shorthands, the slim build wouldn't contain them.

Shorthands maybe some of the most used features (especially click, onmouseover, onmouseout, etc). So for many plugin developers it may not be unreasonable to expect its presence in core code (this point is where opinions maybe divided).

That's an argument against removal, not against deprecation. Deprecation is a means by which developers can be encouraged to stop expecting their presence.

after minify+Gzip, it only saves around 400 bytes.

That seems very high, but if true is an argument in favor of deprecation and eventual removal, because it's about four times larger than what we consider a substantial reduction (and accounts for 1.3% of total size!).

Is there any other reason?

.on and .trigger provide unambiguous non-overloaded means of dealing with all events, including those not covered by shorthands. The latter are syntactic saccharin, not worth the extra file size, the saved keystrokes, the reservation of jQuery prototype properties, or the mental overhead. And if anyone disagrees, they are free to define whatever they want in a plugin—the code is trivial.

You literally can't define this dependency as a plugin developer.

You literally can. You can add this in the download page as an important note. Jquery UI already does this exact dependency. Example if you want draggable widget, you need to have atleast 3 UI core (Core, Widget, Mouse).

Sure, in text. But real dependency management doesn't happen in text, it happens in code, and you can't define this dependency in your code. jQuery UI's dependency management within the download builder doesn't help developers of third party plugins that have dependencies on specific widgets within jQuery UI. jQuery UI does however make this possible through the use of AMD where you can actually define dependencies on individual parts. This is actually what powers the download builder. So a third party developer of Amazing Dialog can very easily, in code, define a dependency on jQuery Core and jQuery UI Dialog. jQuery UI Dialog can in turn define a dependency jQuery Core, jQuery UI Draggable, jQuery UI Resizable, and jQuery UI Position. Those plugins can then define their dependencies, and this works all the way down the chain, resulting in other plugins such as jQuery UI Widget and jQuery UI Mouse being loaded. You cannot do this with modules from jQuery Core.

Plugin cannot actually define dependency inside the code (because it is pure javascript)

Yes, you can. People have been doing this for many years. Please take some time to read about RequireJS (custom solution) and JavaScript modules (native solution).

If you load the full build from Google CDN or any well know CDN, it is 100% true.

It's actually not. There are fairly high cache miss rates from well known CDNs. You can say you want something cached forever, but you don't have control over the end user's cache.

The only reason I chimed in is because I think this "bug" will have a major impact on existing user code + (probably) most of jquery plugin. I would like more people to use this library (but if it breaks lot of existing code, it may have an adverse effect). Shorthand is safe (no bugs), is easy to learn/code/maintain, and has tiny file size (0.4 KB).

Nothing at all will break because this is not about removal.

If these shorthands aren't likely to ever be removed, why not wait for a major version (and new version of jQuery migrate) to deprecate them?

@lpd-au Waiting for a major version wouldn't help in reducing usage of these shorthands. Besides, according to semver deprecations are free to land in minor releases.

Just because they can, doesn't mean they always should. Especially the .click(function) being such a widely used part of the library, the canonical example to show jQuery's elegance over native JS, which isn't documented anywhere as being in bad style. There is no rush here to deprecate for later removal in an imminent major release, which is probably why it's already been pushed back from 3.1.0 to 3.2.0 to 3.3.0... can we just make the wait official? How do you expect usage to fall anyway among developers who already transitioned to jQ3 and removed the migration plugin?

Nothing has broken because of this deprecation. It doesn't make sense to undeprecate the feature just to get rid of a warning in Migrate. You can either ignore the warning or override jQuery.fn.click() after loading Migrate to get rid of it. Or, change the code generating the warning.

Undeprecate? What am I missing here... the issue is still open, marked for an unreleased milestone and isn't documented anywhere that I can find?

I think it's safe to deprecate in the next version. It's not getting removed so no code will be broken.