Monday, October 19th, 2009

jQuery Concrete; ConcreteUI programming in jQuery

Category: JavaScript, jQuery

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.

Hamish told us:

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.

Compared to jQuery.plugins and jQuery.UI widgets, Concrete provides:

  • code clarity – the code structure leads to more readable code
  • extensibility – specificity based method selection allows the injection of logic almost anywhere without monkey patching
  • greater organisational capabilities – syntax promotes modularity
  • reduced name clashes – powerful refactoring-free namespacing eliminates name pollution

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.

A taste:


  1. $('div').concrete({
  2.     highlight: function(){
  3.         this.effect('bounce');
  4.     }
  5. });
  7. $('div.important').concrete({
  8.     highlight: function(){
  9.         this._super();
  10.         this.animate({background: 'white'});
  11.     }
  12. });
  14. $('#namediv').highlight();

In addition to the source, a tutorial and a screencast are available to help introduce the new concepts.

Posted by Dion Almaer at 6:47 am

2.4 rating from 73 votes


Comments feed TrackBack URI

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.

Comment by travisalmand — October 19, 2009

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.

Comment by Jadet — October 19, 2009

I thought it might be a step backwards with the use of onclick attributes 0_0 .

Comment by AWebDev — October 19, 2009

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.

Comment by BCrescimanno — October 19, 2009

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.

Comment by ratbeard — October 19, 2009

@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.

Comment by travisalmand — October 19, 2009


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.

As for performance numbers, there’s the speed test file in the selector source repo. I’ve just made it available without checking out the code here:

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.

Comment by hafriedlander — October 19, 2009

Sorry for my English, I’m French …

Great idea! The speed of testing a selector on an element is very important in your API, and jquery.selector.matches code is excellent, the compilation is probably the best method for a CSS selector. currently
I believe there are only domQuery (extjs), which partly uses this technique.

Viva cascading script sheets !!! ;o)

The contextual element of all selector test is document, but in the css, a class can be assigned to an element, which would reduce the execution time of the test …

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.


Comment by Kimoja — October 19, 2009

@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.

Comment by Jadet — October 19, 2009

@travisalmand @Jadet here are some live benchmarks of NWMatcher ( to play with. You can see it is several times faster than most.
SlickSpeed (tests select() methods):
JSLitmus (tests match() methods):

Comment by jdalton — October 20, 2009

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.

Comment by deadcabbit — October 20, 2009

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.

Comment by BenGerrissen — October 20, 2009

Does this project relate at all to ?

How does jquery.concrete deal with state? Does it encourage attaching data to DOM elements?

Comment by hallettj — October 20, 2009

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!

Comment by travisalmand — October 21, 2009

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.

Comment by BenGerrissen — October 21, 2009

Just for the curious, here’s my css3 selector.

It is the fastest and lightest ever created.

He has yet to be tested, and it may lack some selectors …

Comment by Kimoja — October 21, 2009

For a great video of concrete watch

Very good ;)

Comment by elijahmanor — October 28, 2009

Leave a comment

You must be logged in to post a comment.