I understand that Imba is not appropriate for everyone and every project but I encourage you not to dismiss it. One are where it is clearly valuable is in building prototypes and side projects.
This is a fairly common, and I believe correct, use of the word "tag". The MSDN reference uses the term in a similar manner (as do countless other definitive resources and tools). Consider the first sentence of the MSDN's page on HTML elements:
> This page lists all the HTML elements, which are created using tags.
Things are often messy IRL - especially when they happen organically such as the meaning of words (try defining what is a sea and a lake with no exceptions).
I remember ‘tag’ was used colloquially in the ‘90s - this was before Javascript was popular. When DOM became a thing in 1998, the definition was more formalized to be consistent across JS and HTML. As things stand, tags usually come in pairs, except for a few (such as <br/>?). An element is now defined as both tags + the content.
I believe this evolution happened organically, and many people still prefer the use of ‘tag’ to mean an ‘element’ for conciseness.
It helps lower the barrier to understanding a new concept because you have an existing concept to leap from and language to use. It comes at the cost of precision.
The words `node`, `class`, and `tag` in particular are used all over the place.
There's a reason for the joke that the two hardest things in software are cache invalidation and naming things.
Your quote doesn’t support your argument. Yes, elements are created out of tags (plus content). But a single tag generally does not constitute an element, except for self-closing tags like <br>.
I agree that it’s a somewhat common mistake to refer to HTML elements as “tags”, but it’s unfortunate to bake that mistake into a language.
If it's common enough it's no longer a mistake, it's just how the English language is. If everyone understands each other, then insisting on a "more correct" usage is just pedantry.
Can you provide a concrete example of a case where this usage would be confusing?
I think it’s better framed as an imprecision than a mistake. The naming language has evolved in common real world usage, in the “can’t put the toothpaste back in the tube” sense of language evolution. As such, it isn’t (any longer) incorrect, only imprecise. It isn’t even necessarily ambiguous, because the usage context tends to disambiguate it.
There are certainly cases where the precision matters, but I think this is only one such case if the imprecision causes misunderstanding by users of the Imba language.
The HTML5 spec does not take a stance on how the words "tag" and "element" should be used in day-to-day speech or in other projects, it just distinguishes them for the purpose of the spec. A specification has to be very precise in its wording, but that doesn't mean we all do all the time.
Given that there is no end tag in Imba, that's not especially confusing—there's a one-to-one relationship between tags and elements.
Also, colloquially it's very common to use "tag" because to refer to both, because "element" is longer, including in pretty formal places like Shopify's API:
> there's a one-to-one relationship between tags and elements.
There’s not a one-to-one relationship between HTML tags and elements, so if there is a one-to-one relationship between Imba tags and HTML elements, it follows that there is not a one-to-one relationship between Imba tags and HTML tags — that’s what’s confusing.
By your own insistence a tag is simply a syntax construct, so I'm not sure why it matters that there's a one-to-one relationship between Imba tags and HTML tags. All that matters is that there's an obvious mapping from one to the other (and preferably back), which there is.
Also, I want to re-emphasize that most people use the words "tag" and "element" interchangeably when talking about written HTML. That may be a pet peeve of yours, but it's common enough that it's not an incorrect usage.
Well it powers https://scrimba.com which looks serious enough. I’ve known about it for the past 6 years, but never had the chance to use it because I’ve only done static websites lately.
I am starting work on an automatic irrigation system that will have a web/PWA frontend and I remembered about Imba which I plan to use this time.
Some of the syntactic sugar is very nice, but the overhead of transpiling that to TypeScript to get type checking, then to JS for runtime seems excessive.
I believe that we made a few mistakes with Opa, though. The slicer (the component of the compiler that decided which code should be compiled to client and whic hto server) was a great idea, but it came with considerable pitfalls in terms of security. Since then, I have concluded that too much multi-tier magic is actually a bad thing.
If I were to start a new version of Opa, I would probably force developers to split their code manually between client, server, database and location-independent (presumably by putting stuff in distinct directories). This would be much easier to read/audit. But at this stage, this raises the question of whether an entirely new language is really useful. Why not simply do it with a sufficiently smart toolchain based on TypeScript or any language that compiles to wasm?
Source: I did not start the project but I led the design and implementation.
I still remember the sunny day I was at a Starbucks table with a huge americano and my first second-hand MacBook, stumbling upon Opa and thinking "what a great idea!".
It looked so simple, intuitive, and the fact that I could write both front and back end in the same file was amazing!
I never got to do a large project with it, so I didn't notice the pitfalls you are talking about. But I want to thank you and your team for making me understand that web dev does not have to be painful if you choose tools that you like.
While I think that we made some mistakes in the design, I'm surprised that, to this day, there isn't any widely-used language/toolkit/framework [1] that seems to do as well.
[1] Alright, there's GWT, which does pretty well with different tradeoffs. But for some reason, it seems to be extremely niche. The website mentions that "thousands of developers" use it.
> If I were to start a new version of Opa, I would probably force developers to split their code manually between client, server, database and location-independent (presumably by putting stuff in distinct directories)
Exactly how GWT worked (and still does!). there's a server/, client/ and shared/ directories... but all code is written in Java.
That's entirely possible. I'm probably in the process of graduating to graybeard, because I've been witness to a few cycles in computer science already :)
i was rooting for opa! it was pretty sad when it died. ocsigen does do a lot of the same thing in theory, but in practice i found it really hard to learn and eventually gave up.
Now that OCaml has gained algebraic effects, I suspect that it should be feasible to reimplement Lwt to use these instead of monads, which should make writing async code much easier, which in turn should make Ocsigen much easier.
Well, it very much depends on your definition of "secure". The OWASP top 10 were pretty easy to eliminate entirely with a language that supports static analysis, but we accidentally introduced a couple more:
1. the model made it hard for the developer to know what data was flowing from the server to the client (e.g. are we leaking a secret as part of a closure?)
2. on the web, you can only (mostly) trust the code that's executed on the server, as the client could have been patched to be running arbitrary malicious code, but the syntax of Opa made it very easy to forget that some of the code was living in this client-side warzone, which in turn could lead to serious security vulnerabilities;
3. when you patch code, especially in auxiliary functions, it's easy to lose track of where it's going to be executed, which means that it's easy to accidentally add a secret leak/capability leak.
We tried many things to reduce the problems, and eventually settled on removing most of the intelligence from the slicer, to make it more predictable, and replacing most of the slicer's tier inference with annotations, to make sure that the developers actually paid attention to the decision. I believe that this wasn't sufficient.
It seems that main focus of Imba is code compression. I wonder, at which point they decided that they need a new language for that. I’ve seen things similar to ‘d:hflex ja:center’ many times, and it was achieved by writing a component that translates short props into CSS. I wonder, if there is a popular React library of such components (the ones I’ve seen were internal).
I feel like you missed the point of Imba. It's not solely focused on code compression (although that does appear to be a secondary objective). Instead, Imba is all about empowering developers to create declarative user interfaces without the typical complexities that often accompany such tasks, like dealing with reactivity, signals, custom directives, v-dom, and so on.
IMO there is inherent complexity in the task of creating dynamic user interfaces and reactivity/signals/directives are different tools to deal with this complexity by imposing different mental model on top.
In any case, if Imba offers a new approach it fails to communicate this on the landing page and focuses on code compression instead. To me it reads like Imba is a re-pack of status quo approach (React + Next.js) that focuses on compressed syntax. This is actually a good thing, I just wonder, whether a new language is necessary to achieve this.
> if Imba offers a new approach it fails to communicate this on the landing page and focuses on code compression instead.
Fair enough. While it does touch upon `memoized DOM`, you're correct; it might not be sufficient for readers to grasp the full implications unless they're well-versed in these kinds of libraries. For a deeper dive, you can check out this subpage: https://imba.io/guides/rendering. BTW, I don't have any affiliation with this library whatsoever.
> I just wonder, whether a new language is necessary to achieve this.
To achieve compression, no. But to achieve DOM reconciliation without a v-dom, yes.
From what I see, it vaguely claims to create so-called ‘edit maps’ at compile time, similar to Svelte and million.js. It doesn’t say anything about the algorithm it uses to generate them and what limitations their algorithm puts on application code. I’m planning to do a little research and a blog post on ‘edit maps’, I’ll probably include Imba there too.
How will it work if I put 2 counter components on one page?
If it’s just using global variable for state then it will be shared between component. You can do the same thing in React, it’s just a bad idea.
If it does some magic under the hood to convert regular variables into something different like Svelte pre-5.0 (which Svelte decided to make more explicit in 5.0), then could you point me to docs describing it, I’m curious which approach they took with this.
If you look on the linked page under the "Styling Evolved" section. It appears variables are scoped to the component instance. In the example given each clock has its own variables, even though it is individually set to a different UTC.
In that case the count variable should be moved into a property of the tag. I just like putting it outside the tag because it really drives home "its just a variable".
tag Counter
count = 0
<self @click=(count++)> "count: {count}"
it doesn't have to be anything. You're free to organize your code as you wish: colocate, in a different file ... the compiler doesn't transform the variable in any way, nor does it track its "mutation", it "just" "rerenders" on every change. And it's super fast too!
Do you think in the year 2100 we'll still write Python and C? From that point of view, sounds like we should be happy with the status quo and not create anything more.
Imagine if that was the case in 1991 when I'm sure someone else said "Do we really need Python and other languages? Isn't C, Lisp, Fortran enough?" We would have none of the nice ergonomics that current programming languages provide.
I just think making a new language (and therefore new ecosystem) just to make slight changes to syntax is a total waste of time personally.
Unless you really do something profoundly different in terms of type system, memory management etc, you're just making a new thing to learn and an extra nuisance to use if its toolchain sucks. "JavaScript but looks kind of different" doesn't clear that bar for me. We learned that from CoffeeScript.
I don't have any problem with people making languages for fun but to me if you're asking people to deal with the hassle of a new language it better be for a good reason.
I seem to haven't learned that yet, as I still use Coffeescript heavily and I'm happy it exists.
It's only one data point, but if it makes even just a few people happy, it already has enough reasons to exist.
> a new thing to learn and an extra nuisance to use if its toolchain sucks
> if you're asking people to deal with the hassle of a new language it better be for a good reason
I think the biggest confusion here is that you feel that someone is asking you to use the language, or that the creators of the language are pushing it in people's faces.
Couldn't be further from the truth. The creators build a language for their project (Scrimba.com) and had the nice idea to share it with us. If we find it compelling, we are allowed to use it, give feedback, and contribute to its development if we want it to grow.
I personally can only feel gratitude towards these people.
For whatever it's worth, this is interesting as someone who (a) wants to learn to build UIs, (b) doesn't care about getting a front-end job (so I don't care about learning React or whatever to get me a job) and (c) absolutely hates the Javascript bundled-compiling-insanity hell that is modern front-end.
I will absolutely consider any new simplified language and new ecosystem over this garbage that people only use because its pushed by FAANG companies to have enough labour to keep costs down.
So yeah, if you're a front end dev, maybe not worth it, but there are other demographics than hyper-specialized next/nuxt/react/svelte developers who MUST have the most artistic control possible to create little doodads and whatever.
The question isn't what "slight changes to syntax" the language makes now -- it's what the language can develop into over time. Python 30(!) years ago wasn't the same as Python today.
A small community of people might be interested enough in a language to keep it going until it develops into something interesting, or they might not. It's pretty near to classic darwinian evolution. You don't have to pay attention to every new language, and that's okay. If others do, and it grows into something you're interested later, pay attention to it then. For now, you can ignore it.
CoffeeScript brought more to the table than just syntax changes. Some of the recent niceties we have in JavaScript today were influenced by it.
Also, recall that the whole JavaScript ecosystem was kind of a mess when CoffeeScript was created. ES5 happened at around the same time and its predecessor, ES4, had gone nowhere. I don't remember polyfills really being a thing and you couldn't even use `forEach` reliably. Every JS question on StackOverflow used jQuery in the response whether or not you wanted it.
> Do we really need Python and other languages? Isn't C, Lisp, Fortran enough?
Well, actually... Those days we already had Prolog, Miranda, ML, Smalltalk... Lisp was already doing stuff even today's languages are just starting to do...
I don't know, but I kind of think that yes, that was quite enough... imagine if all the effort that went into Java/Swift/Python/JS had been put into those great languages.
I wouldn't be surprised if there is still a version of C in the year 2100, that can compile code written in the year 2060 or maybe even 2023.
That language might be mostly generated as a form of portable assembly by whatever new language is fashionable in 2100, although humans might still be writing in that language directly, possibly for IOCCC.
Programming languages are like plastics: there are 100s of 'em, each with their own characteristics, strenghts & weaknesses. Every single 1 of them has some niche in which they're better (or at least, preferred) over the others. Sometimes for historical reasons.
That said, like plastics I'm pretty sure we could get by with 10..20 (max) different ones. And those would be nicer to use if all development effort were spent on them vs. spread out over all the other ones.
But hey, who am I to tell someone to stop using / working on language x, y or z? Or which ones to pick as standard?
And that's fine but when you're trying to build something I think you lose a lot when you choose a niche language and the only benefit you get is that it looks a bit different than JS.
- TaskTXT - Plain text todos and tasks with timers https://www.tasktxt.com
- ReadyRunner - GPT chat for desktop https://www.readyrunner.ai
- Chonky Menu Re-Creation - Breakdown of a fancy menu UI https://www.nathanmanousos.com/posts/chonky-menu
I’ve made several videos about Imba too:
- Building a counter in 49 seconds: https://www.youtube.com/watch?v=8XS5q9xhaMc
- Video timeline UI: https://www.youtube.com/watch?v=GbKTEqmCAJM
- All of my Imba videos here: https://www.youtube.com/playlist?list=PLYxkh3w952l5cwxYLcCsd...
I made the (free) official course on Scrimba: https://www.imba.io/learn/imba
Which is also on YouTube: https://www.youtube.com/watch?v=8DcOgcCy7zs
I understand that Imba is not appropriate for everyone and every project but I encourage you not to dismiss it. One are where it is clearly valuable is in building prototypes and side projects.