[bl4ckm0r3]

imo the readability of the proposed solution is not the best, especially for more complex things... it isn't clear to me if he is proposing that to be "under the hood" (like react's createElement), but if not i don't think it's a better solution (even though i understand the problem of using "custom syntax" but it's pretty normal when you are building "on top" of APIs.

[mickael-kerjean]

I am getting through the same phase of rewriting my OSS [1] in vanilla JS [2], the solution I settled down on is to write components in pure es6 like this:

  export default function(render) {
      const $page = createElement(`
          <div class="component_helloworld">
              whatever here
          </div>
      `);
       render($page);

       $page.addEventListener("xxxx");
       onDestroy(/* remove listeners */);
  }

Yes I sort of had to write my own mini framework but it's well under 100 lines of codes [0] with the idea that maintaining that 100 lines of codes is gonna be a massive win compared to keeping up with any "modern framework" npm hell

The core idea is that instead of trying to pretend some cool ideas like HOC or render props, we call a dog a dog and say "decorator pattern" and just use the pattern directly [3] and when we need to compose things we do so as well [4]

ref:

- [0] the skeleton I started to settle on a nice API before starting the full rewrite https://mickael-kerjean.github.io/skeleton/example/index.htm...

- [1] original oss project which I'm migrating: https://github.com/mickael-kerjean/filestash

- [2] current state of the rewrite where you can see this pattern in action https://github.com/mickael-kerjean/filestash-rewrite/tree/ma...

- [3] https://github.com/mickael-kerjean/filestash-rewrite/blob/ma...

- [4] https://github.com/mickael-kerjean/filestash-rewrite/blob/ma...

[bl4ckm0r3]

what is this giving you more than using svelte or something like lit-html?

https://mickael-kerjean.github.io/example/counter

looking at this example (i personally don't like the template string for dom because it's a bit of a pain to read and you need a lot of manual work later, separated from the definition of the markup, to add eventhandlers etc) you rely a lot on rxjs to handle state and IMO it's a bit hard to follow what is going on, compared to https://svelte.dev/repl/f5acc8113ec14bc7946eff9687916fa1 for example

[mickael-kerjean]

> what is this giving you more than using svelte or something like lit-html?

1. that's a trade off. From my point of view most framework provide short term win at the cost of the long run, this short term win is what we call "nice dev experience" and the long term cost is on the maintenance side when your dependencies will be rotten or someone will realise a dependency of your dependency of your dependency was disguised as a trojan. I don't get paid to upgrade my OSS project, if I can make that part much simpler, that's a BIG win for me even if the code doesn't look as nice as in svelte

2. The end goal is to enable people to change the end product by pushing patch of the frontend without having to recompile anything. I have many people contacting me to make changes to the UI and I can't make it because it doesn't make sense for 99% of the users, with this approach I can make a plugin for 1 dude without affecting anyone else and by just shoving a diff of what I need to change to enable that use case

3. I can actually read the code of 100% of my dependencies and yes I've had situation where I was asked this question

> you rely a lot on rxjs to handle state and IMO

yeah I'm a rxjs fanboy, can't help it but this is just a example you could use whatever rock your boat, my boat is definitly on the rxjs camp