Kibi.js: a client-side web framework in 1,024 bytes

by jedschmidt • 15 years ago

45 7 15 years ago

asolove• 15 years ago

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• 15 years ago

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?

ez77• 15 years ago

This is very helpful comment. Have you considered writing articles/blog entries?

reedlaw• 15 years ago

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

hyperturtle• 15 years ago

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?

bretthellman• 15 years ago

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• 15 years ago

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

Kibi.js: a client-side web framework in 1,024 bytes

Related Stories