[wp-trac] [WordPress Trac] #23285: Implement an AMD JavaScript loader in WordPress

[WordPress Trac]

#23285: Implement an AMD JavaScript loader in WordPress
-----------------------------+------------------------------
 Reporter:  auniquename      |       Owner:
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |
-----------------------------+------------------------------

Comment (by bpetty):

 Putting aside @auniquename's personal issues working with jQuery and other
 JS libs themselves, the idea of using RequireJS with
 [http://requirejs.org/docs/api.html#multiversion multiversion support]
 actually does have some merit, and is at least worth some investigation,
 discussion, and possible patch down the road.

 As was mentioned, WP does update bundled JS libraries very frequently, and
 they are often updated to API incompatible versions. They might as well be
 since there's no stable API policy around 3rd party JS libraries still.
 Most of the libraries WP bundles are bundled because they are quality,
 popular libraries, and so they often do have good policies around
 backwards compatibility even when upgrading to API incompatible versions
 (often only removing really old API like WP occasionally does, or
 infrequently used API). So it doesn't happen very frequently, but plugins
 do occasionally break when WP is updated and those JS libraries the plugin
 was originally built on are updated with it to API incompatible versions.
 That is the definition of "API incompatible", code originally written to
 work with older versions is not guaranteed to work with the new API
 incompatible branch.

 I'd be surprised if the plugin review team hasn't seen this with old
 plugins. Do they even review old plugins, particularly ones with high
 incompatible votes in the compatibility matrix, or only new ones?

 Anyway, I believe these are the same issues @auniquename is referring to.
 They are also the same issues I've referred to in the past when discussing
 [http://ibaku.wordpress.com/2012/11/08/wordpress-plugin-and-theme-api-
 manifest-versioning/ plugin API manifest versioning]. I actually do
 believe this is one approach to the problem that could potentially work.

 Replying to [comment:8 auniquename]:
 > People have custom plugins written for their site alone, and then may
 never hear from the developer again and are unable to maintain code
 themselves. Ya, their bed, lie in it, yada, yada...  But if we can prevent
 that, then why not?

 Sorry, but you'll generally find that most of the WP community doesn't
 care about these people, and the response you'll almost always find from
 WP developers is "upgrade your plugins or fix them" - and if their
 developer has abandoned them or disappeared, the answer is hire another.
 You won't get far with that argument.

 Also keep in mind though that if you feel like you're being pushed back,
 it's because you're making a suggestion to change something without even
 providing a patch to review and test out. Anyone that agrees with you in a
 situation like this seems to believe they are volunteering to do the work
 (and I wish they didn't because they aren't). When that happens, they're
 always inclined to defend however it is that WP currently handles (or
 doesn't handle) that issue.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/23285#comment:10>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software