Hi Tauren, I know it's been a good while since you made these comments :). Unfortunately, a new full-time gig, plus a move, plus family busyness threw my schedule enough out of whack that I couldn't make time for a while. For a month, I've been putting aside time regularly again for mundle now.
Anyway, your comments are really appreciated, and even more your time looking over and experimenting. I had to do a little bit of research to come up with the answers to your questions, in spite of having thought about these things early on when making these decisions. So that reminded me that I need to document the answers to a lot of the basic decisions I made for the future, as well. 3) I'll answer the easiest one first ;)- coffeescript. I appreciate the advice, but frankly, this is just for fun and I enjoy writing coffeescript, while writing javascript can be a chore. In any event, I think it's a silly objection, given that the javascript is in lib/ and is plenty readable. 1 and 2) As far as I can remember the choice of XHR+eval had a lot to do with the notion of separating asynchronous loading of scripts from their execution, which is blocking. At the time, I was working on a very large code base and large code bases are, I think one of the core would-be customers of mundle. Therefore, I felt it was an important performance boost to be able to load a lot of small code chunks asynchronously and have them available to be evaluated individually on need. I believe I was influenced in good part by these articles: http://www.stevesouders.com/blog/2010/12/06/evolution-of-script-loading/ http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/ If there's a way to achieve this using other more versatile script loading methods, I'd definitely be open to it, unless there's something else that drove my decision that I'm not remembering right but will remember later ;) As far as the cross-domain concern, I'm not sure this is a concern, since, by design, mundles have to be served by my server-side component which would be on my own domain. Is there a use-case where this would be a concern, given this peculiarity of the client-server interaction that mundle has? Thanks again, and thanks for my first outside-pull request. On Saturday, January 5, 2013 5:39:33 AM UTC-5, Tauren Mills wrote: > > Saleem, > > I had a little time to experiment with mundle tonight. It's interesting > and shows promise, but I have some significant concerns. I'd be interested > in your perspective on them: > > 1. Modules are loaded using XMLHttpRequest, which immediately brings > up cross-domain concerns. Only pages on the same protocol and exact > hostname will be able to load these modules without adding JSONP or CORS > support. > 2. When a module is requested, the payload returned is JSON containing > strings of code which are eval'ed. If you didn't already know, eval is > evil. But even more troubling is that code loaded this way doesn't show up > in the WebKit inspector (without using @sourceURL), thus hard to debug, > set > breakpoints, trace, etc. > > I see room for a tool like mundle, as it solves some problems other > loaders do not. But either one of the concerns above is enough for me to > move on. I suggest that you read this link carefully, as it explains these > issues better than I can: > http://requirejs.org/docs/why.html#5 > > I recommend you consider making the following improvements: > > 1. To get around the cross-domain issues, load modules by injecting a > script tag into the <head> instead of using an AJAX call. A simple example > of doing this can be found in the $script loader (see > https://github.com/ded/script.js/ ). More complex implementations, > such as YepNope, allow scripts to be loaded concurrently in any order, but > executed in the specific order you desire. This is done by loading scripts > as an image and letting the browser cache them, then loading them again > from cache as JS in the correct order to execute them. > 2. Have the server combine modules into a regular Javascript file, not > a JSON file. You have an advantage that most loaders do not - there is a > server-side component! So use it to build and wrap the raw modules with > the > correct "exports" context and so forth. > 3. Word of advice: you will get more interest if mundle was written in > Javascript, not Coffeescript. Most developers I know want critical > components (such ast their loader) to be pure JS. I have nothing > against Coffeescript myself, and have used it on some projects. But I > believe it is something better suited for building your custom > application, > not general purpose tools such as a loader. > > Lastly, I created a pull request to fix an issue when loading mundle > modules from an HTTPS server. I found that all modules were loaded via HTTP > only, even if the current page is HTTPS. Here's the fix: > https://github.com/meelash/Mundlejs/pull/17 > > I hope this helps! > > Tauren > > > > On Thu, Jan 3, 2013 at 3:09 PM, Oliver Leics <[email protected]<javascript:> > > wrote: > >> On Thursday, January 3, 2013 6:44:54 PM UTC+1, Saleem Abdul Hamid wrote: >> >>> Aren't there plenty of successful os projects with GPL? Is there any >>> reason why it doesn't work in the node community, besides what everyone >>> else is doing? Are there a majority of commercial project using node? >>> >> >> Latest discussion: >> https://groups.google.com/forum/?fromgroups=#!topic/nodejs/5xxD2c4UfK8 >> >> -- >> Job Board: http://jobs.nodejs.org/ >> Posting guidelines: >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >> You received this message because you are subscribed to the Google >> Groups "nodejs" group. >> To post to this group, send email to [email protected]<javascript:> >> To unsubscribe from this group, send email to >> [email protected] <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/nodejs?hl=en?hl=en >> > > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
