Nice! Reminds me of https://semantic-ui.com/ and its forked cousin https://fomantic-ui.com/
Progressive Web Components
41–50 of 61 posts
Re: Progressive Web Components
#42For web components to be consumable across frameworks, you still have to write it to be compatible for different frameworks. Our platform team thought they could get away with just focusing on native js, but when it came time to use in React, many behavioral approaches were incompatible. Dealing with re-renders would clear the state of the WC, losing all dropdown items. The toggle button had an infinite re-render gli…
isn't the issue here that React & Co. don't follow standards to support web components?
Re: Progressive Web Components
#43For web components to be consumable across frameworks, you still have to write it to be compatible for different frameworks. Our platform team thought they could get away with just focusing on native js, but when it came time to use in React, many behavioral approaches were incompatible. Dealing with re-renders would clear the state of the WC, losing all dropdown items. The toggle button had an infinite re-render gli…
isn't the issue here that React & Co. don't follow standards to support web components?
React had their own solution to web problems and went with it. Don't confuse that with obstinately discarding your favored technology. I personally tried web components and it was nothing but pain and solved no problems I actually had, unlike React.
Re: Progressive Web Components
#44Earlier quoted context omitted.
isn't the issue here that React & Co. don't follow standards to support web components?
React had their own solution to web problems and went with it. Don't confuse that with obstinately discarding your favored technology. I personally tried web components and it was nothing but pain and solved no problems I actually had, unlike React.
I work mostly with React but maintained a cross-framework web component library for a while, most of the issues that came in from our users we could not do anything about, as they had to be fixed by framework maintainers...the project died.
Re: Progressive Web Components
#45My only issue with Web Components is that, by design, they need to be registered with a globally unique tagname and can't be unregistered.
It's a reasonable compromise given the original purpose of custom elements, but in practice it ends up more maintainable to be inspired by its structures without using real custom elements despite I was initially excited that jsdom supports custom elements nowadays.
Re: Progressive Web Components
#46Earlier quoted context omitted.
isn't the issue here that React & Co. don't follow standards to support web components?
React had their own solution to web problems and went with it. Don't confuse that with obstinately discarding your favored technology. I personally tried web components and it was nothing but pain and solved no problems I actually had, unlike React.
I'm sorry but purposely ignoring standards that were decided upon by multiple parties is always a shithead move. It shows that you don't actually care about community standards and just want to thrust what you believe down everyone's throats.
Re: Progressive Web Components
#47I tried to embrace web components, but when I reached "declarative shadow DOM" I really just stopped seeing the point of all that complexity just to do what I can already do with a library. The target audience of that API seems to be library developers.
Yup. Lit element is much more accessible if you want “just” web components, but with a sane syntax.
As much as I dislike Google, Lit has been a nice middle ground for me.
It's lighter then a framework, events are vanilla JavaScript so you don't have to figure out how to make a JS libray you've found work within some framework's custom event bus.
It has enough rendering support so you don't need to update everything with .innerHTML. Change the state of a component, lit will call your render function but only update the parts of the DOM that have changed. I felt that was a nice partial answer to suggestions you need a virtual DOM because updating the real DOM is slow.
Re: Progressive Web Components
#48Earlier quoted context omitted.
React had their own solution to web problems and went with it. Don't confuse that with obstinately discarding your favored technology. I personally tried web components and it was nothing but pain and solved no problems I actually had, unlike React.
I'm sorry but purposely ignoring standards that were decided upon by multiple parties is always a shithead move. It shows that you don't actually care about community standards and just want to thrust what you believe down everyone's throats.
The issues were more behavioral for us. You can build the web component however you want, and the venn diagram of acceptable WC behavior vs React isn’t a full circle at all. Changing elements directly will mess up any VDOM-based approach, resetting state because rerendering means having a brand new WC, creating custom events in an esoteric way, it was a minefield of incompatibility beyond just “React can work with web components”
Re: Progressive Web Components
#49Earlier quoted context omitted.
React had their own solution to web problems and went with it. Don't confuse that with obstinately discarding your favored technology. I personally tried web components and it was nothing but pain and solved no problems I actually had, unlike React.
I'm sorry but purposely ignoring standards that were decided upon by multiple parties is always a shithead move. It shows that you don't actually care about community standards and just want to thrust what you believe down everyone's throats.
Lol. Or is introducing a "standard" that no one asked for and squealing that no one wants to spend their lives integrating your leaky "solution" a shithead move? Who is shoving things down people's throats really? You are very confused about the timeline for how these events played out.
Re: Progressive Web Components
#50Earlier quoted context omitted.
React had their own solution to web problems and went with it. Don't confuse that with obstinately discarding your favored technology. I personally tried web components and it was nothing but pain and solved no problems I actually had, unlike React.
I work mostly with React but maintained a cross-framework web component library for a while, most of the issues that came in from our users we could not do anything about, as they had to be fixed by framework maintainers...the project died.
Turns out that it's really difficult to make web components work with existing frameworks because instead of simply using existing web primitives as you'd expect, they made new ones. They use incapsulation primitives and state boundaries that make integrating them seamlessly with other frameworks anywhere from difficult to literally impossible. So it's unfortunate but unsurprising that the frameworks didn't fix the issues in time. Framework authors have spoken at length about their difficulties in developing generic interop with web components. Many of those issues persist to this day, long, long after the enthusiasm and momentum has gone.