Style of-, and theory behind the library

[karimayachi]

It seems like we have different views here. My view is that the simpliest and fastest way to handle these complex UIs was to move the HTML markup inside of single-file-component JS files and use real template literals to evaluate them along with real JS expressions.

You seem to have a preference to avoid this and instead implement a subset of javascript in raw HTML files via a complex and inevitably slower parser.

I feel our biggest and most important challenge is to reach consensus about this.

For that reason I'm concentrating on the Propostion. I think if we can get consensus about what we're aiming for, the implementation will follow. And of course I'm very much willing to be 'persuaded' to go 'your way' if that way would cover all the values we include in the proposition.

Right now however I'm a bit reluctant. I think the things I've seen from Knockdown so far in the way it focuses on single-file-components would make it very difficult to fully support the 'Horizontal SoC'-use case, that in my opinion is crucial.

(I haven't written the part about horizontal- vs vertical- SoC yet, so I can't yet fully explain what I mean by it, and also the terminology could change 😉 )

Tbh, I think the proof of concept I made with custom KO-bindings that allow working with WCs already cover almost all of the functionality I envisioned. Thing is: I can't publish it until the bug in KO's templating engine is fixed (I do have a patch for that).

But you made an excellent point about not getting traction on a plugin for a library that is 10 years old and has a lot of inherent problems.

So I think it would be really cool to have a new binding engine in place of KO that would also address CSP, performance, (and as per my taste: decoupling VM from library and syntax of markup), etc...

And if Knockdown does that, than that's great!

OTOH if that engine (say Knockdown) would bring it's own way of doing things, I feel like I'm deviating a lot from the goals I set out for.

If I were to drop my IE-compatibility requirement and would use new(er) technologies like MutationObservers and Proxy-objects it wouldn't be that hard to create such an engine. But, than again: I wouldn't be able to launch or maintain it properly by myself. This is not a one man job as we both already concluded.

So I sincerely hope we still can find common ground. And the way to find this out is probably by putting the technical discussions to the side for a moment and try to get that proposition ready. I will continue working on that the next week or so.

Oh, by the way: it would really help if I could play around with Knockdown a bit. 😄

[avickers]

OTOH if that engine (say Knockdown) would bring it's own way of doing things, I feel like I'm deviating a lot from the goals I set out for.

Well, every library will have an idiomatic way of doing things.

You had mentioned using JS style template literal expressions inside the View. That would result in the exact same View abstraction/implemention, so now it's really only a question of the file extension the View lives in.

Knockdown doesn't really care whether or not things are single file, but components should ultimately be assembled and exported in a single module file.

That's not to say that some/most/virtually all of your HTML couldn't live in an HTML file. Your CSS could live in an S/CSS file. You could configure Webpack/Parcel to import it; or, you could just write it as a JS Template Literal and export/import that and drop it into the components.

The latter is what I do. I have a VS code plugin where any TL preceded by /*css*/ is highlighted as CSS. I create a theme folder and put all of my common theming inside of the index.js and export it.

I tend to include styling specific to an individual component in the base component file, but only if there is a small amount of it. If there is a lot, I would put that in its own file, in the component's directory, and import it also.

View Models can be much the same. Why not use composition for ViewModels also? Isolate business logic/model defined ViewModels into their own folder for reuse and maintainability.

/viewmodels/user/index.js

import {Observable} from '@avickers/knockdown'

export const UserViewModel = {
  username: new Observable()
}

/theme/index.js

export const theme = /*css*/`
a {
  background-color: cobalt;
  text-decoration: none;
}
`

/components/some-widget/index.js

import {Koc} from ...
import {UserViewModel} from '/viewmodels/user'
import {theme} from '/theme'

class SomeWidget extends Koc {
  constructor() {
    super()
    const ko = this.ko()
    const ViewModel = {
      uiSpecific: ko.observable()
    }
    const vm = {...UserViewModel,...ViewModel}

    this.html`<h1>Hello, ${vm.username}!</h1>`

    ko.applyBindings(vm)
  }
  render() {
    this.css`${theme}`
  }
}

Reusable CSS/ViewModels in their own folders to be imported as needed. Reusable HTML as a Component/Custom Element. Is that horizontal enough?