Comments (4)
Just a heads up — I'm going to experiment with this on Friday.
from shoelace.
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.
from shoelace.
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. ✨
from shoelace.
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. 👍
from shoelace.
Related Issues (20)
- Can't find variable: __SHOELACE_VERSION__
- sl-change event bound to vuejs markup doesn't trigger
- Couldn't access styling of selected option.
- `sl-select` doesn't update label if `sl-option` label changes HOT 1
- Broken css in button styles file HOT 1
- sl-input should create fewer native input elements HOT 1
- tooltip placement on range component HOT 1
- Spinners do not display properly in Safari HOT 2
- As I'm a C++ guy ... HOT 2
- How to remove Lit In dev mode warning?
- sl-textarea may throw error on disconnectedCallback because input element is not found HOT 1
- Shoelace Element not updating when using Async-Pipes in Angular or async data in vue HOT 2
- carousel with "slide-per-page" is not working properly in rtl documents HOT 1
- `@watch()` shouldn't patch the prototype every time it's used. HOT 2
- Looping Carousel is out of order when inside of Sl-Resize-Observer
- Menu: Submenus: Right to Left: Submenu Location and Arrows not flipped
- Localisation does not respect browser settings HOT 3
- Events should subclass Event instead of using CustomEvents HOT 1
- Autofocus doesn't work on sl-input in Firefox and Safari HOT 1
- Submenus in dropdown panels don't scroll
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from shoelace.