These are chat archives for thejameskyle/backbone-ractive

21st
Jul 2014
Jamie
@jamiebuilds
Jul 21 2014 18:21
@ianmstew Created a room
Ian Stewart
@ianmstew
Jul 21 2014 18:22
Oh excellent
I can def see this taking off.
Jamie
@jamiebuilds
Jul 21 2014 18:39
Ractive is a rather large library though
Ian Stewart
@ianmstew
Jul 21 2014 18:39
How large?
Jamie
@jamiebuilds
Jul 21 2014 18:39
Backbone+Ractive (without jquery) is about 60kb min+gzip
Ian Stewart
@ianmstew
Jul 21 2014 18:39
:(
Jamie
@jamiebuilds
Jul 21 2014 18:40
granted Ember is 95kb min+gzip
Ian Stewart
@ianmstew
Jul 21 2014 18:40
I’m also thinking comparisions with Angular, Meteor, and React could be validating
Because they all do DOM-patching in various ways
Jamie
@jamiebuilds
Jul 21 2014 18:41
I’m probably not apt to make that comparison
It’s sad that most articles comparing these technologies are by idiots/people unaffiliated with any of them
Ian Stewart
@ianmstew
Jul 21 2014 18:42
What would make a Backbone plugin so powerful is that, as with all Backbone, you pick and choose your tradeoffs.
Yeah, those kind of articles are as entertaining and valuable as gossip magazines half the time.
So, I just zipped React’s production code down to 37K
Ian Stewart
@ianmstew
Jul 21 2014 18:47
Ractive is 49KB
James
@jamesplease
Jul 21 2014 18:47
lol damn
Ian Stewart
@ianmstew
Jul 21 2014 18:48
that was quick+dirty minify and zip
Jamie
@jamiebuilds
Jul 21 2014 18:48
yeah, you need backbone too
Ian Stewart
@ianmstew
Jul 21 2014 18:49
right… you’d need backbone for React as well. at least, they say, "Lots of people use React as the V in MVC"
BUT sounds like ractive doesn’t need the JSX pseudo-language
Jamie
@jamiebuilds
Jul 21 2014 18:51
Well you can also kinda use it for models too
Ian Stewart
@ianmstew
Jul 21 2014 18:51
Oh, interesting
Jamie
@jamiebuilds
Jul 21 2014 18:51
although it’s not enough for the majority of apps
Ian Stewart
@ianmstew
Jul 21 2014 18:51
Were you also messing around with Backbone + React recently?
Jamie
@jamiebuilds
Jul 21 2014 18:52
I was for awhile
Not a big fan of React
it’s interesting, and is an impressive feat of engineering, but it’s an oversolution to a problem that doesn’t exist for most people
Ian Stewart
@ianmstew
Jul 21 2014 18:53
I haven’t used it, but I sensed it would take a lot of buy-in.
Great summary
So, for comparison, Backbone.StickIt is 4KB min+gz.
It really all depends how often the DOM is updating and whether someone wants to write the binding code or not.
Jamie
@jamiebuilds
Jul 21 2014 18:55
well, I also love the templating syntax that ractive gives you
Ian Stewart
@ianmstew
Jul 21 2014 18:56
Me too, it’s based on semantic markup that I already love (Mustache)
And writing view code around natural view architecture rather than efficient DOM updates is worth something to me.
James
@jamesplease
Jul 21 2014 18:57
i contend that data binding is 95% gimmick
to get people excited when they do tutorials
Jamie
@jamiebuilds
Jul 21 2014 18:57
@jmeas agreed
However
Ian Stewart
@ianmstew
Jul 21 2014 18:58
:) I was just about to say that jmeas solves efficient dom updates by writing small enough views and calling reset()—completely within backbone.
Jamie
@jamiebuilds
Jul 21 2014 18:58
Ractive makes templating far more natural, and offers all the hooks you could possibly want
I have so many CollectionViews that are just iterators for ItemViews
James
@jamesplease
Jul 21 2014 18:59
well
if you’re not using ChildEvents i would argue you should be using ItemViews
and <% _.each() %>
or the loop in handlebars if you’re doin that
Jamie
@jamiebuilds
Jul 21 2014 19:01
yeah, but there are times where you still want the methods on ItemViews to be tied to the model and not the whole collection
I think when data-binding commands an entire ecosystem or an entirely new way of thinking that it’s shit, but when its interoperable with everything else it’s rather nice
I can mix Ractive in with anything else
Ian Stewart
@ianmstew
Jul 21 2014 19:03
Yeah, I don’t think it’s important enough to invent a whole new way of life around it.
But my main trouble is that I haven’t completely come to terms with double-rendering vs. no render until data is ready. Having a lib handle this magically and DOM-efficiently makes me feel good in theory. Granted, this is solving a logical issue in my head more than a perceivable end user experience issue in most cases.