
Imba – A new programming language for the web - judofyr
http://imba.io/
======
shadowmint
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

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

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

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

~~~
shadowmint
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. ;)

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

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

~~~
scotty79
I wonder how React with Immutable.js would fare in "Unchanged Render"
benchmark.

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

~~~
dugmartin
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}

~~~
judofyr
Yup, that looks pretty good.

Imba was started before React was available so it wasn't an option back then.
As for today, the language integrates tags in a much nicer way than what's
possible with CoffeeScript + React. This especially pays off performance-wise.

Although Imba was started before React it should be noted that it didn't
include virtual diffing until React showed that it worked.

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

~~~
nostrademons
There's no rule that says the language/library/framework divide has to lie
where contemporary scripting languages put it. In PHP and ColdFusion, HTML is
part of the language; in Ruby or Python it's usually relegated to a templating
library; in Javascript the _DOM_ is usually a library and it's bad practice to
build up HTML strings (in 2015, at least; in 2008 it was _good_ practice to
build up HTML strings, because it was orders of magnitude faster than using
the DOM). In Matlab or R, statistical and linear-algebra functions are part of
the language, while in Python they're a library. In C++, strings, hashtables,
and arrays are part of the standard library (or not even that, in early
versions), while in Python & Ruby, they're part of the language. In Lisp the
language parser is part of the language; in Rust, C++ (under Clang), Python,
and Go it's part of the standard library; in many other languages it's not
available at all.

There are certain best practices that have emerged for general purpose
languages. Imba is not a general purpose language; it's explicitly meant for
web programming, and makes sense that it would build common web programming
functionality into the language itself.

------
viach
"if Ruby and React had an indentation based lovechild, what would it look
like?"

Let me guess!... CoffeeScript?

~~~
judofyr
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();
          });
        };

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

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

~~~
mbrock
foo:bar is property access.

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

~~~
thom_nic
Ok that is awesome.

------
mangeletti
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?

~~~
untog
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)

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

~~~
untog
That's not really the part of unless that bothers me - it's the order. Why not
do:

    
    
        if !record.persisted? && !record.invalid?
            save!
    

or:

    
    
        unless record.persisted? || record.invalid?
            save!

~~~
kbenson
The behavior here, if it comes from Ruby, almost definitely has it's legacy in
Perl, so you can look to Perl for justifications. The main justification is
likely to be that's a natural construct of how we think and communicate, so
why not allow us to express ourselves that way?

Another way to look at it is why do you think the conditional should come
before like you've shown? Because C or even older languages started with that?
If you didn't have prior experience with that form, would you still think it's
inherently better, or would the trade-offs between the two forms seem slightly
more balanced?

------
nailer
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
It's confusing they made a whole nice language that doesn't speak about react
VDOM diffing which .. was the whole point right ?

~~~
sindreaa
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 :)

~~~
Scriptor
Can you give some details about Imba's diffing?

~~~
judofyr
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
So this is basically coffeescript. Where's the react part?

~~~
nailer
Scroll down to 'Tags'.

------
javajosh
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 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
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
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!

------
batiste
Very similar in concept to what I have done with CokeScript.
[https://github.com/batiste/CokeScript](https://github.com/batiste/CokeScript)

------
rushabh
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 :)

------
raffomania
Is there more information about how the 'very efficient rendering' part works?

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

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

------
thom_nic
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?

------
cpursley
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)

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

------
gaigepr
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
"You're gonna indent it anyway!"

~~~
gkya
"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?"

...

------
andrewmcwatters
I don't see the point.

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

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

------
abecedarius
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?

------
EugeneOZ
Again that mistake with ASI - I wonder how much people like stepping on the
same rake.

------
timothycrosley
Reminds me a little bit of the Python -> Javascript two way compiler I wrote:
[https://github.com/timothycrosley/jiphy](https://github.com/timothycrosley/jiphy)

------
BrianDGLS
It's quite beautiful looking.

Unsure of what use it would be, but nice for a change.

------
alkonaut
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?

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

------
uptown
Anybody know the color scheme for the code on this page?

~~~
brianm
Looks like Twilight (which started life with Textmate, but has taken off all
over since), or a variation thereupon.

------
Geee
Interesting. Have you built real apps with this?

------
shaunxcode
I think there would be value in publishing what ever you call your react lib
(all the t*$ stuff) as a distinct js library.

------
jzig
Ugh. I want to use this but I want docs and how bootstrap this into my build
process.

------
Goranek
really love the design, and how it shows the whole language on the frontpage.

------
SomeoneWeird
I lot of these things are basically irrelevant if you use ES6/7.

~~~
cpursley
Are brackets and semicolons now optional in ES6/7?

~~~
benaston
Semicolons have always been optional. Brackets are only used for array
literals (oh and destructuring assignment) as far as I know (and are
required).

------
spyder
Can it render on the server-side (Node.js) without JSDOM?

~~~
sindreaa
Yes, it can. Serverside rendering is still not very well tested, but it does
work. I will create a simple example soon.

------
kazinator
> _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."

------
SeeThruHead
Comparison against Elm and Purescript?

------
techpeace
Fantastic work! Thanks for sharing it with the community. I'm excited to check
this out further.

------
bashyal
Thank you for not saying "transpile".

~~~
TeMPOraL
Yup. "Transpile" is "compile" for those who're too young to ever have worked
with a compiled language.

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

------
bedeho
Awesome!!

------
chipchappelle
oh great, another shitty javascript fraemwork

------
ilovefood
awesome

------
dopamean
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
Virtual DOMs were pretty much invented while searching for a way to get higher
rendering speeds. Just google "virtual dom speed".

------
joeminichino
This is good! Now take away all the unnecessary references to that pile of
junk that is ruby and it'll be great.

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

~~~
matthewmacleod
_By Ruby programmers._

And clearly other people – or we wouldn't be seeing those syntax elements in
other languages.

 _Why is it that Ruby programmers are incapable of imagining anyone doesn 't
love Ruby?_

They're perfectly capable of that, and I think you've let your own prejudices
cloud your judgement.

 _I 've yet to meet a Ruby programmer who doesn't believe that Ruby is the
best thing since sliced Jesus._

Hello, pleased to meet you. I'm a mostly-Ruby programmer who is well aware
that the language is not suited to every task. Need high performance? Look
elsewhere. Need a highly reliable service? Something that would benefit from
static typing? Systems-level tools? Same. Ruby is a pain to deploy and has
lots of irritating legacy cruft.

What this doesn't mean is that the statement "that pile of junk that is ruby"
is anything other than a fucking stupid thing to say.

~~~
joeminichino
yeah sure - I was a bit troll-ish in the language. Let me elaborate. Imba is a
spin-off of javascript intended for front-end use whose syntax is a mix of
coffeescript, jsx and python as well Ruby imho; that said, please name a
single use case in which Ruby will be without a doubt the #1 language for
performance, scalability and all the other aspects involved in maintaining a
business (including availability of programmers). Ruby is only second to PHP,
which is just unreedemable (I'm even certified on it...
[http://www.zend.com/en/yellow-
pages/ZEND005898](http://www.zend.com/en/yellow-pages/ZEND005898) so don't
think I'd refrain from criticizing languages I know, even very well).

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

~~~
techpeace
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 user, I see nothing wrong with bringing
that ethos to other languages. You yourself acknowledge the impact it had on
the development of JavaScript.

We in the Ruby community will keep innovating, and you keep hoping that we'll
stop, and we'll see which happens.

~~~
pluma
> 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 but
MVC is not synonymous with REST.

> Many parts of ES.next

Again, no. ES.next is nothing like Ruby. Some of the syntax was influenced by
CoffeeScript (nobody doubts that -- in fact, TC39 members have explicitly
referenced it on more than one occasion) but the features are neither novel
nor unique to Ruby:

* The class syntax is pretty much universal.

* The arrow functions are evidently influenced by CoffeeScript but look nothing like Ruby's lambda literals (which are the closest equivalent in Ruby). I think CoffeeScript's use of that syntax was actually pre-dated by C# but I may be mistaken.

* Template strings have no more in common with CoffeeScript's and Ruby's string interpolation than with the same feature in other languages. In fact, if anything, I'd say the interpolation syntax is borrowed from PHP -- but the backticks certainly aren't taken from any of them.

* Symbols are kinda like Ruby symbols if you tilt your head and squint really hard and then only focus on the name and not what they actually are. Again, the concept is neither novel nor unique to Ruby.

* Destructuring and rest/spread operators -- yeah, again, not unique or novel. Plus I think even Python preceded Ruby on that.

* iterators and generators -- again, closer to Python than to Ruby.

* import/export -- just an extension of the ideas of CommonJS which in turn aren't anything like what Ruby has.

* promises -- no, sorry, not Ruby.

* the object literal extensions -- again, not Ruby. Ruby doesn't even have object literals in the sense JS does (which is okay, it doesn't have prototypal inheritance either).

> Front-end build tools

No, seriously not. Yes, rake pre-dates grunt and gulp by a fair amount (as
well as jake and other JS-based tools barely anyone seems to use anymore). But
it certainly didn't invent them nor was the biggest factor in popularizing
them. A lot of build tools before the Ruby (and now JS) toolchains came along
were built in things like Java, in addition to the various less formalized
build tools written in Python or simply bash.

> CSS pre-compilation

I may give you that. Less pre-dates Sass but started as a Ruby gem. Of course
neither of them invented CSS minification and there were attempts at
generating CSS before. Compass probably took the crown, though, even though
front-end tools in generally have moved on to the Node ecosystem, which seems
more appropriate for tools primarily concerned with JS (rather than Ruby, Java
or bash).

> JS transpilation

Not _really_. Java-to-JS transpilation was the original hotness that opened up
people to the idea. It was followed by various attempts to port other
languages to JavaScript. I agree that CoffeeScript is the first one that
gained major traction in the startup scene -- although most teams seem to have
realised that the drawbacks aren't really worth it (not just the transpilation
but the entire part where everyone has to learn a new language on top of a
solid understanding of JS itself).

Yes, CoffeeScript was an important step in the evolution of JS but so were
DHTML, pop-unders, JSS and animated mouse cursors and status bars -- and
everyone agrees those were a bad idea.

The Ruby community is very vocal and self-important but it's neither as
uniquely innovative nor as much of an influence as its members like to make it
out to be. If PHP is the kindergarden of programming languages, Ruby is the
angsty teenager complaining about how nobody understands them and writing blog
posts about their deep insights gained from flipping through Atlas Shrugged.

~~~
techpeace
> It was a major factor, yes, but claiming this purely as an accomplishment of
> Ruby is silly.

A major factor in popularizing it, as I claimed. Personally, I had never heard
of it before DHH's 2006 RailsConf keynote. Could you point me to another web
framework that had implemented it before 2006?

> Some of the syntax was influenced by CoffeeScript (nobody doubts that -- in
> fact, TC39 members have explicitly referenced it on more than one occasion)
> but the features are neither novel nor unique to Ruby.

Again, CoffeeScript was popularized by the Ruby community, as uptake increased
greatly when it became a default in Rails. The syntax was heavily influenced
by Ruby, which then found its way into ES.next.

> Front-end build tools

The Rails asset pipeline was actually listed as the inspiration for Brunch,
the closest you can get to replicating its functionality in JavaScript. This
went a long way towards _popularizing_ the notion.

> I agree that CoffeeScript is the first one that gained major traction in the
> startup scene > although most teams seem to have realised that the drawbacks
> aren't really worth it (not just the transpilation...

Yes, and CoffeeScript first gained traction within Rails. You also seem to be
discounting the obvious popularity of ES.next transpilers.

> The Ruby community is very vocal and self-important but it's neither as
> uniquely innovative nor as much of an influence as its members like to make
> it out to be. If PHP is the kindergarden of programming languages, Ruby is
> the angsty teenager complaining about how nobody understands them and
> writing blog posts about their deep insights gained from flipping through
> Atlas Shrugged.

This is rude, untrue, and unhelpful. Be civil.
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

~~~
pluma
> 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
annotations) most of the syntax it adds to JS are either already part of the
language and just not widely supported (i.e. ES2015) or experimental proposals
for new language features intended to eventually land in a future JS spec.

CoffeeScript doesn't work because it requires you to learn a new language on
top of JS. ES.next works because it's bleeding-edge JS (plus some speculative
additions). The code you write for Babel today will likely run without
transpilation in a JS environment a year or two from now.

This is a general trend in web technologies. CSS pre-compilers like Sass are
being replaced or enriched by CSS "post-compilers" like postCSS (that consume
vanilla bleeding edge CSS and spit out CSS that works today). JS transpiler
languages like CoffeeScript are being replaced by ES2015 (and speculative
ES.next) with compilers that translate the code to JS that works today (or
yesterday, even -- Babel generally works fine with IE8/ES3 if you use the
necessary shims and shams).

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 remarkably unique thing about the Ruby community I keep noticing as
an outside its rise and fall of the Brogrammer culture and the aftershock
we're still experiencing to this day. But even that, I think, would have
happened even if Ruby never existed.

~~~
techpeace
> 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 remarkably unique thing about the Ruby community I keep noticing as
> an outside its rise and fall of the Brogrammer culture and the aftershock
> we're still experiencing to this day. But even that, I think, would have
> happened even if Ruby never existed.

Well, you've failed to sway me on that (by far), and the clear chip on your
shoulder you have regarding the Ruby community as a whole leads me to believe
your vociferous arguments to the contrary might be motivated by something
other than your desire to spread the truth.

~~~
pluma
> 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?

