It does appear to have a React-like engine here: https://github.com/somebee/imba/blob/master/src/imba/dom.sta..., but from a quick glance, I can't tell if the quality of the engine is any good (e.g. whether it supports lifecycle methods, efficient sorts, jQuery plugins, etc) because there are no docs and I don't really have time to read the whole codebase right now. Same goes for the speed claim: can't tell if it's actual speed or "cheating" by batching multiple redraws on rAF while not batching them in the React demo. I'm guessing the latter.
Also, I'm not sure I agree with claim of readable output js: http://somebee.github.io/todomvc-render-benchmark/todomvc/im... (look at tag.prototype.render). It's not exactly clean, although it's not terrible either.
With that being said, the language does look like it has some improvements over Coffeescript. The lack of docs is a showstopper for me, however.
That's a fair criticism. We know that docs are severely lacking. But at one point you'll have to release it. The reason it's been private for all these years is because there's always been just one more thing to fix.
And this is just an open-source project. We just think this is a cool technology and want to share it with the rest of the community.
> Same goes for the speed claim: can't tell if it's actual speed or "cheating" by batching multiple redraws on rAF and while not batching them in the React demo. I'm guessing the latter.
Hah, we talked about this before the release. We actually thought about publishing worse results (or adding some code to slow it down) because we were afraid people wouldn't believe it.
requestAnimationFrame isn't used in this demo. The repaint/redraw is not the thing we are trying to benchmark. We might as well hide the whole app during the benchmark, or even detach it from the document. It is trying to measure the performance of bringing the whole view "in sync". If there is something wrong with the way Mithril is forced to render, please file an issue.
> lifecycle methods, efficient sorts, jQuery plugins
There's probably some more lifecycle methods that could be useful, but the amount of lines written in Imba is in the magnitude of 100k. The current approach has been adequate for that.
The sorting is quite efficient. We find the minimal amount of nodes that needs to be reordered. jQuery plugins should work fine as long as they don't touch the parents too much; Imba is quite good at keeping the DOM-node in the tree.
> requestAnimationFrame isn't used in this demo
Interesting. Gonna look into the project more when I get a chance then.
jQuery plugins, from my own experience, are quite naughty. Modals, tooltips and drag-n-drop things are examples of things naive people might try to throw at the system and wonder why things get wonky.
You are absolutely right, and I agree. When you use static tag trees in Imba (with inline caching) the code is not readable. If you only use it for regular things you would write in js (classes, functions, etc) I still think it is quite readable.
BTW, I really love the simplicity of Mithril. It is a very impressive project.
Yeah, for non-tag stuff, the output does look clean. I mentioned this for tags because I didn't see source maps. Transpiled code needs to either output source maps or it needs to be reasonably traceable-by-hand back to the source of a bug (say, in the case a null ref exception)
I just commented below after looking over their benchmark. In it, the Imba implementation, and it alone, is caching and reusing the rendered todo views (globally, forever -- hello memory leak). Without that, they're only 2x faster than React and Mithril, not 60x.
rAF batching isn't an issue. They perform a render(true) after each change, effectively making all frameworks work synchronously.
Other than that, it is an interesting framework, and I wish them well.
I'm really glad to hear that it is still faster even when removing caching. That, to me, is quite insane. But if you wrote a TodoMVC app in Imba, you would do it _exactly_ like the one that is benchmarked. We have even considered adding asserts to warn users if they use uncached nodes in rendering that happens very frequently.
You are actually right that Imba does not dereference these automatically (see other comment re purging by judofyr: https://news.ycombinator.com/item?id=10092454). We could dereference unused tags once every second or so, but for now we think it is better to have manual control of this. Again, how much is usually happening during a render-cycle? Basically nothing. This benchmark is trying to look at how expensive it is to rerender the whole view. Maybe I should make the "Unchanged render" benchmark the main attraction (as it is the most important) -- but it is quite boring to look at.
You build UI components like this:
tag event < div
def render
<self>
<h1> event.title
<p> "Happening on {event.dateString}"1. how much of the speedup is due to replacing JSX, and how much due to replacing the diffing algorithm.
2. how do you improve on the diffing speed, is it due to immutable data structures underneath, or something?
3. do you also provide mount/unmount hooks for the components?
http://imba.io/#/examples/todomvc/app.imba (this annotated app is illuminating, and ought to be put upfront on your site if possible)
The methods are clean and readable:
tag #app
def dirty
persist
render
def add title
if title.trim
TodoList.push(TodoItem.new(title.trim))
dirty
self
def render
var all = TodoList
var active = all.filter do |todo| !todo.completed
var done = all.filter do |todo| todo.completed
var items = {'#/completed': done, '#/active': active}[hash] or all
<self>
<header.header>
<h1> "todos"
<new-todo-input.new-todo type='text' placeholder='What needs to be done?'>
if all:length > 0
<section.main>
<input.toggle-all type='checkbox' :change='toggleAll'>
<ul.todo-list>
for todo in items
<li[todo]@{todo.id} .completed=(todo.completed) .editing=(todo.editing) >
<div.view>
<label :dblclick=['edit',todo]> todo.title
<input.toggle type='checkbox' :change=['toggle',todo] checked=(todo.completed)>
<button.destroy :tap=['drop',todo]>
<edit-todo[todo].edit type='text'>
($$(.todoapp) or $$(body)).append #app
edit: @judofyr, the Scroller example app doesn't work for me on Firefox 40.0.2 on Win 8. It works in Chrome.
- the appropriate method is called [e.g. add]
- which mutates the state [e.g. TodoList.push(TodoItem.new(title.trim))]
- and then render is called, which updates the view/DOM
So in a sense it's not really data-binding, IMO - instead, the render method contains the entire view + view logic, and it gets called each time the state is changed.
Read what I wrote again.
You just wrote a template. That's like JSX.
You ALSO need a library to do the virtaul dom stuff and/or data binding to write an application.
React. !=. JSX.
What you have here is a programming language that compiles to javascript and has an inbuilt templating language. So does ES6; `${hi}`.
That's a fundamental building block, not a replacement for a high level framework, like react.
You say:
>You ALSO need a library to do the virtaul dom stuff and/or data binding to write an application.
OP says:
>Imba includes syntax for tags (scroll down to "Tags"), virtual DOM diffing, event handling (with touch support).
>Although Imba was started before React it should be noted that it didn't include virtual diffing until React showed that it worked.
If he was unsure about what he saw in those examples, then he could always refrain from pissing on the project until he had more information.
Still... I suppose that my original post remains the top here says something. Cant reedit something with no parent. too bad. ;)
Perhaps you haven't looked at the examples.
>React is a template library, not a language.
Irrelevant -- and it's not such a clear cut distinction as you make it anyway.
A new language can have built in first class support for react like templating -- and this does.
>People aren't using react and angular because they have a nice syntax, that's just nice, they use them because you can build applications with them.
Yeah, so the idea behind imba is that if you could do the same things WITH a nice syntax and first class support it would be better.
Seriously do people read TFA?
That's not to say I wouldn't be interested in reading about a language that could somehow compete with Vim, if that was an accurate statement.
React is a template library, not a language.
JSX is a way to write templates, but that's not react, and its not what react does. It's just a shortcut to writing XML.
You could say this is a competitor to JSX, perhaps; but anything more is hyperbole.
People aren't using react and angular because they have a nice syntax, that's just nice, they use them because you can build applications with them.
How do you build ui components using imba? Use react? :P