Suggestions

[NxtChg]

Some suggestions:

1. Rename $type into $tag, it's more appropriate and less confusing, otherwise: $type: "input", type: "text"

2. Rename $components into $kids. Again, less confusing, more appropriate and much shorter!

3. Reverse the naming convention: attributes should start with $, everything else is regular names. Since there are just a few attributes, it makes sense to mangle their names instead of prefixing all the variables with '_', which makes it harder to read. You only use a few reserved keywords (like $tag and $kids), so you can distinguish them from the attributes.

4. Remove $cell, detect elements by $tag, allow $tag == ''.

[devsnek]

2. i would say if $components were going to be renamed (big if), that$children would make more sense than $kids.
3. i personally think the current convention is pretty nice, as the entire idea is to be as "close" to the elements as possible, and this idea would mean renaming all the other attributes
4. it would be dangerous to use a data type to also identify an object as a cell. having a first-class identifier prevents strange issues from popping up, and allows future changes to be made in a safer manner

[NxtChg]

that $children would make more sense than $kids

It's significantly longer, while meaning exactly the same.

i personally think the current convention is pretty nice, as the entire idea is to be as "close" to the elements as possible

It is nice for tutorial examples. In any real world use you will quickly discover that the amount of user data will far outweigh the attributes. It also makes sense to highlight DOM elements, since it's a JS object - regular names should be regular members, as they are in JS, and anything different requires a special highlighting to make it clear.

it would be dangerous to use a data type to also identify an object as a cell

It's no more dangerous than $cell, but removes one keyword and makes things simpler and actually more reliable.

[Caffeinix]

I agree with @devsnek: $children would be fine, but $kids is non-standard and confusing (albeit shorter).

I strongly disrecommend switching $ to HTML attributes. There are not "only a few": there are in fact an almost infinite number, particularly if you use web components (which can define their own) or data- attributes. Since both of those use dashes in their attribute names, mangling the name would be very dangerous. Today:

{
  $type: 'my-custom-element',
  'my-custom-attribute': true
}

With your proposal:

{
  tag: 'my-custom-element',
  '$my-custom-attribute': true  // ??
}

[guscost]

Based on some of these suggestions I've made updates to the API experimentally:

#25

Here's a gist using this API:

https://gist.github.com/guscost/d47e3437e75cd72293cede3ef847121d

It has a couple of changes:

• Keywords and custom props start with $, HTML attributes don't. Could go either way on this but keywords and custom props can definitely share a style.
• No more $type keyword, the tag name is now the value of $cell instead of it being a boolean. Basically I'm gambling that it's worth it to save the extra property on every cell.
• Trying $contents instead of $components because it is shorter.

[NxtChg]

Keywords and custom props start with $, HTML attributes don't. Could go either way on this but keywords and custom props can definitely share a style.

There are two main reasons to switch:

1. This is a JS object, so it would be nice if all the variables you put there behave exactly as they do in JS, so the user can write his code the same as before. '$' will clearly highlight everything that has a special meaning, like DOM attributes or keywords.

2. In real world usage the number of attributes on an element is nothing, compared to user's code. This library is not for defining page structure, right? It's for writing dynamic apps. If people want to define DOM via JSON, that's a different project. But if you want to compete with frameworks, you need to favor code over DOM structure.

No more $type keyword, the tag name is now the value of $cell instead of it being a boolean.

I would still prefer $tag, because it's shorter and clearer. Anyway, that's not that important...

Trying $contents instead of $components because it is shorter.

How about $body? It's as short as $kids and has proper meaning in the context of DOM.

[guscost]

• For the question of "what gets the $ prefix?" I don't think I understand this framework's strengths enough yet to confidently argue for one over the other. On one hand, putting a prefix on the HTML attrs calls out that this is just a proxy object, and that these values have special effects. On the other, not having a prefix on HTML attrs means they match the actual DOM structure. I think there are cases you might not be thinking of where matching the actual DOM structure actually is worth it, but I don't do a lot of static site development or experiment much with web components myself.

• Yeah, it's not that important. I like the uniqueness and brand value of $cell, but $tag is a fine key too.

• I did consider naming the children collection $body, but it's a bit less explicit for the savings you get.

Another idea - what if $tag was used to set the HTML tag, and we called the children collection $cells? Might be too confusing but I think you'd get used to it.

[NxtChg]

On the other, not having a prefix on HTML attrs means they match the actual DOM structure.

This decision should come form the purpose of the library. If it's just to create DOM from JSON, then $ indeed should not be on attributes. But if this library is for dynamic apps, then it makes more sense to mark few special elements and let the user write his code as before.

These special variables are not JS variables, they mean different things, that's why they should be highlighted - to make it clear they are proxy entities for DOM. And to not make programmer's life harder by forcing him to mangle all his variables!

But anyway, the great thing about this library is that it's tiny, so anyone can easily clone it. If one implementation is not willing to be the smartest implementation, somebody will clone it and make a smarter version. So in the end we will have a very good library, one way or another.

Another idea - what if $tag was used to set the HTML tag, and we called the children collection $cells?

It's one of those cute names, which sounds "cool", but is actually more confusing. The library already has a lot of cute names, like "genotype" and what not. These are fun for 15 minutes, and in general should be avoided.

[guscost]

This decision should come form the purpose of the library. If it's just to create DOM from JSON, then $ indeed should not be on attributes. But if this library is for dynamic apps, then it makes more sense to mark few special elements and let the user write his code as before.

Well that's a tough question. What is the purpose of the library? It's hard to say what it might excel at yet, but it might not be the same as something optimized for making big interconnected apps.

But anyway, the great thing about this library is that it's tiny, so anyone can easily clone it. If one implementation is not willing to be the smartest implementation, somebody will clone it and make a smarter version. So in the end we will have a very good library, one way or another.

Definitely, the small size and reuse of built-in JS features is a huge strength.

The library already has a lot of cute names, like "genotype" and what not. These are fun for 15 minutes, and in general should be avoided.

I don't agree, the fact that they clearly come from a domain outside of "normal" programming cuts both ways. On the one hand, it violates the principle of least astonishment, but on the other those words can lock people into a certain way of thinking. At least for now, the choice to pick conventions that model biology might be a strength.

[gliechtenstein]

Guys I just wrote a post to address a lot of issues mentioned here #111

Sorry for the delay, i took some time making sure I express myself clearly so that there's no misunderstanding.

Note that this post is not some idea that's set in stone. I just wanted to share what I was going through when I made all these decisions, since I haven't really talked about those. So please feel free to share your thoughts after reading that. If you still think some of the ideas are bad, feel free to point them out, would love to discuss further.

[gliechtenstein]

Closing since the linked post addresses all the questions brought up here. I appreciate all the feedback shared above, if you have further questions, please feel free to continue the discussion on the linked post.