26 ms·

Shoelace 2.0 release: UI toolkit that works with all frameworks or none at all

218 points by 1337shadow 6y ago

iRomain 6y ago
Very nice library! Good to see web components taking of.
chrismorgan 6y ago
My biggest concern with using Shadow DOM for things like this is that it makes it depend upon JavaScript, which I strongly prefer not to do.¹ I know there’s some research work into declarative Shadow DOM², which has the potential to resolve this, but that’s still quite some way off. As it stands, I don’t feel comfortable using Web Components with Shadow DOM for things like this, which is a pity, because it’s a delightful way to work, and this toolkit looks very good in most regards. Instead, I like Svelte’s model which essentially allows you to write things this way, but have it result in light DOM, so that you can still do server-side rendering if you desire. ¹ Requiring JavaScript harms accessibility, especially for web pages (as distinct from web apps). It makes pages take longer to load, not be as spider-friendly, and be more fragile when JavaScript fails to load, whether deliberately or accidentally—and simple network failures and the likes break things more often than you might imagine. I myself browse the web with JavaScript disabled via uMatrix, mostly because it speeds the web up a lot on average. Privacy improvements are a distant secondary reason. When I encounter pages that require JavaScript, I either give up on them or open them in a Private Browsing window, where I don’t have the uMatrix extension enabled; or if it’s something I expect I may be using more than once or twice, I see about more precise whitelisting in uMatrix. ² https://github.com/whatwg/dom/issues/831 https://github.com/whatwg/dom/issues/831
- P4wl0w 6y ago
  I do not think this is an issue for one very important reason: There is "Web-Apps" that just need JS and when deactivated it does not make sense at all to use them. Look at apps like [Prezi](https://prezi.com/ https://prezi.com/) as an example. I concur that normal content like news articles should still be accessible without activating any JS at all. The idea of real web components not bound to any of these fancy JS frameworks that die and get replaced so quickly nowadays is amazing in my opinion.
  - chrismorgan 6y ago
    To be sure, web apps do exist where not requiring JavaScript would be impossible or unreasonably difficult—though even so, most web apps don’t fit into this category. But the very nature of perceiving this dichotomy as acceptable is what leads to people making websites that require JS: people made web apps that rendered completely with React, saying to themselves that they didn’t need to support no-JS operation here, so now they were familiar with React, then when they went to make normal websites they used what they were familiar with, never mind that requiring JS was a bad idea here. Deciding that it was OK to break no-JS users for apps (still worse, normalising this) inevitably led to breaking no-JS users on sites. People talk about the good of web components not tied to any framework, but in practice it doesn’t tend to pan out that way. These things are a framework themselves, so now you probably have a whole extra framework for every such thing you use (though admittedly each will be a lot lighter than React or similar), and it forces you to work in a different way from what you’re used to within your main framework. People routinely end up wanting (or sometimes needing, especially when React is the root framework) tighter integrations between their frameworks, so they go wrapping the web components in a new layer, e.g. to get better types and tooling support, or to route events through their own system rather than the plain DOM events system, or to do something or other involving types that aren’t just strings. That last one is a major limitation and shortcoming of Web Components as a fully-general solution: if you’re passing in attributes, for example, it’s strings all the way, but people often want and sometimes need more complex things. As an example where this causes substantial inefficiency, imagine a chart element that needs an array of data; if it’s straight web components, you’ll be nudged firmly towards turning it into a bunch of elements, or serialising it as JSON and setting it as an attribute, where setting it as a property (something you can only do via JS, so you’ve lost the declarative nature of the element) will be way more efficient.
    - 1337shadow 6y ago
      Some things are just not going to work without JS: - file uploads, the browser fails to indicate that an upload is in progress, the user clicks "submit" again and again because they don't see that the browser is uploading, - file uploads when part of a form with other fields: if some text field doesn't validate, then the form will be shown again and the user will have to upload his file again, unless you go through the length of partially saving the form ... in which case you give up on having a nice transaction that saves the form at once - selects with at least thousands of choices, they will freeze the browser, you need an autocomplete So, as long as your website requires a file upload, or offers to select an option for a foreign key on a table with a lot of data then JS is required. Now, that might only be the case for a page or two, that doesn't prevent the rest of your site from working without JS because webcomponents aren't as invasive as typical JS frameworks that basically want to own all of your page. If you really want to pass JSON to your webcomponent it's pretty easy: <your-component><script type="text/json" slot="your-data">.. dump your json here</script></your-component> But, you could also render your stuff directly and let the webcomponent inspect the DOM and build its own data structure. Anyway, I fail to see the shortcoming here. WebComponents are not tied to any framework once they are built, or, if they were coded without. Shoelace doesn't require loading of any framework, but it's built with the brilliant StencilJS library: required to build, not to use. For me the only shortcoming is with browser based ES modules but they are being fixed with the ImportMap proposal.
- mamcx 6y ago
  I stumble upon http://tailwindcss.com http://tailwindcss.com & https://htmx.org https://htmx.org and suddenly things have gotten far easier than ever. I have found I write far less markup than bootstrap (despite I only have a few custom css), can do custom styling easily, can do theming easily, etc. And with htmx I could move nearly 95% of all to the server side, yet have close to the same experience than with vue. Considering that a lot of stuff still need to travel to the backend have the logic on the client have not been that useful for my needs. My only gripe? I need to use npm to run the production builds with tailwind for have less size, but, I have (finally!) small css!
- GordonS 6y ago
  > Instead, I like Svelte’s model which essentially allows you to write things this way, but have it result in light DOM, so that you can still do server-side rendering if you desire I've never used web components before, and I use SSR a lot (ASP. NET Core) - are you unable to use SSR with all web components, or only those that use shadow DOM? What's the reason I can't just render an `<sl-whatever>` and render the `value` attribute at the server? Apologies if I've misunderstood or got some of this wrong!
  - chrismorgan 6y ago
    It’s just the Shadow DOM, because it doesn’t serialise (which is roughly demonstrated thus: if you take document.documentElement.outerHTML it won’t include any of the shadow roots, and there’s nothing you can do in a .html file to produce a shadow root without adding JavaScript to insert it). So if you have a component looking like this in your dev tools: <sl-emoticon which="smile"> #shadow-root (open) :-) </sl-emoticon> Its HTML serialisation will still be <sl-emoticon which="smile"></sl-emoticon>, never with a :-). Look, there are ways around this lack of serialisation of shadow roots; the examples in https://github.com/skatejs/ssr https://github.com/skatejs/ssr succinctly show early experiments in the field, where it serialises the shadow root as an element, which it then turns into a shadow root with an inline script—but if the JavaScript doesn’t run, that won’t work and you’ll be left with a weirdly broken element, so I disqualify it and say “Shadow DOM is incompatible with SSR”. But for Web Components in general, there’s nothing stopping you serialising them with their light DOM, though if your component goes adding children to itself when or after you connect it you might need your connectedCallback to detect if this has effectively already happened (on the server side), and wire things up instead of changing its children. This process (wiring a JS-side component tree to an already-existing DOM, rather than rendering from scratch) is known as rehydration and applies to more than just Web Components.
    - claviska 6y ago
      Some of this stuff is bleeding edge and not every possible use case has been addressed. Web components bring a valuable contribution to what browsers are capable of, and everything will catch up in time. For example, there's already talk about a declarative shadow DOM [1].
kstenerud 6y ago
I'm still shocked at the decades it took for web technology to "discover" component based architectures. It's the main reason I steered clear of JS and web tech as much as I could, with a small dalliance to Echo2 in 2007.
- Yoric 6y ago
  To be fair, mozilla had a component-based architecture for the web since 1997 (called XUL). Some things were a bit odd to use but it worked pretty well and for the next ~20 years, it was way ahead of HTML & co. in just about everything, including localization, accessibility and performance.
  - toyg 6y ago
    XUL made one big mistake: RDF. It's basically a law: anything RDF touches, will fail to get adoption.
- DaiPlusPlus 6y ago
  The problem with encapsulated components is you surrender flexibility. For example, “components” for things like buttons and checkboxes are straightforward enough. But what about a checkbox-list? And how does that component accept data for data-binding purposes? Another place where “components” generally fall-over is when a component needs to act as a parent or container for arbitrary markup: yes, there’s the “slot” system but those are still defined and controlled by the component, not the consumer - even though ultimately it’s the consumer’s application. I compare the situation to the component ecosystem for VB6 and WinForms - which to be fair was a lot worse as consumers often had little to no control over how those components rendered, appeared or behaved - but (no pun intended) elements of the same problem exist today. Another example is WPF - which has major unaddressed issues still - which to be fair is worlds apart from WinForms in terms of what it’s templating system is capable of. A nice thing about WPF was that a component (Control’s) XAML was transparent and editable at design-time in VS, so the consuming application’s developer could get what they want out of it, the catch was that WPF templates are horrendously complex: getting VS to expose the XAML for even a <Button> would dump 50KB+ of markup into your application XAML because it was an all-or-nothing system and you needed XAML for every button state and behaviour - right down to the pulsating button glow effect that was only ever used in Windows Vista...
woutr_be 6y ago
Very interesting, a team at my company recently started writing an internal UI toolkit as well. The first stage would just be HTML + CSS (and maybe some JavaScript), but the second stage will be web components as well, to make it framework agnostic.
- claviska 6y ago
  Maybe Shoelace can save you some time. Thanks for checking it out!
Hamuko 6y ago
Why does it feel like JavaScript development is always accompanied with a huge amount of emoji?
- adamhearn 6y ago
  you just don’t understand what it ️ means to ️ develop for the ️ web.
- benbristow 6y ago
  The average age of a developer is ~30 (https://insights.stackoverflow.com/survey/2016#developer-profile-age https://insights.stackoverflow.com/survey/2016#developer-pro...) and JavaScript is very popular (https://insights.stackoverflow.com/survey/2016#technology https://insights.stackoverflow.com/survey/2016#technology). Couldn't actually find any solid figures on the average age of a JavaScript developers. So it's probably likely that it's younger developers (such as myself) that are used to using emoji and like to use a bit of emoji to add colour and personality to the page. I'm rather stereotyping here though, it could be some older person who just loves emoji too
  - claviska 6y ago
    I am in my thirties, so I guess I fit the stereotype. (They're mostly limited to the homepage though.)
- partyboat1586 6y ago
  I used to be with it. Then they changed what 'it' was, now what I'm with isn't it and what's 'it' seems weird and scary to me. It'll happen to you!
  - DJBunnies 6y ago
    Thanks, Abe.
progx 6y ago
But where is the difference to e. g. UIkit? Only write in component-style without div-tags and use css-vars?
- claviska 6y ago
  The difference is in how they're built and consumed. UIkit sprinkles CSS and JS on top of existing HTML elements: <div uk-dropdown></div> Shoelace defines web components, which are custom elements: <sl-dropdown>
- 1337shadow 6y ago
  Well Shoelace/StencilJS/WebComponents leverages browser ESM support and as such is able to import scripts as-needed as you browse, you can see that by leaving the Networking tab open in the browser inspector, and I believe that's pretty nice - that's the kind of reason why webpack got chunk splits ... You can probably achieve that with UIkit if you make one bundle per page with webpack or something, but with web components such as Shoelace you get that for free. So there's that, wether it matters to you or not is up to you of course.
jiofih 6y ago
Little detail not mentioned: no server-side rendering possible at all.
- 1337shadow 6y ago
  I'm not really sure what you mean: I actually pre-render everything in templates, when in webcomponent however I use the slot attribute which also is an implemented standard now. Anyway, that's the feature to pre-render everything: https://stenciljs.com/docs/hydrate-app https://stenciljs.com/docs/hydrate-app
  - DaiPlusPlus 6y ago
    Stencil requires you to use NodeJS - so if you want to use it with a “traditional” non-SPA ASP.NET or PHP web-application then you’re SOL.
    - 1337shadow 6y ago
      Well, at least you can still pre-render inside your web-component tags - like I do in python.
    - yesimahuman 6y ago
      That's not entirely true. If you pre-render your pages then there's no server-side Stencil code needed. You just need to serve those pages to the client and they will hydrate. EDIT: don't understand the downvotes, seeing as we built Stencil. Stencil can definitely be used in a more traditional server-side environment like ASP.Net or PHP
      - DaiPlusPlus 6y ago
        I didn't see any documentation on Stencil's website regarding how to pre-render Stencil components without using their NodeJS toolset. (I did not downvote you, and someone has downvoted me as well, it seems)
  - chrismorgan 6y ago
yalooze 6y ago
On mobile Safari I can’t seem to long press on any links to bring up the menu for Open in background, Copy etc. At first I thought this might be a consequence of how the toolkit was built but it seems its standard Docsify behaviour. A callback to the old ‘disable right-click’ functionality in IE that thankfully newer browsers ignored.
- claviska 6y ago
  Good catch, I never noticed that. I'll see what's up with Docsify and submit a PR if I can fix it upstream.
dilandau 6y ago
Looks like another bootcamper invents a framework. Thanks to dunning-kruger, they have no idea that it sucks, and now are promoting the shit out of it. Or more nefarious, they just want to build up their resume by being "serious open source maintainer". Another day on hn.
- garganzol 6y ago
  I disagree. The OP explores the new territory of web components which are framework-agnostic by their sheer nature. This might be well the future right around the corner.
- mhoad 6y ago
  What was going through your mind when you wrote this?
- 1337shadow 6y ago
  That's some nice personal attacks you got right there ! Just to clarify: I'm not affiliated with the author, and haven't even used or contributed the lib, I just stumbled on it and thought it was pretty nice and wanted to share it. As for my resume well it already has everything you would ever dream of; not that I care: I have my own ventures.
- WrongThinkerNo5 6y ago
  This is a bit off topic, to put it lightly, but seriously, please read your comment again and reconsider how you talk to and about people. It is clear you have supremacist disdain for the creator out of a self-generated sense of superiority, but reality is that it is something you can or cannot use, so just ignore it if you don't like it. Maybe, if you are so much better, you could even provide some mentorship or guidance by providing constructive, i.e., useful, criticism; if it is warranted. But try to maybe address why you are the way you are instead of trying to degrade others as you externalize your issues. I believe you should be able to say what you said and it should not be removed or even lashed with downvotes by the archetypal rabid reddit type mob, but I hope you really consider your words. Even if you are correct on the face of it being just another one of those horrible bootcamper, why would you want to lash at someone who is trying to do things, who maybe didn't have the opportunities you had, or is just trying to improve and get feedback. Not everyone is as perfect as you. With that; let's see your framework that is perfect and far better than Shoelace.
claviska 6y ago
Shoelace author here. A couple days ago, I released Shoelace 2.0, an open source library of common UI components. These components work with any framework, can be loaded via CDN, are fully customizable with CSS (no preprocessor required), and install easily with a simple script + stylesheet. They were built with Stencil.js, which is a fantastic tool. The end result compiles down to vanilla web components. Each component was designed from scratch to be lean, customizable, and easy to use. Accessibility is a common question folks have about component libraries. I’m definitely not an expert here, but I've spent a lot of time trying to get it right. I would like to echo the experts and say that accessibility only starts with components, but hopefully having a good foundation to build on will encourage others to think about it more at higher levels. I hope you'll take a second to check it out! I'm happy to answer any questions you have about the project, how it's built, etc.
- iCarrot 6y ago
  The "in" animation on components like dialog or drawer doesn't seems to work on Firefox (78.0.2 on Windows). Very abrupt in, smooth fade/slide out. Also there are small version of buttons but none for other form controls which is quite odd. Seems nice and lightweight overall. I would love to see a dark version too.
  - claviska 6y ago
    This was addressed for the drawer here: https://github.com/shoelace-style/shoelace/issues/103 https://github.com/shoelace-style/shoelace/issues/103 I can't seem to reproduce this for other components, but I'll check again. > Also there are small version of buttons but none for other form controls which is quite odd. Button, input, textarea, and select all have size variations. It's missing from checkboxes, radios, and switches but I'm not sure how useful that is. Feel free to submit an issue so folks can vote on it. Edit: this has been identified and fixed in dialogs!
- popup21 6y ago
  Have you tested this with compiler frameworks like Svelte? Would this be compatible?
thrownaway954 6y ago
Maybe I'm just a moron but when I see framework or libraries like this, I want to see examples like bootstrap. I see nothing on the homepage that shows me what this actually does. Again... Maybe I'm an idiot, but in today's age, everyone wants things visualized. I think showing some examples right off the bat could not only show the benefits of using this, but help explain it better to people like myself. As of now I see no reason to use this.
- claviska 6y ago
  This is a great idea. I ended up publishing the documentation site _as_ the website and didn't even think to show some examples.
  - thrownaway954 6y ago
    DUDE!!!!! AWESOME!!!!! now that is what i'm talking about! I am in love with the tooltip :) https://shoelace.style/components/tooltip https://shoelace.style/components/tooltip
  - lowmemcpu 6y ago
    Ya, I'd love to see a demo page where you show off 25-50% of your favorite examples. The individual doc pages look really nice though
- cptskippy 6y ago
  This isn't just a UI/UX skin to applied to your website. Looking for an example of what a button or other element looks like is irrelevant as it's customizable. I personally appreciated the introduction to Custom Elements and an explanation of the philosophy of the framework. So much of what we do as developers involves tight coupling and lock-in to a full-stack.
  - thrownaway954 6y ago
    i'm sorry, you're missing the point entirely.
rawoke083600 6y ago
Is it just me or doesn't any of the examples work ?
- claviska 6y ago
  Seems to be working for most people. Are you using a legacy browser?
  - 1337shadow 6y ago
    There's some polyfill for IE11, maybe it would be worth a try ? https://stenciljs.com/docs/browser-support/ https://stenciljs.com/docs/browser-support/ It seems it is necessary for browsers that have been abandoned and that are never going to have TLS 1.3 support: IE11, Edge 16-18 Personally I'd leave it just to push users onto abandoning those browsers that will never support TLS 1.3.
- gremlinsinc 6y ago
  Doesn't work for me on mobile but I'm using materialize for Android which opens it in a web view so that could be part of my issue. Haven't tried Firefox or chrome on mobile.
werdnapk 6y ago
The drawer component doesn't seem to work in Firefox 78. Clicking on the buttons to open the drawers doesn't do anything.
- claviska 6y ago
  This was addressed here: https://github.com/shoelace-style/shoelace/issues/103 https://github.com/shoelace-style/shoelace/issues/103 Just tested with Firefox 78 and verified it's working now. You may have an older cache.
  - werdnapk 6y ago
    Just tried again and yes, it works now.
girishso 6y ago
That looks amazing. Using bootstrap or other css frameworks across different frameworks (react, vue etc) is a pain. This looks like a good start!
rho4 6y ago
The only component I want to see in a demo of any UX framework - be it desktop or web - is the almighty tree table. I‘d like to see sorting, filtering, column resizing and -reordering, including save / restore of the above. Row (multi-)selection, striping, hover. Inline editing. Show me all other components inside a row.
- claviska 6y ago
  Tables can get quite complex as features get sprinkled on. I doubt any out-of-the-box solution will nail it for all use cases. I'm not opposed to including one in Shoelace at some point, but I'd want it to have an API that's capable of handling the majority of [reasonable] use cases in an elegant way. It's definitely high up on the list of components that are challenging to get right!
sheeeep86 6y ago
I'm very excited about web components. One thing that I don't understand yet is how server side pre rendering works in these situations. Basically the elements need to be downloaded before the browser can render anything, which will delay the page in it time. I guess if everyone was using the CDN then these components would be cached for multiple applications. But they would still need to be initialized and render themselves on each page load,which could take long for complex components.
- claviska 6y ago
  I'm no expert here, but Stencil is capable of SSR [1]. I believe you'd need to install Shoelace locally and tweak a few configs to get it working, though. 1. https://stenciljs.com/docs/static-site-generation https://stenciljs.com/docs/static-site-generation

218 points by 1337shadow 6y ago

Very nice library! Good to see web components taking of.

My biggest concern with using Shadow DOM for things like this is that it makes it depend upon JavaScript, which I strongly prefer not to do.¹ I know there’s some research work into declarative Shadow DOM², which has the potential to resolve this, but that’s still quite some way off. As it stands, I don’t feel comfortable using Web Components with Shadow DOM for things like this, which is a pity, because it’s a delightful way to work, and this toolkit looks very good in most regards. Instead, I like Svelte’s model which essentially allows you to write things this way, but have it result in light DOM, so that you can still do server-side rendering if you desire. ¹ Requiring JavaScript harms accessibility, especially for web pages (as distinct from web apps). It makes pages take longer to load, not be as spider-friendly, and be more fragile when JavaScript fails to load, whether deliberately or accidentally—and simple network failures and the likes break things more often than you might imagine. I myself browse the web with JavaScript disabled via uMatrix, mostly because it speeds the web up a lot on average. Privacy improvements are a distant secondary reason. When I encounter pages that require JavaScript, I either give up on them or open them in a Private Browsing window, where I don’t have the uMatrix extension enabled; or if it’s something I expect I may be using more than once or twice, I see about more precise whitelisting in uMatrix. ² https://github.com/whatwg/dom/issues/831 https://github.com/whatwg/dom/issues/831

P4wl0w 6y ago
I do not think this is an issue for one very important reason: There is "Web-Apps" that just need JS and when deactivated it does not make sense at all to use them. Look at apps like [Prezi](https://prezi.com/ https://prezi.com/) as an example. I concur that normal content like news articles should still be accessible without activating any JS at all. The idea of real web components not bound to any of these fancy JS frameworks that die and get replaced so quickly nowadays is amazing in my opinion.
- chrismorgan 6y ago
  To be sure, web apps do exist where not requiring JavaScript would be impossible or unreasonably difficult—though even so, most web apps don’t fit into this category. But the very nature of perceiving this dichotomy as acceptable is what leads to people making websites that require JS: people made web apps that rendered completely with React, saying to themselves that they didn’t need to support no-JS operation here, so now they were familiar with React, then when they went to make normal websites they used what they were familiar with, never mind that requiring JS was a bad idea here. Deciding that it was OK to break no-JS users for apps (still worse, normalising this) inevitably led to breaking no-JS users on sites. People talk about the good of web components not tied to any framework, but in practice it doesn’t tend to pan out that way. These things are a framework themselves, so now you probably have a whole extra framework for every such thing you use (though admittedly each will be a lot lighter than React or similar), and it forces you to work in a different way from what you’re used to within your main framework. People routinely end up wanting (or sometimes needing, especially when React is the root framework) tighter integrations between their frameworks, so they go wrapping the web components in a new layer, e.g. to get better types and tooling support, or to route events through their own system rather than the plain DOM events system, or to do something or other involving types that aren’t just strings. That last one is a major limitation and shortcoming of Web Components as a fully-general solution: if you’re passing in attributes, for example, it’s strings all the way, but people often want and sometimes need more complex things. As an example where this causes substantial inefficiency, imagine a chart element that needs an array of data; if it’s straight web components, you’ll be nudged firmly towards turning it into a bunch of elements, or serialising it as JSON and setting it as an attribute, where setting it as a property (something you can only do via JS, so you’ve lost the declarative nature of the element) will be way more efficient.
  - 1337shadow 6y ago
    Some things are just not going to work without JS: - file uploads, the browser fails to indicate that an upload is in progress, the user clicks "submit" again and again because they don't see that the browser is uploading, - file uploads when part of a form with other fields: if some text field doesn't validate, then the form will be shown again and the user will have to upload his file again, unless you go through the length of partially saving the form ... in which case you give up on having a nice transaction that saves the form at once - selects with at least thousands of choices, they will freeze the browser, you need an autocomplete So, as long as your website requires a file upload, or offers to select an option for a foreign key on a table with a lot of data then JS is required. Now, that might only be the case for a page or two, that doesn't prevent the rest of your site from working without JS because webcomponents aren't as invasive as typical JS frameworks that basically want to own all of your page. If you really want to pass JSON to your webcomponent it's pretty easy: <your-component><script type="text/json" slot="your-data">.. dump your json here</script></your-component> But, you could also render your stuff directly and let the webcomponent inspect the DOM and build its own data structure. Anyway, I fail to see the shortcoming here. WebComponents are not tied to any framework once they are built, or, if they were coded without. Shoelace doesn't require loading of any framework, but it's built with the brilliant StencilJS library: required to build, not to use. For me the only shortcoming is with browser based ES modules but they are being fixed with the ImportMap proposal.
mamcx 6y ago
I stumble upon http://tailwindcss.com http://tailwindcss.com & https://htmx.org https://htmx.org and suddenly things have gotten far easier than ever. I have found I write far less markup than bootstrap (despite I only have a few custom css), can do custom styling easily, can do theming easily, etc. And with htmx I could move nearly 95% of all to the server side, yet have close to the same experience than with vue. Considering that a lot of stuff still need to travel to the backend have the logic on the client have not been that useful for my needs. My only gripe? I need to use npm to run the production builds with tailwind for have less size, but, I have (finally!) small css!
GordonS 6y ago
> Instead, I like Svelte’s model which essentially allows you to write things this way, but have it result in light DOM, so that you can still do server-side rendering if you desire I've never used web components before, and I use SSR a lot (ASP. NET Core) - are you unable to use SSR with all web components, or only those that use shadow DOM? What's the reason I can't just render an `<sl-whatever>` and render the `value` attribute at the server? Apologies if I've misunderstood or got some of this wrong!
- chrismorgan 6y ago
  It’s just the Shadow DOM, because it doesn’t serialise (which is roughly demonstrated thus: if you take document.documentElement.outerHTML it won’t include any of the shadow roots, and there’s nothing you can do in a .html file to produce a shadow root without adding JavaScript to insert it). So if you have a component looking like this in your dev tools: <sl-emoticon which="smile"> #shadow-root (open) :-) </sl-emoticon> Its HTML serialisation will still be <sl-emoticon which="smile"></sl-emoticon>, never with a :-). Look, there are ways around this lack of serialisation of shadow roots; the examples in https://github.com/skatejs/ssr https://github.com/skatejs/ssr succinctly show early experiments in the field, where it serialises the shadow root as an element, which it then turns into a shadow root with an inline script—but if the JavaScript doesn’t run, that won’t work and you’ll be left with a weirdly broken element, so I disqualify it and say “Shadow DOM is incompatible with SSR”. But for Web Components in general, there’s nothing stopping you serialising them with their light DOM, though if your component goes adding children to itself when or after you connect it you might need your connectedCallback to detect if this has effectively already happened (on the server side), and wire things up instead of changing its children. This process (wiring a JS-side component tree to an already-existing DOM, rather than rendering from scratch) is known as rehydration and applies to more than just Web Components.
  - claviska 6y ago
    Some of this stuff is bleeding edge and not every possible use case has been addressed. Web components bring a valuable contribution to what browsers are capable of, and everything will catch up in time. For example, there's already talk about a declarative shadow DOM [1].

kstenerud 6y ago

I'm still shocked at the decades it took for web technology to "discover" component based architectures. It's the main reason I steered clear of JS and web tech as much as I could, with a small dalliance to Echo2 in 2007.

Yoric 6y ago
To be fair, mozilla had a component-based architecture for the web since 1997 (called XUL). Some things were a bit odd to use but it worked pretty well and for the next ~20 years, it was way ahead of HTML & co. in just about everything, including localization, accessibility and performance.
- toyg 6y ago
  XUL made one big mistake: RDF. It's basically a law: anything RDF touches, will fail to get adoption.
DaiPlusPlus 6y ago
The problem with encapsulated components is you surrender flexibility. For example, “components” for things like buttons and checkboxes are straightforward enough. But what about a checkbox-list? And how does that component accept data for data-binding purposes? Another place where “components” generally fall-over is when a component needs to act as a parent or container for arbitrary markup: yes, there’s the “slot” system but those are still defined and controlled by the component, not the consumer - even though ultimately it’s the consumer’s application. I compare the situation to the component ecosystem for VB6 and WinForms - which to be fair was a lot worse as consumers often had little to no control over how those components rendered, appeared or behaved - but (no pun intended) elements of the same problem exist today. Another example is WPF - which has major unaddressed issues still - which to be fair is worlds apart from WinForms in terms of what it’s templating system is capable of. A nice thing about WPF was that a component (Control’s) XAML was transparent and editable at design-time in VS, so the consuming application’s developer could get what they want out of it, the catch was that WPF templates are horrendously complex: getting VS to expose the XAML for even a <Button> would dump 50KB+ of markup into your application XAML because it was an all-or-nothing system and you needed XAML for every button state and behaviour - right down to the pulsating button glow effect that was only ever used in Windows Vista...

woutr_be 6y ago

Very interesting, a team at my company recently started writing an internal UI toolkit as well. The first stage would just be HTML + CSS (and maybe some JavaScript), but the second stage will be web components as well, to make it framework agnostic.

claviska 6y ago
Maybe Shoelace can save you some time. Thanks for checking it out!

Hamuko 6y ago

Why does it feel like JavaScript development is always accompanied with a huge amount of emoji?

adamhearn 6y ago
you just don’t understand what it ️ means to ️ develop for the ️ web.
benbristow 6y ago
The average age of a developer is ~30 (https://insights.stackoverflow.com/survey/2016#developer-profile-age https://insights.stackoverflow.com/survey/2016#developer-pro...) and JavaScript is very popular (https://insights.stackoverflow.com/survey/2016#technology https://insights.stackoverflow.com/survey/2016#technology). Couldn't actually find any solid figures on the average age of a JavaScript developers. So it's probably likely that it's younger developers (such as myself) that are used to using emoji and like to use a bit of emoji to add colour and personality to the page. I'm rather stereotyping here though, it could be some older person who just loves emoji too
- claviska 6y ago
  I am in my thirties, so I guess I fit the stereotype. (They're mostly limited to the homepage though.)
partyboat1586 6y ago
I used to be with it. Then they changed what 'it' was, now what I'm with isn't it and what's 'it' seems weird and scary to me. It'll happen to you!
- DJBunnies 6y ago
  Thanks, Abe.

progx 6y ago

But where is the difference to e. g. UIkit? Only write in component-style without div-tags and use css-vars?

claviska 6y ago
The difference is in how they're built and consumed. UIkit sprinkles CSS and JS on top of existing HTML elements: <div uk-dropdown></div> Shoelace defines web components, which are custom elements: <sl-dropdown>
1337shadow 6y ago
Well Shoelace/StencilJS/WebComponents leverages browser ESM support and as such is able to import scripts as-needed as you browse, you can see that by leaving the Networking tab open in the browser inspector, and I believe that's pretty nice - that's the kind of reason why webpack got chunk splits ... You can probably achieve that with UIkit if you make one bundle per page with webpack or something, but with web components such as Shoelace you get that for free. So there's that, wether it matters to you or not is up to you of course.

jiofih 6y ago

Little detail not mentioned: no server-side rendering possible at all.

1337shadow 6y ago
I'm not really sure what you mean: I actually pre-render everything in templates, when in webcomponent however I use the slot attribute which also is an implemented standard now. Anyway, that's the feature to pre-render everything: https://stenciljs.com/docs/hydrate-app https://stenciljs.com/docs/hydrate-app
- DaiPlusPlus 6y ago
  Stencil requires you to use NodeJS - so if you want to use it with a “traditional” non-SPA ASP.NET or PHP web-application then you’re SOL.
  - 1337shadow 6y ago
    Well, at least you can still pre-render inside your web-component tags - like I do in python.
  - yesimahuman 6y ago
    That's not entirely true. If you pre-render your pages then there's no server-side Stencil code needed. You just need to serve those pages to the client and they will hydrate. EDIT: don't understand the downvotes, seeing as we built Stencil. Stencil can definitely be used in a more traditional server-side environment like ASP.Net or PHP
    - DaiPlusPlus 6y ago
      I didn't see any documentation on Stencil's website regarding how to pre-render Stencil components without using their NodeJS toolset. (I did not downvote you, and someone has downvoted me as well, it seems)
- chrismorgan 6y ago

yalooze 6y ago

On mobile Safari I can’t seem to long press on any links to bring up the menu for Open in background, Copy etc. At first I thought this might be a consequence of how the toolkit was built but it seems its standard Docsify behaviour. A callback to the old ‘disable right-click’ functionality in IE that thankfully newer browsers ignored.

claviska 6y ago
Good catch, I never noticed that. I'll see what's up with Docsify and submit a PR if I can fix it upstream.

dilandau 6y ago

Looks like another bootcamper invents a framework. Thanks to dunning-kruger, they have no idea that it sucks, and now are promoting the shit out of it. Or more nefarious, they just want to build up their resume by being "serious open source maintainer". Another day on hn.

garganzol 6y ago
I disagree. The OP explores the new territory of web components which are framework-agnostic by their sheer nature. This might be well the future right around the corner.
mhoad 6y ago
What was going through your mind when you wrote this?
1337shadow 6y ago
That's some nice personal attacks you got right there ! Just to clarify: I'm not affiliated with the author, and haven't even used or contributed the lib, I just stumbled on it and thought it was pretty nice and wanted to share it. As for my resume well it already has everything you would ever dream of; not that I care: I have my own ventures.
WrongThinkerNo5 6y ago
This is a bit off topic, to put it lightly, but seriously, please read your comment again and reconsider how you talk to and about people. It is clear you have supremacist disdain for the creator out of a self-generated sense of superiority, but reality is that it is something you can or cannot use, so just ignore it if you don't like it. Maybe, if you are so much better, you could even provide some mentorship or guidance by providing constructive, i.e., useful, criticism; if it is warranted. But try to maybe address why you are the way you are instead of trying to degrade others as you externalize your issues. I believe you should be able to say what you said and it should not be removed or even lashed with downvotes by the archetypal rabid reddit type mob, but I hope you really consider your words. Even if you are correct on the face of it being just another one of those horrible bootcamper, why would you want to lash at someone who is trying to do things, who maybe didn't have the opportunities you had, or is just trying to improve and get feedback. Not everyone is as perfect as you. With that; let's see your framework that is perfect and far better than Shoelace.

claviska 6y ago

Shoelace author here. A couple days ago, I released Shoelace 2.0, an open source library of common UI components. These components work with any framework, can be loaded via CDN, are fully customizable with CSS (no preprocessor required), and install easily with a simple script + stylesheet. They were built with Stencil.js, which is a fantastic tool. The end result compiles down to vanilla web components. Each component was designed from scratch to be lean, customizable, and easy to use. Accessibility is a common question folks have about component libraries. I’m definitely not an expert here, but I've spent a lot of time trying to get it right. I would like to echo the experts and say that accessibility only starts with components, but hopefully having a good foundation to build on will encourage others to think about it more at higher levels. I hope you'll take a second to check it out! I'm happy to answer any questions you have about the project, how it's built, etc.

iCarrot 6y ago
The "in" animation on components like dialog or drawer doesn't seems to work on Firefox (78.0.2 on Windows). Very abrupt in, smooth fade/slide out. Also there are small version of buttons but none for other form controls which is quite odd. Seems nice and lightweight overall. I would love to see a dark version too.
- claviska 6y ago
  This was addressed for the drawer here: https://github.com/shoelace-style/shoelace/issues/103 https://github.com/shoelace-style/shoelace/issues/103 I can't seem to reproduce this for other components, but I'll check again. > Also there are small version of buttons but none for other form controls which is quite odd. Button, input, textarea, and select all have size variations. It's missing from checkboxes, radios, and switches but I'm not sure how useful that is. Feel free to submit an issue so folks can vote on it. Edit: this has been identified and fixed in dialogs!
popup21 6y ago
Have you tested this with compiler frameworks like Svelte? Would this be compatible?

thrownaway954 6y ago

Maybe I'm just a moron but when I see framework or libraries like this, I want to see examples like bootstrap. I see nothing on the homepage that shows me what this actually does. Again... Maybe I'm an idiot, but in today's age, everyone wants things visualized. I think showing some examples right off the bat could not only show the benefits of using this, but help explain it better to people like myself. As of now I see no reason to use this.

claviska 6y ago
This is a great idea. I ended up publishing the documentation site _as_ the website and didn't even think to show some examples.
- thrownaway954 6y ago
  DUDE!!!!! AWESOME!!!!! now that is what i'm talking about! I am in love with the tooltip :) https://shoelace.style/components/tooltip https://shoelace.style/components/tooltip
- lowmemcpu 6y ago
  Ya, I'd love to see a demo page where you show off 25-50% of your favorite examples. The individual doc pages look really nice though
cptskippy 6y ago
This isn't just a UI/UX skin to applied to your website. Looking for an example of what a button or other element looks like is irrelevant as it's customizable. I personally appreciated the introduction to Custom Elements and an explanation of the philosophy of the framework. So much of what we do as developers involves tight coupling and lock-in to a full-stack.
- thrownaway954 6y ago
  i'm sorry, you're missing the point entirely.

rawoke083600 6y ago

Is it just me or doesn't any of the examples work ?

claviska 6y ago
Seems to be working for most people. Are you using a legacy browser?
- 1337shadow 6y ago
  There's some polyfill for IE11, maybe it would be worth a try ? https://stenciljs.com/docs/browser-support/ https://stenciljs.com/docs/browser-support/ It seems it is necessary for browsers that have been abandoned and that are never going to have TLS 1.3 support: IE11, Edge 16-18 Personally I'd leave it just to push users onto abandoning those browsers that will never support TLS 1.3.
gremlinsinc 6y ago
Doesn't work for me on mobile but I'm using materialize for Android which opens it in a web view so that could be part of my issue. Haven't tried Firefox or chrome on mobile.

werdnapk 6y ago

The drawer component doesn't seem to work in Firefox 78. Clicking on the buttons to open the drawers doesn't do anything.

claviska 6y ago
This was addressed here: https://github.com/shoelace-style/shoelace/issues/103 https://github.com/shoelace-style/shoelace/issues/103 Just tested with Firefox 78 and verified it's working now. You may have an older cache.
- werdnapk 6y ago
  Just tried again and yes, it works now.

girishso 6y ago

That looks amazing. Using bootstrap or other css frameworks across different frameworks (react, vue etc) is a pain. This looks like a good start!

rho4 6y ago

The only component I want to see in a demo of any UX framework - be it desktop or web - is the almighty tree table. I‘d like to see sorting, filtering, column resizing and -reordering, including save / restore of the above. Row (multi-)selection, striping, hover. Inline editing. Show me all other components inside a row.

claviska 6y ago
Tables can get quite complex as features get sprinkled on. I doubt any out-of-the-box solution will nail it for all use cases. I'm not opposed to including one in Shoelace at some point, but I'd want it to have an API that's capable of handling the majority of [reasonable] use cases in an elegant way. It's definitely high up on the list of components that are challenging to get right!

sheeeep86 6y ago

I'm very excited about web components. One thing that I don't understand yet is how server side pre rendering works in these situations. Basically the elements need to be downloaded before the browser can render anything, which will delay the page in it time. I guess if everyone was using the CDN then these components would be cached for multiple applications. But they would still need to be initialized and render themselves on each page load,which could take long for complex components.

claviska 6y ago
I'm no expert here, but Stencil is capable of SSR [1]. I believe you'd need to install Shoelace locally and tweak a few configs to get it working, though. 1. https://stenciljs.com/docs/static-site-generation https://stenciljs.com/docs/static-site-generation