I am playing around with a different way (at least for me) to construct a JavaScript toolkit. It is called Blade, and you can follow it via the Blade GitHub repo.
I have had this on my local drive for a few weeks now, and the germ of it started with this post. I wanted to get it more polished, but best to get it up somewhere to get some feedback at least on the principles.
There is not much there now, basically a tiny amount of spaghetti code that is not really usable. However, I list out the guiding principles in the README.md, visible on the GitHub source tab.
13 comments:
Awesome name James.
What devices are you targeting? It seems like an awful lot of code for query if this is for WebKit - and yo have a separate file for IE, so it's not that.
I also wonder if mobile wouldn't benefit from a query-lite which would use less code. Though I know little about query or mobile devices.
mwilcox
The code that is in the repo right now is awful spaghetti code, just lifting Dojo modules but wrapping in the API I want.
I wanted to get a feel for the API and object.verb() vs verb(object) and the implicit type conversions before locking down the code.
The runjs modifiers could be used to start with a very small query engine and build up from there for other browsers.
Very nice, just reading through the manifesto (ie: the README file) looks like you've hit a lot of nails on the head (or whatever that metaphor is). Not just the verb thing, but simple things like jslint and jsdoc.
I imagine there are other "go with the flow" principles you'll want to follow, like following the querySelectorAll() behavior (differs slightly from jquery/dojo.query() since the selector always searches from document root), using CSS3 for animations rather than coding them in JS, etc.
Bill
Bill, I just updated the README to mention CSS animations specifically, it would be good to have them in there.
As for querySelectorAll(), I would actually tend to what jquery/dojo does just because it it probably the more expected/reasonable behavior, but it is worth investigating how weird it would be to just use querySelectorAll().
Also, I think there are some psuedos that are useful that querySelectorAll() does not support. Needs more investigation.
There's some discussion about the use of _ on Ajaxian, regarding another library:
http://ajaxian.com/archives/would-you-like-a-_-with-that-new-library-gives-js-what-it-should-have
mikewse: using _ is a risk, but it fits with the name, and using the runjs module loader means that you do not need to actually use _ when writing your code:
run(["_"], function(blade) {
blade("div").attr("title", "hello");
});
Additionally, there is no global in the page that is created for the underscore, so conflicts with existing code is avoided.
I just read some more on github, and the auto type-conversion thingie is quite interesting!
In some sense it is quite similar to operator overloading of other languages, with both its advantages and problems. On the powerful side you could allow several steps of conversion to match the right method, and on the down side you may get the same conflict problems as with operators. F ex, what to do if the same "intuitive" function name is used in two different modules, with types that can be converted from the same base type?
But, still looks promising. Will be interesting to see what more work in this area can lead to!
mikewse: I only want to do the type conversion for strings into a DOM node or a NodeList, so I hope we can contain the problem by limiting the types of conversion.
Basically, I want a way so that I can specify a string and use string operations or DOM operations, but have only one entry function, _() for both. So, use string method to convert a template then a DOM method that can use that string to create a DOM and insert it in the page.
Oh ok, I thought you were envisioning passing things like widget ids and dates in string format, as well as other things.
But you are thinking about doing non-intrusive class augmentation on any class, right? So this would be possible:
_(new MyClass).augmentedMethod()
if I have somehow registered augmentedMethod with the wrapping system.
Anyway, here's a little discussion on date strings. What I guess is what you want to do, is to do something like Prototype but without the intrusiveness. Adding a format method intrusively would give us:
new Date("2001-02-03T04:05+01:00").format("YYYY/MM");
Registering the date augmentation with blade could give us this:
_(new Date("2001-02-03T04:05+01:00")).format("YYYY/MM");
But, to avoid the explicit conversion your conversion system could convert this string to a Date if the format method was only available for dates:
_("2001-02-03T04:05+01:00").format("YYYY/MM");
Or, the string "type" could be specified in the wrapper function:
_("2001-02-03T04:05+01:00", "date").format("YYYY/MM");
Or, an explicit conversion could be done as the first method call:
_("2001-02-03T04:05+01:00").toDate().format("YYYY/MM");
Which of these schemes do you have in mind for blade?
mikewse: Yes, it would be possible to add new methods to _() and they would pollute the bladed object.
However I do not think everything needs to be added to blade as an augmentation. What is not clear to me yet is how a widget system would work into it, for example.
I expect explicit conversion via an explicit method call, so something like your last example:
_("2001-02-03T04:05+01:00").toDate().format("YYYY/MM");
Oops, I meant to say would *not* pollute the bladed object.
I think the node.place() function (with its various placement options) can be eliminated since it duplicates similar jQuery append and insert methods.
Les: that is an interesting point. On one hand place() allows for a number position instead of a relative position specified by a string, but I do not ever recall using place() with a number argument for the position. It might be that we can get away with append, prepend, insertAfter, insertBefore and html.
Post a Comment