Find a Job, Post a job.
Hamish Friedlander of SilverStripe has developed jQuery Concrete as a way to enable developers to easily add functions to groups of DOM elements based on the structure and contents of those DOM elements.
I’d like to announce the 0.9 (API stable) release of the Concrete and Selector libraries for jQuery.
Concrete provides a brand new model of JavaScript code organisation – a replacement for Object Oriented programming that is focused on adding functions to DOM elements based on their structure and content. It’s a merging of the model and view layer that initially seems weird, but can give very powerful results.
We’re standing on the shoulders of giants here, taking ideas from Prototype’s behaviour & lowpro and jQuery’s effen & livequery. Concrete extends these concepts to provide a complete alternative to traditional OO design – self-aware methods, inheritance, polymorphism, constructors and destructors, namespacing and getter/setter style properties, all without a single class definition.
A key component of Concrete is Selector – a CSS selector engine developed in conjunction with Concrete to give it maximum performance. For the use patterns is it designed for, it can out-perform jQuery’s native Sizzle selector engine by an order of magnitude.
Developed by Hamish Friedlander, and partially sponsored by SilverStripe, Concrete is in use in several projects internally, and is a key component of the CMS redevelopment for the next version of SilverStripe.
In addition to the source, a tutorial and a screencast are available to help introduce the new concepts.
This looks interesting and all but I’m not sure what the benefits would be for the extra download for visitors. I haven’t written many plugins for jQuery but it doesn’t seem like an overly complicated thing to do. The shortcuts this provides seem nice but again, is there a huge benefit here? I’m hoping more advanced jQuery folks than me chime in on this.
Plus, I failed to see a source cited for the claim that this new selector engine is faster than Sizzle by an order of magnitude, for the patterns it is designed for that is. I don’t discount it, I just like to see an example supporting statements like that.
Good to see jquery folks are learning from Prototype. If they want a faster selector engine they should also have a look at NWMatcher, or just drop it in there. It’s a lot faster then Sizzle.
I thought it might be a step backwards with the use of onclick attributes 0_0 .
I’m concerned about code reuse with this tool. As I see it (on an admittedly brief scan), in order to reuse the same functionality in multiple areas of the page, you’d need to attach code using an identical CSS selector. But if the functionality is the same and the style is very different I could see this leading to either code duplication or some odd CSS trickery.
This looks awesome! I like the concrete style very much; it feels more like enhancing a document with behavior than rolling a half-baked MVC engine in javascript that has a bridge to the DOM. This feels more like a web way to program.
> I thought it might be a step backwards with the use of onclick attributes 0_0 .
Those events could have been attached unobtrusively, I think he used onclick to make it more clear what the buttons were doing for the tutorial.
> in order to reuse the same functionality in multiple areas of the page, you’d need to attach code using an identical CSS selector. But if the functionality is the same and the style is very different I could see this leading to either code duplication or some odd CSS trickery.
If this turns out to be an issue, you could assign an extra element class to be used by concrete which wont be styled, almost like giving it a type. Adding in that layer of indirection lets you change your elements structure, if necessary.
@jadet – I’m not seeing the increase in speed you describe with NWMatcher over Sizzle. From the Slickspeed test that the NWMatcher provides I don’t see much difference, on Firefox Sizzle loses by a small factor and on Chrome it wins by a small factor. When the difference is less 10 ms then I don’t see the difference.
Of course, those kinds of tests only mean so much considering your computer, the browser and apparently the server you use is a huge part of the outcome.
Yeah, for many plugins this may be overkill – it’s up to you do decide if the extra features are worth the size increase. Concrete was developed while working on a complex webapp, and that’s the space where I see it’s advantages carrying most weight.
It should be noted that the speed gains are because I’m focusing solely on optimizing for Concrete’s use case – Selector is designed to augment Sizzle, not replace it.
As ratbeard said, the onclick attributes in the tutorial are there for clarity, not best practice. In real code you’d use Concrete’s unobtrusive onclick handling.
I guess you might run into situations where code reuse is hard, but we haven’t come across them yet. As ratbeard suggests you can use a descriptive class (‘.accordian’ is used in the tutorial). If you don’t like descriptive classes, I can think of a couple of other ways to reuse code, although this isn’t really the right place to discuss them. Open up a discussion on the google group if you’d like to talk about it more.
I believe there are only domQuery (extjs), which partly uses this technique.
Also, I think it would have been better to create a special attribute, type ‘jscss’ with the same syntax that attribute ‘class’, but who reference the functions name, which itself, incorporate selectors with an property.
Should reconsider things for use, but the essential is there and is very promising.
@travisalmand: Don’t trust slickspeed. Here you can see the operations per second of NWMatcher compared to various others. As you can see it’s way ahead of Sizzle. Every framework could benefit from it. http://dl.getdropbox.com/u/513327/nwmatcher_match_performance.png.
@travisalmand @Jadet here are some live benchmarks of NWMatcher (http://github.com/dperini/nwmatcher) to play with. You can see it is several times faster than most.
.
.
I’m a bit hesitant to link functions to DOM elements: with a javascript template engine this may not be that useful if I understand the concept right – though I _do_ like the idea and feels much cleaner than plain js object here and there.
Makes sense from an CSS/HTML perspective, this is what you want in HTML centric development, so it definatly has a niche. jQuery programmers can (or should) use this in large scale projects with lots and lots of UI DHTML.
However, for application driven development, this is “swing and miss”. In application driven development I want objects that drive HTML, not HTML that drives itself. This also creates NON reusable code, as your js will be fixed to the DOM of the current project.
See this as it is, as a tool (like jQuery) to modify and structure code for DOM behaviour alone. Do not see this as a framework for general code structuring and/or architecturing. There are other frameworks for that, this one just fills a niche.
All said and done, I find this a quite smart implementation of inheritance to DOM behaviour and keeping that beast contained in it’s own environment. Although, it does have area’s which cause more confusion then clarity and this requires an extensive API documentation.
Does this project relate at all to http://github.com/nkallen/effen ?
How does jquery.concrete deal with state? Does it encourage attaching data to DOM elements?
Actually, I tend to distrust arbitrary benchmarks of all types, I’ve learned that from the video game/video card industry. The thing is, every time someone does produce a benchmark someone else tosses out another one to denounce the first one. I really distrust benchmarks suggested by someone who supports a project when testing that project, especially if that benchmark shows it at a huge lead.
But again, with Javascript, the results of any benchmark is heavily tied to variables outside of the framework being tested. Therefore they can only be guides and not definitive.
Plus, if NWMatcher is meant to supplement existing frameworks then it is irrelevant how it performs “against” those very same frameworks. Especially since its speed gains come from a heavily defined set of circumstances it deals with as opposed to the wide range that most frameworks have to deal with.
But hey, it adds to the development community, therefore excellent!
NWMatcher was offtopic and has nothing to do with op.
NWMatcher is actually a(nother) css query engine.
The Selector of concrete IS the supplement to jQuery Sizzle.
Just for the curious, here’s my css3 selector.
It is the fastest and lightest ever created.
You must be logged in to post a comment.
In Episode 25, we chat about IE 8, standards, Acid3, server side JavaScript, and more.
Powered by WordPress.
Entries feed. Valid XHTML and CSS.
