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

2010-10-20:

[16:00] <Wes> The CommonJS module tests use require("system").stdio.print or a free-variable print function
[16:00] <Wes> neither is specified anywhere AFAICT
[16:00] <Wes> Should they be?
[16:09] <deanlandolt> we ought to have a standard means to get at stdio but it's an awkward problem when you don't know what a stream is
[16:10] <deanlandolt> perhaps easier is to spec a console module...someone already did but it's crazy complex
[16:14] <ashb> stdoi.print was kind of implied
[16:14] <ashb> o<->i
[16:18] <deanlandolt> ashb: node has no stdin.print... it does offer up process.stdout.write which is kinda close
[16:19] <ashb> k
[17:06] <Wes> ash: stdio.print doesn't ring nicely with me... does that print to stderr or stdout?
[17:20] <deanlandolt> yeah, kinda confusing
[17:21] <deanlandolt> and does it write a newline
[17:21] <deanlandolt> (that's a huge painpoint w/ print)
[18:09] <Wes> deanlandolt: Oddly, I just bumped into that pain point
[18:10] <Wes> You can't output "loading test....loaded"
[18:17] <ashb> Wes: oh stdio? o_O
[18:21] <deanlandolt> there clearly needs to be /something/ to do that
[18:24] <Wes> I still vote for write() and writeln(), as stolen from pascal
[18:25] <Wes> deanlandolt: brain storm. What HTML4 or HTML5 tags can load free-form data?
[18:25] <Wes> we lost DIV.src with netscape 5
[18:25] <Wes> we have IFRAME but it's a pain to deal with
[18:26] <Wes> although, if we "talk" to an IFRAME window object, we could use it as a module loader
[18:26] <deanlandolt> what do you mean by load free-form data?
[18:26] <deanlandolt> like, load scripts?
[18:27] <Wes> deanlandolt: Yeah. SCRIPT and STYLE tags demand formatted data
[18:27] <deanlandolt> w/o cross-origin policy?
[18:27] <Wes> w/o cross-origin would be nice, but I believe it's a total red-herring
[18:27] <Wes> (anybody running a central server full of modules will minify anyhow)
[18:28] <Wes> I realized a few minutes ago we can bury modules in HTML, for example, as one way to deliver, right inline with the page
[18:28] <Wes> Just use a MODULE tag instead of a SCRIPT tag
[18:28] <deanlandolt> data urls were always possible but you have to base64
[18:28] <Wes> and have your CSS display:none them
[18:28] <deanlandolt> hmm
[18:28] <deanlandolt> or just inline the display:none
[18:29] <Wes> yeah
[18:29] <deanlandolt> there's the new data- attr
[18:29] <Wes> then body.onload = document.getElementsByTagName["MODULE"] and you're away to the races
[18:29] <Wes> data-attr?
[18:29] <deanlandolt> http://ejohn.org/blog/html-5-data-attributes/
[18:30] <Wes> hey, I was about to post that link!
[18:30] <deanlandolt> it'd be a PITA to escape all your quotes though
[18:30] <deanlandolt> so no hand-authoring :)
[18:30] <Wes> "bizarre", I think that means "ripe for abuse"
[18:30] <Wes> argh
[18:30] <deanlandolt> well aren't you talking about abusing it now :)
[18:31] <Wes> that's right!
[18:31] <Wes> I don't understand the quote limitation
[18:31] <deanlandolt> what about it?
[18:32] <Wes> OIC now
[18:32] <Wes> crap, that's not what I'm looking for
[18:32] <Wes> *hmm*
[18:32] <deanlandolt> what's wrong w/ it? you can inline any scripts you want IIUC
[18:33] <deanlandolt> they'll just be ugly is sin
[18:33] <Wes> But it doesn't load a file, it's just inline
[18:33] <deanlandolt> okay
[18:33] <deanlandolt> yeah, that's right, you mentioned DIV.src
[18:33] <Wes> I wish they hadn't taken that away from us!
[18:34] <Wes> I also don't understand the need to load unadultered modules from SCRIPT tags
[18:34] <Wes> I wonder if somebody could write a flash loader?
[18:34] <Wes> Is it because SCRIPT has no cross-origin limitations?
[18:35] <Wes> or ...
[18:35] <deanlandolt> that's part of it i think
[18:35] <Wes> load modules as though they are canvas data
[18:35] <deanlandolt> hmm, a flash loader? interesting
[18:35] <deanlandolt> yeah, that's doable
[18:35] <deanlandolt> i just saw a demo of something like that recently
[18:36] <Wes> WTF? HTML5 has an element named ruby
[18:36] <deanlandolt> heh
[18:36] <deanlandolt> yeah
[18:36] <deanlandolt> but it's lang based
[18:37] <deanlandolt> not prog lang, human lang
[18:37] <Wes> Ah, I see now
[18:37] <deanlandolt> i'm not a linguist but i guess it means something in that world
[18:37] <Wes> Do web-sockets have same-origin limitations?
[18:37] <deanlandolt> also spelled rubi...they probably should have used the *other* spelling :)
[18:38] <ashb> flash is evil
[18:38] <deanlandolt> IIRC they do, yes
[18:38] <ashb> i and many other people use ClickToFLash or similar
[18:38] <deanlandolt> ashb: yeah, good point
[18:38] <deanlandolt> still an interesting idea
[18:38] <ashb> iframe might be doable
[18:39] <Wes> ashb: Can you talk to cross-domain iframes? (I didn't think you could)
[18:39] <deanlandolt> Wes w/ server support :)
[18:40] <deanlandolt> google the window.name protocol
[18:40] <deanlandolt> (i remember using that back in the day before i knew of this kriszyp fellow)
[18:40] <Wes> BTW, have you been tracking the list today?
[18:41] <deanlandolt> yeah
[18:41] <Wes> I'm kind of upset at the summary I read - that RequireJS isn't CommonJS, yet implies that it has the blessing of the community
[18:42] <deanlandolt> that's been pointed out
[18:42] <Wes> I think we should start using the CommonJS Logo to indicate that the implementation passes all the module tests
[18:42] <Wes> or something like that
[18:42] <deanlandolt> does any implementation pass all tests?
[18:43] <deanlandolt> (i have absolutely no idea)
[18:43] <Wes> http://www.sitepen.com/blog/2008/07/22/windowname-transport/
[18:43] <Wes> thanks for that
[18:43] <Wes> deanlandolt: narwhal and GPSEE do. I think flusspferd might. I think v8cgi does.
[18:43] <deanlandolt> nice
[18:44] <deanlandolt> node very likely doesn't
[18:44] <Wes> Yeah, I think his require() implementation is somewhat superficial
[18:44] <deanlandolt> and node is perhaps the most popular CJS-MR implementation
[18:44] <deanlandolt> the only thing i really care about is we don't overload the semantics of require as it exists today
[18:44] <Wes> OTOH it's entirely possible that he does and I just missed the memo :)
[18:45] <deanlandolt> it's locked in in a thousand places...it works...screw it
[18:45] <Wes> deanlandolt: Me too - which is one reason why wrapping everything in functions is annoying
[18:45] <Wes> it's another implementation requirement
[18:45] <deanlandolt> but i guess i don't really see the problem with define providing a require implementation
[18:45] <deanlandolt> it's like rolling your own rquire
[18:45] <Wes> Except that you preclude any implementations which doesn't use a function() { ... } boilerplate
[18:46] <deanlandolt> yeah, it's ugly
[18:46] <deanlandolt> not really, do you?
[18:46] <deanlandolt> could you provide a define fn
[18:46] <deanlandolt> i guess i don't quite understand that issue
[18:47] <Wes> deanlandolt: You have to wrap the module in a function if you're going to pass it around
[18:48] <deanlandolt> what if it's already wrapped in a fn? i've never implemented require so a lot of this is over my head :-/
[18:48] <deanlandolt> i should probably dig into it a little deeper...i've just been satisfied to be handed a working require and go from there
[18:50] <Wes> Well, that's the problem. "what if it's already wrapped in a fn" -- most implementations are, some are not.
[18:51] <Wes> When you add "more stuff" you restrict the possible implementations space
[18:57] <Wes> argh
[18:57] <Wes> now Kris Kowal is advocating the module format
[18:57] <deanlandolt> heh
[18:57] <Wes> I have a half a mind to just throw in the towel
[18:58] <Wes> I personally like being able to write modules in C
[18:58] <deanlandolt> and this would preclude that?
[18:58] <Wes> Well, they have to be javascript functions...
[18:58] <deanlandolt> node has modules in c
[18:59] <deanlandolt> the .node extension
[18:59] <Wes> Do they return a function or an exports object?
[18:59] <deanlandolt> i haven't ever used it...but i can dig up some docs for ya
[18:59] <Wes> if they are used as require(X) then they return an object
[19:00] <deanlandolt> most likely they return an object...though node has the setExports option
[19:00] <deanlandolt> why can't the fn return an object?
[19:00] <Wes> because you have to call it
[19:00] <Wes> function(exports, require)
[19:00] <deanlandolt> yeah, but can't you test that? (i don't know enough about sm internals)
[19:00] <Wes> is the proposed format for a module
[19:01] <deanlandolt> yeah, but can't you call that?
[19:01] <Wes> I can't call an object
[19:01] <Wes> I can re-write all my modules of course
[19:01] <Wes> but, honestly? I'll quit before I do that
[19:01] <Wes> There's nothing preventing me from shutting down the googlecode project, saying "fuck foss" and using our product as-is
[19:02] <Wes> In fact, it would save me about 20 hours a week of trying to better the community
[19:03] <Wes> Grr
[19:03] <Wes> You can re-invent the module spec to keep the people who are unwilling to run a pre-processor happy
[19:03] <Wes> But you can't be bothered to keep existing implementations running
[19:03] <deanlandolt> heh...i don't think anyone's suggesting that
[19:03] <Wes> That's *edactly* what they are talking about
[19:03] <deanlandolt> whatever happens require shouldn't ever change
[19:03] <deanlandolt> they're talking about adding define
[19:03] <deanlandolt> (IIUC)
[19:04] <Wes> define *mandates* a particular implemention of a module system
[19:04] <deanlandolt> that's a good argument against it
[19:04] <Wes> That was never *mandated* before, it was one possible implementation
[19:04] <Wes> Nobody CARES because it's the only possible one on the browser
[19:06] <Wes> I should just have to suck it up, re-write GPSEE's module and system and modules so that users who refuse to use XHR, active server pages, or a build step can be hapy
[19:06] <Wes> It's bloody ludicrous is what it is
[19:06] <Wes> backward-incompatible changes to satisfy whiners
[19:07] <deanlandolt> i agree that backward-incompatible changes this late are insane...there's gotta be a third way
[19:12] <Wes> deanlandolt: honestly? There is no way to embed modules in a script tag without them being functions
[19:13] <Wes> So that's what this entire discussion hinges on:
[19:13] <deanlandolt> are you sure there's zero possible ways?
[19:14] <Wes> Cost:Benefit ratio, where the cost is low for most and high for others, and the benefit is that the module-AUTHORING format can be used directly in a script tag
[19:14] <deanlandolt> i've done it :)
[19:14] <Wes> deanlandolt: Yes. The problem is the var scope
[19:14] <Wes> how?
[19:14] <deanlandolt> i've defined an exports global
[19:15] <Wes> But "var a" in two different modules will refer to the same a
[19:15] <deanlandolt> yeah, i didn't say it was pretty :)
[19:15] <Wes> well, it's also not correct
[19:15] <Wes> (unfortunately)
[19:15] <deanlandolt> yeah, it's garbage
[19:15] <Wes> That's why I was thinking about IFRAME, you get a fresh var object
[19:16] <deanlandolt> still requires preprocessing...but now i see where you're going w/ thsi
[19:16] <Wes> At least with IFRAME you could do SCRIPT tag injection
[19:16] <deanlandolt> i wonder how the natives sandboxing works
[19:16] <deanlandolt> they manage to get globals out of iframes
[19:16] <Wes> I was also thinking about DOM workers
[19:16] <Wes> HOWOooo
[19:16] <Wes> DOM workers might be really interesting
[19:17] <Wes> do know much about them?
[19:17] <Wes> I know they get a fresh var object and can exchange strings
[19:17] <deanlandolt> about dom workers? no...but i know that won't work on older browsers
[19:17] <Wes> Oh, yeah, that's true too
[19:17] <deanlandolt> or native sandoxers? those, i know a bit
[19:17] <Wes> browsers have sandboxes now?
[19:17] <deanlandolt> well, just what i learned talking to folks at jsconf...but i was usually pretty intoxicated for those discussions
[19:18] <Wes> LOL
[19:18] <deanlandolt> yeah, well, no, but you can get fresh global classes (Array, String) out of iframes
[19:18] <deanlandolt> let me look it up
[19:19] <Wes> If you ever get up to the Toronto area, I'll have to make sure I get you good and intoxicated ;)
[19:19] <deanlandolt> canadian moonshine
[19:19] <Wes> Actually, you guys make really good moonshine
[19:20] <Wes> "Maker's Mark"
[19:20] <deanlandolt> i've got a buddy from ontario (north of toronto by 2 or 3 hours...algonquin park area)
[19:20] <Wes> Sounds like the Barrie/Orillia area. Beautiful up there.
[19:20] <deanlandolt> we used to go up there a bit to stay at his father's cavin in algonquin park...we were talking about getting up there again some time soon
[19:21] <Wes> Lemme know if you do, that's only 4 hours from here
[19:21] <Wes> 2 if you have some of that stuff they paint the fighter jets with
[19:22] <deanlandolt> it's south of the park by about an hour...i want to say huntsville or something like that
[19:22] <deanlandolt> can't remember
[19:22] <deanlandolt> yeah, huntsville...that looks right
[19:23] <Wes> Huntsville, yeah, I've heard it's nice up there
[19:23] <deanlandolt> yeah...not much to do... a few tiny bars and a tim hortons
[19:23] <deanlandolt> but absolutely beautiful
[19:25] <Wes> Only one tim's I find that hard to believe ;)
[19:25] <deanlandolt> heh
[19:25] <deanlandolt> yeah, i think you're right
[19:31] <WesMac> Grr, I need to stop developing in the same browser I IRC :D
[19:31] <deanlandolt> heh
[19:31] <deanlandolt> so wrt modules being objects or functions...i still don't see why module scope have to be fns...
[19:31] <deanlandolt> if you provide the define (like you provide require) wouldn't be all the same? the module isn't written /as/ a function but as a fn call
[19:31] <deanlandolt> just don't let define return a fn and you're rine
[19:31] <deanlandolt> fine
[19:31] <WesMac> functions are the only javascript construct that limit lexical scope, IF you're implementing a module system in pure javascript
[19:31] <WesMac> If you want to also use HTML/DOM, for example, you could potentially use IFRAME for the same purpose
[19:31] <WesMac> or window.open
[19:31] <WesMac> The problem, for me, is that native modules simple aren't functions
[19:31] <WesMac> There's nothing to return, they just .. aren't
[19:31] <WesMac> They produce exports objects
[19:31] <deanlandolt> fair enough
[19:31] <deanlandolt> they aren't in other langs i've used for sure
[20:03] <Dantman> *sigh* I'm tired of json-template... I can definitely consider it lacking... I'm to the point I actually modified the source code and changed how it works to reduce how much it gets in my way...
[20:03] * Dantman wishes he had a working EJS project
[20:48] <WesMac> Dantman: How about enterprise java beans?
[20:48] <WesMac> Okay - whoever said module.dependencies requires code-scraping was absolutely correct
[20:48] <WesMac> That's infuriatingly frustrating
[20:48] <WesMac> I want callee-specified dependencies
[20:50] <WesMac> I see caller-specified dependencies as, blah. It's (almost) just sugar for load-multiple-modules-at-once
[20:50] <Dantman> WesMac, I'm hoping to avoid direct Java dependencies besides things like IO, hash algorithms, etc...
[20:50] <WesMac> Well, yes, but EJB is almost there. 2 out of 3 (characters) ain't bad!
[20:51] <jbrantly> WesMac: that would be me ;)
[20:51] <Dantman> I'm still entertaining the idea of abstracting things more till I end up with a real java host (yet another monkeyscript) and potentially hiring someone to port it to SpiderMonkey
[20:52] <WesMac> jbrantly: Ah! Well, the transitive test is sort of the right area of fail, but actually, you can't run any modules which use their dependencies freely (i.e. not inside a function)... because require() throws before I can get at module.dependencies
[20:52] <WesMac> jbrantly: I don't suppose you have any ideas that don't involve scraping for callee-depends?
[20:53] <WesMac> Dantman: Just write it! You can do it!
[20:53] <WesMac> Dantman: Your I/O buffers and crap, that could all be typed arrays and stuff
[20:54] <Dantman> Meh... something like that seems like the perfect thing for another programmer... frankly things are too dependent on me doing them here
[20:54] <WesMac> Dantman: admins are cheaper than programmers ;)
[20:54] <jbrantly> WesMac: no, but kris's suggestion might make the scraping easier
[20:55] <Dantman> I only have two or three areas of code I think we could actually hire someone to do... everything else would take the large task of actually teaching another programmer how Kommonwealth works
[20:57] <WesMac> jbrantly: I was actually thinking about rigorous scraping -- if we *do* use module.dependencies in a way that intends to be scraped, we can verify that the scraping is correct after module load
[20:57] <WesMac> So, basically, Kris kowal's suggestion but with module.dependencies= in front of it
[20:57] <WesMac> Then if module.depencies is different from what we scraped, we can notify the programmer that something went wrong
[20:57] <WesMac> oh
[20:58] <WesMac> which could happen during minification, if the tool were not commonjs aware
[20:58] <jbrantly> WesMac: sounds ok to me
[21:08] <WesMac> mschwartz: mozilla bug 604782 may very well fix your bug
[22:03] <jbrantly> kris zyp usually idles in here, right?
[22:19] <Wes-> jbrantly: s/usually/sometimes/
[23:16] <jbrantly> Wes-: you seem to be one of the bigger opponents of the whole AMD thing. Mind talking some of it through with me? I'm trying to figure out how to make it palatable from a pure CJS-MF perspective
[23:17] <Wes-> jbrantly: I am opposed to change which does not solve problems
[23:17] <Wes-> Well, *real* problems
[23:17] <Wes-> I am much more interested in identifying and solving actual problems -- like dependency expression -- than artificial problems like "I don't like it like that"
[23:18] <Wes-> Which, honestly, is what this looks like from here.
[23:18] <Wes-> For the longest time, the AMD group used mis-direction to try and foist their features
[23:18] <Wes-> mis-direction: "require is unsuitable for the browser"
[23:19] <jbrantly> yea, but we're beyond that now
[23:19] <Wes-> Now that that has been shown to be patently false, they change the issue to "but it doesn't work with SCRIPT tags unless you have a build step or active server content"
[23:19] <deanlandolt> Wes- re: your last email, to be fair the group /was/ called ServerJS back then, so it's little surprise nobody jumped in complaining about browsers
[23:19] <Wes-> Honestly - what kind of web development request that?
[23:19] <jbrantly> lol
[23:20] <Wes-> deanlandolt: It was, but even then, we were thinking of the browser. That's the whole reason for ServerJS - code reuse between the two ends of the stack
[23:20] <jbrantly> I subjectively agree. I think having a choice is fine (xhr, build, or server component)
[23:20] <deanlandolt> certainly, and i remember it being discussed (ad naseum)...just sayin', it didn't include a ton of browser folk
[23:20] <jbrantly> but clearly a lot of people do not agree
[23:20] <Wes-> jbrantly: And two more I think can work - IFRAME/SCRIPT and CANVAS. But I haven't had a chance to implement those yet
[23:21] <Wes-> jbrantly: vocal minority
[23:21] <jbrantly> Wes-: I'm not so certain its a minority
[23:21] <jbrantly> Wes-: requirejs has gained quite a bit of traction
[23:21] <Wes-> Note that even the vocallest person in there says, "Well *I* don't have such constraints"
[23:21] <Wes-> So who does?
[23:21] <Wes-> Who can't use make, can't use PHP, can't use Perl, can't use server-side JS, and can't use XHR?
[23:22] <jbrantly> Wes-: it's a minority from the big picture, yes. But from the web perspective, the majority of people using any form of CJS is using requirejs
[23:22] <jbrantly> s/web/browser
[23:22] <Wes-> jbrantly: So has IE6
[23:22] <Wes-> I'm not going to advocate change just because something else is popular
[23:22] <Wes-> Otherwise, we become the wishy-washy group that follows whatever trend is blowing today
[23:23] <Wes-> I am most concerned with a long-term stable platform, process, community, etc
[23:23] <jbrantly> same
[23:23] <Wes-> Okay guys! From now on, write modules like this, or they won't run everywhere!
[23:23] <Wes-> What kind of BS is that?
[23:23] <Wes-> It had better be for a REAL, TECHNICAL reason
[23:23] <Wes-> not political
[23:24] <jbrantly> I think, frankly, that if we don't move, then the community is going to fragment
[23:24] <jbrantly> it may be political, but I think its reality
[23:24] <deanlandolt> Wes- http://dean.edwards.name/weblog/2006/11/hooray/
[23:24] <deanlandolt> (from 2006 even :))
[23:24] <Wes-> jbantly: I think that if we DO move the community will fragment
[23:25] <Wes-> For example, I doubt CouchDB will implement define()
[23:25] <Wes-> I'm doubtful that JetPack will
[23:25] <Wes-> etc
[23:25] <Wes-> The thing is, the people complaining are probably the ones who want the features
[23:25] <deanlandolt> Wes- i hear you about making backward-incompatible changes, but i /still/ dont see how this is a backward-incompatible change? if you want to support the new format /too/ you have options (as cdorn pointed out you can preprocess...but still, eww)
[23:26] <Wes-> deanlandolt: No! It's an incompatible change that does not run on currently implements
[23:26] <Wes-> implementations
[23:26] <Wes-> sorry, right hand median never giving out
[23:26] <deanlandolt> yeah, but it's not a commonjs module format anymore
[23:26] <Wes-> nerve, shit
[23:26] <Wes-> It's worse than that
[23:27] <deanlandolt> mikeal: you around?
[23:27] <Wes-> It makes the two probglems it TRIES to solve unsolvable because of the :"h, uou want that, use RequireJS instead of CommonJS"
[23:27] <deanlandolt> mikeal: you did the couchdb securable modules implementation right?
[23:27] <Wes-> We should really be solving dependency resolution from a caller perspective
[23:27] <Wes-> And we should standardize on a method to asynchronously provide memos to require
[23:27] <mikeal> deanlandolt: yup
[23:28] <Wes-> We don't need to standardize on an alternate authoring format
[23:28] <deanlandolt> what are your feelings on this whole define discussion?
[23:28] <jbrantly> Wes-: not necessarily. There's nothing stopping people from implementing define()
[23:28] <jbrantly> Wes-: I'm in the process of adding it to node right now. It's not hard at all.
[23:28] <mikeal> i haven't looked yet
[23:28] <Wes-> jbrantly: But there's the kicker. Now you have fragmentation until ALL the implementations are updated.
[23:28] <mikeal> what's the gist of it?
[23:28] <mikeal> it's not pre-defined require metadata is it?
[23:29] <deanlandolt> mikeal: the gist is there's a lot of noise (a /lot/ of noise...damn)...
[23:29] <Wes-> mikeal: People want an alternate way to write modules brought into the standard so that they can be included from SCRIPT tags without a build step
[23:29] <jbrantly> ^ good gist
[23:29] <deanlandolt> it's require.def...or securable modules
[23:29] <mikeal> who plans on implementing that in a browser?
[23:30] <jbrantly> think Transport/C but as a standard API implemented everywhere (including server)
[23:30] <jbrantly> mikeal: its got more browser implementations than server
[23:30] <mikeal> you mean you want it to work in a script tag with no browser modifications?
[23:30] <deanlandolt> mikeal: did you look at kriszyp's node patch? would that be feasible in couch? is it even worth it?
[23:31] <deanlandolt> Wes- if the iframe solution were to work i think you'd be able to make a compelling case that it's unnecessary
[23:31] <deanlandolt> (the canvas solution's a non-starter most likely)
[23:31] <mikeal> what does kris' patch do?
[23:31] <Wes-> deanlandolt: Dammit, I wish my arm was in better shape this week
[23:31] <deanlandolt> heh
[23:31] <Wes-> deanlandolt: Technical non-starter, or political? (I haven't investigated much)
[23:32] <mikeal> in CouchDB we don't do *any* IO on require()
[23:32] <deanlandolt> technical if you consider ie support non-political ;)
[23:32] <mikeal> so most of this stuff is totally unnecessary for us
[23:32] <deanlandolt> mikeal: http://github.com/ry/node/pull/350
[23:32] <Wes-> deanlandolt: Hmm. IE9 too? :)
[23:32] <mikeal> i don't want async modules in node
[23:33] <Wes-> mikeal: Not totally, if the module format changes, you will have to either a) edit modules before use, or b) not use modules written in the idiom or c) support the new standard
[23:33] <deanlandolt> by the time ie<9 falls to low enough usage levels we'll have harmony modules
[23:33] <Wes-> deanlandolt: point
[23:33] <mikeal> i'm not a big fan of harmony modules
[23:33] <mikeal> they do what they were intended to do
[23:33] <mikeal> but it's a different set of priorities
[23:34] <Wes-> mikeal: I have a sneaky feeling that harmony modules will make a fast bootstrap for CommonJS on the client
[23:34] <deanlandolt> i haven't looked too closely at them yet...my only priority is loading freakin code
[23:34] <deanlandolt> but we won't actually be able to use them for 10 years, so commonjs modules /are/ here to stay :)
[23:34] <mikeal> to be perfectly honest
[23:34] <mikeal> i don't think we'll be able to use harmony reliably for like 10 years
[23:35] <deanlandolt> heh...then we agree
[23:35] <Wes-> deanlandolt: I totally see them as a viable alternate way to load CommonJS modules. Assuming they are faster than XHR, the right server-side transformations could make them a win.
[23:35] <Wes-> The only gotcha with harmony modules is the different scope on chain
[23:35] <Wes-> only the standard classes will be aboev the module
[23:36] <mikeal> it's more of a namespace proposal than a modules proposal
[23:36] <Wes-> /scope on chain/scope chain/
[23:36] <Wes-> mikeal: except that it can load files
[23:36] <mikeal> which isn't necessarily a bad thing if you want namespaces, but it doesn't really help you organize your code any more than you can do now in the browser
[23:36] <jbrantly_> deanlandolt: good thing you mentioned kzyp's patch. I didn't see that earlier and was about to do the same myself
[23:37] <mikeal> yeah, but the way it loads the files makes loading large numbers of dependent files so slow as to not be viably used
[23:37] <Wes-> mikeal: That's true -- which is also why I don't understand the current proposal
[23:37] <Wes-> Who the hell loads one file at a time?!
[23:38] <jbrantly_> for development
[23:38] <Wes-> minimize the JS, smash the modules together into an array, populate require() with that array
[23:38] <mikeal> i'm pretty cynical
[23:38] <jbrantly_> loading one file at a time is generally "ok" for dev
[23:38] <Wes-> jbrantly_: so is XHR
[23:38] <jbrantly_> Wes-: debugging, blah blah
[23:38] <mikeal> and i'm not all that mad about the modules proposal because I don't think harmony will actually be usable
[23:39] <Wes-> mikeal: Now that may be true
[23:39] <mikeal> i don't think v8 will implement any feature that is backwards incompatible
[23:39] <mikeal> they won't even implement strict mode
[23:39] <Wes-> seriously?
[23:39] <deanlandolt> mikeal: really? like, ever?
[23:39] <mikeal> sounds kind of like it
[23:39] <mikeal> do you read es-discuss?
[23:39] <deanlandolt> yeah, religiously
[23:39] <mikeal> the v8 team is like "no more modes, these suck"
[23:40] <Wes-> I do, but not with great vigour
[23:40] <mikeal> and Brendan lost his shit
[23:40] <Wes-> Yeah, I saw that
[23:40] <deanlandolt> yeah...i just kinda figured that was backlash at having attempted to /implement/ it
[23:40] <mikeal> because he knew they were really talking about a mode for Harmony so that it can break compatibilty
[23:40] <mikeal> yeah, it's the only part of ES5 they haven't done yet
[23:41] <deanlandolt> i'll be pissed if they never implement proxies...that's the only es-next feature i can't imagine going w/o forever
[23:41] <Wes-> does rhino have proxies yet?
[23:41] <mikeal> there is a feature in proxies that will break way to much shit
[23:41] <deanlandolt> you may not /need/ strict mode for proxies though
[23:41] <mikeal> the whole getter/setter sends a callback thing
[23:41] <deanlandolt> hmm...crap
[23:41] <mikeal> not gonna happen
[23:41] <mikeal> i mean, it totally breaks node
[23:42] <mikeal> if it ever gets implemented
[23:42] <deanlandolt> Wes- rhino has __noSuchMethod__ (like sm)
[23:42] <mikeal> that's a small part of proxies
[23:42] <deanlandolt> still, you just ruined my night :-/
[23:42] <mikeal> the people who wrote the original spec want to do remote objects
[23:42] <mikeal> which means property access does IO
[23:42] <mikeal> which is INSANITY
[23:42] <deanlandolt> heh...yeah, that is crazy...
[23:42] <mikeal> so it's not going to happen
[23:43] <Wes-> Yeah, that's a *very* small part of proxies
[23:43] <Wes-> But a really important part!
[23:43] <mikeal> yup, small but is massive breakage
[23:43] <mikeal> it essentially lets you implement stuff like blocking XHR in pure javascript
[23:43] <mikeal> and we all know how great that works
[23:43] <mikeal> :)
[23:44] <Wes-> Does that hose the browser or just the tab on chrome?
[23:44] <Wes-> Must be just the tab?
[23:44] <mikeal> tab
[23:44] <mikeal> on iPhone it locks every context
[23:44] <deanlandolt> process-per-tab
[23:44] <mikeal> :)
[23:44] <mikeal> it's aweful, and we shouldn't encourage it
[23:44] <deanlandolt> hmm...i should pay more attn...i don't remember reading that bit
[23:45] <mikeal> also, allowing IO to block the execution of the context means you either lock the context or you allow people to modify it which gives you all the problems you get with thread safety
[23:46] <mikeal> but someone wanted these Java like remote object thing
[23:46] <mikeal> so they decided to fuck up javascript
[23:46] <mikeal> again, i'd be pissed if i ever thought it was going to happen
[23:46] <mikeal> i mean, it'll happen in SM
[23:46] <mikeal> because SM is the kitchen sink of js implementations
[23:46] <deanlandolt> :)
[23:46] <Wes-> Yeah
[23:46] <Wes-> That's a bonus and a problem
[23:47] <mikeal> i *hate* the const implementation
[23:47] <mikeal> and the generators
[23:47] <Wes-> ECMA-357 extolls a constant price
[23:47] <Wes-> I like generators, when used properly
[23:47] <mikeal> array comprehensions are cool
[23:47] <Wes-> What's wrong with their const impl?
[23:47] <mikeal> generators make the code really unreadable
[23:47] <mikeal> and don't let you do anything you can't do with forEach
[23:47] <Wes-> It can, yes. I like them for stuff like
[23:47] <deanlandolt> amen to that
[23:48] <Wes-> function(stream) { yield stream.fgets() }
[23:48] <mikeal> in js you have optimized closures and cheap functions
[23:48] <mikeal> you don't nead Python style generators
[23:48] <Wes-> ^^^ I'm not sure how to easily do that without generators
[23:48] <mikeal> Python is crap for closures and function overhead is huge so they are important
[23:48] <Wes-> Heh
[23:48] <deanlandolt> Wes- gimme a few days and i'll show you not only how to do that...asyncronously...but how that composes so you can frame the outbound stream nicely
[23:49] <Wes-> I just realized you're going to say, "You shouldn't be using sync fgets()" :)
[23:49] <mikeal> haha
[23:49] <mikeal> :)
[23:49] <deanlandolt> Wes- ah but w/ forEach you can still use fgets
[23:50] <deanlandolt> each chunk gets yielded and handled just the same
[23:50] <mikeal> i want to break off all the non-breaking features in harmony
[23:50] <deanlandolt> it doesn't look as nice on one line though :)
[23:50] <Wes-> really? Is there a way to do forEach piece-meal without yield?
[23:50] <mikeal> and try to get them actually adopted
[23:50] <mikeal> like ephemeron tables
[23:50] <mikeal> and noSuchMethod, etc
[23:50] <Wes-> ephemeron tables++
[23:50] <deanlandolt> mikeal: don't you think that's exactly what will happen?
[23:50] <deanlandolt> i hate noSuchMethod per se...i mean, you could still do a partial proxy implementation that's stratefied, right?
[23:50] <mikeal> i don't know, i see the rift between harmony and everyone else growing
[23:51] <deanlandolt> stratified
[23:51] <deanlandolt> that big bang approach never lands...i woulda figured tc39 woulda learned that from es4 :)
[23:52] <mikeal> brendan wants to evolve the *language*
[23:52] <deanlandolt> people snipe about html5 not being /ready/ but it's awesome that it's not /one/ thing
[23:52] <mikeal> the problem is that the implementations are now severely optimized
[23:52] <mikeal> which makes adding breaking changes and supporting the optimzations hard
[23:53] <deanlandolt> yeah...still, as you say, there's a ton of non-breaking changes...not specifically lang-related
[23:53] <Wes-> especially in moz land, it's a good thing they have an army of geniuses
[23:53] <Wes-> kitchen sink, an interpreter and TWO JITs
[23:53] <mikeal> i just wish you could turn off all the crazy features
[23:54] <mikeal> i want to turn off all the breaking features
[23:54] <deanlandolt> i'd imagine not having a script type of "application/ecmascript" would turn them off
[23:56] <Wes-> actually, it's a little harder than that.. but at least SOME of them can be turned off, at least last I surfed TFS
[23:56] <Wes-> Like, I think you could make E4X go away
[23:57] <Wes-> generators would be harder, but I think you can ifdef out the piece that generates their byte code
[23:57] <Wes-> which means none of the three engines will see them, and the keywords will be syntax errors
[23:57] <Wes-> now, stuff that would be HARD to kill - deconstructing assignment
[23:58] <Wes-> Hmm... that's probably it
[23:58] <Wes-> Of course, all of these require a re-build

 

 

Logs by date :