Ripple.js – A tiny foundation for building reactive views(ripplejs.github.io)
ripplejs.github.io
Ripple.js – A tiny foundation for building reactive views
http://ripplejs.github.io/
13 comments
Too bad there is no "complex" example at hand, for instance: how it would batch updates for data pushed by the server, while allowing for +fav and +subscriptions without leaving the door open for an absurd amount of open connections where responsiveness to direct user input is always the highest priority which must stay true if animations/transitions are happening.
related comment: https://news.ycombinator.com/item?id=7610465
edit: typofix + animation/transition handling
related comment: https://news.ycombinator.com/item?id=7610465
edit: typofix + animation/transition handling
Thanks for the objection.
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.
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.
Let me rephrase my objection once more.
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?
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?
Well, in your graphics programming example, the "scene graph" consists of UI objects. It doesn't consider of logical objects such as players, enemies and explosions; it consists of frames, meshes, textures, etc., all of which are part of the "view". The logical model (players, etc.) is used to populate the scene graph. The scene graph itself is used as the basis of the composition pipeline that uses something like OpenGL.
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):
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):
Toolbar = React.createClass({
render: function() {
return <div className='toolbar'>
<Button icon="save" label="Save document"/>
<Button icon="close" label="Close document"/>
</div>;
}
});
> developers seem to continuously mush together view and model.
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.
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.
First metalsmith and now this - I love your APIs. Definitely using it in a project sometime soon. I assume it doesn't have the same virtual DOM magic that React has?
Nope, no virtual DOM. I like that concept, but I wanted to keep it simple. I'd like to make a virtual DOM plugin but it's a non-trivial task.
It still batches all changes using requestAnimationFrame and it'll support Object.observe when that's ready.
It still batches all changes using requestAnimationFrame and it'll support Object.observe when that's ready.
Scumbag hamburger menu - links to github instead of showing / hiding unnecessary drawer ;0
The hamburger menu icon is definitely ill-fitting, since the primary association for that icon (and that placement) it has is "menus" and not "documentation".
What are you talking about?
Every time something comes from segment.io my interest level goes up. This looks worthy of checking out too.
Clear and concise documentation explaining everything on a couple pages, which impresses me more than flashy interactive tutorials.
Simple architecture that won't create an unmanageable black-magic mess on the global background and crash with other libraries, even the source code looks so neat and clean. I will be using this soon!.
Looks really intriguing. The other libraries are so full-featured that they're confusing to use. I'll have to play with this.
One minor point: wish it were called something other than Ripple. There's already Ripple for p2p financial transactions.
One minor point: wish it were called something other than Ripple. There's already Ripple for p2p financial transactions.
What other libraries? J/w.
Am I missing something, or is the example in the README installing plugins uselessly?
.use(events)
.use(each)
.use(dispatch);
What about nesting views? And communication between views?
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.
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.
https://github.com/ripplejs/ripple/tree/master/docs/composin...
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.
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.
How well does it handle css properties like size and position being templated?
This could be a really nice replacement of Backbone.View.
Its ripple.min.js is 30kb. Not so tiny is it?
gzips down to 8kb though, and that's the standalone version. Using it with component it will usually share dependencies with other components.
Sorry, I can confirm it is 8kb gzipped, and it is acceptable. I may seemed over reacting to this because I am a developer who spent last month optimizing web pages by reducing js size :)
But don't apologize too much, because now you have "a thing": efficient js. You can make a lot of well-deserved money with a thing like that, so long as you cultivate your mastery of it over time.
[deleted]
Is it just me or is this just a poor re-implemntation of half of knockout.js?
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.