Concerns separation

[imba]

Concerns separation

[somebee]

It is slightly more difficult to separate than one would guess. Since tags really is a core part of the language, I'm not sure where we would draw the line. It is possible to move more of the tag related methods out into a separate library, but since ie. <div.large.warn> is a valid and native part of the language, we need the runtime/framework for that to work as expected (I think).

Is the motivation to be able to use the tags without Imba, or merely to clean up and tighten imba 'core' and be able to use Imba without including all this tag-related stuff? :)

Motivated by the fact that after CoffeeScript hype ppl actively looking for an alternative syntax and ES6 does not fit too well.

The keyword here is "syntax", cause a general purpose language needed, i.e. tags not needed on server... Instead a strong small core that evolves separately from the tags needed.

But if you say Imba was not intended as a general purpose superset, that's ok.
After all, no tool can fit all needs.

[somebee]

Since tags is in fact a core part of the syntax itself, it is probably difficult to separate the two without basically splitting it up into two languages :/ But even though tags are useful specifically for web apps, Imba itself can be used as a general purpose language? Some languages don't have first-class support for regular expressions. But a language like js has.. you can create a regexp with the /regex?/ syntax. It would feel pretty strange if that could throw an error RegExp library not included? Unless we split up Imba in two languages, that would happen if you tried using tags (native syntax) without including the 'framework'.

Maybe we should simply market it more as a general purpose language - because it absolutely is. But imho people who create web apps will get the most benefit from it :)

[lukeed]

I was thinking about this in the car yesterday.

👍 I think it'd be great to split the language from the library. The compiler would stand separate from the lib, and could accept a --lib flag that would internally switch compilation logic for Imba (global) based helpers as opposed to natively-stubbed replacements.

This allows anyone (hello ruby devs?) to write more natural-feeling JavaScript, with option of easily working with/integrating a great DOM library too.

Essentially, Imba acts as the CoffeeScript 2.0 (for syntax & compilation), but comes with an optional but highly recommended library behind it.