Don't try to support AMD loaders in socket.io#491
Conversation
|
I personally hate AMD, it's pointless bloat to everybody who doesn't use AMD, it doesn't work and it's just pointless. AMD support should be solved in build systems not in libraries. So i'm all +1 on this @guille And I agree that this needs to be fixed and removed. |
Don't try to support AMD loaders in socket.io
|
my solution to AMD problem: The library $script.js https://github.com/ded/script.js was an immediate solution for me to convert an HTML file with many JavaScript includes, into one single script, that can be included at the bottom of the page on any website. I have looked at AMD ... And I think that $script.js solution is a better solution then AMD, simpler and smarter. (might be not a better way to write programs but a better solution) It adds to the head of HTML a SCRIPT tag element of asynchronous JavaScript. it adds them in the right order. it uses regular callbacks right after the SCRIPT tag has been finished loading. Because of adding regular script tags asynchronously I think it's much better then async-AJAX and eval. Because global variables remain global - not become within a function. so No need to change anything in the code, and everything works - and asynchronously! A Solution in minutes instead of hours (as if i had to rewrite everything to AMD). from this to this (includeable littleservice.js): so i can use it in any web site like this to my surprise asynchronous loading was much faster then regular html script includes |
|
When will this become part of latest stable version? We need it for docpad/docpad-plugin-livereload#5 |
The AMD loader support that was recently added pollutes things globally.
While undoubtedly useful, this can cause breakage when used with some other libraries, and it is therefore better to let developers do things their own way.
Case in point - #490, which I can reproduce - using Dojo and NowJS together will always break Dojo's
require.This PR undoes the relevant changes made by #453.