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

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

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.

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.

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.

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

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.

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

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.

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

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

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

I see it in less visual clutter.

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.

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.

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?

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.

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.

  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)

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

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

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.