Backbone UI | Hacker News Reader

Backbone UI

perka.github.com

270 pointsliangzan65 comments

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.

If you want styled / styleable UI controls which have full accessibility (as a requirement), check out Dijit.

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.

Go right ahead and test it out at:

http://angular-ui.github.com/

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.

And yet three separate libraries with DOM abstractions are required.

Why should I trust your opinion of the DOM if you require so much third-party code?

That's a great point.

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.

Why not Zepto? It's like jQuery without the weight.

You should just use addEventListener. It's supported by every browser for a while now and is really easy to shim for those targeting IE6-8.

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.

jQuery dependency is also a problem for me - I dropped jQuery and use Zepto instead for a mobile app I'm writing.

[from the link]

> Backbone UI depends on Backbone, Underscore, jQuery, and laconic.

That's a disaster waiting to happen.

care to elaborate?

Requiring four separate APIs is a client-side dependency nightmare; requiring around 15k lines of uncompressed code is a disaster waiting to happen.

Well, it is a disaster that has been waiting for a while now. Several large production apps on that stack, and not really any problems.

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.

Still working through it; a pleasant collection of UI components that, as they say, will be useful to some.

But what stands out is the quality of documentation. Very impressive and clear.

Nice, I wish one will do the same with twitter-bootstrap.

JQuery+Backbone+TwitterBootstrap = Fun+Joy.

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.

Check out luca: http://Github.com/datapimp/luca

Sandbox: http://datapimp.github.com/luca

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

Looks very nice. I'm going to see how it does on mobiles.

I'm just now looking into alternatives to the dreadful jQuery Mobile for a Backbone-based app.

I was looking at jquery mobile and it didn't look too bad - would you mind giving a summary of what you didn't like about it?

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.

Have a closer look - this library was built solely for generating UI from JavaScript.

But it somehow manages to completely suck at it. Even if you trigger the 'refresh' events, you'll still run into trouble.

jQM appears built to generate lots of DOM with JavaScript from static HTML pages.

Loving it already.

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?

Again, thanks for the great work!

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.

Here's an example of a real product built using Backbone UI: https://getperka.com/signup/#account

The whole concept looks super-slick!

But . . . what is Perka and why should I create an account before I know what it is?

I had to go to the url, delete /signup etc. to find out. You might want to make your logo take you home.

here is my alternative to laconic:

    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'

I found it a little unnecessarily complex. Also the way events are handled, tight coupling between components is unavoidable.

Much cleaner then Google Closure IMHO.

Google Closure goes way beyond this.

It's reminding me of Angular. Can you say something about similarities/differences?

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.

Thanks for sharing your viewpoint.

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.

Well, one style is imperative, one is declarative. Some prefer the former, some the latter.

Myself, I much prefer imperative.

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.

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
    }

There are work arounds. What we really need is an HTML standard for including templates on a page. Can't we reuse the <link> tag for that?

  <link href="mytemplate.mustache" rel="template" type="text/mustache" onload="showSnippet()" />

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.

    <link hef='blog.html' rel='template' id='myblog' defer>

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.

I threw together this gist which does your suggestion: https://gist.github.com/2955953

Use like thus:

  var tmpl = document.getElementById('myblog').template;

Beautiful!

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.

When I paste text into a textarea or input fields using the mouse, your models don't update.

Thanks! https://github.com/perka/backbone-ui/issues/9

Wait, is this by the same people as Backbone? If not, then why is it cribbing the name?

Probably not, since it's not hosted at DocumentCloud.

No, this is not by the same people as Backbone. The name refers to the fact that all components are Backbone Views.

It's a Backbone plugin. It's name is accurate, just as any jQuery plugin should have "jQuery" in its name.

Reply on news.ycombinator.com