Impel - HTML5 Javascript ORM | Hacker News Reader

Impel - HTML5 Javascript ORM

impel.simulacre.org

17 pointstortilla11 comments

I'm always wary of third-party libraries that have their own license: http://impel.simulacre.org/crm/license

It's probably not an issue, but if I were to use it, I'd have to spend time parsing this license to make sure that I could use it.

To third-party library authors: please, pretty please choose a well-known open-source license for your project. If you are trying to turn it into a commercial venture, you can still do this with a well-known license (see MongoDB's license for an example: http://www.mongodb.org/display/DOCS/Licensing).

Is it really necessary to add a library dependency like Mootools into a JS ORM?

This is a pretty good example of how not to write Javascript.

Can you give some examples?

I am new to JS and would like to know what to avoid.

Learn about prototypical inheritance and Javascript's lack of types.

Everything in Javascript is an object. By object I mean a hash table (or dictionary, if you are coming from Python). Even functions and arrays are objects! Put that in your pipe and smoke it. Have a look at this code:

    function FancyArray() {} // In this setting a function is just a fancy name for an object.
    FancyArray.prototype = Array.prototype;
    var my_new_fancy_array = new FancyArray();

    my_new_fancy_array[0] = 'foo';
    my_new_fancy_array.length = 1;

Remember that the square brackets and the dot notation are equivalent. This is very important. The last lines could be written like:

    my_new_fancy_array['0'] = 'foo';
    my_new_fancy_array['length'] = 1;

Anyway, this will return you a psuedo Array => ['foo'] (This is the basis of how jQuery works). Going back to the first couple of lines, we made a new object, FancyArray, then set its prototype to the prototype of Array (so we get all the nice methods like toString and push etc.). We then created a new FancyArray.

I'm going to cut this tutorial short because I have somewhere to be, but a good source of good Javascript is Douglas Crockford and his bite-sized book "Javascript the Good Parts" (and a good post of prototypical inheritance here http://javascript.crockford.com/prototypal.html). If you are willing to take a certain level of Russian crazy have a read of Dmitry's blog http://dmitry.baranovskiy.com/ (he wrote Raphaël). He gets it.

Back to Impel, the heavily OO code and the way things are named are a bit of a tell tale sign. The author is probably a Java or PHP programmer who has spent the night getting tipsy in this weird and wonderful gay bar and, hitting on the only chick around, hasn't checked the goods before he moved in for a kiss. Javascript is a beautiful language when you get to know it and accept that it's different from anything you've experienced before.

Yup, it's based heavily on PHP's Propel http://propel.phpdb.org/.

I built it that way so that I could quickly port a PHP webapp backend into Javascript for use in a self-contained HTML5 version of the entire webapp.

If you want a straight JS ORM that takes into account JS's prototypical inheritance, and loose type system then Impel is not for you.

Regarding the license, it's basically the MIT license. Yes, you can use it. Yes, you can modify it. Yes, you can sell it. Just give a little bit of link love back.

So, what makes that array so fancy? I mean, it's name is fancy, but that is about it. Is that really enough for it to deserve that name?

I had this idea about a year and a half ago, and I decided:

1 - To do this in Javascript would require a MASSIVE amount of code 2 - It required too much custom setup on the server, and 3 - It solved a problem that didn't exist.

I still think #3 is the most relevant, but #1 and #2 are still big impediments. From what I can see, this library doesn't address any of those concerns.

Perhaps it will do well, though. I can't wait to see. Good work and good luck!

32k packed is pretty fucking big for a JS ORM.....

It would probably be a lot smaller with a packer that obfuscates field names too (ie: Closure Compiler).

He could probably get it down further by stripping all of these exception strings from the release version and replacing them with structured types and numeric codes. Some of these are really development-time assertions that shouldn't be in the release code anyways:

throw ("doSelectJoinAllExcept requires an array of peer names as an argument")

I'm pretty sure I could write a better JS ORM in less then 10k unpacked (no comments / docs).

Reply on news.ycombinator.com