5 ms·

Mithril author here. It does appear to have a React-like engine here: https://github.com/somebee/imba/blob/master/src/imba/dom.static.imba https://github.com/s

by lhorie 11y ago

Mithril author here. It does appear to have a React-like engine here: https://github.com/somebee/imba/blob/master/src/imba/dom.static.imba 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/imba/js/app.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.

judofyr 11y ago
> 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.
- lhorie 11y ago
  Hi, just wanted to clarify I'm not trying to badmouth, just pointing some things that weren't clear to me (as someone who would be qualified to evaluate the quality of a React-like framework). Lack of docs aside, it does look like a nice project :) > 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.
curveship 11y ago
> can't tell if it's actual speed or "cheating" 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.
- deleted 11y ago
  [deleted]
- sindreaa 11y ago
  See comment: https://news.ycombinator.com/item?id=10095990 https://news.ycombinator.com/item?id=10095990. Thanks for taking the time to looking through the benchmark. I think you are misinterpreting things. Yes we do caching, and yes IF your app created a million tasks every second you would need to manually dereference them at some point. But you could change the caching (as mentioned in the comment) to never cache additional tags (instead of disabling all caching - which would be like going into the code of Mithril and React and remove all checks in the virtual dom). 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 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.
sindreaa 11y ago
> Also, I'm not sure I agree with claim of readable output js: http://somebee.github.io/todomvc-render-benchmark/todomvc/im.. 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. 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.
- lhorie 11y ago
  Thanks :) 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)

by lhorie 11y ago

judofyr 11y ago

> 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.

lhorie 11y ago
Hi, just wanted to clarify I'm not trying to badmouth, just pointing some things that weren't clear to me (as someone who would be qualified to evaluate the quality of a React-like framework). Lack of docs aside, it does look like a nice project :) > 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.

curveship 11y ago

> can't tell if it's actual speed or "cheating" 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.

deleted 11y ago
[deleted]
sindreaa 11y ago
See comment: https://news.ycombinator.com/item?id=10095990 https://news.ycombinator.com/item?id=10095990. Thanks for taking the time to looking through the benchmark. I think you are misinterpreting things. Yes we do caching, and yes IF your app created a million tasks every second you would need to manually dereference them at some point. But you could change the caching (as mentioned in the comment) to never cache additional tags (instead of disabling all caching - which would be like going into the code of Mithril and React and remove all checks in the virtual dom). 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 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.

sindreaa 11y ago

> Also, I'm not sure I agree with claim of readable output js: http://somebee.github.io/todomvc-render-benchmark/todomvc/im.. 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. 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.

lhorie 11y ago
Thanks :) 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)