7 ms·

Lol, love your comment! Funny thing is that there are more people on your side than what this community might tell you! Silence is golden for a reason ;)

parksy 6y ago
I appreciate the support I guess but at the same time I don't understand what you mean by there are an unspecified number of people on my side and that silence is golden - either that means I should be quiet and join the throngs of the self-superior invisible some-jority which I think is condescending to the fine folk here, or it means I personally should be silent and not express my honest confusion, frustration and dismay. That's not going to happen either. I did come out pretty strong in my apprehension but I am serious in wanting to know specifically what the benefit of this is, and I don't really care whether I am making a fool of myself for asking questions lol.
- dmitriid 6y ago
  Theory: web components provide a standardised component model for the web so that you don't need to rely on frameworks and a bunch of JavaScript to create interchangeable interoperable components that are no different from built-in browser components. Oh, and you can extend existing built-in components with your own behaviours. Reality: - WebComponents is a collection of 4 web standards, one of them is already deprecated, and v0 of another one is also already deprecated. - The standards provide a verbose, error-prone imperative API that leaks implementation details left and right - The API is so bad, that the official stance is "the API is aimed at library and framework developers, and you are not expected to write your components using this API". And if you look at the frameworks, they try to not even compile/transpile down to this API - Since all WebComponents basically have is DOM APIs, the official stance is basically "yeah, they are good for implementing leaf nodes" (that is basic dump components like an simple input field, or a label) because you still need a full-fledged lib/framework for anything else - You cannot extend some (most?) of the built-in components. And even if you can, your custom implementations will not participate in form events, so you have to create workarounds if you want to submit values from your components - They break accessibility - They don't work without JavaScript - They cannot be rendered server-side - They are not strictly HTML, but a subset of it, because you can't provide callbacks for their custom events (you can do onClick, but you cannot do onSomeCustomEvent) - And on the social side of things, their proponents will very rarely acknowledge or discuss these issues in public (even though there are dozens if not hundreds of issues with extensive discussions on GitHub), but will spend not an inconsiderable amount of time and energy bashing non-webcomponent libraries and frameworks
  - parksy 6y ago
    Okay I think I get it: 1. Define elements in script by extending htmlelement 2. Follow the allowed structure in the DOM so that the custom elements don't break / conflict with anything 3. Use CSS to make the custom element look nice. Then, basically what we have is: 1. A class-based way to attach event listeners in a standard interface (which is nice) 2. what we always had to do anyway (unless framework forces using JS to inject HTML at runtime) 3. what we always had to do anyway 4. Can't use custom events anymore... Encapsulation fTW. But now that brings us to a situation where, essentially, it comes down to which htmlelement classes take precedence in our dependency hierarchy. Some libraries are probably compatible but you can't guarantee it because there's no explicit package dependencies between different implementations, so if you choose two different component libraries you may end up with unexpected behaviours and bugs. So if I were to build a component library that is "compatible" with all major component libraries, essentially what I'd have to build is a shit-ton of "mappings" and exceptions that define an order of precedence of which component variants my library should interact with or cede to? I don't really like the idea of "just magically working with incompatible libraries" right? Does that seem about right? I think I learned something new and fundamental today, and the overall approach makes sense if you pick a single library to build your application but I can't see it having any realistic value if you're to try and jimmy it into existing products, in fact I can see that being an extremely expensive exercise and potentially adding a load of overheads to maintain and configure. Also I can see now why no one really answered the question about ARIA tab orders and accessibility, it's not the job of these libraries. I'm not a very smart person, thanks again to you and everyone else jumping on my thread to take the time to explain :)
    - dmitriid 6y ago
      In theory you wouldn't worry about idiosyncrasies of specific component libraries if they are based on web components because they would provide only a single interface: properties go in (as in customElement.myCustomProp = <some-value>), events go out (as in customElement.attachEventListener(<some-custom-event>, (e) => <do something in your callback>)). This is definitely true for "dumb" components aka leaf components such as labels, footers, links, basic inputs. However, since you need more (for example, data-binding and reactivity), this may become a question of interoperability, and I don't really know how that plays out in the real world. > I'm not a very smart person, thanks again to you and everyone else jumping on my thread to take the time to explain : No stupid questions, right? :) And the whole web components discussion is extremely muddied. Mostly because people expect you to already know what they are about, and talk about and use libraries on top of them: lit-html, stencil etc.
- pupdogg 6y ago
  What I meant was that are a lot of like minded developers here who cringe every time they have to hear how JS is going to teleport us from Earth to Mars. And since there are no bonus cookies that can won by proving that you can create a functional website simply by using some good old HTML with CSS and vanilla JS, a lot of us resort to being silent and enjoy the show! So, what do ya say? Would you React the same way? ;)
  - parksy 6y ago
    It's funny because in writing my previous reply to you I felt a momentary sense of inclusion into a special club, I did think something along the lines of "should I just enjoy the show" and then on reflection I realised that taking such a stance would be equivalent to having no voice at all, and it would also essentially evaporate my chances to learn anything new from the good folk here as it would set up a "me vs them" context, which I don't believe would lead to me learning anything new. Don't get me wrong, I can see where you're coming from and feel the same way many times myself, but I am no stranger to conflict, and I spent a great deal of my life fawning to people or deferring my opinion for some "greater ideal" that other people tried to set for me, like you are doing now. You have set up so many logical fallacies, talking about "so many developers", "bonus cookies", and some weird need to "prove" ourselves, that I don't even know where to begin unwrapping whatever complex you have. Get help. You will be happier. I decided in this instance to say whatever is on the top of my mind no matter how stupid it makes me look, I don't seek camaraderie with anybody at face value just because you purportedly represent a group that I can join. "Like minded developers"? You would have to try harder to entice me to be a part of your group, if you even have a group. I really don't care to feel superior to anyone, results speak for themselves, so good luck I guess establishing a weird inner circle of ideals but I really want no part of it, nor do I need any endorsement from such a group. Wow, that felt so fucking weird to type.
    - pupdogg 6y ago
      Take it easy Freud, there’s no need to break your intellect down into so many pieces and get personal. Cheer up!

parksy 6y ago

I appreciate the support I guess but at the same time I don't understand what you mean by there are an unspecified number of people on my side and that silence is golden - either that means I should be quiet and join the throngs of the self-superior invisible some-jority which I think is condescending to the fine folk here, or it means I personally should be silent and not express my honest confusion, frustration and dismay. That's not going to happen either. I did come out pretty strong in my apprehension but I am serious in wanting to know specifically what the benefit of this is, and I don't really care whether I am making a fool of myself for asking questions lol.

dmitriid 6y ago
Theory: web components provide a standardised component model for the web so that you don't need to rely on frameworks and a bunch of JavaScript to create interchangeable interoperable components that are no different from built-in browser components. Oh, and you can extend existing built-in components with your own behaviours. Reality: - WebComponents is a collection of 4 web standards, one of them is already deprecated, and v0 of another one is also already deprecated. - The standards provide a verbose, error-prone imperative API that leaks implementation details left and right - The API is so bad, that the official stance is "the API is aimed at library and framework developers, and you are not expected to write your components using this API". And if you look at the frameworks, they try to not even compile/transpile down to this API - Since all WebComponents basically have is DOM APIs, the official stance is basically "yeah, they are good for implementing leaf nodes" (that is basic dump components like an simple input field, or a label) because you still need a full-fledged lib/framework for anything else - You cannot extend some (most?) of the built-in components. And even if you can, your custom implementations will not participate in form events, so you have to create workarounds if you want to submit values from your components - They break accessibility - They don't work without JavaScript - They cannot be rendered server-side - They are not strictly HTML, but a subset of it, because you can't provide callbacks for their custom events (you can do onClick, but you cannot do onSomeCustomEvent) - And on the social side of things, their proponents will very rarely acknowledge or discuss these issues in public (even though there are dozens if not hundreds of issues with extensive discussions on GitHub), but will spend not an inconsiderable amount of time and energy bashing non-webcomponent libraries and frameworks
- parksy 6y ago
  Okay I think I get it: 1. Define elements in script by extending htmlelement 2. Follow the allowed structure in the DOM so that the custom elements don't break / conflict with anything 3. Use CSS to make the custom element look nice. Then, basically what we have is: 1. A class-based way to attach event listeners in a standard interface (which is nice) 2. what we always had to do anyway (unless framework forces using JS to inject HTML at runtime) 3. what we always had to do anyway 4. Can't use custom events anymore... Encapsulation fTW. But now that brings us to a situation where, essentially, it comes down to which htmlelement classes take precedence in our dependency hierarchy. Some libraries are probably compatible but you can't guarantee it because there's no explicit package dependencies between different implementations, so if you choose two different component libraries you may end up with unexpected behaviours and bugs. So if I were to build a component library that is "compatible" with all major component libraries, essentially what I'd have to build is a shit-ton of "mappings" and exceptions that define an order of precedence of which component variants my library should interact with or cede to? I don't really like the idea of "just magically working with incompatible libraries" right? Does that seem about right? I think I learned something new and fundamental today, and the overall approach makes sense if you pick a single library to build your application but I can't see it having any realistic value if you're to try and jimmy it into existing products, in fact I can see that being an extremely expensive exercise and potentially adding a load of overheads to maintain and configure. Also I can see now why no one really answered the question about ARIA tab orders and accessibility, it's not the job of these libraries. I'm not a very smart person, thanks again to you and everyone else jumping on my thread to take the time to explain :)
  - dmitriid 6y ago
    In theory you wouldn't worry about idiosyncrasies of specific component libraries if they are based on web components because they would provide only a single interface: properties go in (as in customElement.myCustomProp = <some-value>), events go out (as in customElement.attachEventListener(<some-custom-event>, (e) => <do something in your callback>)). This is definitely true for "dumb" components aka leaf components such as labels, footers, links, basic inputs. However, since you need more (for example, data-binding and reactivity), this may become a question of interoperability, and I don't really know how that plays out in the real world. > I'm not a very smart person, thanks again to you and everyone else jumping on my thread to take the time to explain : No stupid questions, right? :) And the whole web components discussion is extremely muddied. Mostly because people expect you to already know what they are about, and talk about and use libraries on top of them: lit-html, stencil etc.
pupdogg 6y ago
What I meant was that are a lot of like minded developers here who cringe every time they have to hear how JS is going to teleport us from Earth to Mars. And since there are no bonus cookies that can won by proving that you can create a functional website simply by using some good old HTML with CSS and vanilla JS, a lot of us resort to being silent and enjoy the show! So, what do ya say? Would you React the same way? ;)
- parksy 6y ago
  It's funny because in writing my previous reply to you I felt a momentary sense of inclusion into a special club, I did think something along the lines of "should I just enjoy the show" and then on reflection I realised that taking such a stance would be equivalent to having no voice at all, and it would also essentially evaporate my chances to learn anything new from the good folk here as it would set up a "me vs them" context, which I don't believe would lead to me learning anything new. Don't get me wrong, I can see where you're coming from and feel the same way many times myself, but I am no stranger to conflict, and I spent a great deal of my life fawning to people or deferring my opinion for some "greater ideal" that other people tried to set for me, like you are doing now. You have set up so many logical fallacies, talking about "so many developers", "bonus cookies", and some weird need to "prove" ourselves, that I don't even know where to begin unwrapping whatever complex you have. Get help. You will be happier. I decided in this instance to say whatever is on the top of my mind no matter how stupid it makes me look, I don't seek camaraderie with anybody at face value just because you purportedly represent a group that I can join. "Like minded developers"? You would have to try harder to entice me to be a part of your group, if you even have a group. I really don't care to feel superior to anyone, results speak for themselves, so good luck I guess establishing a weird inner circle of ideals but I really want no part of it, nor do I need any endorsement from such a group. Wow, that felt so fucking weird to type.
  - pupdogg 6y ago
    Take it easy Freud, there’s no need to break your intellect down into so many pieces and get personal. Cheer up!