#ender.js

[dayjs-blog]

Ender.js的plugin之一，簡化那該死的HTML5 drag & drop interface的library

看似沒Ender.js也可以獨立運作這樣

(Ender.js是甚麼之後再說)

Dagron: Ender interface to HTML5 Drag and Droppables

[mishagreenberg-blog]

Ender.js

So I have been messing around with ender.js. I found some things I like and some I don't. I am a huge fan of the jeesh but ender has not sold me yet. Here's why:

0) The idea that you can store all your modules in npm and serve them to the browser sounds good to me but there are some issues. I really like seeing modules as separate files when I am debugging. Ender builds a big monolithic file containing all your libraries concatenated together, so it is not easy to sort through them to find the lines of code you need. It is also a pain to have to build the library file every time there is an update.

1) What is the value of having a library that is really only meant to work in the browser environment living in npm? Perhaps it could make sense for some utility libraries like underscore.js, but what about a canvas library like paper.js? 

2) I am not a big fan of the global $. Why not just keep the libraries separate instead of trying to mesh them all together. How can I tell which library $.pluck comes from? I am a HUGE fan of micro-frameworks and I find it very useful to see which dependency object owns the method I am calling. In ender's defense I could use it's commonjs module syntax [require(module)] to access the modules separately, but I really like the feel of defining dependencies as arguments in the module closure - that is just a personal preference I guess, though here is a well thought out argument in favor of amd by Miller Medeiros.

So right now I am sticking with require.js and using some of Dustin Diaz's great modules like klass. I serve the library files to the browser separately during development so the modules are all easy to read. Once I am ready to deploy, I can build a big uglified js file using r.js that has all my production code in it.