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
