This is not a criticism of this project specifically, but I feel like when you come out with a framework like this you should have a big "Why you should use Framework XYZ instead of Boostrap" section somewhere, because this is the main question most people will have.
>but I feel like when you come out with a framework like this you should have a big "Why you should use Framework XYZ instead of Boostrap" section somewhere
This is true for any product whatsoever, not just a framework.
Answer this question, and make it the headline of your landing page:
If I am your ideal prospect, why should I say yes to
you rather than any of your competitors?
I think it's fairly obvious as to what the benefit is, considering how many times an app idea that's too "bootstrappy" gets railed on.
This seems like a decent alternative for out of the box design. Once/if this becomes popular then it too could become too standard- but for now, it's very different. That's good.
As far as design is concerned, I think more frameworks in the market is a good thing. The saturation could make the bad designers worse, but it gives good designers just more tools to explore with.
I'm really hoping the irony of linking to a CoffeeScript-generated JavaScript file and using it as an example of properly-written JavaScript was at least part of the joke here.
more like instead of Foundation since it uses Compass+Sass.
I just glanced at it and it seems extremely close to Foundation, it even uses orbit. I like the tooltips and the forms, the documentation is actually better than the Foundation one. I don't particularly like the grid system as it works in ratio (feels like you have to do more math).
What's really hard for new frameworks to overcome is the huge community that Bootstrap has created, checkout the big badass list of Bootstrap resources:
CMIIW, the project you mentioned is not really usable for customized bootstrap, it's all-or-nothing.
Since I want to include (customized) Bootstrap into Compass but don't use fancy stuff (variables etc), I simply rename bootstrap.css to bootstrap.scss and be done with it.
In our current project instead of putting the framework's html/css into our codebase I'm outputting as bare bones html as I can with semantic class names on everything and then mapping those classes to the framework using sass mixins/extends/includes.
To make a RWD site I'm having to rewrite a lot of the framework to be mixins instead of classes so that I can use them in @media as SASS doesn't allow @extend in @media any more[1]. What I'd find really useful would be a framework thats entirely built from mixins/partials and outputs no css until you create your own classes that use them.
> What I'd find really useful would be a framework thats entirely built from mixins/partials and outputs no css until you create your own classes that use them.
the actual sensible question would be "..instead of this", and the answer is clearly "because it's been around much longer, many more people use it already".
Bootstrap is the incumbent so other similar frameworks _must_ explain why they are better, or it's the default choice.
Of course if you actually want to know why you should use a framework like bootstrap then you can just read bootstrap's site.
What I would like to see is an html/css/js framework like bootstrap or groundwork that is completely generic, with no styling at all; just a wireframe that lays everything out as it should. Then provide the ability to customize the look either manually or by some gui on the web. Otherwise you get a raft of "bootstrap" sites out there that all look the same unless a front-end dev goes through the painstaking process of overriding the default styles of the framework.
I use a CSS grid framework called Neat (built on top of a Sass mixin library called Bourbon) to do exactly this. Keeps my markup semantic, and is very easy to implement.
Plus, Bourbon has an amazing selection of Sass mixins and functions that make building stylesheets a joy.
I couldn't imagine developing withouteother anymore :)
This is exactly why I switched to Skeleton (http://www.getskeleton.com/). It's a few style sheets which are completely stripped down. It gives you a grid and a set of responsive media queries. Oh sure, there's some very basic styles for buttons and forms, but I ripped those out so it's just the essentials. Now, it just has what you need without bug all to get in your way.
Last I checked, Skeleton is just a grid system and doesn't attempt to be a complete framework (and is basically the old Foundation Grid isn't it? -- I think the guy that made Skeleton used to be a Zurbian) -- We can easily extract the grid system from Groundwork to be stand-alone and use it in the same way. If you'd like, create an issue on the Github page and I'll make it happen!
Agreed. I've mostly forgone using bootstrap-like foundations because of this issue. It's a lot easier to build something custom from scratch than to undo all the bootstrapped stuff. Maybe it gets you some pretty button styles off the starting block, but later when you really need to fine-tune your UX, it's hard to disentangle what you want from what's "in there". Plus, I find it a lot easier to create semantic markup when I can choose the class names and structure myself rather than using things like "col-256" which force you to create extraneous markup.
I've found that starting with the source .less files makes it easier to customize, and not include what you don't need... like using FontAwesome for the icons. I do find that bootstrap is a bit too prescriptive in terms of it's offerings, and hope that it can grow a bit. I like where it is a lot better than jQueryUI for example, but find that the more sites that use it with minimal changes, the more you notice it.
I agree with this -- I aimed at making Groundwork as close to this as possible. Even the button styles (colors, radius, borders, etc.) are all easily customized in the _variables.scss file. I think there's more we can do to make it even more generic of coarse, I encourage you to create issues on the Github page if you find components have too much stylistic direction. :)
hehe, I <3 Zurb, I've followed them and the cool stuff they post on their Playground and have been inspired with what they've done with Foundation over the years, too. Orbit seemed like a great component to include in Groundwork to achieve a MVP. I plan to write a fresh alternative or enhance and contribute to Orbit moving forward. The current version isn't quite as flexible as I want it to be (it needs to properly support content-only sliders with no images, have less image dependencies -- possible utilize SVG/font icons for controls, etc.)
Foundation has really tought me a lot and inspired me over the years. I gladly admit that I've been heavily influenced and learned a lot by the amazing work the Zurbians have been doing. I thought about just contributing to Foundation, but had so many ideas and things I wanted to do, that I knew they would eventually tire of reviewing my frequent pull requests :)
This framework is quite broken on the iPad (in Chrome).
- The dropdown menu doesn't work well. It triggers on hover, but trying to do "hoverintent" on the iPad simply fires the click event on the button, causing the menu to appear briefly before the page navigates.
- I can't even scroll at all on the demo pages. Dragging the page (to scroll) just drags the whole tab rather than actually scrolling.
Thank you very much for the feedback. If you would post the issues you're experiencing on the Github page, that would be really helpful in getting any bugs resolved! :)
As mentioned, one of the first things that should be addressed when you're building a competing framework is what yours offers that the "big boys" don't. I don't really see that; indeed, what I'm first hit with is something that doesn't look as polished as Bootstrap.
As I poke through it, the whole framework looks like an analog to Bootstrap; I have to ask ... why? Is responsive text the only thing not available on Bootstrap?
Also the grid designations of .two.thirds versus .span9 makes me vomit all over myself.
I appreciate and respect your opinion on this, but can you explain what about these semantic class names you find is causing you nausea? I've considered having them be chained (i.e. .two-thirds) instead of seperated, but find myself thinking that "<aside class="one mobile third"></aside>" and "<article class="two mobile thirds"></article>" is more natural for me to type
Not wanting to be too critical, but there's lots of talk about "not wanting to look Bootstrappy" (or to a lesser extent, "Foundationy") — in that without customisation sites using them can look cookie-cutter.
This is ugly - I'd rather see sites using Bootstrap or Foundation than this, however solid the codebase is.
Trying not to be excessively critical as building a framework like this is a big undertaking, but the aesthetics are bad, it doesn't differentiate itself, and it managed to crashed my browser. All very troubling, especially for a front-end framework.
Sorry! Not sure what the deal is with the Safari issue related to the tooltips plugin yet. :/
However, as stated in big superscript on the brand name, Groundwork is in Beta and was just published on February 5th (15 days ago). If you would all submit issues and contribute to the project on Github, I bet these bugs will quickly become a thing of the past! :D
Well I found this framework quite interesting, I don't want Bootstrap's visuals and baggage so I found this very appealing, the grid system is robust and appears to solve my problem which Bootstrap doesn't easily. As for the visuals, well I'm of the opinion that they don't need to look good to be good. Visuals designers usually aren't good at making generic frameworks, it is more of a programmer's undertaking to distill HTML & CSS into it's reusable parts, so for a framework to look good out of the box it needs both skill sets from it's developers.
I need to actually reposition my grid elements when breakpoints happen, not just resize or reflow them. The reordering seems promising (so I can alter the flow by appending css classes instead of needing to mess with html structure).
Thank you all very much for the feedback on this, I wasn't aware of the negative impact the viewport resizer was having on these mobile devices. It is to be expected that iframes would perform poorly on them and I had included a regex to redirect mobile user agents to the home.html page to avoid them having that served up. Perhaps the mobile device detection needs a more reliable method... Any suggestions? :)
I am aware of this issue, but haven't identified the problem yet (not on Mountain Lion with my current device) -- any help from the community would be much appreciated! Post any information that would help to resolve this issue here: https://github.com/groundworkcss/groundwork/issues/12
Modal design (full screen button) & responsive text are the only things I notice at first glance that might be missing from other more established frameworks.
This issue is most likely related to the resizer -- if you close the resizer are you still experiencing this issue on the iPad? Also, if everyone can please post issues on the Github Issues that would be very helpful! Thank you! :)
my biggest problem with all of these framework is using them on an existing site. it would be great if all of them wrapped there styles in a parent class that way it wouldn't breaking existing styling.
And for the LESS junkies out there:
* LESS Elements: Mixins library for LESS (http://lesselements.com/) * Semantic.gs: Semantic CSS grid system for LESS (http://semantic.gs/)
Hey, thank you for the feedback. Just to be sure, are you referring to the Messages and Callout UI elements? If so, I totally see your point, that may be something we'll want to change.
