
Backbone UI - liangzan
http://perka.github.com/backbone-ui/
======
ajitk
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.

~~~
burriko
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.

~~~
Nervetattoo
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.

------
creamyhorror
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

------
mkmcdonald
> 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?

~~~
joestelmach
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.

~~~
mkmcdonald
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.

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

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

~~~
mkmcdonald
[from the link]

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

That's a disaster waiting to happen.

~~~
joestelmach
care to elaborate?

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

~~~
datapimp
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.

~~~
fadzlan
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.

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

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

JQuery+Backbone+TwitterBootstrap = Fun+Joy.

~~~
_pdeschen
Good to hear folks are interested in such combination. Currently working on
such implementation currently dubbed backstrap. Might release it sometimes
soon.

~~~
collypops
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.

------
bdunn
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!

~~~
Nervetattoo
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.

------
ilaksh
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>

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

~~~
bitdiffusion
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?

~~~
lucian1900
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.

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

~~~
lucian1900
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.

------
pestaa
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!

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

~~~
charliemagee
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.

------
shaunxcode
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'

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

------
mcginleyr1
Much cleaner then Google Closure IMHO.

~~~
rbanffy
Google Closure goes way beyond this.

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

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

~~~
MatthewPhillips
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.

~~~
Kilimanjaro
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
        }

~~~
MatthewPhillips
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()" />

~~~
Kilimanjaro
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.

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

Use like thus:

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

~~~
Kilimanjaro
Beautiful!

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

~~~
joestelmach
Thanks! <https://github.com/perka/backbone-ui/issues/9>

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

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

