I wonder why they choose not to use native input element for a checkbox. Was it for a consistent visual theme?
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.
Agreed. This seems great, but ditching standard form elements for a bunch of divs and spans generally ends up an accessibility nightmare.
Backbone.UI.Button = an anchor tag with a span inside rather than a button tag.
Backbone.UI.Checkbox = an anchor containing some divs rather than an input[type=checkbox].
Radio group and Pulldown give similar output.
For me this is a 100% deal breaker. I can understand the desire to dress up checkboxes which doesn't work great as native controls but a lot should be doable just by wrapping it in some custom stuff.
Without form elements it has not compatibility with existing solutions, you can't use this to add some interactive components to an existing form and expect to native-submit that form.
I remember that when Backbone came on the scene, not having to use native elements was a selling point. If you wanted to use native elements you could. But you'd end up having to put `event.preventDefault();` in every one of your event handlers.
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.
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
It's been on my todo list for a while now to remove the JQuery dependency from Backbone UI, since we're now only using it mainly for event handling and positioning.
JQuery was an obvious choice when this project was born over a year ago. I've since formalized my preferred method of DOM generation into the Laconic library, but have yet to do the same for the last bits of JQuery still being used.
Of course, the problem with jQuery is that you're required to use an all-or-none approach. Feel free to send me an e-mail (check my profile) if you have DOM questions.
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.
Then we turn around and use that framework to clumsily tie back together presentation and logic. Wonderful.
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 require another, near 10,000 LOC, library is asking a lot. JQuery should be for end developers only.
Instead write your libraries to HTML standards, and provide links to polyfills that they'll need. Don't assume everyone is targeting IE6.
Agreed - laconic is a tough sell for me but I can get over that. However having JQuery required as well!? Too heavy now for any mobile web apps I'd planned.
I think the point is there may come the times when there two frameworks that depends on different version of dependencies. It could be the Backbone-UI and something else.
It would be okay if the consumer code is dependent on all the libraries. But if one of your framework is dependent on certain version of library and another one depends on another version of the said library, that is disaster waiting to happen. It would be hard to upgrade one framework , hence making it hard to move forward since your code is all tangled to all the frameworks.
Good to hear folks are interested in such combination. Currently working on such implementation currently dubbed backstrap. Might release it sometimes soon.
That's also good to hear. Now I don't need to implement it. That was my first reaction to seeing Backbone UI. I look forward to seeing what you come up with.
Component-izing Backbone views is a fantastic idea, and something I'm doing pretty frequently with Planscope.
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.
However, by using Backbone views to wrap logic, componentInstance.hide() or whatever else is doable, and IMO a lot more elegant. Nice work!
We've started to see a lot of component-izing Backbone, and more will come for sure.
I'm dabbling with some of the same in our codebase, and we were meant to release a grid component that I now fear has grown too big and hairy.
Not so sure on the idea of breaking it up this far; Buttons and checkboxes are single html-elements, so if you follow this approach fully you get a lot of views for a complex app — that'll be a performance issue.
This is just a little bit towards the direction I am going with my project. https://github.com/ithkuil/cureblog
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). https://vimeo.com/43784316
It looks pretty nice and it works well enough for static pages.
But if you're generating the UI from JavaScript, it really doesn't cooperate.
It also has various performance problems, especially on Android (since its authors appear to prefer iOS). It creating tons of DOM elements doesn't help either.
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.
Is this normal? Can anyone comment on this, please? How would one go about dressing this up?
CSS3 is very powerful these days and you can do amazing things without resorting to graphics.
Where you absolutely cannot avoid a graphic (like having an icon or something), the use of pictographic fonts is becoming increasingly popular. Mostly due to reasons of scalability to different resolutions on different devices.
Also, if you're unfamiliar with CSS generally, the 'conventional' approach (as opposed to img tags in markup, or characters in an icon font) would be to use a sprite. This is also advantageous from a frontend performance standpoint as you avoid additional network overhead in getting individual graphics down to the client.
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??)
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.
Client side templates are a hack, presently speaking. They are inserted into a script tag in the head (usually), so if you are working a single page app you need to include every template for your entire site in the head of the document. It works, but man is it ugly.
Then you have to include some bulky library that parses these scripts and compiles them to a function that you'll use later. All this happens pretty fast, but not any faster than just using the DOM apis.
I can't find the link, but I believe there is a proposal to standardize client side templating, so hopefully that will make the process a bit cleaner.
Something like this may unclutter the situation, just use xmlhttprequest to get the templates on demand:
//synchronous
body.innerHTML = render('blog.html',data)
//asynchronous
render('blog.html',data,body)
render=function(url,data,obj){
if url in cache: use cache
var http = xmlhttprequest()
http.get(url,obj?async:sync)
http.onready:
parse data in html
if obj: obj.innerHTML = html
else: return html
}
I like that, except that templates are used on demand, so onload would be useless. A better way would be to put an id on them and defer their load for when really needed.
But still, we don't want to load 50 templates at the same time if the app is big then use one or two in that session, that's why loading them on demand with httprequest might be a better solution.
*Besides, being static in nature they would be cached on the server and client for instant access.
Ideally you would preprocess your assets server-side (e.g Jammit), so templates end up being just another script to load.
This is still ugly, in that debugging templates is an impossible pain the arse because there's no useful line information. On the plus side they're much easier to read than a chain of DOM manipulations.
It's arguable whether this is "better". I usually have to interact with the DOM programmatically anyway (attaching events, for example), so why not build the DOM in javascript as well?
I use eco templates (CoffeeScript in HTML) that do not need a library to be interpreted once they are preprocessed server side. You minify them and save them as a variable in your source. No clutter, works nicely.
I realize that templates are a popular choice for many, but I view them as an unneccesary layer of indirection. Sort of like printing out an email, hand writing a response, and scanning it back in as a reply. Once your markup has been converted to a document object model, why not embrace it?
I think it's kind of like the difference between writing in assembly and C.
Using a bunch of calls to appendChild() and setAttribute() results in code that is difficult to read, because it's so low-level. You can't "see" the generated HTML, just like in assembly you can't really "see" the code structure.
Whereas using templates lets you "see" your HTML, with an easy-to-understand structure. So it's the natural, default choice for ease-of-use and maintenance.
I really like this style of templating, it's pretty close to how Seaside generates it's HTML, but more direct since it manipulates the dom directly. Also using the DOM directly is very fast.
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.