Haxe

but think it's beginning to get clean enough to use. although much less features it is easy to hook up, tries to do less.

hscript is no longer a haxeui dependency 🥳

hscript removal seemed to save 400kb on JS output though I didnt set up a "good test".  It seems to be required in other backends still though that is assumed because it still lists it as a library in vscode

its a start, there are certainly other issues though... namely it looks like the haxeui macros are bringing in refs to all components... 🤦‍♂️

https://github.com/haxeui/haxeui-core/blob/master/haxe/ui/macros/ModuleMacros.hx#L226

thought really, its this: https://github.com/haxeui/haxeui-core/blob/master/haxe/ui/macros/ModuleMacros.hx#L235

im trying to hack it a little at the moment, just to see if it would have a positive impact

Yeah seems to do way more than needed in many cases

it does _all_ of them... everything in the classpath that is Component derived

i wasnt aware to be honest that getModule / getType adds it to the dependencies and output

It doesn't add to output if you enable dce full °°

Must be something preventing it to get rid of it entirely :x Not the issue anyway

Parsing the classpath in search for all components is very expensive

And uh.. what's the use of populateClassMap()?

indeed, and a quick way to fill up deps it seems

its basically to so that xml can work... ie button => haxe.ui.components.Button

(oh wait I'm on my coconut sample, no wonder it still works there xD)

im pretty sure i can do that on demand though

(need to disable it entirely somehow for coconut, but later °°)

so far ive hacked it in and my output size has halved (900kb)

- emptied `populateClassMap()` (well, added a `return;` to first line)
- added this to the beginning of Macros.build(): 
```
var cls = Context.getLocalClass();
haxe.ui.core.ComponentClassMap.register(cls.get().name, cls.toString());
```

right, yeah, ofc... cocnut doesnt need the xml stuff