Ripple.js – A tiny foundation for building reactive views (ripplejs.github.io)
A tiny foundation for building reactive views with plugins. It aims to have a similar API to Reactive, but allow composition of views, like React.
The major difference with other view libraries is that there are no globals used at all in ripple. Each view has it's own set of bindings and plugins. This makes composition of views really easy.
Views that are created with ripple can be composed within other views and reused. Data flows in a single direction and is kept in sync automatically.
27 comments
[ 3.1 ms ] story [ 49.9 ms ] threadIt still batches all changes using requestAnimationFrame and it'll support Object.observe when that's ready.
Web components seem much more promising for the very reason that we shouldn't have to reinvent an event bus when we already have an evented DOM.
Yep, you can nest views in a similar way to React. It's not exactly the same, but it's similar. Data is kept in sync and components are re-usable.
Communication between views is either through events, passing in callbacks, the dispatch plugin (uses custom DOM events and bubbling like Flight). There are a few ways to do it depending on the problem. Views have references to their children and the owner too.
One minor point: wish it were called something other than Ripple. There's already Ripple for p2p financial transactions.
related comment: https://news.ycombinator.com/item?id=7610465
edit: typofix + animation/transition handling
I have never heard of Reactive, React, or Ripple.
I don't understand how this is better than Knockout, which has been around since 2006?
To summarize your objection, this library hardwires events to the UI. I don't understand how that allows for composition, and even then, the composition is happening at the view level, rather than the model level, which seems like a mistake???
Sorry if I am naive or coming off as rude. I just don't get it.
In graphics programming, it is customary to have a Scene Graph which is a Model that represents the scene you need to Render.
In Desktop/Web programming for business apps, this design pattern/abstraction step seems completely absent, and developers seem to continuously mush together view and model.
What "composition" can't be achieved simply by having a Knockout Virtual Element, or Template Selector driven by a ViewModel property?
React, as well as this library, are pretty much exactly like this, except you replace OpenGL with the DOM. They are purely about managing UI state; they provide the controller (C) and view (V) parts of MVC, and leave the model (M) aspect to the developer to work out using some other library. For example, it's entirely feasible to combine React with Backbone models. Unlike traditional MVC, however, the responsibilities of the controller are generally handled by the view itself.
The composition that they are talking about is about treating components as first-class objects. For example, in React, you can do this (via JSX, a preprocessor for JavaScript that allows you to embed HTML in JS):
Here, Button is not a real HTML element, but another component which is embedded in the parent component. By expressing this as a pseudo-element, it's possible to treat it as a black box that knows how to render itself.It used to be, but it less likely with recent frameworks. I don't know Knockout. I read a little about it seems like some kind of HMVC but more like mMVC where m = mess.
Reactive can be used with KJS. KJS has observables, and the RP library will be plug to that.
Reactive Programming is about reacting to events, like bindings Model to View: if another user +fav this post, an updated will be pushed to all others and the new score will appear. You can also bind other behaviors to non-data "models" like xhr pool.