3 ms·

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 Li

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.
  - toqy 5y ago
    > That products survive this long with React illuminates how resistant the community is to... reading and doing work in the easiest, pragmatic way possible. My point is that you were entirely wrong. Web Components are not ready for primetime, they are half baked. If they were the easiest and most pragmatic way possible to build web applications people would do so. The only thing they are the easiest and most pragmatic for is to build a simple non-form associated component that can be used across frameworks. Like a card. > It has always been a chore in one way or another. It's actually never been a chore to make an <input> behave properly. Something that literally every component library needs to do.

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.
- toqy 5y ago
  > That products survive this long with React illuminates how resistant the community is to... reading and doing work in the easiest, pragmatic way possible. My point is that you were entirely wrong. Web Components are not ready for primetime, they are half baked. If they were the easiest and most pragmatic way possible to build web applications people would do so. The only thing they are the easiest and most pragmatic for is to build a simple non-form associated component that can be used across frameworks. Like a card. > It has always been a chore in one way or another. It's actually never been a chore to make an <input> behave properly. Something that literally every component library needs to do.