71–80 of 135 posts
I generally like to see a "kitchen sink" page with everything from the framework in addition to the option of having to go through the various parts and discovering whether they exist and what the defaults look like. I don't know if this is a popular opinion, but if so it would be nice if it became the de-facto practice when these are released. This applies to all frameworks pretty much - if your web framework suppor…
What I enjoy about Spectre.css is that there is no javascript and the CSS is readable. It's easy to drop their CSS into a react component and extend it because it's so readable.
Breaking fundamental rules of user experience right off the bat is not a good sign when I'm evaluating a CSS dependency.
Earlier quoted context omitted.
I find the critical difference is length of time committed to a project. For my core business interfaces I use my own framework developed and refined over many years. For front end website development I just recently gave up and decided to use Bootstrap. (not implemented yet, just decided it recently) Mainly so that any web designer can jump in on the site and be productive with it, not just me. I don't want to use m…
> Mainly so that any web designer can jump in on the site and be productive with it, not just me. This is why I think CSS FWs (but also web FWs) are often preferred. At some point a large'ish team should be able to dive in to the project, get some shit done, and more on to other work. This get reeeealy hard without a high degree of standardization. FWs are primarily a means of standardization for me.
I don't work with a large team internally, but externally I do. Every website built using my platform has potentially multiple people editing it.
Also, wouldn't you consider long term support just as important as team size?
As much I don't like other people's frameworks, the more common the framework the more history of support online and ease of finding someone who can fix/upgrade it later.
At least that is my assumption moving forward with Bootstrap. Anyone else have feedback on supporting Bootstrap sites long term?
Lightweight => 10 KB I'm actually more looking for a grid system using flex in a few bytes
The more web development I’ve done the more I’ve swung back to just writing CSS myself rather than depending on CSS frameworks; I’ve ended up seeing these less as ways to accelerate development for a team that is skilled at frontend, but instead as a way for people who don’t like styling or have little experience in frontend development/low design sense to style things reasonably. But I keep seeing frontend framework…
When the occasional project comes along where some misinformed decisionmakers decide that the UI needs to be sexy, then it's vanilla CSS or maybe SASS time.
Earlier quoted context omitted.
As a "non-fluent CSS user", I find it challenging and frustrating to maintain visual consistency and cross-browser compatibility without frameworks. I totally appreciate the fact it's me being lazy to really learn CSS who is at fault. Think of it like different construction methods - you can build something, let's say the Pyramids, or you can take something already built and beautiful, but is not what you need, and s…
I think you're probably still thinking about CSS as it was 5 years ago. When you had to do weird hacks to get things the way you wanted them. Modern CSS is much easier. In fact, if you are sticking .row and .column everywhere you are doing considerably more work than just to define a grid layout using display: grid once in your CSS, and then just use semantic HTML thereafter.
Flexbox has very good support and consistent behaviour in all major browsers and for most of the time we can use flexbox model. With some learning for using flexbox and grid I could appreciate their utility. (though I do not use CSS regularly)
The state of CSS is very much improved and these days we don't have to depend on hacks like the float and clear in CSS. But, minor problems like the inconsistent behaviour of display:grid in IE 11 - make the need for a CSS framework relevant.
The more web development I’ve done the more I’ve swung back to just writing CSS myself rather than depending on CSS frameworks; I’ve ended up seeing these less as ways to accelerate development for a team that is skilled at frontend, but instead as a way for people who don’t like styling or have little experience in frontend development/low design sense to style things reasonably. But I keep seeing frontend framework…
Why would still make sense for skilled teams like yours? I can think several reasons:
- Prototyping: Probably not everything you do is detailed development and you might want to throw a quick prototype with not-too-bad styles. It won't be groundbreaking, but the ROI of using a CSS framework for those normally pays off.
- Cross-browser testing: an open source library will get bug reports from many varied places, and normally it's well tested cross-browser. Do you know about all of the flexbugs [1]? Do you even want to know? What about the 2012 trick of Paul Irish for box-sizing [2]? Did you know it was updated in 2014 and how awesome this update is?
- Documentation: when onboarding a new member on the team, if you are using one of the more popular libraries there is a large amount of documentation, github issues, stackoverflow questions and general articles on the web. While you might put the work to do this internally, even with great teams the internal documentation is normally very much worse than the OSS docs.
- Other topics such as accessibility (color contrasts, keyboard states, etc) are normally polished in the libraries. It's not free, it comes after bug reports.
For these reasons it doesn't make any sense that an experienced team build the whole CSS utilities from scratch for each project. So the only sensible thing as a company is to reuse some of the CSS through projects. Then you got an internal library! Why not open source it? You got one of those!
Just look at the CSS [3] of "simple button" of my library, which already inherits half the style from a label. If I had to do buttons from scratch I'd forget at least 2 of those: the cursor pointer (because most links with .button would have it naturally, but not those with events and without href!) and the box-shadow to 0 (which only happens in some obscure combination of browser, device AND resolution). I just offloaded that knowledge long time ago into my library and now I focus on improving on other things :)
[1] https://github.com/philipwalton/flexbugs
[2] https://www.paulirish.com/2012/box-sizing-border-box-ftw/
[3] https://github.com/franciscop/picnic/blob/master/src/plugins...
The more web development I’ve done the more I’ve swung back to just writing CSS myself rather than depending on CSS frameworks; I’ve ended up seeing these less as ways to accelerate development for a team that is skilled at frontend, but instead as a way for people who don’t like styling or have little experience in frontend development/low design sense to style things reasonably. But I keep seeing frontend framework…
Our organization adopted Bootstrap because it's a consistent and familiar framework and it takes less time for the inexperienced developers (most in my experience) to come up to speed on an app.
When you have 20 developers rotating responsibilities between 40+ apps with regular turn over and contractors cycling out, have consistent project setups and standard frameworks across the organization is essential.
Earlier quoted context omitted.
One of the sad realities of the web was proliferation of bootstrap everywhere. IIRC it was intended as a prototyping framework at first. But even sadder is grid frameworks based on the CSS grid popping up :( https://www.youtube.com/watch?v=mDRfFEcj3-Q
For 'business CRUD' interfaces, choosing something like Bootstrap is a good option. Record lists and entry edit forms etc generally don't need a designers eye.
I could replicate the bits I use from bootstrap using something else or from scratch but the RoI in terms of time invested just makes no sense.
I don't think I've ever used bootstrap 'as is' since 2, I generally create something similar to a 'theme' that is layered on top of whatever is BS-current, makes upgrading a lot less painful that way since I isolate a lot of my changes.
The big advantage is done right you leverage all the thousands of bug reports to fix things without overly constraining yourself.
Earlier quoted context omitted.
I've done frontend for quite awhile. I usually start with some sort of framework for every project and use only the minimal pieces for the foundation. Generally you need the same stuff for every site: - reset/normalize the styling cross browser - basic grid system - typography, forms, and buttons - "componentized" files with variables (sass, less, post css, etc) Basically I start with a custom build of whatever frame…
But is that grid system consistent across different sites? In my experience, I usually need to customize the "grid" to specific breakpoints and widths, as defined by designs/content. I find that it's often faster to just write a few helper classes for layout – specific to the site I'm working on – rather than use 15% of a framework's grid and still do heavy lifting. Of course, this isn't the case if the design team d…
https://picnicss.com/documentation#grids
In exchange it makes the framework a bit heavy (~10kb), but if you use the CSS these can be modified and optimized as seen here: https://github.com/franciscop/picnic/blob/master/src/plugins...
Edit: this is the independent experiment I did before merging the grid system into Picnic, which I think it's still quite cool: