New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added UMD wrapper to make swfobject compatible with CommonJS and AMD #12

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
4 participants
@Munter

Munter commented Sep 3, 2012

This patch makes swfobject compatible with CommonJS and AMD module loaders

@pipwerks

This comment has been minimized.

Show comment
Hide comment
@pipwerks

pipwerks Sep 4, 2012

Member

Thanks for the suggestion. The SWFObject team has long maintained that we will keep the codebase as light and independent as possible. The SWFObject 2.3 beta has been placed on GitHub specifically so patches like yours can be maintained via separate forks. It's not a criticism of your code -- the patch is great for its purpose -- but adding CommonJS and AMD support is not on our roadmap, and this patch doesn't fix any bugs. Hope you understand. Cheers

Member

pipwerks commented Sep 4, 2012

Thanks for the suggestion. The SWFObject team has long maintained that we will keep the codebase as light and independent as possible. The SWFObject 2.3 beta has been placed on GitHub specifically so patches like yours can be maintained via separate forks. It's not a criticism of your code -- the patch is great for its purpose -- but adding CommonJS and AMD support is not on our roadmap, and this patch doesn't fix any bugs. Hope you understand. Cheers

@pipwerks pipwerks closed this Sep 4, 2012

@Munter

This comment has been minimized.

Show comment
Hide comment
@Munter

Munter Sep 4, 2012

So let me get this straight.

You are arguing that an uncompressed 270 bytes raw source increase that keeps the original functionality intact, yet offers the features of delayed module loading and support for nodejs is to high a price to pay in terms of file size.

Yet you have a source that is non-modular, which includes several copy/pasted domload scripts of multiple kilobytes regardless of what other modern libraries people already have on the page that offer the same functionality.

And then you say that the purpose of putting the code on github is to deliberately fragment the code base without having a single authoritative repository that actually has all the fixes.

Dear sirs, thank you for adding increased incentive for developers to move away from flash.

Munter commented Sep 4, 2012

So let me get this straight.

You are arguing that an uncompressed 270 bytes raw source increase that keeps the original functionality intact, yet offers the features of delayed module loading and support for nodejs is to high a price to pay in terms of file size.

Yet you have a source that is non-modular, which includes several copy/pasted domload scripts of multiple kilobytes regardless of what other modern libraries people already have on the page that offer the same functionality.

And then you say that the purpose of putting the code on github is to deliberately fragment the code base without having a single authoritative repository that actually has all the fixes.

Dear sirs, thank you for adding increased incentive for developers to move away from flash.

@avetisk

This comment has been minimized.

Show comment
Hide comment
@avetisk

avetisk May 30, 2013

@Munter can't agree more with you.

avetisk commented May 30, 2013

@Munter can't agree more with you.

@marcog83

This comment has been minimized.

Show comment
Hide comment
@marcog83

marcog83 commented Oct 14, 2013

@Munter +1000

@kud kud referenced this pull request Dec 18, 2014

Open

package.json please #34

@zwetan zwetan referenced this pull request Mar 16, 2016

Open

proposal #10

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment