This is an impressive framework and the performance seems to be outstanding. Have you considered posting your framework to https://krausest.github.io/js-framework-benchmark/current.html so that we can do an apples to apples comparison?

Rebranding Process for Imba

The purpose of this is rebrand is to visually establish Imba as a reputable contender to the major branded web frameworks and languages. This rebranding process is being lead by @iamtirado in a way that is orderly and effective. @iamtirado has 10+ years of experience, in a way that is orderly, and will result in a professional result for the brand. @iamtirado is available to refine any design chosen before the final implementation of the brand.

The following steps will hopefully make the process orderly and effective:

2.2 Submit Black & White Logos that fit the identity of Imba (Fun/Fast/Powerful) 2.3 Submit Colors that fit the Identity of Imba (Fun/Fast/Powerful)

Step 1:

The process will begin by identifying 3-5 major characteristics for the Imba language and community.

• [X] 1.1 Comment below with 5 characteristics that exemplify imba and the community to you, and rank them in order of 1-5

1.1 Result

Here is a tally of the votes of why we love Imba.

Fast Performance: 33 votes
Beautiful Syntax: 29 Votes
Capability/Functionality: 21 Votes
Fun to Use: 11 votes
Rebel: 4 votes

I simply weighed the votes as follows:

1. = 5votes
2. = 4votes
3. = 3votes
4. = 2 votes
5. = 1 votes

I then, combined the votes for the words that were similar as follows

Fast Performance: Fast(29) + Responsive(4) = 33 Beautiful Syntax: elegant(9) + clean(5) + simple(7) + easy(3) + comfortable(1) + readable(4) = 29 Capability/Functionality: smart(9) + innovative(5) + expressive(5) + intuitive(2) = 21 Fun to use: funny(2) + playful(5) + fun(3) + quirky(1) = 11 Rebel: rebel(1) + antimainstream(3) + radical = 4

Conclusion

Developers are drawn to Imba primarily because of its unmatched performance. Secondly, by its simple, readable syntax. Thirdly, by its near-limitless functionality. And lastly, perhaps because the vDOM has such a strong community behind it, you will find that early Imba adopters must have a bit of a rebellious spirit to challenge it.

Identity of Imba

Since the votes add up to 98, we can treat the votes as a percentage as you think of future contributions to the brand.

Imba's identity lies 33% on Speed, 29% on Simplicity, 21% on Functionality, 11% fun and 4% Rebellious.

We can attribute the other 2% to other single votes that didn't get clumped in like fresh or future.

Step 2

• [x] 2.1 In 3~7 words, write a tagline for Imba that embodies Imba's Identity. The less words, the better.

2.1 Result:

Tagline: The Fun, Fast, Powerful Web Lang.

The tagline is simple and clear, and incorporates 3 elements of Imba that are key to Imba users. Easy language was mentioned a lot. Fast was mentioned a lot, but creator of Imba recognizes that it may not always be the "fastest", Powerful is another key feature of Imba, because it's not only fast, and easy, it's also highly capable of building fully-capable web applications from front end to backend.

Fun/Play/Simple = 10 mentions Fast = 7 Mentions Smart/Powerful/Pro = 3 mentions

• [x] 2.2 Submit Black & white Logos that embody the identity of Imba Starting with a black and white logo design makes sure that the logo has a better design, and then color can be integrated unto the design. Think about a language Icon for code editors as you design.

• [x] 2.3 Submit Colors that embody the identity of Imba, with moodboard or mockups if possible. (https://coolors.co/ is a great tool for building and sharing a color palette.

🚧 WORKING ON STEP 3.0

Step 3: Final Brand Proposal

Code of Conduct

Any creative process will seem subjective to personal opinion to most people, and opinions can be endless.

• Keep your input short, constructive, and focused around the identity of the brand, rather than personal identity.
• Address comments to the task at hand, and use reactions to provide feedback.
• For back and forth discussion, discuss in gitter to keep the thread clean.

We appreciate any orderly involvement in this thread by anyone. Special attention to @somebee @foxbunny @altteo @madmaniak @russoturisto @allain @sh4hids @nemanjaglumac @athif23 @perborgen

The imba documentation does not indicate what constitutes valid indentation.

In discussion with @somebee there was agreement that it is tabs only.

Please document & adjust the lexer to only use tabs as indentation.

I'm looking through the lexer now to see if I can find where the lexer makes that decision.

Imba Version: 2.0.0-alpha.100

import 'imba/router'

let counter = 0

imba.mount <header>
	<a route-to="/"> "Main"
	<a route-to="/one-page"> "ONE-PAGE"
	<a route-to="/two-page"> "TWO-PAGE"
imba.mount <main>
	<em> "Counter: { ++counter }"
	<div route='/one-page'> "It one-page"
	<div route='/two-page'> "It two-page"
	<div route='/'> "It main-page"
imba.mount <footer>

It stopped working after clicking on links

video.mp4.zip

Any particular reason why these are missing?

b: red5 5px solid - border: bb: red5 5px solid - border-bottom bt: red5 5px solid - border-top bl: red5 5px solid - border-left br: red5 5px solid - border-right

Maybe we could include css in Imba as it was done with html? I see it this way: we can have additional to render function (for example style) where we write css for the current Imba tag with readable and light syntax (stylus alike) and with hierarchy. At the moment css in the comments looks at the wrong place.

def style
     [self]
           color:red
           display: block
           [div]
                  color: white

The 3xl syntax interferes a little with dimensions / numbers with units, and does not feel too clean imho. It is also definitely possible to just use concrete font sizes instead of any of these aliases, but I've grown to like them, and think that designing becomes easier when we deliberately constrain ourselves with these types of presets. Same goes for box shadows and border radius etc.

Let's keep the sm- md- lg- variants out of the discussion - they are a separate issue/discussion.

So, to cover more ground I'm proposing another size alias, hg for huge. Then we have sm md lg xl hg. There are some potential variations here. The current proposal I'm liking the most is:

xxs 10px
xs  12px
sm  14px
md  16px
lg  18px
xl  20px
xxl 24px
xxxl 30px
hg 36px
xh 48px
xxh 64px
xxxh 96px

For reference, here is the current scale:

xxs 10px
xs  12px
sm  14px
md  16px
lg  18px
xl  20px
2xl 24px
3xl 30px
4xl 36px
5xl 48px
6xl 64px

What are your thoughts?

For Imba v2 we are trying to get an official mascot. Below are some proposals from Torarin Jørstad, which ones do you like best? Please reply with either a screenshot of the versions or color and position.

Thanks.

Description

(1) Ability to generate a range with the range syntax.

const range1 = [0..2] # --> [0, 1, 2]
const range2 = [0...2] # --> [0, 1]

(2) Ability to generate a dynamic range with the range syntax.

const start = 0
const end = 2

const range1 = [start..end] # --> [0, 1, 2]
const range2 = [start...end] # --> [0, 1]

Why

This would be really useful in keeping things DRY. We could declare a range and reuse it in multiple places if needed.

Possible Implementation & Open Questions

I am very new to this language so maybe I'm missing something here. :)

(Posted this comment on HN, but figured I'd copy it here for discussion.)

I just spent an hour looking at the Imba benchmark. Yep, it's cheating. Which is a shame, because I really like the framework as a whole.

The vast majority of the speedup comes from a single sneaky line of code. The majority of their "Everything" benchmark's time is spent in the reorder step. They've implemented this as "remove a random todo, render, push the removed todo back onto the end, render." The Imba implementation, and it alone, caches the rendered todo view, so that they can re-use it once the todo is reinserted. This single optimization is responsible for the vast bulk of their claimed speed. Removing it puts Imba only 2x faster than React, not 60x.

If you want to try it yourself, look at line 55 of app.js. Change:

    res.push((this['_' + todo.id] = this['_' + todo.id] || t$('todo')).setObject(todo).end());

... to:

    res.push(t$('todo').setObject(todo).end());

Furthermore, this isn't a caching strategy you'd want to use in a real app. It holds onto all DOM nodes ever created, thereby leaking quite a lot of memory.

Again, I think Imba is cool, and fast, just not otherworldly fast. I hope this was just an "oops!" and not an intentional misrepresentation.

tag foo
    def render
        <self>
            if true
                <h3> "hello"
                <h3> "world"

Compiles to:

return this.setChildren((true) && (
    [(this[-1] = this[-1] || t$('h3')).setContent("hello").end(),
    (this[-1] = this[-1] || t$('h3')).setContent("world").end()
    ]
)).synced();

The error seems to be caused by the key being chosen by var key = parent.tree.indexOf(self), and self isn't a children of the foo-tree.

Description

I get a warning in the console for css & + & mt:1.2em

▲ [WARNING] Unexpected "{" [css-syntax-error]

    app/shared/types/markdoc/config.imba?styles:3:9:
      3 │ .ku-af + {margin-top: 1.2em;}
        ╵          ^

Reproduction

https://scrimba.com/scrim/cqmnDrt7

System Environment

*

Description

this code

class Command
        process
	def run
		process = new WCProcess({proc, cmd: self})
		console.log "ran {cmd}", process

return process = new WCProcess({ proc, cmd: this }), console.log("ran " + this.cmd, process);

and JS complains about undefined process

Reproduction

System Environment

*

Currently imba can infer when a definition is an object with no need of curly braces

let object = 
	one: "one"
	two: "two"
	three: "three"

Could the same be done for arrays?

let array_of_objects =
	a: "a"
	b: "b"
	c: "c"
	---	
	one: "one"
	two: "two"
	three: "three"
let array_of_primitives =
	"one"
	2
	three
	{key:val}
	key:val # same outcome as previous
	[array]
	true

Maybe allow it if we specify the data type?

let data\array = 
	"one"
	2
	three

I also want to propose an additional syntax for object arrays. Could this be made possible? It would save many lines of code for me on some data heavy projects.

let array_of_objects =
---	a: "a"
	b: "b"
	c: "c"
---	one: "one"
	two: "two"
	three: "three"

Description

I was trying to boot up the imba.io docs server, and I expected the server to boot up. Instead, I got this ugly error message:

npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '@jest/[email protected]',
npm WARN EBADENGINE   required: { node: '^14.15.0 || ^16.10.0 || >=18.0.0' },
npm WARN EBADENGINE   current: { node: 'v17.8.0', npm: '8.7.0' }
npm WARN EBADENGINE }
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '@jest/[email protected]',
npm WARN EBADENGINE   required: { node: '^14.15.0 || ^16.10.0 || >=18.0.0' },
npm WARN EBADENGINE   current: { node: 'v17.8.0', npm: '8.7.0' }
npm WARN EBADENGINE }
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '@jest/[email protected]',
npm WARN EBADENGINE   required: { node: '^14.15.0 || ^16.10.0 || >=18.0.0' },
npm WARN EBADENGINE   current: { node: 'v17.8.0', npm: '8.7.0' }
npm WARN EBADENGINE }
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '[email protected]',
npm WARN EBADENGINE   required: { node: '^14.15.0 || ^16.10.0 || >=18.0.0' },
npm WARN EBADENGINE   current: { node: 'v17.8.0', npm: '8.7.0' }
npm WARN EBADENGINE }
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '[email protected]',
npm WARN EBADENGINE   required: { node: '^14.15.0 || ^16.10.0 || >=18.0.0' },
npm WARN EBADENGINE   current: { node: 'v17.8.0', npm: '8.7.0' }
npm WARN EBADENGINE }
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '[email protected]',
npm WARN EBADENGINE   required: { node: '^14.15.0 || ^16.10.0 || >=18.0.0' },
npm WARN EBADENGINE   current: { node: 'v17.8.0', npm: '8.7.0' }
npm WARN EBADENGINE }
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '[email protected]',
npm WARN EBADENGINE   required: { node: '^14.15.0 || ^16.10.0 || >=18.0.0' },
npm WARN EBADENGINE   current: { node: 'v17.8.0', npm: '8.7.0' }
npm WARN EBADENGINE }
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '[email protected]',
npm WARN EBADENGINE   required: { node: '^14.15.0 || ^16.10.0 || >=18.0.0' },
npm WARN EBADENGINE   current: { node: 'v17.8.0', npm: '8.7.0' }
npm WARN EBADENGINE }
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '[email protected]',
npm WARN EBADENGINE   required: { node: '^14.15.0 || ^16.10.0 || >=18.0.0' },
npm WARN EBADENGINE   current: { node: 'v17.8.0', npm: '8.7.0' }
npm WARN EBADENGINE }
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '[email protected]',
npm WARN EBADENGINE   required: { node: '^14.15.0 || ^16.10.0 || >=18.0.0' },
npm WARN EBADENGINE   current: { node: 'v17.8.0', npm: '8.7.0' }
npm WARN EBADENGINE }
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '[email protected]',
npm WARN EBADENGINE   required: { node: '^14.15.0 || ^16.10.0 || >=18.0.0' },
npm WARN EBADENGINE   current: { node: 'v17.8.0', npm: '8.7.0' }
npm WARN EBADENGINE }
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '[email protected]',
npm WARN EBADENGINE   required: { node: '^14.15.0 || ^16.10.0 || >=18.0.0' },
npm WARN EBADENGINE   current: { node: 'v17.8.0', npm: '8.7.0' }
npm WARN EBADENGINE }
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '[email protected]',
npm WARN EBADENGINE   required: { node: '^14.15.0 || ^16.10.0 || >=18.0.0' },
npm WARN EBADENGINE   current: { node: 'v17.8.0', npm: '8.7.0' }
npm WARN EBADENGINE }
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '[email protected]',
npm WARN EBADENGINE   required: { node: '^14.15.0 || ^16.10.0 || >=18.0.0' },
npm WARN EBADENGINE   current: { node: 'v17.8.0', npm: '8.7.0' }
npm WARN EBADENGINE }

up to date, audited 300 packages in 12s

73 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

> [email protected] build
> npm run build-content && npm run build-api-docs && imba build index.imba


> [email protected] build-content
> imba scripts/build-content.imba

error here Error: EPERM: operation not permitted, symlink 'C:\Users\Robotics\imba\imba.io\node_modules' -> 'C:\Users\Robotics\AppData\Local\Temp\tmp-1968-wIERrm3Vx0Wd\node_modules'
    at Object.symlinkSync (node:fs:1668:3)
    at De.write (C:\Users\Robotics\imba\imba.io\node_modules\imba\bin\imba.imba.js:172:2634)
    at C:\Users\Robotics\imba\imba.io\node_modules\imba\bin\imba.imba.js:169:768
    at processTicksAndRejections (node:internal/process/task_queues:96:5) {
  errno: -4048,
  syscall: 'symlink',
  code: 'EPERM',
  path: 'C:\\Users\\Robotics\\imba\\imba.io\\node_modules',
  dest: 'C:\\Users\\Robotics\\AppData\\Local\\Temp\\tmp-1968-wIERrm3Vx0Wd\\node_modules'
}
Error: Cannot find module 'marked'
Require stack:
- C:\Users\Robotics\AppData\Local\Temp\tmp-1968-wIERrm3Vx0Wd\build-content.js
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
    at Function.Module._load (node:internal/modules/cjs/loader:778:27)
    at Module.require (node:internal/modules/cjs/loader:999:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at renderer (C:\Users\Robotics\imba\imba.io\src\util\markdown.imba:1:16)
    at C:\Users\Robotics\AppData\Local\Temp\tmp-1968-wIERrm3Vx0Wd\build-content.js:9:59
    at Object.<anonymous> (C:\Users\Robotics\imba\imba.io\scripts\build-content.imba:7:10)
    at Module._compile (node:internal/modules/cjs/loader:1099:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:975:32) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    'C:\\Users\\Robotics\\AppData\\Local\\Temp\\tmp-1968-wIERrm3Vx0Wd\\build-content.js'
  ]
}

Node.js v17.8.0 

Run the command below to reproduce the issue.

Reproduction

npx imba create test-throw && cd test-throw && npm i && npm run build

System Environment

System:
    OS: Windows 10 10.0.19043
    CPU: (2) x64 Intel(R) Celeron(R) CPU  N3060  @ 1.60GHz
    Memory: 1.02 GB / 3.91 GB
  Binaries:
    Node: 17.8.0 - C:\Program Files\nodejs\node.EXE
    npm: 8.7.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Spartan (44.19041.1266.0), Chromium (107.0.1418.35)
    Internet Explorer: 11.0.19041.1566
  npmPackages:
    imba: ^2.0.0-alpha.223 => 2.0.0-alpha.225

Description

vscode is complaining this error for tsconfig.json

and ts-plugin cannot see the type of global component

i have to diable checkJs to silent these errors