More from Patrick Mueller's sudden blogginess...
"The level of functionality we have today, provided by the browsers, for components/modularity of javascript code is <script src="">. Basically, all the power, flexibility, and functionality of the C preprocessor's #include statement (good and bad). But I'm looking at my calendar to see what year this is again. Doh!http://pmuellr.blogspot.com/2008/11/javascript-service-frameworks.htmlThe big JavaScript frameworks build their component stories on top of this, and the whole thing just gives me the willies looking at it."
Patrick also mentions Java's service frame-querkiness with class loaders, jar files, etc. I don't know much about OSGi - which he and others suggest plugs some holes.
Dang. I agree these are issues. I am wondering though how simple a language can be, and fill the service frame-querkiness some other way. For one thing, language-level frame-querks don't play well together across multiple languages. Unless you cram them together into a single VM and make them all conform to some base-level language concepts.
Patrick heads in this direction when he writes about GoogleGears WorkerPools as a potential mechanism for better service isolation...
The great thing about the WorkerPool stuff is that it brings another dimension to the JavaScript story - separate environments / contexts / spaces. The ability to have a bunch of code running, separated into protected object spaces, with very explicit communication channels open between these spaces.There is little that's language-dependent about that. And this lowers the burden on what must be "in" the language per se.
1 comment:
Great term - frame-querks.
I'm not a huge fan of OSGi itself, but it's not terrible, it's good enough, and not sure if there's really any alternative in Java-land.
Good point on language neutrality, hadn't really thought of that. The messaging between workers in Gears is basically JSON-ifiable data. No pointers, no code, just simple data structures. Again, lends itself to literally any other language. Even if you're just dealing with what Gears provides, you could use a JS shim to talk to any other language via HTTP no problem; your non-JS language would be on the server-end of the HTTP pipe. Would be nice to avoid HTTP if not required tho ...
Post a Comment