I don't see any benefit to using this framework to Bootstrap. The author lists the following pros and cons:
Pros:
- Published under the incredibly permissive MIT License (sure, I don't know enough about the different licenses to comment on this)
- Very well documented (bootstrap is very well documented, and has a huge community behind it)
- Seems to be easier to learn/use (that's subjective, but I think bootstrap is plenty easy to use)
- Has a Grid layout (yes... who doesn't use a grid layout?)
- Uses LESS (so does bootstrap)
- A very nice implementation of buttons, modals, & progress bars (again, subjective, but bootstrap has a great, and simple, button and modal implementation, haven't used the progress bars. also, <button class="btn"> is much better than <div class="button">, especially if you're going for semantics)
- Uses an Icon font for many of it's features (k, sure)
- Has some very useful extras such as the inverted class (so does bootstrap)
- Open to community contribution (so is bootstrap)
Cons:
- No image slider (bootstrap has this)
- No thumbnail classes (bootstrap also has this)
- No visibility classes (bootstrap has this)
- No SASS (does have LESS) (not really a con but ok)
- Not at a release >1.0
I'm not trying to dis the framework (I haven't use it), but the author is claiming that it is somehow superior to bootstrap and foundation and does not present any evidence supporting this claim.
The actual project itself points to "why it's better" - http://semantic-ui.com/ (this article is just a puff piece for it)
The basic "problem solved" is this statement right here:
Lose the Hieroglyphics - Semantic is structured around natural language conventions to make development more intuitive.
Is the difference between <div class="col-lg-4"> and <div class="column"> that hard for people? Sounds like a solution to a non-problem for me...
The author does a really shitty job of pointing out the differences between Bootstrap/Foundation and SemanticUI but if you browse through the documentation and examples it becomes clear that this framework has several features, components and modules that neither bootstrap or foundation have like dimmers, 3D transforms (shape), equal height columns, dividers, validation, ...
It features a lot of UI patterns that are pretty hard to pull of with bootstrap alone and that imho makes it worth it.
I'm not yet convinced by the actualy class name semantics, it might be a learning curve though. And i absolutely hate the button-divs ... bootstrap does a way beter job at keeping html semantics for buttons.
That being said, this seems like serious competition for bootstrap and foundation. I'm curious for the final release.
Interesting definition of "semantic". In terms of the code, I'd take <button> over <div> every day of the week. Similarly lists, <nav>, and all that other lovely html5 stuff.
I really don't like stuff like <div class="right floated text"> - specifying the layout with class like that is pretty gruesome.
But then, I suppose "semantic" has a different meaning for this project than the one that I'm used to in the HTML/CSS/etc. world...
"Article footer citation" is semantic in a language that describes structured content, while "big red button" is semantic in a language that describes design.
It does make perfect sense; for example, you may want to reuse the appearance of a nav bar button some place where a .nav-bar-button class would look strange, and the nested selectors that most popular frameworks use make this impossible (requiring .nav-bar-button to be a child element of .nav-bar). I went pretty far down this rabbit hole a few years ago before pulling back a bit recently. It's a very appealing concept, but in production you often run into corner cases where your basic display classes cause unwanted cascading (especially when wielded by users without a deep knowledge of CSS), requiring you to write a bunch of reset utilities with !important attributes. It's also ungodly messy, as a lot of people point out, and refactoring can be a nightmare when you have to grep for class names like "right" and "text" over dozens or hundreds of templates.
I've since settled into a pattern of using generalized module definitions (list-module, list-module--header, list-module--separator, etc), which is verbose but creates highly portable and maintainable classes. The few presentational classes that I do still use regularly are for white space (padding, margin, defined in short class names like .ptm for padding top medium, a convention borrowed from Nicole Sullivan's OOCSS libraries), and a contextual color palette (.box-warning, .text-danger, etc). The best of both worlds approach is to use a large library of presentational classes as sass placeholders (%color-scheme-inverse, %clearfix, etc) and @extend them where required. This does generate slightly larger CSS files but if you are properly modularizing your style definitions it shouldn't be an issue. The stuff that semanticUI is doing looks great and is a step in the right direction, but way-too-generic class names and lack of namespacing are a constant source of bugs (along the lines of putting all of your variables into a single global scope and using names like 'first' and 'finished').
>Semantic in the sense that it uses display classes to describe the appearance of elements, not their content or structure, which is what people mean when they talk about semantic markup (<header><section><footer>, etc).
... on bizarro planet, where everything is the opposite of this reality.
edit: or is the grammar you used here just terribly ambiguous? confused. what does "which" refer to?
That was brought up a lot the first time this was posted, but I think it's a good description for how he uses CSS class names with inheritance to structure things.
I find it interesting the author of this is so earnest about getting an image slider. I can't remember where I saw it, but it made it to the front page of HN... it was a single-purpose site demonstrating that sliders/carousels are lazy answers to information hierarchy challenges. I agree, although I've been guilty of using sliders in the past. However, I'm trying to make amends and try to come up with design solutions that don't require a carousel or slider.
I don't have any research to back up that sliders are detrimental if not just ineffective. But I do see how they can be just convenient...and not in a good way. The fast food of design? Tastes good at first but doesn't really sustain?
Will this fill the void of CSS frameworks for rapid WebApp development?
Bootstrap is fine, but even in Responsive mode it is not made for developing sound application interfaces on the mobile form factors. The grid adjusts, but the elements do not do a good job of resizing for touch over mouse use.
RatchetUI (http://maker.github.io/ratchet/) seems to be the best hat in the ring currently (one of the lead devs is one of the guys from Bootstrap and another is from Zurb); but the commitment to project leads me to believe even the founders aren't sure what they want out of it.
This looks pretty promising. I'm also very happy that they used LESS instead of SASS for their CSS pre-processing. I'm excited to see where this project goes.
Why do you prefer LESS over SASS? I prefer the latter, only because of how well it plays with Compass and the command line watch/compile it provides. I have tried all of the Less GUIs, but they only disappoint, and I have not yet found any similar command line tool.
I'm a massive LESS fan, but I'll admit one of the biggest failings in the tooling is the lack of upstream saving/compilation. Compiling on save is one thing, but if it doesn't recompile the manifest, it's useless.
Some of the Bootstrap v3 changes, like using class="glyphicon glyphicon-..." vs. just "icon-..." are things that seem inferior from a pure HTML standpoint, but were motivated by performance differences, especially on mobile devices. There's some hard learned lessons in the existing frameworks that shouldn't be thrown away lightly. (In static site it may just be a search & replace to change, but in a single page app such things could be much more complicated to change after the fact...)
Performance wise it's more efficient using a base class (.glyphicon) and a modifier class (.glyphicon-adjust) instead of applying base styles with a pattern ([class^="icon-"]). Read about the other motivations for the change here: https://github.com/twbs/bootstrap/pull/6342
This is not horrible. The architecture is pretty decent, and it seems a lot of thought went into categorizing the different aspects of the library. I, especially, like how each item is broken down into types, groups, states, and variation.
The UI makes some interesting choices, but I'm sure this could be skinned with a bit of elbow grease.
I'd say my only real complaint is the validation on forms - it seems specifically inefficient to declare an object in JS and pass in each form field and set it's rule as "empty". I would consider utilizing a data attribute and doing something like data-validate="empty". You could even accept a list of them with something like "data-validate="empty email" etc. The only downside would be figuring out a way to still accept custom messages - something like data-message="Please enter your first name." would be fine for one validation check, but passing in a multiple messages for multiple validation rules would get ugly fast.
Do I seriously have to click that little menu button to expand the left hand menu every time I want to look at a new element?
I just want to click through and browse the different elements but its seriously laborious. Maybe I missed something but based on that I dont think Ill give this the time of day.
I must say: It looks awesome. I've been using it for a small project, and it's pretty ok. The docs are lacking though; I've been through them a few times, but if I have to go back to something I saw, the website doesn't really allow you to do so; the docs need to be better structured.
As for the naming; it works, but the examples are lacking as well. Some don't have all the markup you need, leaving you to inspect the site, others have hidden constraints with accompanying tags that are required (tends to go wrong when you start mixing up stuff).
It's a pretty cool looking project, but I'm not sure this is the way to go. My ideal framework would be bootstrap with some UI elements from here, with Foundation's grid system.
This is not a semantic framework. Just because the class names are more defined, they're still the same classes for the same purpose.
A CSS framework that uses classes for decoration will never be a semantic framework.
In order to achieve true semantics you have to have a complete separation of presentation from markup.
Nonetheless, I like this framework, specifically the UI modules that are in place. We need a standardized set of modules like rating, and so on. Good job.
AFAIK, "three columns" is not semantic. It has to relate to the content, not the style. Otherwise one would have defined semantic as "using full words". As a CSS framework can't cover all the cases, you need to apply it in a semantic way. Some pseudo-LESS-code would be like:
Interesting, but I wonder how well it will do? Bootstrap is already very widespread and benefits from network effects. Foundation is a nice alternative to Bootstrap that appeals to people looking for such (I'm a Foundation user myself). But a third framework? Can it get traction?
Of course it can, if it offers something different. Compared to bootstrap 3 I don't really see it. Even their own biased comparison doesn't really show a difference if any. For their comparison I would have preferred to see what makes it different on the less side of things. Ie used bootstrap properly.
Bootstrap doesn't care about your environment, can be abstracted easily into automated Grunt->Assemble generation (amongst other flows) using JSON data as the informer, works with an immense amount of different use cases, has highly active forks with SASS rather than LESS (if that's your flavor), and doesn't care about your development model regarding JavaScript. In effect, it's neutrally-opinionated on a high level.
Gumby might have its merits, but if I'm working with a set of fairly green developers new to the industry, I'm not throwing a highly-opinionated system at them to back them into a corner.
Bootstrap trades initial learning curve for huge expressibility. The column 'hieroglyphics' allow responsive behavior and column size to be declared in a single token. Semantic UI looks great, but the mud flinging tastes sour.
$ create "Website that has a homepage with a picture of dogs and a picture of me. Oh, and a little blog with a twitter feed. Make it look cute, idk, like pink and blue, but not bold, but that washed out water color that's in right now."
---> Making...
---> Looking for pictures of puppies...
---> Writing several blog posts for you...
---> Created! http://my-website-blah-blah.tld
Pros:
- Published under the incredibly permissive MIT License (sure, I don't know enough about the different licenses to comment on this)
- Very well documented (bootstrap is very well documented, and has a huge community behind it)
- Seems to be easier to learn/use (that's subjective, but I think bootstrap is plenty easy to use)
- Has a Grid layout (yes... who doesn't use a grid layout?)
- Uses LESS (so does bootstrap)
- A very nice implementation of buttons, modals, & progress bars (again, subjective, but bootstrap has a great, and simple, button and modal implementation, haven't used the progress bars. also, <button class="btn"> is much better than <div class="button">, especially if you're going for semantics)
- Uses an Icon font for many of it's features (k, sure)
- Has some very useful extras such as the inverted class (so does bootstrap)
- Open to community contribution (so is bootstrap)
Cons:
- No image slider (bootstrap has this)
- No thumbnail classes (bootstrap also has this)
- No visibility classes (bootstrap has this)
- No SASS (does have LESS) (not really a con but ok)
- Not at a release >1.0
I'm not trying to dis the framework (I haven't use it), but the author is claiming that it is somehow superior to bootstrap and foundation and does not present any evidence supporting this claim.