I thought this page would be of interest. It introduces ss.load.code() that allows you to require modules in the browser in an asynchronous manner. (Of course that is different from an asynchronous require on the server)
Loading Assets On Demand (in socketstream) https://github.com/socketstream/socketstream/blob/master/doc/guide/en/loading_assets_on_demand.md On Thu, May 17, 2012 at 8:30 PM, Angel Java Lopez <[email protected]>wrote: > Interesting... thanks for the detailed history. > > Isaac, this is nice topic for dinner at Buenos Aires, with Argentinean > meat and wine ;-) we are waiting for your talk at http://jsconf.com.ar > > On Wed, May 16, 2012 at 9:11 PM, Isaac Schlueter <[email protected]> wrote: > >> Synchronous require() not a "wart". Nor are fs.*Sync functions warts. >> They're a valuable API that's there for a reason. >> >> require() is for the startup time of your application. It's >> significantly faster and simpler than loading modules asynchronously. >> If you want a more complex module loader, then **build one**, and load >> it synchronously at program startup. >> >> I'm not just speaking theoretically here: I was personally very >> involved with the development of node's module system, which started >> out as a dual sync/async thing. Some of you may remember include(), >> include_async(), and require_async(). >> >> You know what else has to be read synchronously at startup? The node >> binary. >> >> Node is for writing servers. Servers have a startup phase where >> they're not serving requests. >> Node is also for writing command line utilities. Command line >> utilities are best when they start up quickly. >> >> Do you think that we just do asynchronous IO because it's some kind of >> new fad, a word we say over and over again because it broadcasts >> membership in some kind of club? No. That's not rational. >> >> Do you think that "async" is some kind of magic gel that you pour over >> your program and it makes it webscale? Please. Computers are not so >> easily fooled. You make programs go faster by using resources wisely, >> not by praying to some event loop gods. >> >> Why does any of this matter? The point of doing things asynchronously >> is so that you can continue to serve requests while IO is in progress. >> This is relevant **only** because IO (especially network IO) is many >> many orders of magnitude slower than anything else in your program. >> >> You can take advantage of this by serving requests while other >> requests are waiting on IO. >> >> If you want to dynamically reload modules at run-time, there's a good >> chance that you would be better off running that module as a child >> process, and restart it on changes. The cluster module in v0.6 was a >> good proof of concept for doing this, and in v0.8 it's much more >> fleshed out. Dynamic module reloading is something we explored very >> thoroughly in the early days of node's module system. It is fraught >> with peril. The correct approach is to restart the server when you >> want it to load new code. You can do this with workers in a cluster >> pretty easily. >> >> Otherwise? yeah. require() blocks. It's optimized for the startup >> phase of your program, where it is important to go as fast as >> possible, rather than be available to requests. Your server isn't >> serving while it's happening. If you're require()ing something that >> is not a native module, and not cached, then this means you'll wait a >> few ms (or more!) while it reads from disk. That's why node programs >> typically do a bunch of require() calls up at the top of the file, not >> inside the server callbacks. >> >> There's been a lot of exploration to come to this point, and figure >> out the direction forward. I think we can make these patterns a lot >> simpler to take advantage of. Adding an asynchronous require() would >> not be correcting a wart. It would be a step backward. >> >> >> On Wed, May 16, 2012 at 8:50 AM, Axel Kittenberger <[email protected]> >> wrote: >> > The true question is, why doesn't node follow its own naming >> conventions, >> > and call it requireSync()? >> > >> > I know the answer is probably, because some code functions are older >> than >> > these conventions. Anyway it makes a bad role model for module devs, if >> the >> > core already takes it quite lenient. >> > >> > I'd suggest a 2nd optional parameter, which can be a buffer or string >> what >> > would be the files contents, even the filename is just a phony name to >> sure >> > uniqueness and reuse. So if you need any kind if asynchronousness, >> database, >> > web-fetch or whatever, its your responsibility to aquire the contents >> before >> > calling require which by itself is always a requireSync. >> > >> > Am 15.05.2012 20:30 schrieb "MartÃn Ciparelli" <[email protected]>: >> > >> >> So the question would be: why an async-driven platform uses sync-driven >> >> way to load modules? >> >> >> >> 2012/5/15 Marak Squires <[email protected]> >> >>> >> >>> require() is a sync call. >> >>> >> >>> If you need an async require ( a require that performs i/o ), you >> should >> >>> check out a plugin system like Broadway >> >>> ( https://github.com/flatiron/broadway ) >> >>> >> >>> This will allow you to require modules with an optional .init and >> .attach >> >>> methods, which can both accept optional callbacks. >> >>> >> >>> >> >>> On Tue, May 15, 2012 at 8:49 AM, Guoliang Cao <[email protected]> >> wrote: >> >>>> >> >>>> Hi, >> >>>> >> >>>> I'm new to Node.js and wrapping my head around the asynchronous >> >>>> programming model. A question comes to mind is why 'require' itself >> does not >> >>>> use callbacks like below. I believe IO is involved in require and a >> lot of >> >>>> things can fail. >> >>>> >> >>>> require('http', >> >>>> function(http){ >> >>>> // do stuff with http >> >>>> }, >> >>>> function(error) { >> >>>> console.log("Failed to load http"); >> >>>> }); >> >>>> >> >>>> >> >>>> Thanks, >> >>>> Guoliang Cao >> >>>> >> >>>> -- >> >>>> 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 >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> -- >> >>> Marak Squires >> >>> Co-founder and Chief Evangelist >> >>> Nodejitsu, Inc. >> >>> [email protected] >> >>> >> >>> -- >> >>> 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 >> >> >> >> >> >> -- >> >> 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 >> > >> > -- >> > 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 >> >> -- >> 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 >> > > -- > 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 > -- 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
