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

I've noticed that some projects being complimented for having good docs come from CTOs (esbuild is another example). I'm hoping that by pointing out this little correlation, people might feel more inclined to spend more time on writing docs for their projects if they aspire to climb in the career ladder :)

Very true!

One small note to the author: the “We are hiring” at the very top, on mobile, is a bit broken. It appears on three lines. It looks great in mobile landscape, but not in mobile portrait mode.

One piece of feedback: it took me a moment to work out what 'pt', 'o' and 'fs' were. Single character variables are fine for algorithms but for demos you really want to use actual words.

One thing that site does not specify is the Imba's license (MIT)

Exact opposite of Elastic.co.

Is it just me? This website is super laggy on my PC (which can run modern games just fine). Hardly hits 50 fps when scrolling. How slow can one get and still claim to be fast?

Very true! It's a great landing page for a language that gets into the meat of it right away with clear examples in code blocks. Nice work.

I love the font chosen for the demo code, the descender on the f is very charming.

Thanks for sharing, I really like projects like this. And the website is really informative.

I find it less of a new language and more of a JS preprocessor, removing lots of the cruft and integrating XML-tags and CSS in a very neat way.

What I miss:

1) I feel the web is shifting to more type checking. TS, Elm, Kotlin.js... I personally also prefer more typesafety, especially if the project grows in LOC/team size.

2) Compared to JSX, Imba does a much better job in integrating adjacent technologies. Though I much prefer these to be integrated in an eDSL fashion. For example how Elm does HTML templating (in Elm) or Kotlinx.html[1].

Just taste i guess. Good luck with yr project!

[1]: https://github.com/Kotlin/kotlinx.html

Totally agree, this is obviously the work of someone who knows how to teach.

Asynchronous code can sometimes be difficult to write efficiently so having implicit awaits might help with avoiding accidentally made fire and forget calls. An interesting concept might be to explicitly call a function as asynchronous with a new keyword flipping the typical usage of ‘await’. I’d still advocate for the usage of ‘async’ in function signatures though as it helps when reasoning through an asynchronous code base.

That pretty much describes Lua.

https://hyperscript.org

and its async transparency in particular:

https://hyperscript.org/docs/#async

hyperscript isn't a general, full-stack programming language though, it's focused on pure front end stuff, sort of a modern jQuery replacement.

(Disclaimer not a web but backend dev.)

In my experience it's much more important to modularize/capsulate/segmentate by groupings of business logic then by groupings of implementation details.

Applying this to web applications (not simple text focused websites) this would mean that its preferable to have everything (HTML+JS+CSS) related to a specific widget (e.g. counter) in one place, instead of splitting it into many parts sprinkled across many files potentially in different folders. Similarly you also would e.g. want the CSS to be encapsulated as to the component as far as possible.

Its a bit of a different matter for classical html documents where the HTML made sense without JS or CSS and both where thinks you added "on top" to "just make it a bit nicer" but this isn't the think anymore for modern webapps (and many fancy websites).

Also if you work in a situation where you have many huge teams working on the same UI at the same time touching the same logical component (but normally different aspects of it) then having a more clear segregation can also make sense, but >99% of all companies are not ever in that situation.

This is also for example a major critic I have with react, it splits one logical unit across different files making it much harder to reason about it for the benefit of adding a bit more decoupling which isn't needed by >99% of dev teams.

Personally I've always been kind of confused by the common best practice of separating everything. React and Vue single file components made so much sense to me.

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.

> The distinction between HTML, JS and CSS always made perfect sense to me.

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

rather than

    <div color=red>

in a document representation language? Let alone today's CSS atrocities. Mind, I'm not talking about CSS' out-of-control layout model complexity, but inventing a new syntax (or a thousand microsyntaxes really) on top of already syntax-heavy markup.

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.

It's because of components.

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.

The pragmatic answer is that, for the the large companies usually behind those frameworks, they can have many independent teams that are working on split components, without marching on each other's toes.

But to me, there's a parallel to be made between both the newer trends of components and micro-services, and the old idea of Object Oriented Programming. In all cases, you get sold on the idea that everything should be cut down into tiny pieces.

Theoretically the separation of concerns has tons of merits, but in practice there are a lot of rough edges when those separate pieces have to interact with each others.

And the tradeoffs may not always be worth it when your project isn't on the scale of those large companies (it very rarely is).

Separation only works for so-called leaf components: buttons, links, tabs etc. that can actually be reused.

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.

I think eventually everyone just realized that so much of the styling is dependent on the element hierarchy that makes up the page that it’s pointless (and indeed painful) to separate your HTML from the component that uses it.

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

> ... [W]hy [are] a lot of new web languages/frameworks are mixing logic and content in the same file again...?

In olden days, the DOM was treated like something shared. This could lead to a single DOM elements receiving changes from all over the place: Multiple CSS selectors would include it and apply style rules, and multiple JavaScript scripts might select and manipulate it. Spitting the CSS/HTML/JavaScript into multiple files just makes it harder to know what's doing what.

The new frameworks are built around the idea that when we need to manipulate or style a DOM element then it should be isolated from the rest of the DOM, and so should the CSS and JavaScript that do the manipulating. In other words, what we often call "components".

For convenience, we often group these three things into the same file, or into small files sharing the same directory.

Reasoning about them much simpler, because each one is like a tiny HTML document with just a few DOM elements. No need to review hundreds of CSS selectors or JavaScript event handlers, because everything is together in one small package.

A feature usually consists of all three HTML/CSS/JS.

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

For web apps, you often want your content/HTML to dynamically render different elements depending on application state. Using a separate template file and having your logic plug into the template is often more complicated than just having your flow logic (if/else chains checking application state) return bits of relevant HTML/content inline.

Hard to describe, but it feels like it makes much, much more sense. I think it's because the divide between html/css/js is supposed to be one of concerns, but in reality the concerns are interwoven in many ways, and leads to issues when using them at scale. None of the scaling issues I've faced in the past re-occurred when I used a framework that combined the languages into single files.

A bad metaphor I just came up with: You're cutting a birthday cake. If you do the horizontal cuts you could at best have like 4 cuts and it's very hard. If you do the vertical cuts you could easily have like 16 cuts for everyone.

Because the horizontal way separates the concern the wrong way, or more precisely, the non-scalable way.

The idea is the same way that backend architectures are migrating from layered architectures to microservice or DDD alike architectures.

HTML, CSS, JavaScript separation of concern: 3 layers. Layered architectures: presentation, application, domain, infrastructure etc. There's only O(1) number of layers, so it's not scalable enough for modern applications. You can came up with more layers, but it's still O(1) and would be more strechy, despite the business and codespace are growing fast. People will struggle because everytime they change one layer, they have to find the corresponding other layers of code - it starts to defeat the purpose of separation where it should help people not caring other layers when modifying code.

A more critical separation of concern is to have O(n) separation: you can different domains like products, inventory, sellers, account managment, custommer support etc. If your business continue to grow, you could have more of them. And more importantly, it's much easier to separate teams into pizza-sized teams than layered separation.

Don't get me wrong, layered architectures are still useful. In fact, most of the DDD implementations are layered. But there's mental overhead when you introduce separation. Communities like React and Vue decide that it makes sense to merge layers in Front-end for local reasoning over separation, and accoding to my experience it works well (because I find it's very common to modify HTML, JavaScript, and CSS at the same time before I even started to use React).

The distinction makes sense on documents but it starts to break on apps. Javascript depends on HTML and HTML is generated by JS.

As others have mentioned, it's being used when writing components. Why does it work so well for components though, since you could just as well still separate the CSS? I think it's because of code co-location. Everything that describes how a component looks and functions lives in one file only. That's also why inline styles and utility libraries are palatable now, it's easier to reason about if it's described directly on the element, and you don't need to remember to update all usages of the inline style since it's a re-used component. It's even one step less indirection than using class names in that context, which is handy.

I also think most people are quite bad at organizing CSS, so I'm personally thankful for this change even though I love a well organized simple CSS/HTML site. It means less projects I inherit are rabbit warrens of legacy CSS to unravel.

> The distinction between HTML, JS and CSS

When all three of these things have to care very directly about eachother, separating them makes less sense.

It never made a lot of sense in practice. Designers couldn't maintain CSS files because the language was too complicated for most. And these days, most DOMs in dynamic web pages are generated by the JS so the HTML/JS separation doesn't make sense either. Separating content, presentation, and logic is a good idea in theory, in practice not so much.

This is exactly why I prefer Angular to React.

Our designer wouldn't have been able to deal with HTML markup within the JS files in React. Having the HTML and (S)CSS separated out made life much easier for him in Angular.

(edit: Naturally downvoted due to being slightly critical of React on HN. Which happens every time.)

CSS "separation of concerns" never worked well anyway:

https://adamwathan.me/css-utility-classes-and-separation-of-...

Some of the early React talks from 2013 give great answers to this question IMO https://www.youtube.com/watch?v=x7cQ3mrcKaY

Another way too look at it: Do you prefer backend, frontend, and databases to be separate teams, or should each team have ownership over their own backend, frontend, and db?

It depends. If your work is to create a new counter app every day to support some specific, single usecase, in other words you write a lot of simple apps and not a single complex one, then it’s definitely a win for productivity.

Another marketing pet peeve that I have is term "blazing" fast. I think it's so overused now on any new tool's landing page posted online that I instantly just assume that it is, in fact, of relatively average speed. Are there no other synonyms for fast these days?

That's not really a complaint about languages so much as it a complaint about marketing though, is it?

I don't go learning every language to mastery level, but I try to at least keep track of whereabouts they lie in the spectrum so I can cut through marketing-speak when I see it.

The way I see it, if a thing is being dogfooded in production, it's production grade. People can debate go-vs-rust or whatever till they're blue but the reality is simply that you can ship something with either and there are always going to be proponents and detractors for each side.

While I haven't followed Imba that closely, I've been aware of it for years, and I have to say it's one of few projects that actually has interesting technical takes on several fronts.

Then don't use it. Some of us do like productive (ie. expressive and batteries included) languages. PHP, Python, JavaScript and Ruby still power most websites. There's plenty of choices for enterprise languages and frameworks if you want.

Productive, everything included languages/frameworks such as this are great for freelancers, designers, students, and anyone who wants to get up and running quickly. You can also still create maintainable projects with expressive languages (Google and Python, GitHub and Ruby are a couple examples).

People are doing things that don't break with 'productive' languages.

Considering Javascript is the only language supported on the frontend, claiming to be more productive is definitely valid.

Coffeescript was a breath of fresh air compared to writing ES5.

Fair enough - and so you skip the languages that doesn't fit that bill for you and pick one that you feel bring you those outcomes. No hurt feelings!

I don't see the value in being able to "type fast".

I see it in less visual clutter.

You could be doing stuff that works decently, is great for humans, and still be productive (maybe even fast). Or figure out how to do it faster next time.

Someone else may want you to be fast and productive. Or... they'll find someone else who can provide what they want who is faster and more productive than you.

(Disclaimer: I'm the author of Mithril.js)

I looked at this a few years ago and IIRC, it refers to a very specific optimization for recycling DOM nodes in very specific cases. Recycling basically just means reusing pre-existing DOM subtrees instead of naively creating new ones. To my knowledge, Inferno.js and Mithril.js implemented a similar optimization but eventually dropped it because it was difficult to compute when the optimization could be applied and it wasn't worth the complexity (when using virtual dom anyways; my understanding is that imba doesn't do virtual dom)

I recall Imba always had quite nice perf numbers. Recycling DOM nodes did indeed give huge performance increases in synthetic proofs of concepts I did for Mithril.js. A good real world example where it's supposed to shine is tabular data: typically you'd key your rows to get good array diff performance, but this means paginating recreates the entire table from scratch every time. Recycling means reusing the existing DOM instead of re-incurring document.createElement call overheads for the entire table. Of course, in practice it's quite a bit more difficult to deal with edge cases (e.g. DOM state such as element focus)

The two things that I thought were problematic with Imba were a) lack of typing (which has since been addressed) and b) compiled output readability (i.e. it looks nothing like source code). It looks very nice otherwise, and it has come a long way since 7 years ago.

Most frontend frameworks are not created to solve performance of vanilla web applications, but rather to make engineering larger and complex applications easier.

I learned React to know what it was about and what people were talking about. I think a lot of people get the wrong idea about React. They say the virtual DOM is the most important feature, but I think it's actually the fact that it forces you to componentize your code. And it does this by making non-componentized code very painful to work with, so you have to componentize to be able to have any shot at getting React to work.

But if you already have the componentization mindset, I don't think React really adds anything. As you have said, managing raw DOM operations can be significantly faster. And because you have componentized your code, they are significantly easier to reason about.

The only problem is that working with a medium-sized smash of code is not as painful in vanilla JS as it is in React. So if you've grown your application over time, adding bits and bobs to it piecemeal, you're likely to end up with an application structure that is inherently difficult to manage. Then folks rewrite in React, get forced to componentize, and lo-and-behold, everything is much easier to manage.

At this point, whatever gets you there, gets you there, I guess. Personally, I make VR applications that run in the browser, so I coveteth performance.

I will try to add v2 to that benchmark relatively soon - it is a lot faster than v1 and has a much lower memory footprint and faster initial load time :) Should probably combine it with a few pull requests to the benchmark itself - as I consider it pretty flawed (see another comment here).

Yeah, the typescript-imba-plugin does quite a lot of magic and might be a little rough to get into.

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.

> Create a good language and people will flock.

What a truthfully useless statement. "Good" means having opinions about things that dont matter? Like "I don't like that css uses full words, I prefer these acronyms"

Who gives a shit? Is this language designed to prevent copy pasting? You may be on to something here.

Thought this at first but it's just tailwind css aliases. They are interchangeable with the full name.

fs = font-size

fw = font-width

ta = text-align

c = color

> Usually I think trying to make your own language for anything more than a DSL is a bad idea.

Depends what "your own" means. If it's a one-off language just for one specific project, then you're right. But this one is much more than that. Surely you don't think people should stop making new languages entirely?

It's more like the other way around..

The truth about Svelte: https://gist.github.com/Rich-Harris/0f910048478c2a6505d1c321...

Svelte was a minimalistic and familiarity-optimised response to Imba:

"These projects are all very cool, but there's a reason they haven't hit mass adoption: they want to control the entire world. You can't adopt Elm or Imba incrementally" - Rich Harris of Svelte

Imba: Created in 2010. Released some 7 years ago, Github repo in around 2015. https://imba.github.io/imba-guide/lvl0/about/

Svelte: Initial release November 26, 2016. https://en.wikipedia.org/wiki/Svelte

https://krausest.github.io/js-framework-benchmark/2020/table...

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.

You can definitely use 'just the language' part. I'm using it daily for scripting, and we've written a lot of apis and libraries at Scrimba that does not utilize any of the framework-ish features of the language. But to make the tags and styling work really well it (imho) has to be thought of at the language-level.

Yes, there are plans for an imba course on scrimba! It is almost comical, but scrimba was originally created with the sole purpose of teaching people Imba. Here we are, 4 years later, finally preparing to make a course :D

Yep, we will be making both individual scrims to use as examples and tutorial about building something more comprehensive.

A couple reasons I can think of: - The less logic you do on the client means more data required to be sent over the wire. - Connections are getting faster but we aren't at the point where they're negligible.

For example, if I need to do complex form validation in real time I could send the form value to the backend, have it validate, and receive a response which introduces a lot potential of failure points. Alternatively I could write some logic on the frontend to validate, and this problem expands as the amount of fields in your form increases.

There is built-in type-checking, but currently only via the tooling. It integrates with TS as a language service plugin (https://github.com/Microsoft/TypeScript/wiki/Writing-a-Langu...) so you get great warnings/errors, type inference and much more. To define standalone types or interfaces you still need to use `.d.ts` files, but that may change in the future :)

Interesting.

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

That's sad.

You can import any node module and use it with imba syntax. I’ve never had a problem doing this.

As far as I understand it, the language came first and in order to teach it to others the founder created a screencasting tool of sorts, which became a company in its own right: https://scrimba.com

Ironically, it seems the company focused on content to teach primarily other technologies while using Imba to build it all. It's a rather fascinating story actually, which I'm paraphrasing and probably mostly got wrong, but if you're interested you can read more on their hiring page: https://scrimba.recruitee.com

N.B.: I'm not in any way affiliated with Imba or Scrimba. The first time I heard of the technology and the company was today, through HN, so I have no skin in this game. I'm probably also mostly wrong about everything above, so you know..

They funded https://scrimba.com, an interactive coding tutorial platform, that is written in Imba.

Scrimba

No, not right now. The current version of tags is relatively tightly coupled with the DOM for maximum performance. It should be possible to create a bridge like react-native but it hasn't been an area of focus thus far!

Sure, you can apply tailwind classes like `<div.w-32.h-32.rounded-full>` etc, but I'd definitely recommend using the built in styling as it is much more powerful (value interpolation, flexible modifiers etc).

We linkify text submissions for Show HNs and other interesting text posts where it's clear that the feature isn't being misused. I did that on the OP.

See also https://news.ycombinator.com/newsfaq.html:

Q: How do I make a link in a text submission?

A: You can't. This is to prevent people from submitting a link with their comments in a privileged position at the top of the page. If you want to submit a link with comments, just submit it, then add a regular comment.

VDOM is certainly not faster. Svelte says "VDOM is pure overhead", and VDOM approaches are generally beaten by Imba and reactive libraries like SolidJS:

https://krausest.github.io/js-framework-benchmark/2021/table...

https://svelte.dev/blog/virtual-dom-is-pure-overhead

Lost me there tbh :)

With a few minor exceptions, the responsive view looks great to me. The issues mentioned in this thread seem less to do with imba's architecture and more to do with rushed, last-minute marketing decisions (e.g. adding in the "we're hiring" chip; which, by the way, is fixed now). No excuses, of course, although as someone who painstakingly builds nice mobile views for complex web apps, no matter how good the library is (I was using Theme-ui), the process is still like building a house on-top of jello.

Yep, I'm on mobile and the website doesn't really give me much confidence in how Imba works with responsive development

True, it doesn't seem to work so well, see screenshot: https://pasteboard.co/KgkhOEo.jpg

It's a tool that comes with NodeJS.

npx will run the node package from node_modules if it's present, else it will npm install the package and then run it.

It's a command from node that allows executing commands from node_modules.

You can use all browser APIs as if you were using JS.

Here are some results for v1:

https://krausest.github.io/js-framework-benchmark/current.ht...

(but the author claims v2 is much faster)

Next time, please explain why.

Why do you think this?

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

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

I've thought about this a lot. I considered "con" for constants. I don't hate it. It also works as a double entendre-- "con" in Spanish means "with". So the following code could be read as "with name equal to Brad".

  con name = 'Brad'

I can't help but feel that it's somewhat jarring though.

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)

Edit: After thinking about it some more, I think I prefer "const" over "con", but "def" over both.

Why does const irk you? const sounds a lot clearer than con. Is that your primary criteria for picking a language? ;)

You are obviously right.

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

Tbh, var is actually deprecated since v1, so any mention of var in the docs is a mistake. Are there any other languages using 'con' for constants?

I've never used a language with a 'cons' keyword, but nevertheless that's what I'd assume your 'con' was, if you didn't tell me otherwise.

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.

Good idea IMO. That feature should be pretty easy to add (famous last words).

if we want to nitpick I hate the fact that many dynamic languages need keywords to express very little information.

If js was made with types then the syntax `any x` (yeah lose the colon too, who gives a shit) is suficient to express that x is a variable, then `number x` could mean variable of type number, and `const number x` could mean constant of type number.

Is the difference in length bothering you? In that case I find that let for immutable and var for mutable is pretty good, although for a language that's lose to JS that might not be a good idea. Maybe let for mutable like in JS, and val for immutable? (inspired by Scala).

Personally I don’t use any languages with reserved words

Why should there should be a flag word before IDentifier, indeed the answer is.

[constant variable name] = value

is not the right thing?

> please insert other names below to educate me

Bjarne Stroustrup, Anders Hejlsberg.