Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Imba – A new programming language for the web

imba.io

Post reply on HN
Print view View original

151–160 of 180 posts

Re: Imba – A new programming language for the web

#151

Post by javajosh »

sindreaa wrote: post #147
javajosh wrote: post #112

Okay, so I just took Imba for a little spin. Some thoughts: I like the way it looks. A lot. Love, love the tags. Really like the simplified object literals. The use of global variables for class state is deeply troubling - they are not scoped at all. The parser is far too forgiving. if you change do |x| x x into something like do x x x it will compile fine, but be wrong. The tooling is quite nice, and I like the defa…

Thanks for the feedback. What do you mean with global variables for class state? We do consider moving class-bodies inside an actual function (again) - but there is a virtual scope there in the compiler. So class A var i = 10 var i = 20 Compiles to function A(){ }; var i1 = 10; var i = 20; So they are actually scoped even though it does not look like it in the compiled js. I'm looking really forward to improving the…

Ah, okay, well that example makes it clearer. It wasn't clear from your example (or from my local test) where you just show this:

   class Todo
	# variable defined in class scope
	var count = 0
Which compiles into this:

   var count = 0;
And also your example page elides the IIFE that your compiler surrounds all output with, implying (falsely) that it's global.

As for ST, I think that for me based on my brief experience, you might want to add more compiler warnings to the watcher. (Basically I messed with Imba locally with two ST windows side-by-side, looking at Imba on the left and js on the right, treating the watcher output as compiler output.) Don't get me wrong, ST feedback is great, but the watcher feels more canonical. Besides, not everyone has ST!

Re: Imba – A new programming language for the web

#152

Post by shadowmint »

mintplant wrote: post #149
chc wrote: post #124

Earlier quoted context omitted.

judofyr's comment that you're quoting was posted after shadowmint's.

The second quote, maybe, but the first comes directly from the comment shadowmint is responding to here.

Its great how you can edit comments isn't it? Both quotes were edited.

Still... I suppose that my original post remains the top here says something. Cant reedit something with no parent. too bad. ;)

Re: Imba – A new programming language for the web

#153

Post by girvo »

chc wrote: post #124
mintplant wrote: post #84

Earlier quoted context omitted.

I can only conclude that you're so focused on aggressively dismissing this person's work, in the typical HN fashion, that you didn't actually read the comment you responded to, or any of their other responses throughout this thread. 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 dif…

judofyr's comment that you're quoting was posted after shadowmint's.

Sure, but it's in the damned article.

Re: Imba – A new programming language for the web

#154

Post by curveship »

I just spent an hour looking at the Imba benchmark. Yep, it's cheating. Which is a shame, because I really like the framework as a whole.

The vast majority of the speedup comes from a single sneaky line of code. The majority of their "Everything" benchmark's time is spent in the reorder step. They've implemented this as "remove a random todo, render, push the removed todo back onto the end, render." The Imba implementation, and it alone, caches the rendered todo view, so that they can re-use it once the todo is reinserted.

This single optimization is responsible for the vast bulk of their claimed speed. Removing it puts Imba only 2x faster than React, not 60x.

If you want to try it yourself, look at line 55 of app.js. Change:

    res.push((this['_' + todo.id] = this['_' + todo.id] || t$('todo')).setObject(todo).end());
... to:

    res.push(t$('todo').setObject(todo).end());
Furthermore, this isn't a caching strategy you'd want to use in a real app. It holds onto all DOM nodes ever created, thereby leaking quite a lot of memory.

Again, I think Imba is cool, and fast, just not otherworldly fast. I hope this was just an "oops!" and not an intentional misrepresentation.

Re: Imba – A new programming language for the web

#155

Post by curveship »

lhorie wrote: post #58
shadowmint wrote: post #24

This isn't a competitor to react; its a competitor to ES6/typescript/coffeescript. 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 nic…

Mithril author here. 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"

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.

Re: Imba – A new programming language for the web

#156

Post by mbrock »

nawitus wrote: post #137
simplify wrote: post #101

Earlier quoted context omitted.

Re implicit calling: what would you write if you wanted to access `foo.bar` as a function instead of calling it?

I'm also wondering this. It looks like a huge design error.

foo:bar is property access.

Re: Imba – A new programming language for the web

#157

Post by davelnewton »

pluma wrote: post #130
techpeace wrote: post #104

Earlier quoted context omitted.

Here's a quick (incomplete) list of web innovations you can thank the Ruby community for either popularizing or inventing outright: * REST * Many parts of ES.next * Front-end build tools * CSS pre-compilation * JS transpilation I spent years happily using multi-line template strings while JS developers informed me how idiotic I was for using a transpiler. Since Ruby's goal is to be a language that brings joy to the u…

> REST No. Rails populated a form of REST and everybody likes to pretend everything Rails is REST and there are a ton of frameworks trying to imitate Rails' approach to REST but Rails neither invented REST nor was it the one thing making REST popular. It was a major factor, yes, but claiming this purely as an accomplishment of Ruby is silly. I would be willing to give Ruby the point for MVC because of ActiveRecord bu…

> I would be willing to give Ruby the point for MVC [...]

I wouldn't.

Re: Imba – A new programming language for the web

#158

Post by sindreaa »

curveship wrote: post #154

I just spent an hour looking at the Imba benchmark. Yep, it's cheating. Which is a shame, because I really like the framework as a whole. The vast majority of the speedup comes from a single sneaky line of code. The majority of their "Everything" benchmark's time is spent in the reorder step. They've implemented this as "remove a random todo, render, push the removed todo back onto the end, render." The Imba implemen…

Hi there.

This is utterly wrong, and if you had cared to read about what the benchmark is trying to achieve, you would understand (https://github.com/somebee/todomvc-render-benchmark).

You cannot simply remove caching and reusing nodes from the benchmark (which you do with that change). This is the way Imba does diffing, and it would be akin to removing the React virtual dom!

As we mention in the readme: "Even though it looks incredibly boring, the "Unchanged Render" is possibly the most interesting benchmark. All of these frameworks are plenty fast if they only render whenever something has changed. But if the frameworks are fast enough to render the whole app in 0.01ms, you could skip thinking about all sorts of tracking to keep the view in sync."

In a real world app you do not create 1000000 todos. The actual data rarely change that much. As for purging the cache, see comment: https://news.ycombinator.com/item?id=10092454. Quote:

One thing to be aware of is that Imba doesn't automatically remove the cache for you, because we've found that it's tricky to determine when you actually want to purge it. For instance: if mouseOver else Just because `mouseOver` becomes true for one frame doesn't mean you want the ``-tag to be purged from the cached and removed. Keeping it around is nice for performance and convenience (e.g. state, jQuery plugins). In practice it turns out you want to purge whole pages/sections at the same time, which is way friendlier for the garbage collector as well.

If you _really_ want to not cache things this way, you can change the line to:

    res.push((this['_' + i] = this['_' + i] || t$('todo')).se ...
Which would only ever cache as many dom nodes as there are tasks, but change which nodes are used for which tasks.

Re: Imba – A new programming language for the web

#159

Post by [deleted] »

curveship wrote: post #155
lhorie wrote: post #58

Earlier quoted context omitted.

Mithril author here. 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" 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 framework…

[deleted]

Re: Imba – A new programming language for the web

#160

Post by sindreaa »

curveship wrote: post #155
lhorie wrote: post #58

Earlier quoted context omitted.

Mithril author here. 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" 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 framework…

See comment: 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). 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.

Post reply on HN