Show HN: Imba – I have spent 7 years creating a programming language for the web

https://github.com/krausest/js-framework-benchmark

Great work so far, I’m excited to give imba a spin.

I took a cursory look at the docs and it looks like async/await is pretty much directly analogous to how it works in JS, with the difference that you don't need to mark functions as async in order to use the await keyword. Does this mean that if you use await in any function then any other function calling it will have to be refactored to add an await keyword, just like you have to refactor any call sites in JS if you make a function async?

I remember seeing someone here on HN showcasing a language where they did the opposite, making it so that await is implicit, so calling fetch or anything async doesn't require an additional keyword, and functions don't need to be refactored just to sprinkle async/await everywhere. I'll see if I can find that language again, but it seems to me there may be some idea sharing between the two that could perhaps yield some amazing features...

I run into subtle bugs all the time due to missing awaits, it's incredibly frustrating.

[1]: https://hyperscript.org/posts/2021-04-06-aysnc-transparency-...

Our designer wouldn't have been able to deal with HTML markup within the JS files in React.

I guess if I were to rationalize my position, I'd say it's because I have a hard time finding related things when they're separate. If a button or "a" tag have a special click handler, I want to know when looking at it. If it just has classes, then I don't know if that are for style or if they're for behavior. I know there are some conventions out there where you prefix classes with "js-" etc, but if you just use "onclick" then it's obvious and you don't need a convention.

> I have a hard time finding related things when they're separate.

Store them in the same directory?

I agree on the events/business logic that they make sense to couple with the template code.

Really? HTML is already heavy on syntax, and the whole point of SGML-style angle-bracket markup is to invisibly structure text hierarchically and sneak in rendering properties or other "metadata" not rendered to the user, via attributes. In which universe, then, has it ever made sense to write

    <div style="color: red">

    <div color=red>

If you think about it, CSS appears to have gotten these ninja super-powers because HTML was locked in a decade-long stagnation while W3C was busy with XML, RDF, and whatnot. Then again, in the last decade using <div>s for nearly everything was frowned upon, so with the precedent set in the decade before, CSS just had to re-order, re-place, re-arrange ad absurdum without any discernible mental discipline. Or, maybe the CSS WG people just couldn't stop.

The end effect is that CSS isn't approachable for even seasoned graphic artists let alone laymen; another effect being browser complexity resulting in monopolies.

A false separation-of-concerns narrative has ruined many languages and approaches (such as enterprise OOP); for the web it was particularly idiotic given it's founded on composable documents.

JS? Once it was out there, evolution of HTML and declarative UIs basically stalled because there wasn't anything you couldn't do using JS. Nevertheless, CSS had also grown into outlandish complexity. Basically, the "web stack" of today is what any standardization effort should've avoided.

Web app dev has started focusing on single, separate, reusable components instead of trying to design everything on the page at once.

Often, in these components, the HTML, CSS, and JS is still separated, but now (theoretically) you can plug that component in anywhere (even a different app) and, as long as you feed it the right data, it should just work.

If you are actually using components, that isn’t much of an issue.

In a time when you’d be returning a whole document every single time, it might make sense to say ‘style this one document with this one stylesheet’, and even more so in a time when HTMl was still more or less semantic (e.g. an actual document).

So, if you split by technology, you don't have the code belonging to one feature in one place.

And even then you will definitely run into issues such as "in this particular case this particular tab will look like this".

While the web was mostly leaf components (text, articles, images, links) this separation kinda worked. The moment you move into app territory, there are not that many things that are reusable and benefit from separation, because your UI is directly dependent on business logic and vice versa. And because every screen in your app is a unique view into a unique part of your functionality.

This lets you choose from multiple frameworks - comparing svelte against a few react variations, what I saw was that svelte was always fastest, but usually by a factor less than 2 (any react was 1.x times slower than the svelte).

The imba vs react numbers (from the article at https://www.freecodecamp.org/news/the-virtual-dom-is-slow-me...) shows a 30-40x speed difference.

And when you benchmark the speed of creating 10000 dom elements in an instant, less than 5% of the time should really be spent inside the framework one is supposed to test.

I stand by my claim in the mentioned article that tiny changes to a larger dom tree is a far better indicator of real world performance than anything else. Here Imba is really orders of magnitudes faster than react.

The last time I tested it, Imba was more than 10x faster than Svelte as well, but I'm not proficient enough in Svelte to claim that as a fact, and I have tremendous respect for Rich Harris and everything he's done with Svelte and other libraries.

FWIW, my initial impression of imba is that it's very impressive. I do think you rightly point out that, at this point, it may still be hard to leave larger ecosystems of react/vue/etc. DOM/UI speed of the project's JS toolkit generally has not been any meaningful impact in the projects I've worked on in the last several years - the data size and audience and app space just don't really call for it. However... as my needs change, imba will be something I'll revisit. Thank you.

I checked out https://github.com/imba/typescript-imba-plugin for a bit and I'm still quite lost. Love to learn more!

Also, what is the cross-file refactorings in the tooling? Thanks!

We essentially do the type-checking by compiling the files to js with jsdoc annotations, and for some features we also generate `.d.ts` files (see https://dev.to/somebee/global-type-augmentations-with-automa...). There is still a lot of work to be done on the integration. There are bugs and missing featyres, and the type-checking only happens in the tooling atm. The compiler could not care less about your types.

Since it is developed as a ts language plugin, references to imba files (like goto definition etc) works from ts/js files (you can include imba files in js/ts), and renaming methods / files works across all ts/js/imba files in your project.

Is there a clear separation between those two parts? Could someone take just the language without the framework and use it for something that's not web related?

I had the impression "tightly coupled with TS" would mean type checking.

That's sad.

1. https://www.youtube.com/watch?v=Gzj723LkRJY

Does imba also have native app framework too?

I'm impressed!

From a first look, I love the dimension types and the tags which compile down to native web components.

Hope good things for this.

Also -- wow those Nordics are super productive programmers/coders/developers/open-sorcerers (Sindre Aarsaether & Sindre Sorhus & Linus Torvalds & ...<please insert other names below to educate me>...) -- could it maybe have something to do with: The low GNI, the high HDI and the great weather for coding? (cold, blistery, bleak, focused, electrons-and-light universe is only outlet in a desolate landscape)? I have been to Oslo. The architecture is great.

PS - I use my own memoized DOM with minimal/granular updates in my own quirky framework (https://github.com/i5ik/vanillaview)

PPS - BTW memoized DOM is a great term of art. I perhaps shall be using it from now.

CONGRATULATIONS, SIR!

PPPS - Also what you are doing with Scrimba is so incredible. And GOOD. You are such a fuqing genius. Wow!

So the first thing I did here is look up the docs and see how variables are declared. Aaarghh.. "let" and "const" again :)

  con name = 'Brad'

If I had my druthers, I think I would choose "var" and "def" to declare mutable and immutable variables, respectively.

  def PI = 3.1
  def degreesToRadians = degrees => degrees * (PI / 180)

  var degrees = 180
  var radians = degreesToRadians(degrees)

The 'const' nomenclature is an abomination before science and human progress. However, given the prior art, I don't think we can hold it against a new/emerging language.

Anders, help us! Do the right thing. You are the only one who can.

(Of course, 'const' could be grandfathered and still work forever. Right-minded people, please upvote this obviously-right person at least back to a neutral #000.)

"const" seems clearer to me. "con" seems very open to misinterpretation: could mean many things.

Are there any advantages to "con" over "const"?

The more often a construct is used in a language, the shorter I like it to be.

It groups variable definitions mentally by having them all the same length if they are "var", "let" and "con".

It would often make the code look more uniform which is more beautiful in my eyes. Example:

https://github.com/facebook/react/blob/cae635054e17a6f107a39...

I would prefer the lines 226 and 227 to start with "con" and "let". It would make the code visually more appealing to me.

I’m sympathetic to wanting code to have good aesthetics. If I was writing those lines I probably would have daydreamed for 5 minutes thinking of new names for map and record so that the equal signs would line up.

I'm no particular JS fan, but 'const' is much clearer, it's a complete syllable, just like 'var' or 'func'. Yes 'fun' is used, but I think that's awkward for the same reason.