Mochabot log - CommonJS IRC channel: #commonjs on irc.freenode.net

2010-11-17:

[14:56] <mschwartz> Wes-_ you about?
[14:56] <mschwartz> seen this? https://github.com/senchalabs/connect
[14:57] <mschwartz> and this?
[14:57] <mschwartz> http://expressjs.com/
[14:58] <Wes-_> Nope. Sencha looks a bit like JSGI
[14:58] <mschwartz> sencha is extjs
[14:58] <mschwartz> the company that makes it
[14:58] <Wes-_> As does expressjs
[14:58] <mschwartz> yep
[14:58] <mschwartz> the git repos look recent enough
[14:58] <mschwartz> like 4 days ago, last mod
[14:59] <mschwartz> perhaps one of the biggest things holding back server side JS is the lack of a corporate sponsor
[14:59] <Wes-_> I have to admit, though, my interest level in middle is pretty low :)
[14:59] <mschwartz> well, mine too at this point
[15:00] <Wes-_> mschwartz: Don't need a corporate sponsor, just large corporate projects
[15:00] <Wes-_> er, middleWARE not middle
[15:00] <mschwartz> well, my boss disagrees
[15:00] <Wes-_> *shrug* - if he wants to dedicate resources, he should go right ahead and start spending money then :)
[15:01] <mschwartz> heh
[15:01] <mschwartz> that's not the point
[15:01] <mschwartz> btw
[15:01] <mschwartz> he wrote this:
[15:01] <mschwartz> http://www.amazon.com/JavaScript-Complete-Reference-Thomas-Powell/dp/0072253576/ref=sr_1_2?ie=UTF8&qid=1290007896&sr=8-2
[15:02] <Wes-_> My opinion is that the biggest thing holding us back from widespread adoption is the insistence by the web-platform guys that you have to drop everything else in favour of ssjs
[15:02] <Wes-_> I think a migratory stack would be extremely beneficial
[15:02] <mschwartz> they dropped perl (or whatever) in favor of ruby
[15:03] <Wes-_> No, they dropped perl in favour of PHP
[15:03] <mschwartz> Ruby Central, Inc.
[15:04] <mschwartz> where's the SSJS, Inc.
[15:04] <Wes-_> switzerland
[15:04] <mschwartz> who?
[15:04] <Wes-_> Chris Zumbrunn
[15:04] <mschwartz> unless he's a very rich guy pumping lots of money into it, it is not close to the same thing
[15:05] <mschwartz> where's the ssjs conferences?
[15:05] <Wes-_> mschwartz: you seem to be missing the point
[15:05] <Wes-_> ssjs is irrelevant
[15:05] <Wes-_> CommonJS is what matters
[15:06] <mschwartz> I agree commonjs is a huge step forward
[15:06] <mschwartz> yet
[15:06] <Wes-_> And if you're not aware of JSConf et al.. well, maybe you should re-examine the advice I gave you last week
[15:06] <mschwartz> where's the CommonJS, Inc.
[15:06] <Wes-_> (get up to date!)
[15:06] <Wes-_> mschwartz: it's at your house, hurry up and finish the paperwork, please
[15:09] <mschwartz> JSconf is all about client side
[15:09] <mschwartz> I look at the speakers and only Dahl is a server side guy
[15:09] <mschwartz> people are still viewing JS as a browser language mostly
[15:15] <Wes-_> JSConf is NOT all about client side - the last three have had server-side sessions
[15:15] <Wes-_> I expect that to grow as the community grows
[15:16] <mschwartz> so who's a corporation doing a huge server side JS project?
[15:16] <Wes-_> That said, if you want to organize a server-side conf, if it's in Toronto I'll try and kick in
[15:16] <Wes-_> mozilla is a corporation, I thinik
[15:16] <Wes-_> I know I am
[15:16] <mschwartz> I said HUGE corporation
[15:17] <mschwartz> like one that does $100M in revenue or more
[15:17] <Wes-_> I think Mozilla does $100M in revenue or more
[15:17] <mschwartz> And what do they do server-side?
[15:18] <Wes-_> JetPack is CommonJS and non-browser-content
[15:18] <Wes-_> They're also actively looking at node-on-spidermonkey
[15:18] <Wes-_> And BeSpin runs on Node
[15:18] <mschwartz> jetpack?
[15:18] <mschwartz> looks like client side
[15:19] <Wes-_> Well, maybe you should read a little deeper
[15:19] <mschwartz> or to build Firefox addons
[15:19] <mschwartz> At this early development stage, the SDK includes tools for running, testing, and packaging add-ons along with a variety of APIs for extending Firefox, including an initial set of "high-level" APIs that make add-on development simple and powerful. Look for additional high-level APIs and tools to make add-on development even better in future releases!
[15:20] <Wes-_> hint: firefox extensions are not the same thing as browser content
[15:21] <mschwartz> geez
[15:21] <mschwartz> It's not like helma.org
[15:21] <mschwartz> "powered by helma"
[15:21] <mschwartz> that's what I'm looking for
[15:21] <Wes-_> so go download helma then
[15:21] <Wes-_> actually, you might be more interested in RingoJS
[15:22] <mschwartz> http://www.ruby-lang.org/en/
[15:22] <mschwartz> This website is made with Ruby and powered by Radiant CMS.
[15:22] <Wes-_> Look, if you don't like the state of CommonJS, either fix it, or stop bitching
[15:23] <mschwartz> you missed the point
[15:23] <Wes-_> Frankly, I'm getting rather annoyed with your continued transmission of bad energy
[15:23] <mschwartz> I am saying the lack of a big corporate sponsor is hurting
[15:23] <Wes-_> so fix it!
[15:23] <mschwartz> you and me and our pittance of money won't change much
[15:23] <mschwartz> and that Sencha IS a big company
[15:23] <mschwartz> that's getting into it
[15:23] <Wes-_> So they wrote some middleware that runs on node
[15:24] <Wes-_> I personally don't care
[15:24] <mschwartz> they wrote server-side JS is the big deal
[15:24] <mschwartz> it's a well funded javascript company
[15:24] <mschwartz> it's huge news
[15:24] <mschwartz> I think positive
[15:24] <Wes-_> Okay, well, you need to learn how to express yourself better then
[15:25] <Wes-_> constant complaints are one of the best ways to cause people to tune you out
[15:25] <Wes-_> okay, gtg, bbbiab
[15:25] <mschwartz> whatever
[16:05] <mschwartz> anyhow
[16:05] <mschwartz> I really see Sencha putting those projects out in the public domain is a hugely positive step
[16:06] <mschwartz> Sencha, being a JavaScript company that is well funded gives SSJS, and particularly CommonJS more credability
[16:06] <mschwartz> on top of that, Sencha does a lot of consulting projects for big companies, and the implication is that they're implementing some SSJS stuff for their clients
[19:32] <Wes> deanlandolt: around?
[19:32] <Wes> kriszyp: ping
[19:35] <kriszyp> hi
[19:36] <Wes> kriszyp: I implemented your script-tag dom injection algorithm, works great (haven't tested in IE yet)
[19:36] <Wes> kriszyp: FWIW - I found that it is possible to do 404-recovery with script.onerror, at least in firefox
[19:37] <Wes> This allows a 100% passing grade for the modules/1.0 test suite
[19:37] <kriszyp> nice
[19:37] <kriszyp> yeah, I think jrburke still hasn't conquered that one yet
[19:37] <Wes> Thanks for sharing the algorithm, there are details there that would have taken me eons to figure out (I dont' normally do front-end work)
[19:37] <kriszyp> heh
[19:38] <Wes> kriszyp: *nod* - if I get this working on IE I'll be sure to let him know the details. I just tested Safari, it works there too
[19:38] <Wes> The key is that the loader does not invoke the module factory until the first issuance of rrequire
[19:39] <kriszyp> great, that would be really nice to have proper error handling, I know that there have been complaints about that on the requirejs ml, and jrburke wanted to solve that problem
[19:39] <kriszyp> yeah
[19:39] <Wes> So during dependency resolution, we can effectively memoize 404 via the onerror handler, and then make require() throw at the right time
[19:39] <kriszyp> that makes sense
[19:39] <Wes> Also, window.onerror throws in addition to script.onerror (at least in firefox)
[19:40] <Wes> This means that my console gets notified about the 404 and the script just keeps on trucking
[19:41] <kriszyp> proper circular reference handling also depends on deferring module factory execution until a require call too, doesn't it?
[19:44] <Wes> kriszyp: I believe it does. 99.9% sure you can't get it right without doing that.
[19:45] <Wes> The reason for that, FWIW, is that modules aren't "true" modules in the "2nd class" sense in CommonJS -- loading the module has observable side-effects
[19:45] <Wes> This is one major difference from Simple Modules
[19:46] <Wes> kriszyp: Your proposal today, this basically a CommonJS version of what you were musing about on es-discuss?
[19:47] <kriszyp> I think I had mentioned plugins, but this is more based on discussions from requirejs. requirejs has a really complicated plugin system now, so this was my proposal for a simple plugin system (and just wanted to get it in front of commonjs too)
[19:47] <kriszyp> I think it could be used in a ES6 (custom) module loader as well, but wouldn't need to a part of ES6.
[19:53] <Wes> kriszyp: FWIW -- I too am playing with plug-in systems. My work currently is on developing a regular environment where details of the module loader can be overriden by user code. The idea being that multiple commonjs host environments could be targetted by 3rd party loaders.. So you could develop transports, package systems, mappings, etc on a cross-platform basis
[19:54] <kriszyp> nice
[19:54] <Wes> The idea of being able to load in non-JS resources is intriguing, but I haven't figured out exactly where that fits in my mental model of "the stack"
[19:54] <Wes> But I've been thinking about it since you mentioned it ~10 days ago :)
[20:17] <hannesw> Wes: that memoizing script load errors until require() thing sounds great
[20:18] <hannesw> I think one of the benefits of require() is (or should be) that your code breaks when you actually try to use a missing module
[20:18] <Wes> I agree
[20:19] <hannesw> do you have a link for kriszyp's script injection algorithm?
[20:19] <hannesw> Would be interesting (also not a frontend guy :)
[20:34] <Wes> hannesw: http://pastebin.mozilla.org/855803
[20:35] <hannesw> thanks Wes!
[20:35] <Wes> hannesw: details -- this for loading with a module.declare()-style wrapper into a SCRIPT tag which was inserted into the DOM
[20:36] <Wes> works really well, I can run the entire /1.0 test suite without caching effects in ~300ms
[20:36] <Wes> and that includes two purposeful 404s
[20:36] <hannesw> very cool!
[20:37] <Wes> I have to say, a module format that includes a wrapper sure makes a bunch of things fall in together nicely on the browser side of things
[20:38] <Wes> One big one is that we can write the "main module" directly in a script tag embedded in the HTML document
[20:38] <Wes> this then means that the HTML can use exports from the main module as event handlers and so on

 

 

Logs by date :