As someone that's done a lot of webcomponent work, this actually looks really solid compared to a lot of other libraries out there. These docs look great too.<p>All issues I can see are fairly minor. I'd like to see inputs use the native formAssociated api rather than just relying on hijacking FormData (though using the FormData hijack as a fallback). Component scoped design tokens should be part of the `:host{}` style for that component, not in the global scope. Semantic tokens would also be a better approach for improved themability. The localization is hacky, but I'll give the authors major props for actually pushing a suggestion to the spec[1] to allow for better handling in native components.<p>Some other minor things I'd like to see is performance comparisons with similar React/Vue/Svelte components as well. Webcomponents can fall into poor performance when there are many occurances that overuse observedAttributes.<p>All in all though, this library looks really great.<p>[1] <a href="https://github.com/whatwg/html/issues/7039" rel="nofollow">https://github.com/whatwg/html/issues/7039</a>
Have you seen OpenUI5 by SAP? -> <a href="https://github.com/SAP/ui5-webcomponents" rel="nofollow">https://github.com/SAP/ui5-webcomponents</a><p>Look neat. They even have Typescript type definitions to it.<p>I did a simpile test with ScalablyTyped in order to import those into ScalaJS to no avail but there might be a fix.
I've used shoelace components, overall I've been happy with them.<p>The only parts I don't like are the event based APIs.<p>It's 2022, I feel like we've settled on promises as the best way to handle async.<p>The author wasn't particularly receptive to the issue I raised around it, even offering to create a PR.<p>I think event based APIs are really holding what would otherwise be a very nice component set back.
As someone who doesn't have a clue about frontend components, but have the desire to build them, how does this compare to <a href="https://lit.dev/" rel="nofollow">https://lit.dev/</a> ?
Relevant previous discussion from when 2.0 was released a couple of years ago, changing Shoelace from a CSS library to a JavaScript/Web Components/Shadow DOM library: <a href="https://news.ycombinator.com/item?id=23866894" rel="nofollow">https://news.ycombinator.com/item?id=23866894</a>.<p>My top-level comment thread there is particularly still relevant and applicable; the mandatory use of Shadow DOM means client-side JavaScript execution is required and server-side rendering impossible, which I don’t think is good for most web stuff.
The complete and utter failure of the web as a platform is evidenced by the umpteenth framework offering the same set of the most basic components: avatars, badges, radio buttons, selects.<p>Kudos to Shoelace for including a draggable splitter which is usually missing from other libs.<p>The web is stuck in the perpetual "reinvent the concept of circle" stage without even moving onto "reinvent the wheel" stage. This "great and new" lib is literally indistinguishable from, say, jQuery UI from almost 20 years ago.
Shoelace looks awesome, and I think it's libs like these that are the future. People get hung up on the apparent confusion and circular movement of the frontend community but if you look closer you can see the incremental improvement.<p>Native web components are the endgame for flourishing frontend ecosystem (that many see as mostly waste, and sometimes they're not wrong) -- in the future you'll be to build whole sites writing HTML like:<p><pre><code> <script src="/path/to/some/custom-component"/>
...
<custom-component> ... </custom-component>
</code></pre>
That's the future Shoelace is helping bring about and I think it's a really nice minimally, and paradoxically simple way to build webpages that have the functionality you want without the hassle of heavier frameworks, if you're lucky to find just the right component to spice up your page.<p>I will say that it's hard to execute cleanly on this vision and it looks like Shoelace is doing a pretty good job -- I made a small contribution to this space[0], and I have to say that getting started with my project is much less clean (as far as dogfooding goes it was functional but didn't taste great!).<p>Looking forward to trying out Shoelace in the future.<p>One thing I really want to see tackled though (by a standards body) is the data management story. Maybe it's best left to practitioners and library authors but I think something like services-as-DOM-elements[1] (disclaimer: I thought this up) could work. Then we get a world where we can drop pre-made display elements <i>and</i> pre-made data stores onto pages.<p>Also heavy mention to tailwind -- the class soup bit is annoying but it's sparked an absolute explosion of reusable templates which I think are helping people build better looking sites faster than ever before. Just like with Bootstrap, of course, we're all getting tired of seeing really similar design elements but the acceleration is probably a net good, even if it requires abusing CSS a little bit.<p>[0]: <a href="https://gitlab.com/mrman/landing-gear" rel="nofollow">https://gitlab.com/mrman/landing-gear</a><p>[1]: <a href="https://mrman.gitlab.io/services-as-dom-elements" rel="nofollow">https://mrman.gitlab.io/services-as-dom-elements</a>
Not only is this a web page with its own loading screen, it's a web page with a loading screen that shows every time you open the page or click a link on the website.<p>My browser has a loading bar and your web page is not a video game pulling in hundreds of megs of assets in the background. What could possibly justify this kind of behaviour for a UI toolkit?