
Imba: A new programming language for web apps - judofyr
http://imba.io/?
======
creamyhorror
I've been following Imba for the past several months since the initial
announcement on HN.

I like the clean syntax, tags, and high performance, so I hope you guys
attract interest despite all the library/framework fatigue we're experiencing
in frontend JS land. It's rather refreshing to be able to write code and view
all together, like _< div.marker>.css(appropriate_styling)_

It would be great if you had some walked-through example apps on webpages
(like the old site used to have). That kind of thing helps people better
understand the benefits of your approach.

~~~
SimeVidas
I think the HTML standard prohibits you from using non-standard tags like
<clock> or <star>, unless they have a dash in them.

~~~
Kiro
This can't be true. I use non-standard tags without dashes all the time for my
custom directives in Angular.

~~~
acoard
Non-standard tags generally work in all browsers modern, but they aren't part
of the spec. It's just like custom attributes which don't start with `data-`.
They're recognized and work, but not strictly speaking legal. Your code _fill_
fail HTML5 validation tests.

------
estefan
All these languages du jour should go out of their way to answer the question:
"why bother?".

10x faster than react. OK cool. Except unless it has something like react
native it's irrelevant if you might want to write an app in future with any
sort of code reuse since you'll be tied to the web (unless you want the
inevitable world-of-pain of trying to integrate this preprocessor into your
xcode/android builds...).

~~~
JustSomeNobody
These are devs who would rather build tools to build a web app than to build a
web app. Different people have different itches. We don't have to consume what
they produce. Just have to read about it on HN.

~~~
_vya7
Well and fine, but those tools then need to be maintained _forever_ , and they
become _yet another tool in the stack_ for developers who come on board to a
company which has adopted them. It's easier and quicker to learn a new library
like React, or even a new DSL like JSX, than a new language.

~~~
JustSomeNobody
I don't disagree with you.

------
ianamartin
I have a backlog of personal projects of various kinds that I have been
tinkering with for years now. But since I'm a back end guy, that's what I
normally work on when I have free time.

Every time I decide that I'm going to take the plunge and get down and dirty
with front end stuff, I get completely paralyzed by choice, and I end up
deciding that the most sensible way for me to move forward is to learn the
fundamentals and design front ends with html + CSS + vanilla JavaScript.

As you can imagine, my elegant back-end designs have interfaces the 90s would
have deemed tacky.

I really like the syntax (Python guy checking in here), but I don't even know
where to start integrating this into a Pyramid app or what to do with it.

I don't even know how to get started here. I have a market research app for
building questionnaires. Like SurveyMonkey, but different. I want the front
end to be trello-like so that you can move the questions around that way.

I "know" JavaScript pretty well at this point. But when I look at the front
end code for an open source trello clone, I swear it's just effing magic.
Doesn't even relate in my mind to the language I thought I've been learning
all this time.

Since these kinds of threads tend to attract a lot of front end people, I
thought I'd ask here: is this an appropriate language for a trello-like
interface?

There was a certain point in my career when I was learning Python when I went
from knowing _how_ to write classes and functions to being able to know _what_
classes and functions to write to achieve my goals.

I know how to do things in JS, but I have no idea what to do to accomplish my
goals.

Any tips from anyone?

~~~
jestar_jokin
\- Don't worry, there's only a few different paradigms in use by the different
libraries and frameworks out there. Just look at the examples and see which
one piques your interest.

\- Do some analysis to break down your problem into manageable steps, until
you reach steps small enough to action. For example, a task tracking board
might have the following components: columns (representing "status"), drag and
drop (which changes the position of some DOM elements, plus updates the task
status), and a form (to capture the task status). So, look for ways to solve
each of those problems. e.g. column might be made easier using a grid layout
system, such as provided by Bootstrap. Drag and drop can be handled using
HTML5 features. And form handling can be made easier (or fancier) using any
number of libraries out there.

I wouldn't jump on a brand new language for the purpose of solving a problem,
if you don't have a clear idea of the solution you would like to implement.
Writing code is a means to an end, not a goal itself. It'd be easier to write
a solution using methods you're familiar with, then rewriting it using
different technologies.

------
manyoso
Doesn't solve any of the big problems with large scale javascript apps:

1) Lack of type checking leading to exploding runtime exceptions

2) Object inheritance/prototype is weird and counter intuitive to other OO
languages

3) Lack of proper encapsulation leading to spaghetti code when combined with
#1

I suspect we are in for a new era of languages targeting web assembly to be
used as webapp frontends and backends but if they don't tackle the big issues
above then what is the point?

~~~
programminggeek
There is no solution to large scale JS apps.

Large systems are inherently problematic. The only way to "fix" them is to
break them into smaller modules and subsystems.

Fancy abstractions and features will never solve large system issues. The
large system issue is that it's large.

~~~
manyoso
This is too clever by half. Some tools/languages are more amenable than others
to creating and maintaining large apps. Very large applications have been
written and maintained in C/C++ for decades. My contention is that Javascript
is _particularly_ ill-suited to the creation and maintenance of large scale
apps in the long run for the reasons explained.

Any new language which purports to be an improvement upon Javascript should at
least attempt to rectify these issues. That's my thesis.

~~~
j42
This is actually quite fascinating (and part of my upcoming book...)

Despite the obvious high/low-level language differentials, people have been
managing multi-million-line C code-bases since the 80's. Then again, think of
how little the build tooling has actually _changed_ \-- instead of
fragmenting, you're left with llvm, gcc, make at the core of most compiled
software.

JavaScript is the exact opposite with the lowest possible barrier to entry
(built-in to every web browser...), and the proliferation of frameworks and
libraries may be due to this in combination with the lack of fundamental
understanding of design patterns that can scale. Lots of people trying to
partially solve symptoms, missing the forest for the trees.

Theoretically there's nothing preventing good patterns in high-level UI
development, but I'm not quite sure it's been done right, yet and have no idea
when the dust will settle.

~~~
manyoso
Javascript and other dynamic language like it are very good prototyping
languages and for developing a quick mock-up to explore the pros/cons of a
potential solution to a problem. But the lack of type checking and proper
encapsulation turn into big headaches when scaled to a large app with even a
few more junior developers.

Without a compiler/type checker to help spot obvious problems in code runtime
exceptions explode. This happens even for senior developers. And the lack of
proper encapsulation other than by convention can/does lead to an explosion of
the surface area of source code that a dev needs to know and be familiar with
in order to refactor and make changes to large codebases which makes for very
brittle large apps.

Hence, I look forward to new languages targeting web assembly that will be
more amenable to creating/maintaining large scale and long lived apps.

------
temp
[https://news.ycombinator.com/item?id=10866540](https://news.ycombinator.com/item?id=10866540)

[https://news.ycombinator.com/item?id=10863827](https://news.ycombinator.com/item?id=10863827)

[https://news.ycombinator.com/item?id=10091454](https://news.ycombinator.com/item?id=10091454)

~~~
chvid
Getting thru at HN takes multiple submission it seems. Even for a big project
like this.

~~~
dang
It 'got through' on the first try:
[https://news.ycombinator.com/item?id=10091454](https://news.ycombinator.com/item?id=10091454).

------
madmaniak
I recommend it. Syntax for tags and tags inheritance is awesome. I keep my
fingers crossed for Imba.

------
davidw
Worlds collide: IMBA has meant International Mountain Bike Association to me
for the past 25 years or so.

~~~
nik736
For me it's the short form for imbalanced ;-)

------
tomlong
Finally, a new programming language for web apps.

------
golergka
To all people who reply negatively to this: don't you guys actually like
learning new languages?

Why?

~~~
randallsquared
I _do_ like learning new languages, but there's a certain amount of fatigue in
this particular space, given the pace of announcements and limited time.
There's a worry that one could spend all one's available time for learning new
things and have learned nothing of value in two years.

For this to be of value, it has to provide at least one of four things:

1\. Becoming a widely-adopted system (like node.js)

2\. Strong influence on widely-adopted systems (like Elm)

3\. Insights that influence one personally (like most any lisp)

4\. More fun than alternative things one could be playing with

~~~
smt88
Even Elm is far from widely adopted, though I agree it has really captured
people's attention

~~~
randallsquared
The widely adopted example was node.js; Elm was my example of a system that
has had strong influence on widely adopted systems (like React/Redux).

------
tomcam
Surprising how many comments are of the "why bother" variety as opposed to
critiques of Imba itself.

~~~
mruniverse
"why bother" should be the first question asked and first question answered
(by the Imba team).

~~~
FilterSweep
This, as well as the fact that recent years have brought on new language
fatigue from having a completely new language with its own syntax and its own
pros and cons being shown every 6 months. "Why bother" is important.

------
tempodox
Reminds me somewhat of Opa, [http://opalang.org](http://opalang.org)

------
lhorie
I see you guys did a lot of work on improving the docs since last time you
submitted. Keep up the good work!

------
scotty79
I love languages that understand indentation. Actually imba looks like many
things I love mixed together.

------
tomcam
It looks very much worth a try to me. Couldn't find anything about database
bindings in the docs.

~~~
tomcam
OK, that was handled very quickly on gitter! Just use something like knex.js,
duh.

------
amelius
Ok, so what is the reason it is more than 10x faster than React (as claimed on
their web-page)?

~~~
mako-taco
If I had to guess, the use of requestAnimationFrame
[https://github.com/somebee/imba/blob/7ab3d380562b8e6cd09ab09...](https://github.com/somebee/imba/blob/7ab3d380562b8e6cd09ab0942cfa8529ad65eedb/lib/imba/scheduler.js#L7)

------
chvid
Why not use the more familiar C-syntax of JavaScript?

~~~
nv-vn
Because trading familiarity for usability is not beneficial in 90% of cases.

~~~
oneeyedpigeon
But usability is very strongly affected by familiarity.

~~~
wtetzner
Only for a very short time.

------
ericathegreat
I like the syntax from the front end, but the details for back end seem a bit
light on. I can't see much in the examples around persistence of data on the
server side. Is this covered/planned?

------
woah
Is it actually 10x faster than React? If you're not doing
shouldComponentUpdate, then the benchmark is misleading.

~~~
sindreaa
React and Imba can both optimize using shouldComponenUpdate (in Imba you would
add the same logic inside node#commit). Utilising shouldComponentUpdate (in
React and Imba) requires additional logic by the developer, not the framework.
This is not an optimisation at the framework level - but an endpoint where the
developer can write their own custom optimisations. Adding your own manual
checks all around your app to check for statechanges is inelegant, cumbersome,
and bug prone. In my opinion it defeats much of the purpose of a virtual dom,
if you are expected to do your own diffing before sending it through. Also,
the relative performance difference is about the same when turning it on.

I fully stand behind the benchmark, and would even go as far as saying that it
is more relevant for real world applications than benchmarks like dbmonster
where everything in the view updates on every render. This effectively tries
to calculate how quickly each contestant can reconcile the whole view
(synchronously), but when only parts of the view has actually changed.

Here is some additional discussion about the benchmark:
[https://github.com/somebee/imba/issues/9](https://github.com/somebee/imba/issues/9)

------
mikkom
As this seems to be some kind of javascript derivate using node.js on the
backend (?) I'm interested in how this deals with async operations, ie. can
you create functions which take a long time to run without blocking other
users?

This is especially important as they are targeting server side too.

~~~
vertex-four
I'm not reading anything which suggests they're targeting server-side.

~~~
jarcane
_This whole website is written in Imba. It uses the same code for server and
client. After the initial load, all navigation in the browser is happening
with history push /popState, and rendered directly on the client, yet any hard
refresh should land you at the same spot when rendered from the server, thanks
to using the same logic for routing as well._

[http://imba.io/guides#toc-examples-scrimbla](http://imba.io/guides#toc-
examples-scrimbla)

------
codygman
How does it compare to the amazingly fast ur/web?

~~~
xaduha
It doesn't? It's closer to Coffescript I think.

ur/web might be hard to get into for someone who doesn't have ML or Haskell
experience.

------
Keats
Non-closing html tags? Looking at the doc it seems it is using the same
structure as hiccup or hyperscript except. What was the reasoning?

~~~
adrusi
Well the rest of the language is indentation-based and lacks closing
delimiters so it would be inconsistent for the embedded markup to have closing
delimiters.

------
gbersac
Isn't it pretty much the same thing as dart. Except dart also manage the
backend and is already used and mature ?

------
johnhenry
At first glance, this seems a lot like elm. I wonder if anyone could point to
a comparison of sorts?

------
felipellrocha
Why are we still compiling to javascript, when we should be compiling down to
WebAssembly?

------
tasqyn
in website it is written "Imba brings the best from Ruby ..." exactly what?

------
arunix
“You must avenge my death Imba, ... I mean Simba.”

------
such_a_casual
The syntax of this looks absolutely stunning. It gives the code a real beauty.

------
abatista111
I built this simple module pattern framework that makes building apps pretty
simple. the idea is that everything is a controller (module patter) so you
break you app into controllers or modules.
[https://github.com/ThinkAcademy/MasterControl](https://github.com/ThinkAcademy/MasterControl)
check it out its open sourced by
[http://thinkacademy.io/](http://thinkacademy.io/)

------
imaginenore
Actually on their own benchmark page the imba example is the slowest.

[http://somebee.github.io/todomvc-render-
benchmark/index.html](http://somebee.github.io/todomvc-render-
benchmark/index.html)

~~~
virtualSatai
What's your specs/browser? I get:
[http://i.imgur.com/dtKCSxL.png](http://i.imgur.com/dtKCSxL.png) in Waterfox
40.1.0, and [http://i.imgur.com/4bu0Hev.png](http://i.imgur.com/4bu0Hev.png)
in Chrome 47.0. 20x and 26x improvement over the slowest.

------
alfanick
it gets boring... why we need another language?

------
_Codemonkeyism
My imba language:

10 GOSUB CREATE_WEB_APP_THAT_I_WANT

20 DEPLOY TO_CLOUD

~~~
Lapsa
canihaz facebook for 200$

------
qwertyuiop924
Yay! Another new programming language for hipsters! Another pointless
technology to learn!

For god sakes, use js &co, clojure, or elm. Nothing else is worth it.

~~~
aeze
You know your examples were/are considered new languages at one point, right?

~~~
qwertyuiop924
yeah, but I feel they have a reason to exist. Clojure exists because it has
interesting ideas about immutability, and is a lisp. Elm exists because FP.
This exists because... Why? They thought we needed a new syntax for JSX? They
thought we needed another language that was kind of like coffescript, but
different in subtle ways? I don't know, and I can't see what this is bringing
to the table.

~~~
such_a_casual
Then don't use it? There's no reason to bash on anyone for making something,
even if it's absolutely useless:

[https://news.ycombinator.com/item?id=10758290](https://news.ycombinator.com/item?id=10758290)

~~~
qwertyuiop924
Sorry, I didn't mean to bash on them for making. Let me clarify my opinion.
What annoys me is that they made a thing, which is of debatable use, and
talked it up as the next big thing, which everyone should use, because it's
amazing. That bugs me.

