Thanks for all your hard work on all of this stuff! 🙌

I think so, probably @U04VC31U8 needs to let us in.

alan linked me to "solve the first problem" which was very entertaining

Thx! That was wild. Nowadays the first thing we check is version numbers! With a utility for that!

what is your take on Web Components, ie. the standard ones that ship with web browsers these days?

i kind of like the abstraction, i think it's a good one, pretty ideal for wiring up to reactive state, good separation of concerns i think

i like that they somehow managed to restrain themselves from incorporating anything reactive, which i'm sure was very difficult for them

Got a link? Like, to a great web component? But, hey, if the component is fine, agreed, we connect to it and drive it like it was just a SPAN. "i like that they somehow managed to restrain themselves..." :rolling_on_the_floor_laughing:

The MX philosophy is to let the Wrappee be, by wrapping thinly. Less work for us, really.

i kind of like building the app with web components, using the encapsulated dom and css, etc. that can't really be emulated with plain html, css, and js

Do you have a link to a good web component? I honestly thought that initiative was dead. The beauty of both H/J and MX, is that we can emulate such things; our technology goes beyond plain html etc. Web/MX, for example, offers a built-in style type so we can specify a style where each style property has its own formula. I rarely use it, but when I do it is super self-documenting/configuring/debugging, based on surrounding state. We can even easily have one style property reactively adjust to another, such as altering background to dynamically adjust to color based on the latter's luminosity. Are web components that programmable? And the DOM api does offer that style property granularity of update. Huge performance win? Hugely unlikely. 🙂 But it goes to our power to author the DOM, the key to programmer productivity. I suspect a good web component falls short of such authorability, to invent a word, but hopefully they are parameterized sufficiently that a reactive wrapper could be as effective. But this is all too abstract. Let me know a great web component and we can get more specific. Looking forward to it, I really thought they were dead! Thx!

I have an app i wrote for a project of mine, all constructed using the web components api. i didn't use any off the shelf components, i made my own. i ended up putting that ui on hold, i'll see if i can open source it

the main advantage to using the web component api to construct a widget vs. functions which compose dom elements like in hoplon, is that web components provide a real low level api which your web component can extent to imlpement things like appendChild()

by extending appendChild your component can work properly with any js library that expects to use the dom node apis to navigate the dom etc.

like with the dom composition approach your widget's root element is usually not where you want children to be appended, web components allow your component to decide how and where children are added to it

Hmmm. Web/MX moves straight from proxy-dom kids to dom appendChild. Does Hoplon not do that? I did not look closely enough to see how it manipulated the DOM. And tbh, I cannot imagine a Web UI that does not maintain a valid, standard DOM navigable by arbitrary libraries. How on earth would a browser render such non-compliant DOM artifacts?

no, i mean supppose you have a widget in hoplon which has the following structure

(defelem foo [attrs kids]
  (div
    (div
      (map some-wrapper kids))))

if foo were a web component and kids up there were some lis, the DOM structure would look like this:

<foo>
  <li>...</li>
  <li>...</li>
</foo>

<div>
  <div>
    <li>...</li>
    <li>...</li>
  </div>
</div>

i think this is HUGE and i don't understand really why it hasn't gotten more traction

like this means that i can use off the shelf vanillajs libraries when i want to, and those libraries don't need to know about the inner structure of my components, because from their perspective there is none

also webcomponents allow you to implement your own attribute behavior

something that is impossible to do without monkeypatching things in js

and finally there is the css encapsulation option, which i think can be really powerful, especially when combined with reactive state to drive it

a lot of the latest css features that have become standard across browsers, combined with web components, makes it possible to create truly reusable components

unfortunately you need to make js classes in order to take full advantage of the web component stuff which is not well suited to cljs, but i figured all that out and it's just library code now, you don't need to mess with classes to create components

It does sound powerful, like the jump from ASM to 3GL, but is it too little too late? And the power of function composition still seems like it could go as far. Are components lighter weight/faster? I might not be a fair judge any more, now that Flutter has turned my head. I have kinda moved on from single platform programming.

do Flutter elements/components have a generic "append to me" extension point? if so it would seem that would align them with what webcomponents offer from my own use of components the big idea definitely felt like the generic append. after learning from micha i made a few for $WORK and part of the sell was, our existing jquery helpers and plugins actually worked with the new webcomponents, since jquery uses the native stuff

the proper mental image of that architecture is of a cave man putting on a brand new set of air jordans

Ah, $WORK. And legacy code! Blissfully ignored by us semi-retired, ivory tower, best of all possible worlds fiddlers! "extension point"? Whassat? And tbh, I still do not grok Web components. Meanwhile, I thought of another Matrix rule: "If a property is not an input, either a purely unwrapped value or a formula, it may not be set." That is just me being a fuddy duddy. We could allow it, but dataflow would not work. God forbid I start acting like a strong static typer, but I also buy into true freedom involving constraints. I think I mentioned that Garnet KR let's devs go wild. Seems to GOTO-ish to me.

Regarding the "add" I just mean it seems good when containers/collections participate in a generic interface. So you don't have to know the underlying structure of the container to put in or get things the way you do with html fragments

Flutter is pretty good, but at time it is shockingly uptight. "You cannot add that as a child, it does not inherit from SizerBlub". And there is none of the deep consistency of HTML: parent, children*, attributes, we're done. My god, they even have .child and .children depending on whether a list is allowed! :) And because it is OO, every widget designer can go their own way. I ended up with a half-dozen patterns after wrapping just 20% or so of Flutter.

^^ this is how web components work