

Kibi.js: a client-side web framework in 1,024 bytes - jedschmidt
https://github.com/jed/kibi

======
asolove
It is both wonderful and terrible to see so many js frameworks. Wonderful that
js has taken off and is so easy to use that so many people can build useful
reusable components to share with the world. Terrible in that all of the
discussions I've seen comparing these frameworks center on "features" or
"size" instead of the important parts of day-to-day use.

For example, I often see Spine and Backbone compared, and Spine is said to
"use a Backbone-like API" but be "lighter." Now I've used both to build fairly
substantial apps, and I can tell you the day-to-day experience is very
different.

So let me give you an example of where the two APIs differ, in a way that a
naive inspection doesn't catch, and that I haven't seen publicly discussed
anywhere.

The biggest difference between them is managed attributes in the models.

Spine uses a Rails-like API, where you can change your model's attributes as
much as you like, by saying this.name = "whatever", but it's only when you
call this.save (or updateAttributes) that the change is "committed" in the
sense that a "change" event is sent to the controllers and other objects that
want to observe the model. And this event is very coarse, you just know the
object changed, not what about it changed.

In contrast, Backbone uses managed attributes, so you say person.set("name",
"Adam") and this immediately fires both a "change" and a "change:name" event.
So controllers can observe models in a much finer-grained way and respond to
only the changes they want. And there's no business about "saving" locally
just to fire changes in the UI, you just save when you actually want to store
the data (in local storage or on a server).

In my experience, the Backbone way is far preferable for building responsive
event-driven UIs. And note that the implementation of attributes is so short
it has nothing to do with Backbone being "bigger" than Spine. It's just a very
meaningful API difference no one ever talks about.

Maybe you disagree. Maybe you like another js framework for other meaningful
API differences. Let's discuss that carefully, rather than just making more
frameworks and labeling them.

~~~
hendler
Thoughtful and correct.

The ecosystem has exploded, and there may need to be an extinction event... or
not. JS is more open than other languages' frameworks. There are so many non-
public horrible and wonderful backend frameworks that just weren't part of
OSS/github social coding.

Also, simply lighter frameworks should exists if they take a week to create.
Calling them a "framework" might be an apples to oranges in some cases. (e.g.
YUI vs. Spine)

At worst it's exposed chaos that's always existed and hopefully a community
learning phase. Before jQuery and the like, how many "libraries" existed on
relatively equal footing?

------
bretthellman
Congrats on the framework. Quick tip... I don't see size being a selling point
these days. It's almost meaningless. It would be interesting to find something
new like how much time it saves compared to the status quo. Just an idea...

~~~
firefoxman1
To me the important part of being "lightweight" is memory consumption and
speed. The page performance is much more important than initial load time.

------
reedlaw
Underwhelmed by the demo app. Can anyone explain why this is good/useful?

~~~
hyperturtle
The whole app is contained in the source of <http://kibi.herokuapp.com/>

It looks like each page is defined inside a <script type='text/plain' data-
kibi='{pathname:'',id:'',location:''}'></script>

Where data-kibi is metadata to specify when, with what data(jsonp) the content
inside should be rendered?

