HTTP/2

[shoelace-style]

HTTP/2

[claviska]

Just a heads up — I'm going to experiment with this on Friday.

[claviska]

Your insights on HTTP/2 are appreciated, but your arguments derail the project's objective.

Shoelace provides a simple way for users to include the library (locally or via CDN) and customize it without having to worry about preprocessors. I wrote about why this is a problem in a post on David Walsh's blog. Coincidentally, I saw it yet again in the wild just yesterday. This happens a lot.

Shoelace lets people behave as they're used to behaving, but still offers the benefit of easy customizations with a lighter overall size. The core is intended to be fairly minimal. It includes only what I consider to be essential components for 98% of websites/web apps I create. By the very nature of CSS, it can be extended easily.

Most people want to copy and paste a link and use it via CDN. They don't want to dick around with NPM, preprocessors, task runners, or build processes. Not everyone is a developer or a power user. Many just want to copy/paste and have it work.

Furthermore, people are lazy. They don't want to write their own variables.css from scratch, so I provide a reasonable starting point and let them customize components as desired. A few extra bytes won't hurt anything compared to the full blown libraries they've been loading in production for years.

It's pointless, because your Autoprefixer query (that determines which prefixes are generated) might be inadequate for other projects and will render the dist useless.

No it won't, because most people don't give a shit. They just want it to work. I provide a baseline dist that's suitable for the average user. Power users will load the source and run it through whatever conversions they want in their own build process. They'll completely ignore dist the same way they do when they use Bootstrap with a preprocessor.

Looking at the CDN dist, it's actually not 100% minified, some people might want to minify it according to their own arbitrary rules.

Then, once again, they won't use the dist version. They'll run the source through their own build process and call it a day.

Don't you agree that it's not a framework's responsibility to consider a project's own specific build process?

I agree, which is why both source and dist files are offered. I think you're not understanding why the dist exists, and because of that you're ignoring a huge percentage of users who simply will not take the time to create a proper build process for the websites and apps they're creating. This is the gap Shoelace is filling. It's why the library is getting so much attention. Requiring any kind of build process at all creates a barrier of entry for many, many users.

Much of what you suggested makes sense, but all of it can be achieved using the source files in your own build process. I'm not sure why you think changing the dist is a good idea when it will make Shoelace less appealing for tons of users.

To be 100% clear:

• /source – use it along with your own build process when you want to custom tailor Shoelace to your needs
• /dist – use it when you want a fast, lightweight tool to prototype

Again, I appreciate your insights into HTTP/2, but I'm not going to argue back and forth about fundamental objectives. I feel I've described this library's goals pretty well, and I hope it makes more sense now.

[claviska]

Thanks for your insights on HTTP/2 😄

I beg the question: with the rise of HTTP/2, will it still be relevant to concatenate shoelace's CSS into a single file for distribution in a production context? Arguably: no.

It's not necessary now. In fact, until earlier today the website was using the source files directly. No minification. No prefixes. Not even HTTP/2. I don't think anyone even noticed.

To get to the point, I think shoelace should not build and distribute the concatenated version.

This is an interesting idea, and I'm open to doing it if we continue to minify/autoprefix the source files and dump them into dist. It makes the project more versatile and extensible.

However, I feel it's imperative that shoelace.css be included as well, even if it remains just a series of @imports. This gives people a one-shot way of including the base project, and will remain the recommended way to use Shoelace via CDN.

Some additional thoughts:

• If we do this, let's also move core variables to shoelace.css
• Variables for specific components (e.g. alerts, badges, etc.) should be moved to their corresponding CSS file (so not including one won't bear the weight of its variables)
• In the future, we'll be able to offer shoelace.css (core) along with a series of optional first-party themes/components that would otherwise weight the project down

The goal is to make things more modular, but maintain a one-line way for users to get started using Shoelace.

All in all, it's a great idea. 👍

Side note: Cloudflare sponsors CDNJS and it supports HTTP/2. If you use it that way, you'll automatically get HTTP/2 support. ✨

[darksonic37]

I'm not exactly sure what you took from my post. What changes are you thinking about making?

However, I feel it's imperative that shoelace.css be included as well, even if it remains just a series of @imports. This gives people a one-shot way of including the base project, and will remain the recommended way to use Shoelace via CDN.

This can be made available for prototyping but should not be given much emphasis. If you really want to be HTTP/2-aware, you should make it very clear that this should only be used for prototyping and is not recommended for production because it

• means you're transferring bytes you might not need
• delays processing and executing while waiting for the full response
• invalidates cache upon a single byte change, forcing another full transfer

Any other take on this just does not make sense in regards to HTTP/2.

This is an interesting idea, and I'm open to doing it if we continue to minify/autoprefix the source files and dump them into dist. It makes the project more versatile and extensible.

It's pointless, because your Autoprefixer query (that determines which prefixes are generated) might be inadequate for other projects and will render the dist useless. Maybe they want to target less browsers, maybe they want to target more, who knows? In most cases the autoprefixing that was done will be overwritten by the end-user's own build process anyway, so this is wasted time.

There's many ways to go about minification as well. Looking at the CDN dist, it's actually not 100% minified, some people might want to minify it according to their own arbitrary rules. As a library I would just stay out of that. Production environments have very specific needs that you just can't be accountable for. It's the end-user's responsibility to introduce shoelace into their own build process and do what they want with it.

I realize most frameworks take autoprefixing and minification into consideration, but maybe we should change that. Don't you agree that it's not a framework's responsibility to consider a project's own specific build process?

If we do this, let's also move core variables to shoelace.css

This makes sense, independently of the whole HTTP/2 discussion. It centralizes customization: variables and files you want to load all in one place. 👍