I know there is already Kendo UI for jQuery—a platform-agnostic solution—but it would be nice to have a UI Kit that uses Web Components (web primitive) for componentization. Is there any intent to create a Web Component flavor?
Antoniya
Telerik team
commented on 13 May 2024, 07:18 AM
Hello Andrew,
Thanks so much for writing to us. Although we don’t have UI suite that uses Web Components just yet, we’re currently evaluating the need to build it. It would be extremely helpful to us to better understand where your need comes from, what is it you’re building, what is your timeline and why this is the way you want to go?
Appreciate if you can take 20-30 min of your time to chat. You can book a time that works for youhere. Let me know if you don’t find slot that works for you.
Sorry for not responding or booking a time. The link for booking is invalid, again, probably due to me waiting so long to reply. I would love to chat about my needs if you could resend/relink.
Quick answer: We have many products using many different tech stacks, so we would love a platform-agnostic solution.
Just circling back to comment a thought. It would be great if Web Components could be built as a standalone UI suite but, then those web components could also be used as the guts of all the platforms component counterparts, essentially centralizing all style, accessibility and logic for all suites.
Dimo
Telerik team
commented on 11 Dec 2024, 11:58 AM
@Andrew - thanks for the follow-up. I will chime in, as Antoniya is out of office.
Our web products already use the same HTML markup and CSS styling, so the idea has its merits. However, it may be more suitable for a scenario where a company wants to introduce multiple brand new UI products for different frameworks. In our case, it may introduce additional complications or breaking changes. For example, a lot of components render markup conditionally or programmatically, and the logic is native to the respective framework (Angular, React, Blazor, etc.) If we were to reuse common web components client-side, this will force us to integrate additional APIs or even re-implement component functionality in another way. This will also make our products wrappers, while developers tend to prefer native solutions.
That all tracks, for sure. I can't imagine the complexity of a shift in approach like this for a suite as large as Kendo UI, but the simplicity in my mind is that web components are common web primitive, so there is no extra "buy in" to centralize componentry. Thanks for listening!
Hello Andrew,
Thanks so much for writing to us. Although we don’t have UI suite that uses Web Components just yet, we’re currently evaluating the need to build it. It would be extremely helpful to us to better understand where your need comes from, what is it you’re building, what is your timeline and why this is the way you want to go?
Appreciate if you can take 20-30 min of your time to chat. You can book a time that works for you here. Let me know if you don’t find slot that works for you.
Best,
Toni, PM
Hi Toni.
Sorry for not responding or booking a time. The link for booking is invalid, again, probably due to me waiting so long to reply. I would love to chat about my needs if you could resend/relink.
Quick answer: We have many products using many different tech stacks, so we would love a platform-agnostic solution.
@Andrew - thanks for the follow-up. I will chime in, as Antoniya is out of office.
Our web products already use the same HTML markup and CSS styling, so the idea has its merits. However, it may be more suitable for a scenario where a company wants to introduce multiple brand new UI products for different frameworks. In our case, it may introduce additional complications or breaking changes. For example, a lot of components render markup conditionally or programmatically, and the logic is native to the respective framework (Angular, React, Blazor, etc.) If we were to reuse common web components client-side, this will force us to integrate additional APIs or even re-implement component functionality in another way. This will also make our products wrappers, while developers tend to prefer native solutions.