I wonder why they choose not to use native input element for a checkbox. Was it for a consistent visual theme?<p>Using custom widgets instead of native often leads to usability issues. In this case, when the a checkbox gains focus, a SPACE BAR scrolls the page instead of toggling its state.
For those who are looking for this, but for a more opinionated, less-tabula-rasa framework, there's Angular-UI for AngularJS. (AngularJS provides more conveniences and a more defined framework than Backbone, having come later.) It's still in early development and has minimal documentation, but hopefully will grow into a nice set of widgets and wrappers for Angular users.<p>Go right ahead and test it out at:<p><a href="http://angular-ui.github.com/" rel="nofollow">http://angular-ui.github.com/</a><p>edit: there are also connectors for Angular-Sencha-Touch and Angular-jQuery-Mobile and an attempt at an Angular-Bootstrap connector...hopefully they'll all keep growing
> This framework is written to embrace the DOM rather than fight it.<p>And yet <i>three</i> separate libraries with DOM abstractions are required.<p>Why should I trust your opinion of the DOM if you require so much third-party code?
Just so we're clear, we got away from things like jQuery's approach to Javascript to get clumsy JS off of a DOM basis. We built a "back-front-end", as I lovingly refer to it, to keep objects more... well, object-y.<p>Then we turn around and use that framework to clumsily tie back together presentation and logic. Wonderful.<p>Templates aren't a hack. They are they method to create extensible objects in the presentation layer. Backbone UI users seems to be forgetting Backbone's original intent.
JQuery dependency is a deal-breaker for me. Telling library consumers that you <i>require</i> another, near 10,000 LOC, library is asking a lot. JQuery should be for end developers only.<p>Instead write your libraries to HTML standards, and provide links to polyfills that they'll need. Don't assume everyone is targeting IE6.
Still working through it; a pleasant collection of UI components that, as they say, will be useful to some.<p>But what stands out is the quality of documentation. Very impressive and clear.
Component-izing Backbone views is a fantastic idea, and something I'm doing pretty frequently with Planscope.<p>Your average jQuery plugin has you modifying state via invoking the plugin again on a selector with like a string argument that represents a function - this always felt clunky to me.<p>However, by using Backbone views to wrap logic, componentInstance.hide() or whatever else is doable, and IMO a lot more elegant. Nice work!
This is just a little bit towards the direction I am going with my project. <a href="https://github.com/ithkuil/cureblog" rel="nofollow">https://github.com/ithkuil/cureblog</a>
I also made a video of an earlier version (spent a day modernizing the UI a bit since then and I think it looks much better now, also improved a few other things but the basic concepts are the same). In case anyone is interested in extending this idea of components even farther than he is going in Backbone UI (for example to a Node.js backend). <a href="https://vimeo.com/43784316" rel="nofollow">https://vimeo.com/43784316</a>
Looks very nice. I'm going to see how it does on mobiles.<p>I'm <i>just</i> now looking into alternatives to the dreadful jQuery Mobile for a Backbone-based app.
Loving it already.<p>Fantastic JavaScript -- but styling mechanism leaves a lot to be desired. I understand beautiful graphics are not the scope of this work, however, the CSS-only approach might not be flexible enough for most designers.<p>Is this normal? Can anyone comment on this, please? How would one go about dressing this up?<p>Again, thanks for the great work!
here is my alternative to laconic:<p><pre><code> String.prototype.$tag = (args...) ->
args.unshift "<#{@toString()}/>"
$.apply window, args
("ul".$tag
class: "someUL"
html: "li".$tag
text: "some text in an li"
class: "some class"
click: ->
console.log "some click event").appendTo 'body'</code></pre>
I'm confused by their description of templates as "messy" and their decision to use laconic. Not an opinion that I think is widely held and definitely doesn't make sense to me. (by html templates do they specifically mean ejs/erb type templates versus jade/haml??)<p>Using html templates is good separation of concerns and js just isn't very good at expressing html structure. Jade would have been a much better choice IMO. Laconic does a good job of minimizing the problems with using js to programatically build dom in js but still doesn't come close to a proper templating language.