
Imba – Create complex web apps with ease - octosphere
http://imba.io/
======
dang
A 2016 thread:
[https://news.ycombinator.com/item?id=10901054](https://news.ycombinator.com/item?id=10901054)

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

------
codingdave
I'm unclear about what this is, other than a new flavor of syntax for
JavaScript.

The tagline of "Create complex web apps..." also turns me off. If there is one
perspective that needs to change in modern app development it is to stop
making "complex apps." Simple is good. KISS, and all that. I'd respond far
better to "Simplify your app."

~~~
erokar
It's more than a new flavor of JS, it also supports e.g. routing and
components.

Some web apps ARE inherently complex. You might dislike that, but it seems
unfair to criticize Imba for that fact.

~~~
peteforde
In defence of the person you're replying to, can we not assume that web apps
are inherently complex to the degree that complexity is table stakes? I feel
like you're being reductive because the actual comment is that "complex web
apps" should not be the aspiration. Telling someone that they shouldn't
simplify something that is by definition hard is totally missing the point.
Removing pain from a difficult process is legit; complex is not a status
badge.

~~~
johnday
I think people tend to talk past each other on this issue. The real problem
with deciding upfront that something must be complex, is that it switches off
that part of your brain which searches for simple, but hard-to-find,
solutions. It encourages "greedy development" where you dive in before scoping
out the best architecture, because who cares about the difference between
complex and slightly more complex?

Actively searching for simple solutions to hard problems encourages high
quality design and architecture. Moreover there is no one way to do simple
things; simplicity requires a wider toolset than complexity. If your marketing
explains how your tool helps people to make a complex thing, it's either
incorrect or it's a bad solution.

~~~
ebiester
So, let's say you take the simple solution. Then, the application keeps
getting more and more complex due to the functionality requirements.
Gradually, you've poorly and inconsistently implemented versions of the
complex patterns in the first place, and the end result suffers for it.

I've dreamed of creating a multi-phase approach to software where simple and
complex can co-exist and methodically transition along the way, but I've yet
to be able to crack the problem.

~~~
johnday
You might have misread the thing I was proposing. If your application "keeps
getting more and more complex due to the functionality requirements" then by
definition there's no off-the-shelf library or service that can help. If your
complexities are known in advance, you can choose a pattern which builds good,
simple, composable code.

Honestly even if you're complexities _aren 't_ known in advance, it's still
easier to build composable solutions out of off-the-shelf parts.

------
wslh
My only issue about creating web apps is in the UI/UX side so I don't get why
nobody is succesful in this front. This will be really revolutionary. With
successful I mean a UI builder hiding the details (think Windows Forms or
XCode) and with a good set of sample apps.

~~~
sansnomme
The main difficulty is that networked apps have a network to deal with and
generating those bindings coupled with today's demands for interactivity etc.
makes things tricky. RPC frameworks like gRPC tend to be quite rigid in this
aspect too (requires setting up exact specifications), despite making things
easier for the client. Also, the threat vectors are completely different. If
all browser apps run on a iOS device (i.e. locked down tightly with secure
elements, can be used as Point of Sale machines, very difficult to temper)
with data piped over TLS then it might be another story. But we don't live in
that world. Browser apps have to deal with the fact that they can be tempered
with easily. That a lot of things requires securing on both the client side
and the server side (just think about how many times you have had to write two
validations for form input). Servers have to be designed not to be easily
compronised. It forces data and state to be clearly specified and mapped out.
You can't just hold everything in-memory when you have to pipe things down the
wire.

Potentially soon we will be seeing more of such things. MSFT WebForms didn't
work out for all sort of reasons, but with stuff like front end Flutter,
WebAssembly, the whole server-control GUI over WebSockets thing with Phoenix
LiveView, Plotly Dash, .NET server side Blazor we are seeing a resurgence of
this idea. Building rich UI and having to manage state both ends is a pain in
the butt and makes stuff like authentication/authorization tremendously
difficult to implement properly and correctly. We have come a full circle.

What's almost ridiculous is all the manpower and engineering effort that was
put in over the years just so we can have a better UI and UX. You can build a
shiny GUI in React and use the same COBOL accounting software code running in
a DOS simulator that once powered a TUI software and the end user would not
know the difference and would be more than happy to hand over money.

------
rubyn00bie
Is there a way to do this with just plain ol' javascript? Or do I have to use
the "language?"

Things like this scare me because it's like a more tightly coupled
coffeescript that's gonna be hell to maintain in 10 years, will become awkward
with new (JavaScript) language features, or will just omit those features
until its untimely demise...

------
tobr
I experimented with Imba for a bit a few years ago. Ultimately there was way
too little documentation at the time for me to get past some of my initial
confusion.

Scrimba.com is extremely impressive, however. It’s written in Imba, and also
has a couple of Imba courses [1]. Looks like a good place to start!

1: [https://scrimba.com/search?q=imba](https://scrimba.com/search?q=imba)

~~~
duiker101
Seriously, I glanced at the webpage and was a bit whatever but that caught my
attention. It's very very nice!

------
peteforde
Yet another JS framework. This time around... Ruby-flavored Vue.

On one hand, people should absolutely go where their passion projects take
them. Building languages and compilers is often a critical step on the path of
deeper understanding.

However, there's no way to get past the fact that there are too many front-end
frameworks that offer same-but-different syntaxes. Most of these have no
chance of achieving a large enough ecosystem, but every framework demands
reinvention of everything all over again.

It pains me to consider how much smart person energy is currently channeled
into creating flavor of the day JS instead of building stuff with whatever
tech they are already proficient with.

Case in point: I am MUCH more excited by the Scrimba screencasting platform
than I am by the prospect of spending an open-ended amount of time learning
another, not-obviously-better framework.

~~~
octosphere
> It pains me to consider how much smart person energy is currently channeled
> into creating flavor of the day JS instead of building stuff with whatever
> tech they are already proficient with.

I always thought `diversity is good`, but maybe in certain instances it's not.
Perhaps a certain saturation level is reached and diversity just adds noise to
the system and causes enormous overlap and your "smart person energy" is
mostly spent re-inventing the wheel

~~~
peteforde
Are we allowed to make thinly veiled gestures towards the 2020 Democratic
candidate lineup? I don't want to get hell-banned.

Honestly, after React, Vue, Angular, Ember, Stimulus, Meteor and Backbone, how
does anyone truly have time to learn learn about Svelte, Marko, Knockout,
Aurelia, Riot, Omi, Foundation, Catberry, Composer, Yo-Yo, Vomit, Mithril,
Polymer, Sencha... I'm not making a single one of these up. I know that I'm
forgetting at least a half-dozen.

Note: try Stimulus!

Seriously though, if you're following every development on more than two JS
frameworks, you are procrastinating, lying to yourself and not achieving your
full human potential.

~~~
nineteen999
The very situation you are describing explains why many of us have avoided
working in the web ecosystem entirely for the last 20+ years or so, and don't
miss it at all.

Many people thrive in these kind of frenetic, fast changing environments.
Others (myself included) don't.

~~~
peteforde
Punchline: my top-level comment was downvoted with an angry passion. My
interpretation is that there is a silent mob of people here that are so
threatened by the idea that the only thing they know might not be God's
Ultimate Solution that anyone who suggests that things were a lot better a
decade ago is to be punished.

All I know is that after I help my friend with her React stuff, I go back to
Rails and thank my lucky stars.

------
cordite
One thing I am struggling to find is an example of calling a REST api, or
graphql

~~~
erokar
There's an example at the bottom of this page:
[http://imba.io/guides/essentials/state-management#state-
mana...](http://imba.io/guides/essentials/state-management#state-management)

------
Touche
This looks pretty fascinating! Think I'll try it out in a small app.

------
dandigangi
Out of curiosity - if a memoized DOM is faster than virtual, why doesnt the
React team to move that?

I wonder if its technical complexity and what it would be under the hood. I
know Fiber was redone recently-ish.

~~~
Can_Not
If you're "reacting" to a lot of changes, I suspect memorizing might end up
ballooning your memory usage.

------
erokar
At first glance Imba reminds me of Coffescript, in a good way. A language that
replaces JS' unfortunate Java-like syntax and helps reveal its simple and
elegant semantics.

~~~
stefano
> helps reveal its simple and elegant semantics

JS semantics are neither simple nor elegant. There's a reason there are whole
books dedicated to avoiding certain parts of the language, and it's not the
syntax.

For example, the syntax of the == operator is trivial. Its semantics however
is complex and inelegant (it looks like an equality operator, but it doesn't
express an equality relationship).

~~~
erokar
I'm familiar with JS' warts, which can be avoided. At the same time JS has
e.g. functions as first class objects, few and simple types, object and array
literals, and a prototype based OO.

This makes its semantic more elegant and simple than some other mainstream
languages, like e.g. C++, Java or C#, IMHO.

------
kvakkefly
Imba <3

~~~
Waterluvian
Sounds like you know it well and like it a lot. Could you share some
commentary on what you like so much?

