Cool Mariusz, looks good... I'll switch to that this weekend, hopefully. saleem
On Tuesday, March 27, 2012 1:34:34 AM UTC-7, Mariusz Nowak wrote: > > Guys, check https://github.com/medikoo/find-requires > > -- > Mariusz Nowak > https://github.com/medikoo > http://twitter.com/medikoo > > On Tuesday, March 27, 2012 10:26:32 AM UTC+2, Bruno Jouhier wrote: >> >> Same way you do it: regexp >> >> On Monday, March 26, 2012 9:49:28 PM UTC+2, meelash wrote: >>> >>> 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
