12 ms·

Imba – A new programming language for the web

• deleted 11y ago
  [deleted]
• nailer 11y ago
  I don't think of react as a language, but rather a virtual DOM + JSX. This looks like a nice modern syntax which is both an ES6 focused minimal JS (removing unnecessary tokens) with HTML building included.
  • agumonkey 11y ago
    It's confusing they made a whole nice language that doesn't speak about react VDOM diffing which .. was the whole point right ?
    • sindreaa 11y ago
      Hi. We actually do a different kind of diffing - which turns out to be substantially faster than React: http://somebee.github.io/todomvc-render-benchmark/index.html http://somebee.github.io/todomvc-render-benchmark/index.html. The language has just been released, it is still very lacking when it comes to documentation. Working on it :)
      • agumonkey 11y ago
        Fair enough, I guess you have other more important things to do then.
      • Scriptor 11y ago
        Can you give some details about Imba's diffing?
        • judofyr 11y ago
          What part of the diffing? Imba only uses `===` for diffing. If you want Imba to re-use a DOM node, you must use the same tag object. Imba provides syntax for caching nodes as properties on the current object. For instance, in order to re-use DOM nodes in a for loop you do this: for event in @events <event@{event.id} name=event.name> The loop body compiles down to: (this['_' + event.id()] = this['_' + event.id()] || t$('event')).setName(event.name()).end() The next time you render the view, Imba will find the tag objects that have been reordered (using `===`) and move them to the right place. 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 <something> else <something-else> Just because `mouseOver` becomes true for one frame doesn't mean you want the `<something-else>`-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.
• endymi0n 11y ago
  So this is basically coffeescript. Where's the react part?
  • nailer 11y ago
    Scroll down to 'Tags'.
• ilovefood 11y ago
  awesome
• viach 11y ago
  "if Ruby and React had an indentation based lovechild, what would it look like?" Let me guess!... CoffeeScript?
  • _hadrian 11y ago
    yeah, just add the jsx to CoffeeScript :D
  • judofyr 11y ago
    Imba was actually forked from CoffeeScript three years ago. After the fork there's been a bunch changes, both in terms of adding tags, but also when it comes to the object model and variable scope. - Implicit calling: `foo.bar` calls `foo.bar()` and `foo.bar = 123` calls `foo.setBar(123)` - Objects have instance variables that's separate from the methods. Well, technically the instance variable `@bar` is just stored as a property with name `_bar` on the object. - Variables must be declared with `var` and they correctly shadow previously defined variables. - `do` provides a syntax sugar for the pattern "function as the last argument" - Optional arguments work together with block parameters def timeout(amount = 0, &cb) cb(amount) Compiles to: function timeout(amount,cb) if(cb==undefined && typeof amount == 'function') cb = amount,amount = 0; return cb(amount); }; - `self` is a keyword which is a saner `this`, and instance variables are automatically looked up using `self`: def end @client.on("end") do @server.end Compiles to: function end(){ var self=this; return this._client.on("end",function() { return self._server.end(); }); };
    • untog 11y ago
      - Implicit calling: `foo.bar` calls `foo.bar()` and `foo.bar = 123` calls `foo.setBar(123)` Wuhh. Why wouldn't you use JS defineProperty here?
      • judofyr 11y ago
        There's one historic reason (it wasn't widely available when Imba was started). Another reason is performance: the last time we benchmarked this `defineProperty` was slower than regular function calls. Maybe it's improved now. Semantically the biggest difference is that you don't need to do anything special for marking a method as a property: class List def length # … In this case `list.length` just works. The disadvantage of this is that if you want to get the function itself, there's a separate syntax (`list:length`). Other than that, this is mostly about taste/style.
• SomeoneWeird 11y ago
  I lot of these things are basically irrelevant if you use ES6/7.
  • nailer 11y ago
    Most of it's good, just a cleaner JS, but it'd be better to drop the classes and lambda-type short function syntax in favour of ES6 classes and arrow functions.
  • cpursley 11y ago
    Are brackets and semicolons now optional in ES6/7?
    • benaston 11y ago
      Semicolons have always been optional. Brackets are only used for array literals (oh and destructuring assignment) as far as I know (and are required).
• Goranek 11y ago
  really love the design, and how it shows the whole language on the frontpage.
• joeminichino 11y ago
  This is good! Now take away all the unnecessary references to that pile of junk that is ruby and it'll be great.
  • tracker1 11y ago
    I don't know that I agree with that... a lot of the syntax definitely burrows from Ruby, but then again so does CoffeeScript... this actually looks a lot like CoffeeScript with embedded razor templating. I think this is either developed by or targeted at people with a ruby background, and does give some context. I'm actually more happy with something closer to JS (EX6/7 transpiling) with React (JSX) than something like this. Usually when you approach headaches on larger teams with JS, it's more that you haven't broken things down as well as you can/should more than a language construct. JS projects tend to work far better from discrete separations of components, views, functions and composites... simple components can be thought of react components that only use properties for rendering, views are a composition of components that use stores for state interaction. Functions are modules that have singular discrete testable functionality and composites are similar to classes but yeild an object tethered to state/options but mainly glued together from modules that expose a single workflow function. There's also control/workflow type composition, and node-style object pipes tend to work very well in many of those scenarios... get batch of items from db into an object stream through workflow steps, queues, etc. It's definitely an interesting abstraction of a few ideas together, I'm not sure what it does in terms of improving a larger workflow. Other than a more wrist friendly syntax.
  • matthewmacleod 11y ago
    This tool is forked from Coffeescript, which is deliberately designed to resemble Ruby. There's a good reason for that – some aspects of Ruby's syntax are well-loved. It might be more effective for you to use your time understanding why these aspects are important, since you apparently feel this project is good, and less time being a bit of a dick about it.
    • pluma 11y ago
      > some aspects of Ruby's syntax are well-loved. By Ruby programmers. Why is it that Ruby programmers are incapable of imagining anyone doesn't love Ruby? This isn't a universal truth for all programmers either. I've met plenty Java programmers willing to admit the shortcomings of Java, I've met PHP programmers painfully aware of the language's warts, I've even met Python programmers willing to admit Python's limitations. I've yet to meet a Ruby programmer who doesn't believe that Ruby is the best thing since sliced Jesus.
• bashyal 11y ago
  Thank you for not saying "transpile".
  • TeMPOraL 11y ago
    Yup. "Transpile" is "compile" for those who're too young to ever have worked with a compiled language.
    • andybak 11y ago
      I suppose the idea is that 'compile' implies a low-level target whereas 'transpile' suggests translating to another high-level language. I can see some sense in making this distinction.
      • WorldMaker 11y ago
        In the larger linguistics world you have a distinction between "translation" (conversion between languages) and "transliteration" (conversion between forms of a language; cursive writing versus typing versus speech, for instance). I remember this being a particularly important distinction in learning American Sign Language (ASL) because the vocabulary is roughly English-ish it is very easy to transliterate and try to say in ASL an English sentence "as is" without meaningful changes, but just with dealing with the differences between, say, English and Spanish, to speak ASL properly you need to actually translate to more idiomatic forms and abstractions. This is extremely important to ASL not just from a "speak better ASL" standpoint but also because it comes out of a foundational, cultural imperative: ASL was not seen as "a real language" until it proven to some linguists that it validly needed translation, was not just a transliteration of English but in fact a language with its own idioms and grammar requiring translation. This disagreement is so fundamental to ASL also because there was so much pressure from people to "speak real English" rather than develop their own language. There is a transliteration-focused "alternative" to ASL that includes all of the useless English grammar and stutter words like "the" that ASL handles grammatically different, and ASL had to prove its existence against it and also to prove that it was better and also to prove that ASL speakers could still read/write English to work with the rest of the English-speaking country when their native language was grammatically different enough to require translation... It's an interesting cultural battle to read about. All of which is a long winded example to get back to the idea that the translation/transliteration difference is very similar to the compilation/transpilation difference and while I don't think we've yet seen a cultural battle for supremacy between the terms, I do think there is a usefulness in keeping the distinction. I also see the conversion between idioms/abstractions as being the key difference between compilation and transpilation. Machine language has much different idioms/abstractions from a high-level language; CoffeeScript and TypeScript try to stay very similar in idiom/abstraction to EcmaScript.
• raffomania 11y ago
  Is there more information about how the 'very efficient rendering' part works?
  • judofyr 11y ago
    There's two parts of the "very efficient rendering": 1. It store the previous rendered tag and does a diff. (Just like React). 2. Every tag is compiled to JavaScript that's easy for the optimiser. tag event < div def render <self> <h1 bar="123" baz=bar> "Hello world!" Compiles to: // Setting up the tag-object. Then: tag.prototype.render = function() { return this .setChildren(Imba.static([ (this.$a = this.$a || t$('h1').setBar("123")).setBaz(bar) ], 1)) .setText("Hello world!") .synced() } While React passes an object of props around, Imba will instead call setters. These setters are very easily inlined by modern browsers. Also note that it caches directly on the tag object itself which gives another additional boost. Since it caches the objects themselves it can also compare everything with `===` and/or `indexOf`. The `Imba.static`-call marks an array as static which is a guarantee that the structure of the array won't change. In this case Imba will not do the full diff-algorithm, but instead compare each item element-by-element. And yes, once you've achieved the minimal amount of DOM changes needed (like React), the next step for performance is all of these little tweaks. Does it matter? It all depends. Imba is capable of rendering bigger applications than React when you use the "render everything over again in the animation loop". TLDR: The tags are more integrated into the language. The language is also designed around features that's easy for the optimiser.
• judofyr 11y ago
  Disclaimer: I've been following the development of Imba while it's been a private project (for six years now). Lately I've been helping out fixing bugs and improving smaller parts of the language. Having tags as a proper part of the language is very nice. This just works in Imba: <ul> for event in @events <li> if event:type == "like" <like event=event> elif event:type == "comment" <comment event=event> In React I'd have to use `map` and refactor parts into variables. I've been struggling to use React on teams with designers because small design changes can cause rather huge changes in how the code is structured. Other than that you can think about it as indentation based JavaScript with implicit method calling (`foo.bar = 123` calls the setter `setBar`) and saner handling of `this`.
  • keithy 11y ago
    I would really like to see React do something like this as a shortcut to having to do map. It would be SO helpful.
    • pluma 11y ago
      The benefit of JSX is its syntactical simplicity. Lots of beginners seem to think JSX adds all kinds of language features but in reality most of them are unrelated to JSX and either part of ES6 or experimental features of ES7. The only new thing JSX brings to the table is the element syntax. And all that does is translate `<a b={c}>{d}</a>` to `React.createElement(a, {b: c}, d)`.
  • ufo 11y ago
    The React API would be much nicer if it could use Javascript generators.
  • dugmartin 11y ago
    You can do that right now with CoffeeScript+React and it looks almost identical: {ul, li} = React.DOM # require in like and comment components here... ul {}, for event in @events li {}, if event.type is "like" like {event: event} else if event.type is "comment" comment {event: event}
• rushabh 11y ago
  As someone who has been developing using Javascript for 10 years and has seen many frameworks comes and go (including authoring one), this looks refreshingly good on first impressions. Far better than coffeescript or React. Congrats! Plus, I love the fact that the syntax looks Pythonic :)
• uptown 11y ago
  Anybody know the color scheme for the code on this page?
  • brianm 11y ago
    Looks like Twilight (which started life with Textmate, but has taken off all over since), or a variation thereupon.
• thom_nic 11y ago
  So... I don't understand if you're supposed to use this with react, or instead of react? If the answer is "instead," is it a language and a view framework?
• keithy 11y ago
  Hmm might have to try this out. The TODOMVC test http://somebee.github.io/todomvc-render-benchmark/index.html http://somebee.github.io/todomvc-render-benchmark/index.html looks promising .
• shadowmint 11y ago
  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 nice, they use them because you can build applications with them. How do you build ui components using imba? Use react? :P
  • kbenson 11y ago
    My first thought as well, even though I know little except the marketing about React. It's like if someone said "Foo: a new competitor to Rails", or "Bar: a new competitor to Vim". 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.
  • judofyr 11y ago
    Imba includes syntax for tags (scroll down to "Tags"), virtual DOM diffing, event handling (with touch support). Yes, React is not a language in itself, but there's quite big overlap in what Imba does and what React+JSX does. You build UI components like this: tag event < div def render <self> <h1> event.title <p> "Happening on {event.dateString}"
    • shadowmint 11y ago
      No. 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.
      • mintplant 11y ago
        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 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.
• meowface 11y ago
  I actually think this looks really good, but 3 things: 1. Why differentiate it from CoffeeScript so much? Why not call it DOMCoffeeScript or something? Are there any core language changes from CoffeeScript other than the tag features? 2. I'm not sure how I feel about the mixture of XML tag characters with HAML/Jade-like indentation. My gut instinct is to always look for a closing tag with XML/HTML. Why not use some kind of sigil like % or @ or ! to represent a tag, since clearly the requirement for both a left and right caret is now obviated? 3. Why require the `var` keyword instead of making it the default? That's one of my biggest pet peeves with languages like Javascript and Lua. Local-by-default always makes the most sense.
  • judofyr 11y ago
    1. Because the semantics are quite different. See my other post. 2. It's still nice to separate the attributes from the content: <h1 title="hello"> "Foo" Why use a new syntax when everyone knows HTML/XML? 3. The lack of `var` in CoffeeScript is its worst feature ever IMO! Every time I write `someVariable = …` I'm terrified that I will accidentally overwrite a previous variable. Imba improves on JavaScript here and will correctly shadow multiple `var` in the same function.
    • tracker1 11y ago
      People also know CSS query selectors... <label> <input:checkbox:checked#myCheckbox> <span> Some Text Might be nicer than actually spelling out the attributes and properties, if you're taking an already wrist friendly language and bolting on tags, then taking that a step farther would probably be a nice idea as well.
      • judofyr 11y ago
        Imba supports the syntax for IDs and classes: <label#foo.bar .baz=isBaz> "Label" compiles to: ti$('label','foo').flag('bar').flag('baz',this.isBaz()).setText("Label").end() where `flag` is a method which adds to the class list (unless the second argument is falsey).
• batiste 11y ago
  Very similar in concept to what I have done with CokeScript. https://github.com/batiste/CokeScript https://github.com/batiste/CokeScript
• mangeletti 11y ago
  I have to admit I was really not excited to see this: var answer = if number == 42 The language looks shockingly pleasant in a number of ways, but everything being an expression seems odd. Would somebody mind helping me understand the value (semantic, performance, etc.) of such a choice?
  • dustingetz 11y ago
    Expressions compose
  • untog 11y ago
    CoffeeScript (which this is forked from) has some parts like this that I strongly dislike, such as using the unless keyword after an action. For example: doSomeThing() unless person.present For me that utterly destroys readability - in my mind, when I see a (), that function is being called there and then. The fact that you can invalidate that later in the line confuses me deeply - and it doesn't really provide any benefits above an if statement anyway. The rest of CoffeeScript is great though, don't get me wrong. (though ES6 JavaScript has taken the best features anyway)
    • applecore 11y ago
      The unless keyword is very useful for when you're testing an exit condition, e.g., return unless...
    • mangeletti 11y ago
      To play devil's advocate, when using Python's ternary operator like this: something() if False else y The `something` function is never called.
    • matthewmacleod 11y ago
      That's not specific to 'unless' – it's the general postcondition style that's is derived from Ruby. Indeed, for single-line if statement bodies in Ruby, it's the recommended style. It fits the style of Ruby to try and cut down on syntax noise where it's not needed. Contrast: save! if !record.persisted? && !record.invalid? save! unless record.persisted? || record.invalid? Though I do appreciate it's a bit unusual compared with most other languages – CoffeeScript does owe a lot to Ruby's syntax.
• abecedarius 11y ago
  Loops as expressions return an array as the value, the page says, but the JS code on the right doesn't seem to show this happening. Which is right? Or does the compiler notice in these cases that the value is not used, and not produce it?
• kazinator 11y ago
  > Imba is a new programming language for the web that compiles to performant and readable JavaScript. More like, "Imba is a new syntactic 'skin', which transliterates to JavasScript."
• EugeneOZ 11y ago
  Again that mistake with ASI - I wonder how much people like stepping on the same rake.
• dopamean 11y ago
  Why do people keep throwing around the idea that "X tool is Y times faster than React?" Last I checked no one was claiming React is super fast and I don't know anyone who uses it for its speed. It just seems like such a strange thing. It's like building a new car and claiming it's 100 times faster than riding a horse.
  • stdbrouw 11y ago
    Virtual DOMs were pretty much invented while searching for a way to get higher rendering speeds. Just google "virtual dom speed".
  • habiteer 11y ago
    If only horses existed, and you were the first to make a car, would it not be an apt comparison? With performance at 100k renderings per second you don't need to care about keeping the view in sync anymore?
• aorth 11y ago
  Fun fact: "imba" means "sing" in Swahili, a language spoken in East Africa (Tanzania, Kenya, and to some extent Uganda, Rwanda, Burundi, Malawi, and DR Congo).
• cpursley 11y ago
  Interesting, great work. As someone who's never been able to get on board with JavaScripts syntax, this looks like a viable alternative to CoffeeScript. Also, for React applications I've found that LiveScript (a functional compile to JS language) makes for a great JSX alternative as shown here: https://arch-js.github.io/docs/02-basic-tutorial.html https://arch-js.github.io/docs/02-basic-tutorial.html
• techpeace 11y ago
  Fantastic work! Thanks for sharing it with the community. I'm excited to check this out further.
• jzig 11y ago
  Ugh. I want to use this but I want docs and how bootstrap this into my build process.
• bedeho 11y ago
  Awesome!!
• pluma 11y ago
  I for once would appreciate it if Ruby programmers would stop trying to avoid writing JavaScript by writing their own JS-based implementation of Ruby. With ES6 and Babel this "new programming language" provides nothing interesting other than making your code look more like Ruby.
  • klibertp 11y ago
    > Ruby programmers would stop trying to avoid writing JavaScript by writing their own JS-based implementation of Ruby I would appreciate it if people knowing very little about programming languages stopped commenting on new languages. Nearly every comment here is either baseless or irrelevant or simply wrong. It's frustrating. In your specific case: CoffeeScript and this are most certainly not a "JS-based implementations of Ruby." This is: http://opalrb.org/ http://opalrb.org/ And how the language "looks" - its syntax - does matter, but not in the way most people think it matters. It's just that the syntactically simpler constructs tend to be used more often, so the choice of syntax affects the code people write. The rest, including "readability" or simply "beauty", is meaningless in the long run. EDIT: I'm in no way involved in this project!
    • pluma 11y ago
      That's why I said "their own" JS-based implementation. And the point is that it goes out of its way to re-invent features already supported by ES6 just so they look more like Ruby. Like using string interpolation instead of template strings, for example. It's not a language built on top of JS to improve upon JS, it's just as contrived as CoffeeScript (which unlike this one actually had a reason to exist in that it influenced the development of ES6 when a lot of features it implemented weren't yet part of JS). What is the benefit of learning this language? Who is this for? JS programmers? No, they could just use Babel to write something that will eventually become vanilla JS. Does it bring anything new to the table like ClojureScript or LiveScript does? No, it's basically CoffeeScript with ES6 scoping rules and JSX elements. So in the end all it adds is another barrier to entry for new developers joining your project/company with the only benefit being that it's "prettier". I'm not saying bad ideas aren't worth exploring -- they are, and if your bad idea happens to involve creating your own programming language, all the more power to you. But the only "good" reason to use this language is if you want your JS to look like Ruby. Just like Haml is for people who want their HTML to look like Ruby; and like Sass (not SCSS, I mean the original braceless syntax) is for people who want their CSS to look like Ruby.
• BrianDGLS 11y ago
  It's quite beautiful looking. Unsure of what use it would be, but nice for a change.
• rgbrgb 11y ago
  We've been using this coffeescript/jsx project throughout our codebase: https://github.com/jsdf/coffee-react https://github.com/jsdf/coffee-react Similar idea but just ads JSX tags to Coffeescript (cjsx). Only ergonomics problem is that the syntax highlighting sometimes breaks on single quotes used within the XML tags so you end up having to do something like `<p>{"you're fired"}</p>` so that it doesn't mess up the highlighting in your whole file.
• deleted 11y ago
  [deleted]
• timothycrosley 11y ago
  Reminds me a little bit of the Python -> Javascript two way compiler I wrote: https://github.com/timothycrosley/jiphy https://github.com/timothycrosley/jiphy
• gaigepr 11y ago
  Personally, I am really over the white-space as a delimiter in my programming languages. I used to love python but that is a long lost love.
  • prezjordan 11y ago
    "You're gonna indent it anyway!"
    • gkya 11y ago
      "But you will have to read it later." "If you mess up your indentation, you're in hell." "Tabs or spaces? If the latter, how many of them?" "On what particular character will I be able to hit % to find where the related block is started?" ...
  • cheapsteak 11y ago
    What made you change your mind/tastes?
• andrewmcwatters 11y ago
  I don't see the point.
• javajosh 11y ago
  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| xx into something like do x xx it will compile fine, but be wrong. The tooling is quite nice, and I like the defaults - although it's still a little bit of a mystery where the imba.js file comes from in the Hello World browser example (I ended up just copying it from Github). I'd like to see argument comprehensions, and the option to generate code outside of an immediately excuting function (so I can play with instances at the dev console) I would like to see a "strict" mode for imba that chokes on a do block without pipes, for example. I think that if JavaScript has taught us anything it's that anal compilers might frustrate us at build time, but that frustration is nothing compared to the frustration down the line when things break at runtime.
  • sindreaa 11y ago
    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 sublime plugin to show much more stuff from the compiler and warn about calls to undefined methods etc. There is a lot of analysis from the compiler that can be used to improve the ide-like experience.
    • javajosh 11y ago
      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!
• Geee 11y ago
  Interesting. Have you built real apps with this?
• PSeitz 11y ago
  I usually don't like the javascript transpiler languages, but this one seems really decent. The classes are even more powerful than those in ES6
• shaunxcode 11y ago
  I think there would be value in publishing what ever you call your react lib (all the t*$ stuff) as a distinct js library.
• alkonaut 11y ago
  The overview didn't answer my biggest question: what kind of (compile time) type system does it have? Can I use it to get proper type checking, inference and primitive types?
• TeeWEE 11y ago
  The author of imba has some problems understanding languages vs frameworks/libraries. I quote: "Imba is a new programming language for the web that compiles to performant and readable JavaScript." Ok, so i understand Imba is a language spec with an implementation that compiles to javascript. "It has language level support for defining, extending, subclassing, instantiating and rendering dom nodes." Ok so there is special syntax to create DOM elements. Nothing new here. Its just syntax over javascript. What can be done with imba, can be done with vanilla javascript. "it is more than 20 times faster than React" Wait, what? React is a javascript library, not a programming language. Written in javascript.... How can Imba be faster? Does Imba also include a dom-diffing algorithm.. If so, why would you built that into the language... Woudnt it be better to write a library in imba-lang that can do dom diffing? I'm lost here.
  • judofyr 11y ago
    > Does Imba also include a dom-diffing algorithm Yes. > Woudnt it be better to write a library in imba-lang that can do dom diffing? It is: https://github.com/somebee/imba/blob/master/src/imba/dom.static.imba https://github.com/somebee/imba/blob/master/src/imba/dom.sta.... It's a required runtime library if you want to use the tag syntax. The difference between "language" and "core library" is always a bit mushy. For instance, the JavaScript doesn't only specify the semantics of operations, but also the main objects (String, Array, etc) and a set of functions (push, pop, indexOf, etc). In the sense that JavaScript ships with default objects for dealing with Arrays and Strings, Imba ships with default classes for dealing with tags and DOM elements. Yes, we could say that tags should just be sugar syntax over regular function calls (which it actually is) and move the DOM diffing out of "Imba". But really, the main point about Imba is the tag functionality and we believe we only need one good implementation.
  • pc2g4d 11y ago
    I think they were comparing based on the performance of a simple application: "For a semi-complex application like TodoMVC, it is more than 20 times faster than React with less code, and a much smaller library." I think the comparison makes sense because Imba seems to imply a lightweight framework. At least, the generated code in the examples on the front page references a `t$` function, which has to come from somewhere.
• deleted 11y ago
  [deleted]
• spyder 11y ago
  Can it render on the server-side (Node.js) without JSDOM?
  • sindreaa 11y ago
    Yes, it can. Serverside rendering is still not very well tested, but it does work. I will create a simple example soon.
• abecedarius 11y ago
  The tag syntax looks like the biggest advantage over ES6. Couldn't ES6 do that though as a template string type? -- like dom`<div> ${contents} </div>` As far as I can tell on a quick google, this remains to be done. (I saw some hits for HTML string templates as opposed to direct DOM construction.)
• chipchappelle 11y ago
  oh great, another shitty javascript fraemwork
• curveship 11y ago
  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.
  • sindreaa 11y ago
    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 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 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 <something> else <something-else> Just because `mouseOver` becomes true for one frame doesn't mean you want the `<something-else>`-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.
• SeeThruHead 11y ago
  Comparison against Elm and Purescript?