Wednesday, December 16th, 2009
Scripty2 in the wiiiild
Category: Scriptaculous
Thomas Fuchs has some new controls and functionality to show us inthis scripty2 preview:
Try the scripty2 UI demos! (alpha version, so there are some kinks!)
Those controls are written with the super-nice Prototype class system and custom events, so they’re super-tweakable and make it a snap to create extensions and customized versions. More controls are in the works, and there should be a beta release this year (or grab the code from github).
They support full keyboard navigation and provide accessibility hooks through WAI-ARIA.
The best thing is that they’re compatible with Themeroller (from jQuery UI) themes! So you can just reuse/tweak existing themes very easily, plus scripty2 comes with a special scriptaculous theme, thanks to Samo Korošec.
Bonus– here are two new sightings of scripty2 in the wild:
- derStandard.at Express, experimental site by leading austrian newspaper Der Standard
- Ford Fusion 41, made by Amy and me
Just make it jQuery compatible, add an API plus a lot of demos / code examples and and I would love to use it in the future… Oh sorry – just day-dreamin’. ;)
Autocomplete does not work for me in IE 8.
@gabel: What exactly do you mean by “jQuery compatible”? It has an API with docs at http://scripty2.com/doc/ and some demos are linked to in the post, along with more at http://scripty2.com
@gabel, not everything needs to use jQuery. Competition is good. The Prototype community really needs more projects such as this (even if it is just the next version of scriptaculous). Especially ones that are still being actively maintained. I would kill for a replacement for the Prototype Window Class or Prototype UI (something I hoped would replace the latter).
Gabel means this: “scripty2 depends on Prototype 1.6.1 or later.”
.
Which is equal to “libX depends on jQuery 1.3.1 or later”.
.
*shrug*
MyTableGrid is an excellent prototype/scriptaculous project, you can check http://pabloaravena.info/mytablegrid
@gabel: jquery would be better of learning from scripty when it comes to proper queue and scope. The jquery queue/dequeue principle alongside every effect being attached to elements is the wrong way of thinking if you want proper animation. Having to jump through hoops to get the same thing done and having a ton of plugins out there attempting to fix animation in jquery prove that.
.
Rewriting scripty to add proper animation on top of the crippled stuff that’s in jquery right now makes no sense. I’d rather see Prototype make itself more compatible with other frameworks, with its class-based inheritance, custom events and extensions to the language itself it’s a much better fit for scripty. A framework agnostic scripty would be nice too but that’s probably not going to happen any time soon.
@jadet, prototype can only be compatible with other frameworks if they dropped their entire documentElement.prototype augmentation (or work with frameworks that don’t handle elements), but then it wouldn’t be Prototype if they did.
.
MooTools, Prototype, Dojo, jQuery and even YUI are direct competitors to eachother. Prototype is the odd one out when it comes to “playing nice with other frameworks” because it’s severely obtrusive.
@bengerrissen: mootools shares that problem since it started out as a fork of prototype and also extends prototypes. There are a lot of ways to fix compatibility issues so that frameworks play nice together, most of them are already being discussed on core mailings lists.
@Jadet
‘mootools shares that problem’
You say problem, I say design choice. Guess that’s why I play better with other developers! :P
I say scripty2 is looking great!
@ Jadet
Please do not spread your ignorance to others: Mootools IS NOT and WAS NOT a fork of Prototype. Period. It also never prototypes the Object native, which alleviates many issues that some native modifier libs have.
And that’s the word.
What a weird tab implementation. It looks nice, and I’d use it for somethings, but its really _not_ tabs as any one would define them.
@csuwldcat: please read up on your javascript library history, you haven’t been paying attention.
@sixtyseconds: labeling a compatibility problem a design choice doesn’t make your code play better with other developers. Those who recognize the problem and change their code get to play with a lot more developers.
Next to scripty2, I’ve also written the ‘antithesis’ to it, a 50-lines of code animation framework called emile.js (just pure JavaScript/DOM, works with any framework), grab it at http://github.com/madrobby/emile
Personally, I see jQuery more as an add-on as a complete framework– it provides a CSS+DOM utlitities DSL for JavaScript. Prototype.js goes much further, extending the language itself (e.g. Enumerables), a really usable class-based OO system and other non-DOM, non-CSS stuff.
We’re actually concentrating on more of the language extension stuff, the latest development versions have the CSS engine pluggable (e.g. use Sizzle or NWMatcher). Chances are, you might see a version of Prototype that’s much more pluggable and modularized soon. :)
Competition is good, and the UI controls look slick, but this is not jQuery yet. By this, I don’t mean API similarity (then what’s the point of innovation?) but simplicity. But it is good to know that Scriptaculous has evolved into a full-fledged UI library.
@Jadet – The MooTools philosophy on this is that developers shouldn’t load any and every javascript library available just for plugins and UI bling. They feel that if a plugin is good enough, the developer should take the time to port the plugin to run on MooTools. This isn’t a flawed view any more than you suggesting that every plugin should work on any library in any website.
They have, of course, implemented what they call dollar safe mode. This helps somewhat with compatibility unless the library you want it to be compatible also alters natives. Why load 2 libraries that both alter natives? I guess that gets us back to loading needless extras…
Then we get to the age old debate of altering natives to begin with. Prototype and MooTools have both been built on the premise of utilizing javascript’s prototypical nature by extending the native prototypes. You may not think that’s the best approach to writing a javascript library, but then you are neither Prototype or MooTools, so I guess that choice is not up to you.
When I said that I play nice with other developers it was just some humorous way of pointing out that what you may consider to be problems are most likely the outcome of extensive planning and discussion… :)
@sixtyseconds: I agree, loading multiple libraries is bad practice and should be avoided. But the reality is people do this all the time as they plug together code from different places. Most developers don’t have the luxury to convert everyone on a project to a specific framework and will eventually be forced to abandon frameworks that keep extending native prototypes since those don’t mix. That’s one of the main reasons why frameworks that don’t extend native prototypes easily grow out to be way more popular for the mainstream user.
@csuwldcat: Here’s some reading material to get you started, http://www.slideshare.net/jeresig/javascript-library-overview-presentation/32
i’ve just had a great idea. a framework abstraction that abstracts the framework layer, so you can use any library for any framework! that way, you can use a mootools library, a jquery plugin, a prototype library, etc…
i’m gonna call it mooqueryaliscious, and it’s gonna have standard COBOL syntax.
Imo. don’t mix frameworks that do the same thing 90% of the time and if you do, you deserve all incompatibility issues that goes along with it.
.
I personally prefer mashing up specialist libraries focussed on a single purpose (ie. NWMatcher + Emile), however reality usually forces me to use prototype.js or jquery.js.
.
Changing frameworks to co-exist in the same scope is a mistake imo. if anything, they SHOULD break eachother. Developers bloating pages with duplicate functionality should be punished. Creating an environment where you can use all frameworks (that do the same thing 90% of the time) next to eachother is BAAAAD on all levels.
@Jadet: A “spiritual fork” – not an _actual_ code fork. Just to clear things up.
@Jadet – Dude, don’t preach to me on this, the Moo guys (and gal) looked to Prototype for some conceptual and code inspiration. Not sure you are aware of what FORK means when it comes to coding. FORKING is taking a given code base, copying it, and changing/adding a few things…WHICH IS NOT WHAT THE MOO FOLKS DID, OK FOGEL!
@ Jadet + driverdave: When it comes to compatibility, Mootools releases the $ fn when it detects it on init, it falls back to document.id() for this functionality.
Conflicts occur more frequently with Prototype because they modify the Object native which is a compatibility non-starter under some conditions.
Other than that, there is jQuery’s noConflict() which helps mitigate conflict issues with most libraries that don’t detect collisions inherently as Moo does.
@csuwldcat: You should have a look at your caps-lock, and check Resig’s slides to see how broad the meaning fork is. At the first release of mootools everybody called it a Prototype fork, it’s pretty obvious that with that we don’t mean changing a few things around and giving it a new name. Next time you start calling people ignorant you might want to make sure you know what you are talking about.
@Jadet –
So because Resig says fork has many variants YOU get to decide which to apply to what a framework developer says? Uhhh, why not go with reality instead actually find out the facts instead. The Mootools author was initially inspired by Prototype and did not fork it, and “spiritual fork” sounds a hell-of-a lot closer to “inspiration” than “copy” to me hombre. You can *say* whatever you want, that doesn’t change the facts what the reality is.
Call me crazy Jadet, but I am going to go ahead and stick with this *generally accepted* version of what “fork”means as opposed to what a SINGLE developers puts on a slide, maybe you should think about what you label other frameworks as be for doing so: http://en.wikipedia.org/wiki/Fork_%28software_development%29
Wow, I made about 50 typos in that comment, please forgive; that’s what typing comments from a stupid phone gets me! :P
@csuwldcat: It’s not a single developer that calls it a fork, everyone called it a fork at the time and a lot of people still do. Google is your friend. If you’d been paying attention you would have known what I ment with Mootools starting out as a Prototype fork and saved yourself the trouble coming across as an ignorant jackass.
@All other than Jadet -
Just so you all know what Jadet mean by “everyone” I searched for these queries on Google, mootools fork of prototype – mootools “fork of prototype”, and found a single Google Groups post, the slide that Resig made, and this article *this.inject(‘irony’)* that claimed anything along the context that Jadet is claiming. In conclusion: “everyone” to Jadet is Resig, one guy on a Google Group, and himself – lol, you have to be kidding me son…
Just for your own investigatory curiosities, here is the link that shows what “everyone” supposedly thinks on this issue: http://lmgtfy.com/?q=mootools+fork+of+prototype
And that’s the Word. :))
@csuwldcat: Spending less time trolling around wasting people’s time might help you to dig around and learn a thing or two, have fun growing up ;)
Will do guy who makes sweeping-and-provably-false-claims about a framework he likely uses infrequently or never – right back at ya slick! ;)
Oh, and I officially call shenanigans on your lack of response to the letmegooglethatforyou link that you prompted with this line: “Google is your friend” – Thanks for that insight Jadet, I am after-all in the process of “growing up”, so as you can imagine I’m trying to get healthy portions of milk, Wheaties, and your advice on googling shit that I KNOW like the back of my hand.
woo.
Another wheel.
I think *fork” is a wrong term when discussing js frameworks. We all copy bits code from eachother, open source to the core.
.
@ExtAnimal, wrong. All people who yell *woo another wheel* should be forced to ride a horse and carriage as obviously they don’t believe in innovation.
This is the first time I hear MooTools being called a Prototype fork.
.
We all take ideas from everyone. That’s what Open Source is about. MooTools takes from Base2, Prototype. Prototype takes from us, http://www.prototypejs.org/2009/2/16/pimp-my-code-1-element-storage, and that’s wonderful. And everyone has been credited when credit was due.
.
Obviously you weren’t around at the time to know about these things. Quoting slides, and removing the word `spiritual`, doesn’t help you look serious.
jQuery in 2006: http://cld.ly/d1tgp
@Thomas Fuchs – I totally dig the added controls and Themeroller support, I think it’s a really clever idea.
@Post Hijackers – I think we can all agree that MooTools was heavily inspired, not a true fork by definition, by Prototype as were others. Early MooTools builds included Prototype’s copyright notice and used much of the same API such as bind, bindAsEventListener, delay, $A, $, Object.extend, capitalize, camelCase (camelize), trim (strip), has/add/remove/toggleClassName, get/setOpacity/, get/setStyle, Ajax.getTransport, toQueryString (serialize, Object.toQueryString)
.
http://web.archive.org/web/20061021175741js_/mootools.net/mootools.js
.
And continues to be inspired by Prototype/Scriptaculous as MooTools More API has min, max, stripTags, repeat (times), parseQueryString (toQueryParams), Sortables (Sortable.create)
.
Credit was clearly given and that’s a good thing :D
.
http://web.archive.org/web/20061024032526/http://mootools.net/
.
None extend the Object.prototype. Any framework that extends dom or native objects will have naming collisions and/or 3rd party problems. It’s the nature of the beast.
ps. Scripty looks dandy ;) keep it up.
Sorry to get back to the subject at hand,
We have been using scripty2 for a couple of months and this library is awesome. We were a bit afraid about porting our legacy code from script.aculo.us, but it was a breeze.
About the background thread, the only incompatibility I have ever found is between Prototype and Mootools. According to our experience, Prototype works fine with the rest.
OMG, did ajaxian turn into yet another place where we can throw mud at each other? Staring to call each other things doesn’t make you right or look like it for that matter. Actually just gonna make you look stupid instead of someone who knows what he’s talking about. If you can’t keep a discussion on a civilized level it wont matter if you’re right or wrong since you’ll make yourself look ignorant. Did it turn out that while some developers are expanding their knowledge they lose their social skills? Please don’t turn this page into yet another meaningless battlefield of who are right and wrong. We are all here to help and learn from each other not to fight each other.
And oh, by the way, Scripty2 looks pretty good and looking forward to use it on the pages that i work for.
I’m sorry for the vehement defense, but ask yourself this: If someone told everyone in your grad school class that you “basically forked” your thesis from your classmate’s – which you spent months writing, would you be pissed at that person? I am not the guy who wrote the framework, but it is an achievement that took quite a while. To flippantly call it a virtual copy of something else pretty disrespectful in my opinion.
I am sorry to see the scripty, and thus Prototype, made so few changes in such a long time.