I hate to risk starting a my-framework-is-better-than-your-framework
thread, but I'd really like to here people's opinions on / experiences
with the merits of prototype + lowpro over other frameworks such as
JQuery that seem to be gaining some mind-share.
We've been bundling lowpro with Hobo for a while and are intending to
move towards "lowpro style" for all the client-side behaviour that
comes with Hobo.
At the same time I've always got half an eye on JQuery, and have been
getting increasingly tempted to at least give that option a try.
One thing that occurs to me is that I'd miss the nice rubyisms that I
get with prototype (e.g. little things like String#gsub)
It would be awesome to port the low pro syntax to JQuery. Now the thing is, low pro is just a tiny abstraction layer above proto, in theory we should be able to port the same layer to JQuery.
> Here's my take from September: > http://meme-rocket.com/2007/09/07/agnostic-unobtrusive-javascript/ Short > of it is you need the livequery plugin if you want to do UJS on dynamic > content. And it is of course possible to use both prototype and JQuery > together.
On 1/21/08, Matt Aimonetti <mattaimone...@gmail.com> wrote:
> It would be awesome to port the low pro syntax to JQuery. Now the thing is, > low pro is just a tiny abstraction layer above proto, in theory we should be > able to port the same layer to JQuery.
I've considered doing this myself. Ive used both jquery and prototype heavily in the past. The reason I like prototype over jquery is that prototype offers more general programming tools where as jquery is just about dealing with the DOM. Secondarily, in my experience, the chaining idiom in jquery tempts people into writing some pretty unreadable code.
However, jquery is really compact, very well documented and does its job well so I can see the attraction so 10 minutes spend writing behaviours on top of it would be well spent. Ill see what I can come up with. Something like:
$('.date').attach(DatePicker, { opt1: 34 });
Would do the job, I can even bring over the inheritance stuff...and the DOM builder. I'll do it tomorrow morning if I have time.
> On 1/21/08, Matt Aimonetti <mattaimone...@gmail.com> wrote: > > It would be awesome to port the low pro syntax to JQuery. Now the thing > is, > > low pro is just a tiny abstraction layer above proto, in theory we > should be > > able to port the same layer to JQuery.
> I've considered doing this myself. Ive used both jquery and prototype > heavily in the past. The reason I like prototype over jquery is that > prototype offers more general programming tools where as jquery is > just about dealing with the DOM. Secondarily, in my experience, the > chaining idiom in jquery tempts people into writing some pretty > unreadable code.
> However, jquery is really compact, very well documented and does its > job well so I can see the attraction so 10 minutes spend writing > behaviours on top of it would be well spent. Ill see what I can come > up with. Something like:
> $('.date').attach(DatePicker, { opt1: 34 });
> Would do the job, I can even bring over the inheritance stuff...and > the DOM builder. I'll do it tomorrow morning if I have time.
That's a point. I'll make it use livequery if its present although these days I don't really favour those kinds of solutions. If I need to work with a changing DOM I use event delegation.
I'll see what I can put together.
On 1/26/08, Matt Aimonetti <mattaimone...@gmail.com> wrote:
> > On 1/21/08, Matt Aimonetti <mattaimone...@gmail.com> wrote: > > > It would be awesome to port the low pro syntax to JQuery. Now the thing > is, > > > low pro is just a tiny abstraction layer above proto, in theory we > should be > > > able to port the same layer to JQuery.
> > I've considered doing this myself. Ive used both jquery and prototype > > heavily in the past. The reason I like prototype over jquery is that > > prototype offers more general programming tools where as jquery is > > just about dealing with the DOM. Secondarily, in my experience, the > > chaining idiom in jquery tempts people into writing some pretty > > unreadable code.
> > However, jquery is really compact, very well documented and does its > > job well so I can see the attraction so 10 minutes spend writing > > behaviours on top of it would be well spent. Ill see what I can come > > up with. Something like:
> > $('.date').attach(DatePicker, { opt1: 34 });
> > Would do the job, I can even bring over the inheritance stuff...and > > the DOM builder. I'll do it tomorrow morning if I have time.
Testy = $.klass({ initialize: function(arg) { alert('ive just been attached with the arg ' + arg); }, onclick: function() { alert('ive been clicked'); }
});
Btw, $.klass is a full port of the Prototype Class.create stuff so you get that as a bonus and can use all the inheritance stuff in the same way.
Another little bonus is that if you are running livequery it does some magic and automagically attaches new instances of the behaviour whenever the DOM is changed so for the above example if you $(document.body).append('<p>Another para</p>') then it gets its own behavior instance as well.
So, I think it needs some more bashing (and some unit tests) and I think it would be good to ship with some behaviors like normal Low Pro does. Probably Remote and Observed...
What do ya'll think? After sitting and coding it Im actually really pleased with how it turned out. It's much simpler than the Prototype implementation and fits jquery's style a lot more. I might defect :)
I think it's awesome Dan. The last thing keeping me on the prototype stack was lowpro. I'll probably miss prototype but JQuery documentation is so much better and the add-ons are compelling enough. I'm moving. I'll write when I get there…
> What do ya'll think? After sitting and coding it Im actually really > pleased with how it turned out. It's much simpler than the Prototype > implementation and fits jquery's style a lot more. I might defect :)
Oh feck. I've only just got to grips with prototype... ;-)
I tried the implementation and its great! Kudos on whipping it out so
quickly.
Now, another question I have with all this framework talk.. and dare I
say it.. but Mootools 1.2 is always something that has caught my eye
with its efficiency, speed, clarity of code, and code/framework
philosophy. Any thoughts?
> Now, another question I have with all this framework talk.. and dare I > say it.. but Mootools 1.2 is always something that has caught my eye > with its efficiency, speed, clarity of code, and code/framework > philosophy. Any thoughts?
Heh...at this time, no. I don't think I want to support loads of versions of Low Pro and peronally I've never seen where Mootools fits into the puzzle as far as JS libraries are concerned. In my opinion, it doesn't really offer anything that Prototype or jQuery haven't got so I've never thought to use it myself. However, Im by no means saying it's not a good library.
I'd be totally happy for someone to do the port though. After using Low Pro's behavior classes quite heavily over the past year or so I'm really convinced that its the best way of writing components and managing the complexity of Ajax applications in general and the idea is totally transferable between libraries. I even considered trying to write Low Pro in a library independent way but after investigating it it definitely felt like it would end up very over-engineered.
To be honest, Low Pro has become quite a compact piece of code so it would only take me another 30 mins or so but I'm not sure I'd be qualified to support code that I wouldn't use myself and it would be better ran by someone from the Mootools camp.
> To be honest, Low Pro has become quite a compact piece of code so it
> would only take me another 30 mins or so but I'm not sure I'd be
> qualified to support code that I wouldn't use myself and it would be
> better ran by someone from the Mootools camp.
Right, that is understandable. However, my underlining objectives in
my applications are to achieve efficiency and performance, especially
over a browser executing JS where there are varying computers and
browsers. That usually lends itself to the people in charge of a
framework. Once I begin to adopt a framework and my applications
consume it, I hate having to port my code, so I always spend a lot of
time making a decision.. the hard part is to look ahead and consider
which framework will last.
Mootools has an interesting test suite comparing the various
frameworks: prototype, mootools and jquery right in your browser.
http://mootools.net/slickspeed/
These are older versions so I copied the test code and posted it on my
server with the latest versions of each framework: http://nulayer.com/~peter/jstest/
... I like jQuery, and I'd prefer to use it because of its adoption
and support, but from this small subset of a test, it does not perform
well at all. Reading the jQuery blog, they've taken on a developer to
optimize their code, I'm looking forward to seeing what they come up
with.
On 1/28/08, Peter <peter.kielt...@gmail.com> wrote:
> ... I like jQuery, and I'd prefer to use it because of its adoption > and support, but from this small subset of a test, it does not perform > well at all. Reading the jQuery blog, they've taken on a developer to > optimize their code, I'm looking forward to seeing what they come up > with.
From looking at that there's not a huge amount in it. In my experience, since all the selector engines jumped up in performance a while ago framework speed is not a problem. High performance is normally achieved at application level. Doing things like using event delegation, lazy evaluation and generally writing code in a way that makes for the least amount of work possible is what really counts. Even before the selector speed up it wasn't a huge problem - you just needed to be careful with what selectors you used. However, I say this from my experience. So although I work on a lot of pretty JS heavy applications I've never felt the need to write a raytracer in JS or something similar.
But yeah, back to the original point. If you do like Mootools and want to port Low Pro then that would be cool. It's already got a class implementation which is most of what Low Pro JQ's code is so its probably going to be very simple to do.
'p.hide_myself:click': function() { // this refers to the paragraph being clicked $(this).hide(); }
});
Chris from Err the blog, mentioned that he was excited about seeing LowPro being ported to JQuery, he just whished you were using click instead of onclick.
I'm personally really excited, especially with the new Merb release coming up, I believe JQuery will grow in the Ruby community. I'll do my best to try to see if I can come up with behaviors.
> On 1/28/08, Peter <peter.kielt...@gmail.com> wrote: > > ... I like jQuery, and I'd prefer to use it because of its adoption > > and support, but from this small subset of a test, it does not perform > > well at all. Reading the jQuery blog, they've taken on a developer to > > optimize their code, I'm looking forward to seeing what they come up > > with.
> From looking at that there's not a huge amount in it. In my > experience, since all the selector engines jumped up in performance a > while ago framework speed is not a problem. High performance is > normally achieved at application level. Doing things like using event > delegation, lazy evaluation and generally writing code in a way that > makes for the least amount of work possible is what really counts. > Even before the selector speed up it wasn't a huge problem - you just > needed to be careful with what selectors you used. However, I say > this from my experience. So although I work on a lot of pretty JS > heavy applications I've never felt the need to write a raytracer in JS > or something similar.
> But yeah, back to the original point. If you do like Mootools and > want to port Low Pro then that would be cool. It's already got a > class implementation which is most of what Low Pro JQ's code is so its > probably going to be very simple to do.
...is just as clean as Event.addBehavior. I've basically just brought across the behavior classes part.
> Chris from Err the blog, mentioned that he was excited about seeing LowPro > being ported to JQuery, he just whished you were using click instead of > onclick.
The on being at the start of methods that catch events is an important part. We need to differenciate which methods are intended to catch events and which are just normal methods. If we do this then behavior classes can catch custom events as well which is a very good thing.
> I'm personally really excited, especially with the new Merb release coming > up, I believe JQuery will grow in the Ruby community. I'll do my best to try > to see if I can come up with behaviors.
Yeah, I'm liking how its turned out so far. My only reservation is that what behavior classes do can and is currently done using plugins:
$('input').attach(DatePicker);
could be done as:
$('input').attachDatePicker();
However, I think behavior classes have advantages over this method on accounts that they are actual classes that you can inherit from and augment yourself. The only way you can customise plugins is to crack open the source and change it which is never ideal.
Just written some rambling crap on my blog about it all :)
> However, I think behavior classes have advantages over this method on > accounts that they are actual classes that you can inherit from and > augment yourself. The only way you can customise plugins is to crack > open the source and change it which is never ideal.
This is awesome! I love the way you've implemented behaviors as
classes. This is going to be very useful.
I'm not sure if you know this or not but in jQuery 1.2.2 we added what
I call "special events". Not sure if it will benefit the port of Low
Pro or not. If your not familiar with them it allows you to handle an
event in a ... well ... special way. It isn't documented yet but for
an example of the special events "api" check out the
$.event.special.mouseenter and $.event.special.mouseleave (http://
dev.jquery.com/browser/trunk/jquery/src/event.js#L343).
After a quick glance over the code it looks like you are missing a
return statement on line 10. I'm going to play around with this as
soon as I get the chance.
--
Brandon Aaron
On 30 Jan, 18:46, "Dan Webb" <d...@danwebb.net> wrote:
> Just written some rambling crap on my blog about it all :)
> > However, I think behavior classes have advantages over this method on
> > accounts that they are actual classes that you can inherit from and
> > augment yourself. The only way you can customise plugins is to crack
> > open the source and change it which is never ideal.
I read your blog post and it was right on. Just as other software is
built, it should be modular, extensible, and maintainable. I have been
recently turned on by jQuery after using Prototype and Mootools, but
I'm surprised that jQuery's OO implementation is not as strong. The
callback approach that someone mentioned is definitely not an elegant
or adequate solution. Perhaps Low Pro is the saviour of this problem,
but I'd expect Low Pro to be integrated with jQuery since it's just a
small stretch in their design.. plus adds so much. Mootools is quite
nice from that perspective.
> I read your blog post and it was right on. Just as other software is
> built, it should be modular, extensible, and maintainable. I have been
> recently turned on by jQuery after using Prototype and Mootools, but
> I'm surprised that jQuery's OO implementation is not as strong. The
> callback approach that someone mentioned is definitely not an elegant
> or adequate solution. Perhaps Low Pro is the saviour of this problem,
> but I'd expect Low Pro to be integrated with jQuery since it's just a
> small stretch in their design.. plus adds so much. Mootools is quite
> nice from that perspective.
On 2/1/08, timothytoe <timothy...@gmail.com> wrote:
> Wow. MooTools selectors are fast!
Yeah? last time I looked there wasn't much in it at all. Since all the libraries jumped in speed in that area its just simply not been a problem for me anymore. More performance anywhere is good I suppose but its not something I really think needs much more development in libraries at this time.
>>Since all the libraries jumped in speed in that area its just simply not been a problem for me anymore.
It's not a problem for me, either. Very little time is spent in the
selectors. I was just impressed. jQuery is way behind in 3 browsers.
Interestingly, it is much better in IE, which I suppose is where you
want to put the work, since IE is so slow.
--T
On Feb 1, 10:15 am, "Dan Webb" <d...@danwebb.net> wrote:
> On 2/1/08, timothytoe <timothy...@gmail.com> wrote:
> > Wow. MooTools selectors are fast!
> Yeah? last time I looked there wasn't much in it at all. Since all
> the libraries jumped in speed in that area its just simply not been a
> problem for me anymore. More performance anywhere is good I suppose
> but its not something I really think needs much more development in
> libraries at this time.
On Feb 1, 1:15 pm, "Dan Webb" <d...@danwebb.net> wrote:
> On 2/1/08, timothytoe <timothy...@gmail.com> wrote:
> > Wow. MooTools selectors are fast!
> Yeah? last time I looked there wasn't much in it at all. Since all
> the libraries jumped in speed in that area its just simply not been a
> problem for me anymore. More performance anywhere is good I suppose
> but its not something I really think needs much more development in
> libraries at this time.
Dan,
What does jQuery have over Mootools besides a bunch of plugins that
are not easily extensible without callbacks?
> What does jQuery have over Mootools besides a bunch of plugins that > are not easily extensible without callbacks?
I don't think I'm qualified to answer that. I don't know much about Mootools in detail. Maybe nothing. Last time I checked the source was just after it was released and I liked the look of it. It's kind how I'd structure a lib if I was starting my own. However, its a latecomer to the game so its got to offer something really different and I don' think it has as yet. It's keeping pace with the other libs (and possibly surpassing them in parts) but not enough for me to invest in it as yet.
I think with jQuery you either love the $() chaining idiom or you don't. Personally, I love the plugin system for jquery and find it convenient for some tasks but I've always mostly worked with Prototype. I wasn't trying to diss it on my blog, I was just exploring whether Low Pro was even worthwhile for jQuery or not.
|
