A big goal of Kelp is easy customization without a build step. Leaning on the power of the modern web, I want you to be able to customize the hell out of it without ever having to jump into the command line, without ever installing any dependencies, and without every running a build. But finding the right balance of developer experience and web performance with that setup is hard, and I'm not sure what the right structure is. Today, I wanted to dig into a few options, and maybe even get your feedback! Let's dig in… The current raw structureKelp currently has a ton of modular files. It uses For a project still in development, it's been really nice to work modular files, open up a browser, and immediately see the changes without waiting for anything to compile. But should the "finished product" work like that, too? The benefitsIn the HTTP/2 world, we can download lots of modular files concurrently, so having a bunch of smaller files can actually be a good thing. And it makes customization absurdly easy. Let's say you wanted to use containers and the grid, but didn't need any of the other layouts. You can just open up
If you've been a developer for a while, you may have also had the experience of opening up a project, going to run a build… and getting a bunch of errors about out-of-date dependencies or security issues. It sucks, especially when you just want to update a line or two of CSS. This approach completely avoids that issue. You just edit and go! The consIt's really just one, but it's a big one. Kelp's modular files are really small (some are 0.3kb in size). With compression (like gzip or brotli), files under 1kb in size don't compress very well, and often end up bigger than their uncompressed versions. I ran some tests on this with Kelp, and the entire suite of utility classes bundled into a single file was about the same size (gzipped) as just one of the individual files in it was (also gzipped). Keeping them modular is actively harmful from an end-user perspective, resulting in 10x the data transfer for the same amount of stuff. A few ways to fix thisI've been thinking about this a lot (probably too much), and I see two potential options.
Both approaches get you to the same place: larger files that compress better, and a build-free experience for the end-user. But they also both have a few trickle down effects, and I don't love either of them. With both options, you can't just comment out an Option 1 means scrolling through bigger source files to find the stuff you want to edit or update. Option 2 means maintaining a build system and remember to run a build before each deploy (yes, I could automate it, but still). Text editors and |
Related Post:
- Daily Digest: A New Era in Materials Science: Antiferromagnetic Quasicrystals Unveiled, and more ...
- I’ve been quiet. Here’s why—and what I’m doing now.
- Thank you for joining the VoltBuilder Mailing List!
- Handbag Blowout: Purses to Fit Every Style
- Please confirm your VoltBuilder Mailing List subscription
0 Komentar untuk "[Go Make Things] The build vs. buildless tension"