Over the last few episodes I ported a few of my old Imba 1 apps to Imba 2, so it's time for some overall impressions.
None of these apps were complex, or particularly performance-sensitive, but it's enough to see some problems.
The most important point is that Imba just needs to commit to doing a full release.
Imba 2 is a full rewrite of Imba 1, with no source code compatibility, no automated upgrade tools (not like they helped Python much), and significantly different capabilities, so Imba 1 solutions won't map clearly when porting.
Even for very simple apps I had to do some serious changes, for me mostly because Imba 2 components can't represent parts of an
<svg> the way Imba 1 components could.
So right now it's impossible to recommend Imba to anyone:
- I definitely can't recommend that people use Imba 1, as that's no longer developed
- I definitely can't recommend that people use Imba 1, and switch to Imba 2 later, as upgrade is too painful
- I could maybe recommend Imba 2 alpha, but that's always sketchy
At some point Imba needs to make a list of issues stopping full release, address those issues, and then do a full release.
Imba 2 made a terrible decision of using indentation with 4-width tabs. That was already recommended default in Imba 1, but you could have used spaces instead if you wanted. Now it's tabs only, and it won't compile otherwise.
This is a terrible idea. As far as I know no other language does this.
Very few languages are indentation sensitive. According to this list it's only 2% of all languages. And overwhelming majority of them follow 2 spaces rule, with notable exception of Python using 4 spaces.
As far as I know, the only other indentation-sensitive language that uses tabs is Makefile, which uses standard 8-width tabs, in a way that never nests, and let's be honest, it's a trash tier mess of a language.
So Imba 2 is completely alone with its choice.
Why does it matter? Because if you leave the editor and copy and paste anywhere else, like a blog, stack overflow, github PR or a bug report, slack, email, or whatnot, tabs are guaranteed to get messed up. At best you get 8-width tabs which look like total ass. More commonly you get some unspecified number of spaces instead, and code won't work when you get it back to the editor.
There are some languages that use tabs for indentation, but none of them are indentation sensitive, so if code is messed up this way, you can just run autoformatter. It's impossible for an indentation-sensitive language to even have an autoformatter.
So 4 spaces would be far superior to 4-width tabs for indentation.
Of course an even better solution would be 2 spaces. There's a good reason every single web language uses 2 spaces, and that's because HTML by its nature is very deeply nested, and the more nested the structure is, the more it wants narrow indentation per level.
Notably Ruby used to be mostly 4 space indented like Python back in the days, but because Ruby is a more nested language due to blocks, it switched to 2 spaces. 4 spaces sort of works for Python, as it's generally less nested than Ruby or Imba, but if it was designed today, it would probably go with 2 spaces as well.
Imba 2 is exactly the kind of language that really should have 2 space indentation. Markup is directly in the code, as is SCSS-style nested CSS.
One thing that's great about Imba documentation is the initial page. If you open imba.io, those examples look extremely tempting, and answer "Why should I care about Imba" question really well. Unfortunately if you want to follow that, and click "Getting Started", that's where it all ends.
Unlike jQuery or Svelte, Imba is a big framework, and it has a pretty steep learning curve, so it desperately needs both comprehensive reference, and good tutorial.
Svelte has pretty much the best tutorial of any framework, so it would be great if Imba did something similar. And that's something I recommend every framework doing.
Another thing Imba needs doing is having comprehensive reference. This is usually easier than writing tutorials.
Imba has builtin Tailwind-SCSS-thing, and I think that could be great, but I'm just baffled by one design choice. Unitless numbers are treated as 4px each. So
width: 10 means
width: 40px. The whole HTML ecosystem assumes "unitless = px" in so many places, and I have no idea why Imba did this (other than just copying Tailwind class names).
At least with this there's a simple workaround of always specifying
px unit, but this is going to cause so many surprises, and as far as I know isn't even documented anywhere.
Imba 2 is now based on Web Components, and that comes with a lot of limitations like no support for SVG components. To be honest I don't know how much it matters in practice, but it's a choice no other major framework makes.
The most important thing that changed between Imba 1 and Imba 2 was the meteoric rise of Svelte.
Imba 1 vs React or Imba 1 vs Vue was a fair proposition back in 2019 - you have to pay all the early adopter costs, but you get a great reward at the end.
All of this might still be true, but now Imba also has to compete with Svelte, and the payoff just isn't there. Svelte asks for a lot less, and delivers pretty much the same thing - fully reactive low-boilerplate frontent language.
That's not to say that Svelte is some sort of ultimate frontend framework, but it's the one to beat if you're targetting early adopter crowd, and I haven't really seen a convincing Imba vs Svelte story.
Even if you want a CoffeeScript-like language, in principle it's possible with Svelte. Right now it's a bit messy, to make it work more smoothly, CoffeeScript compiler would need to be tweaked to support
$: labels, other than that it's just some rollup configs. But the thing is - CoffeeScript-style languages are not very popular since ES6 came out.
Not until it does a full 2.0 release, and sorts out its documentation.
Even after that happens, I'd still recommend Svelte first.
That's enough Imba 2 for now. In the next few episodes I'll be taking a look at a few more technologies.