btw, bruno, how do you do the dependency analysis? A full parser? On Monday, March 26, 2012 12:01:41 AM UTC-7, Bruno Jouhier wrote: > > I have a similar thing. Not fully packaged but I published it a while ago: > https://github.com/Sage/streamline-require > > It analyzes the dependencies server side and supports both synchronous and > asynchonous requires. Like yours, it returns the entire dependency graph in > one shot. So the client gets everything it needs in one roundtrip. It also > monitors changes to the source tree and returns a 304 if the browser has an > up-to-date version. > > There is one further refinement: when you request additional module > asynchronously, the client sends to the server the list of modules that it > had requested before and the server computed the list of dependencies of > the new modules as well as the list of dependencies of the modules that had > been requested before and it sends back to the client a single response > with the modules of the first list that are not in the second list. So, if > the client had gotten A, B, C, D, E, F in a first require and requests G > which requires B, C, and H, the server only returns G and H to the client. > I the client then requests I which requires C, F and H and J, the server > returns only I and J. > > Overall, this is extremely fast. > > I was doing the dependency analysis client side before and loading the > modules one by one. Terrible in comparison. > > Bruno > > On Sunday, March 25, 2012 1:04:52 AM UTC+1, meelash wrote: >> >> tl;dr - Client-side require with a server-side component that caches >> dependencies, bundles them, and caches the bundles. Need feedback on >> the concept, syntax. Need suggestions/contributions on implementation. >> Although, this works for me, it is almost just a proof-of-concept, >> needs work. >> >> >> As part of a project I'm working on, I spent a few hours writing a >> little client-side module loader with a server-side component enabling >> what I think is a pretty neat meaning to CommonJS module syntax. This >> morning I pulled it out of the rest of my project and attempted to >> package it in a useful way for others to use. >> >> The basic idea is this- in your client-side code, you can use require >> in either a "synchronous" or asynchronous fashion- >> module1 = require('some/path.js'); >> require('some/other/path.js', function(err,result){module2 = >> result;}); >> >> An asynchronous require makes a call to the server component to get >> the file in question, but before returning the file, the server parses >> it, finds all the synchronous require calls, loads those files as well >> and returning the whole thing as a package. That way, when the >> original file that was asynchronously loaded is executed and comes to >> one of those synchronous require calls, that file is already there, >> and the require is actually synchronous. >> >> At this point, maybe this screencast demo will help to clarify how it >> works: >> http://screencast.com/t/nOU53BRYUAX<http://screencast.com/t/nOU53BRYUAX> >> >> Put another way: >> If I async require fileA, and fileA has synchronous dependencies on >> fileB, and fileC, and an asynchronous dependency on fileD, the server- >> side component will return (in a single "bundle") and keep in memory >> fileA, fileB, and fileC, not fileD, and it will execute fileA. >> The client-side also separates fetching the files and eval'ing them >> (the method of getting files is xhr+eval). So, let's say fileA has >> require('fileB'); that executes when the file is parsed and executed >> on the client, but require('fileC') is inside a function somewhere. >> Then fileA will first be eval'ed, then fileB when it comes across >> that, and the text of fileC will just be in memory, not eval'ed until >> that function is called or some other require to it is called by any >> other part of the program. >> >> Another example- >> fileA has dependencies fileB, fileC, fileD, fileE, fileF >> fileG has dependencies fileC, fileE, fileH >> >> When I call require('fileA', function(err,result){return 'yay';});, >> the module loader will load fileA, fileB, fileC, fileD, fileE, and >> fileF all in a single bundle. >> If I, after that, call require('fileG', function(err,result){return >> 'yay';});, the module loader will only load fileG and fileH! >> >> Hopefully, that's clear.... >> >> The advantages- >> Being aware of the difference in synchronous and asynchronous require >> in your client-side code make it extremely natural to break all your >> client-side code into small reusable chunks- there is no penalty and >> you don't have to "optimize" later by deciding what to package >> together and what to package separately. >> Handling dependencies becomes nothing. You don't have to think about >> it. >> The server can have a "deployment" mode, where it caches what the >> dependencies of a file are and doesn't ever need to parse that file >> again. >> In "deployment" mode, the server can also cache bundles of multiple >> files that are requested together, so when another client requests >> that same bundle, it is already in memory. >> >> To sum up: >> xhr+eval-when-necessary client-side module loader >> both synchronous-ish and asynchronous require in your client side-code >> --the synchronous require is actually a command to the server-side >> component to bundle >> server-side component >> --parses for dependencies and bundles them together >> --can cache dependency parsing results and whole bundles >> >> >> So- thoughts? Is this a horrible idea? Are there some gotchas that I'm >> missing? >> >> Specific advice needed- >> • How to package this in a way that it can be easily used in other >> projects? How can I make it integrate seamlessly with existing servers >> and make it compatible with different transport mechanisms? >> • How to handle path resolution? >> • Suggestions for licensing? >> • Suggestions for a name- (Mundlejs is a portmanteau of Module and >> Bundle- didn't really think long about it) >> >> Things that need to be (properly)implemented: >> • server-side "parsing" is just a brittle regexp right now: >> (line.match /require\('(.*)'\)/) >> • neither type of server-side caching is implemented (pretty easy to >> do) >> • uniquely identify clients and keep the server away of what modules >> they already have, so we can just send the diff of cached modules- >> currently, I'm sending the entire list of already cached modules with >> every xhr call, so the server doesn't load a dependency twice. >> • proper compatibility with module specifications (i.e. CommonJS)- >> right now, it's just require and module.exports >> >> >> Code is available here: >> https://github.com/meelash/Mundlejs<https://github.com/meelash/Mundlejs> >> To test it: >> from Mundlejs/tests/, run >> node server.js >> visit http://127.0.0.1:1337/ and open your browser console. > >
-- 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
