4 ms·

This is about "feels like" and me too--the little newsletter popup and lack of substance shows this. React became obsolete over the past few years as browsers i

This is about "feels like" and me too--the little newsletter popup and lack of substance shows this. React became obsolete over the past few years as browsers increasingly adopted the mix of web components features (eg componentDidMount vs connectedCallback). Just using React, and the explanations for why a technology is and isn't used in an organization speaks to the level of practical knowledge and detritus in projects. That products survive this long with React illuminates how resistant the community is to... reading and doing work in the easiest, pragmatic way possible. Like why bother writing an article like this?

JoeyJoJoJr 5y ago
That is a big call regarding web components. I did some looking into web components for a recent project and React is just way ahead in many areas. You could use a framework like Lit to help smooth things over, but that just speaks to the underlying standard being somewhat cumbersome to use. I totally want web components to succeed and be the new way of doing things, but I get the feeling that is still a while away.
- jimmont 5y ago
  Big call? I suppose there's a point where having done enough work in projects affords some perspective. Whenever anyone gets the feeling to do something else the docs will probably be there, as they were the past few years.
- spankalee 5y ago
  I think calling web components "cumbersome" belies the intention of the APIs, which is to enable custom HTML elements, encapsulation, and interop - fairly low-level concerns. Lit takes care of templating and reactivity. Web components don't have those, it's expected that you use other methods, including what you already use, to create DOM and react to state changes. The DOM may eventually add templating and reactivity, but that's a pretty big question given how many approaches and syntaxes there are. Until then libraries are fine and allow for multiple opinions.
  - jimmont 5y ago
    Only a clarifying point to add about Lit: tagged templates provide templating and have native support, all Lit does is provide API extensions for reactivity, ie state management. So when a portion of a template is associated with an object, only that part is updated due to how the libraries work. And this is fundamentally all the it provides (unless I've misunderstood something). Lit-html provides functional state+template views while LitElement provides the OO/class oriented lifecycle approach--collectively now rebranded as "Lit". https://lit.dev/ https://lit.dev/ Please call out corrections as needed.
toqy 5y ago
I've been maintaining a web component library with Lit for a while. Web components overall don't feel ready for primetime. Just making a custom input field and have it work with a <form> is chore. Just look here at how much overall code is needed to do it right: https://github.com/ing-bank/lion/blob/master/packages/input/src/LionInput.js https://github.com/ing-bank/lion/blob/master/packages/input/... After you get through all the inheritance and mixins it's thousands of lines
- jimmont 5y ago
  I only have this generalized experience to respond with (at the moment): For the private project i work on full-time, the few dependencies related to ING and Lion were the most problematic and the first to get ripped out. I have no idea about the specifics of your dependency, and will not review the work you're mentioning in detail. However, ING, based on my limited experience, is nothing to base any assumptions on. Based on my limited experience, ING and Lion appear to be distinctly inferior examples of work done with Lit and web components. That was my first and last time working with anything Lion and ING related.
  - toqy 5y ago
    That's just one example, and the issues with form associated components are not limited to ING. The Microsoft FAST form components also have a fuck ton of code to achieve what <label> + <input> can do in any non-webcomponent framework. There are proposals for this and most of the other issues I have with web components. But they all feel like issues that could have been covered from the beginning. Also if you go all Lit on an app with many nested shadow doms it becomes fairly painful to test with tools like cypress.
    - jimmont 5y ago
      What is your point--or question? Form elements are complex. I'm not familiar with cypress. Puppeteer has worked fine for my needs. If the thesis is simply that using web components is a chore, well, welcome to frontend work. It has always been a chore in one way or another. Web components are the first time I can say--for my own professional experience--it was less so than previously. Generally a superior experience to all of: React, Angular, Backbone, jQuery, etc. Maybe you just need to hire me? I couldn't say without more detail.

JoeyJoJoJr 5y ago

That is a big call regarding web components. I did some looking into web components for a recent project and React is just way ahead in many areas. You could use a framework like Lit to help smooth things over, but that just speaks to the underlying standard being somewhat cumbersome to use. I totally want web components to succeed and be the new way of doing things, but I get the feeling that is still a while away.

jimmont 5y ago
Big call? I suppose there's a point where having done enough work in projects affords some perspective. Whenever anyone gets the feeling to do something else the docs will probably be there, as they were the past few years.
spankalee 5y ago
I think calling web components "cumbersome" belies the intention of the APIs, which is to enable custom HTML elements, encapsulation, and interop - fairly low-level concerns. Lit takes care of templating and reactivity. Web components don't have those, it's expected that you use other methods, including what you already use, to create DOM and react to state changes. The DOM may eventually add templating and reactivity, but that's a pretty big question given how many approaches and syntaxes there are. Until then libraries are fine and allow for multiple opinions.
- jimmont 5y ago
  Only a clarifying point to add about Lit: tagged templates provide templating and have native support, all Lit does is provide API extensions for reactivity, ie state management. So when a portion of a template is associated with an object, only that part is updated due to how the libraries work. And this is fundamentally all the it provides (unless I've misunderstood something). Lit-html provides functional state+template views while LitElement provides the OO/class oriented lifecycle approach--collectively now rebranded as "Lit". https://lit.dev/ https://lit.dev/ Please call out corrections as needed.

toqy 5y ago

I've been maintaining a web component library with Lit for a while. Web components overall don't feel ready for primetime. Just making a custom input field and have it work with a <form> is chore. Just look here at how much overall code is needed to do it right: https://github.com/ing-bank/lion/blob/master/packages/input/src/LionInput.js https://github.com/ing-bank/lion/blob/master/packages/input/... After you get through all the inheritance and mixins it's thousands of lines

jimmont 5y ago
I only have this generalized experience to respond with (at the moment): For the private project i work on full-time, the few dependencies related to ING and Lion were the most problematic and the first to get ripped out. I have no idea about the specifics of your dependency, and will not review the work you're mentioning in detail. However, ING, based on my limited experience, is nothing to base any assumptions on. Based on my limited experience, ING and Lion appear to be distinctly inferior examples of work done with Lit and web components. That was my first and last time working with anything Lion and ING related.
- toqy 5y ago
  That's just one example, and the issues with form associated components are not limited to ING. The Microsoft FAST form components also have a fuck ton of code to achieve what <label> + <input> can do in any non-webcomponent framework. There are proposals for this and most of the other issues I have with web components. But they all feel like issues that could have been covered from the beginning. Also if you go all Lit on an app with many nested shadow doms it becomes fairly painful to test with tools like cypress.
  - jimmont 5y ago
    What is your point--or question? Form elements are complex. I'm not familiar with cypress. Puppeteer has worked fine for my needs. If the thesis is simply that using web components is a chore, well, welcome to frontend work. It has always been a chore in one way or another. Web components are the first time I can say--for my own professional experience--it was less so than previously. Generally a superior experience to all of: React, Angular, Backbone, jQuery, etc. Maybe you just need to hire me? I couldn't say without more detail.