Comparison against Elm and Purescript?
Imba – A new programming language for the web
161–170 of 180 posts
Re: Imba – A new programming language for the web
#162I 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…
I now ran the benchmarks with the this['_' + i] change (which disables per-task caching, but does not really remove any/all caching alltogether. Imba is still 35x faster than react on the 'everything' benchmark (and even faster on the others). I still would write my apps exactly like they are in the original benchmark, but do you agree that the ['_' + i] change removes what you call 'sneaky code'?
UPDATE: Since the performance was just as good with this dumber type of caching I have changed the actual benchmark to work this way. Would you still consider that caching sneaky? If so, I'm not sure what to say. Yes, Imba caches dom nodes for reuse. That is the whole philosophy behind its 'virtual dom'. Now it does not 'leak memory' anymore either, even though this 'leak' is a feature (ref comment about manual pruning) and not a bug.
Re: Imba – A new programming language for the web
#163This 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…
> 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.
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.
Re: Imba – A new programming language for the web
#164I 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 thou…
I wonder how React with Immutable.js would fare in "Unchanged Render" benchmark.
Re: Imba – A new programming language for the web
#165Earlier quoted context omitted.
> The syntax was heavily influenced by Ruby, which then found its way into ES.next. I pointed out the major syntax additions of ES6 and to what extent they are based on Ruby or not. > You also seem to be discounting the obvious popularity of ES.next transpilers. I'm not. Babel and other "ES.next" transpilers are drastically different in spirit from CoffeeScript. With some exceptions (e.g. JSX and Flow type annotation…
> CoffeeScript doesn't work because it requires you to learn a new language on top of JS. The folks that have been quietly productive with CoffeeScript for years, and have and continue to make millions of dollars because of it, would likely disagree with you on that point. > Your point is that Ruby's role to all of the developments you mention is essential and unique. I'm arguing it's not. By far. > The only remarkab…
> other than your desire to spread the truth
I'm ranting. What ever gave you the idea either of us is talking about objective truths?
Re: Imba – A new programming language for the web
#166Earlier quoted context omitted.
WSDL/SOAP are not REST. I'm telling you that REST was popularized by Rails, because it was the first major web framework to use it. You've yet to refute that argument, but you do continue to be rude, so have a good one!
>WSDL/SOAP are not REST Well if you define REST as "Web Apps developed with RoR" then I guess you're right, Rails is definiteley the pioneer of Rails development. >You've yet to refute that argument There was (at least) Tomcat deployed and quite popular, and yep, everything moved through REST interfaces. Even with that one and the huge success it had in the enterprise world, I wouldn't dare to say that the success of…
The funny part is that technically Rails and Rails-inspired REST frameworks get it wrong. They're just exposing the server-side models via REST interface and the server-side models in turn expose the database's tables. That's REST by the books but not particularly useful unless all you're interested is exposing your database tables to the clients.
Automagic REST APIs may be easier to do with "RESTful" MVC frameworks but what you really want is a domain-oriented REST API. But I digress.
Re: Imba – A new programming language for the web
#167Earlier quoted context omitted.
Can't really comment re the language (the tags as part of the language is very nice, I agree), but it's been in development for 6 years and there are no docs? If it were just a Coffeescript fork & just basically a matter of syntax, then maybe fair enough (but LiveScript & CS both have relatively extensive docs), but this project has much grander claims (ie that it's also a high-level framework competitor) + a grand t…
Unfortunately we were too busy building actual applications. In total it probably sums up to a number in the magnitude of 100k LoC. EDIT: But yes: Docs are lacking, and that is a reason for you to not pick Imba for a project right not. We'd still think it would be worthwhile for you to checkout though. There's some interesting ideas in there.
I will do! I didn't mean to be too down on it, just slightly disgruntled when I tried to locate semi-detailed docs. Looking forward, and given you've been building real stuff in it, maybe worth writing up how you've used it, how how the features have been useful, how projects have been structured, how they fit into workflow etc.?
Re: Imba – A new programming language for the web
#168Earlier quoted context omitted.
>WSDL/SOAP are not REST Well if you define REST as "Web Apps developed with RoR" then I guess you're right, Rails is definiteley the pioneer of Rails development. >You've yet to refute that argument There was (at least) Tomcat deployed and quite popular, and yep, everything moved through REST interfaces. Even with that one and the huge success it had in the enterprise world, I wouldn't dare to say that the success of…
The funny part is that technically Rails and Rails-inspired REST frameworks get it wrong. They're just exposing the server-side models via REST interface and the server-side models in turn expose the database's tables. That's REST by the books but not particularly useful unless all you're interested is exposing your database tables to the clients. Automagic REST APIs may be easier to do with "RESTful" MVC frameworks…
Here's a handy test to determine if two technological terms mean the same thing: are they used interchangeably? If I said to someone, "oh that looks like you need a SOAPful interface," would they assume that I meant RESTful? Probably not, since they're two different technologies. The move to REST was actually inspired by the perceived deficiencies in WSDL and SOAP.
> The funny part is that technically Rails and Rails-inspired REST frameworks get it wrong.
Well, that's a bit tangential to my original point. I wasn't claiming that you specifically liked the way it was implemented, just that Rails, and thus the Ruby community, was responsible for its popularity. Despite the length of this thread, neither of you has managed to debunk that claim with anything resembling evidence.
Find a reference to Tomcat using REST before 2007, and give us the link. I'd bet you can't, since Rails was the first major web framework to implement REST.
> REST hit it big with the www, www is REST's killer app.
Since REST was invented in 2000, and the web itself had been around for a bit before that, I fail to see how this could be true.
Re: Imba – A new programming language for the web
#169Earlier quoted context omitted.
> 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.
Could you name a major web framework that implemented the MVC pattern prior to Rails?
Re: Imba – A new programming language for the web
#170Earlier 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…
> 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. 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, funct…
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)