I’ve been using Materialize in a moderately large project but have been quite disappointed with the lack of customizability. I have experience with Bootstrap, Semantic and Materialize and Semantic has become my personal favourite.
We are now in the process of replacing the front end library of the project and thinking about using Semantic. Does anyone advise against it? Has anyone ran into serious deal breakers with Meteor + Semantic?
I made the transition from Bootstrap to Semantic a few months ago on a medium sized project. There are some “gotchas” with some of their components and how they interact with reactive data (and data that may not be available right away), but overall I’ve found it to be a very enjoyable framework to work with, and with a decent amount of community behind it.
If I were to do things over again, I think I’d take a week or two and build out the components I know I’m going to be needing first, to understand them in an isolated environment. A good example of this learning experience for me was understanding how to pre-populate a select dropdown without firing the change event for the select.
There are actually quite a few patterns I’ve found helpful in working through Blaze+SUI, I just haven’t had the downtime to really document them out. Feel free to DM me though if you run into specific things!
Thanks I feel I ran into some similar issues with Materialize, so shouldn’t be anything too new. Hadn’t thought about the issue you mentioned so it’s great to have the heads up. Will be using Blaze + Semantic as well, good to know someone who already had to go through some of the inevitable issues!
We use Semantic with Blaze exclusively now from bootstrap and love it. It’s so well designed you almost don’t need a template, just some CSS customizations.
It is missing two components which we had to get elsewhere, a slider and a sliding range, but you can find those out there.
Hum, actually that’s quite an important component missing. Hadn’t noticed. Decided to do a bit of github browsing and found this thread which links to this pretty awesome demo . So, an official slider might not be that far off
One issue you should be aware of is that semantic is that responsive design was an after thought. So as long as you are designing for one screen size, development will be a breeze. but if you need a responsive ui, the classes you have to use to make components ‘look good’ on all screen sizes are not consistent like using other grid-based libraries like materialize.
Yeah, I think everyone using SUI is eager to see those make it into core, but there are some pretty easy workarounds for a lot of them. The calendar was pretty much plug and play with the .js and .css files dropped into appropriate directories.
One more quick tip before the end of Friday – SUI will cause your standard-minifier-css package to choke quite a bit on client-side rebuilds. You will probably want to do this in development.
Hum, that’s sounds quite interesting! Could you share a small example/guide? Although I’m quite comfortable with classic CSS, less and sass are things that I haven’t properly looked into.
I love Semantic UI but they use JQuery to handle the DOM. It is fine with Blaze but with shadow-DOM front-ends like React or Vue it is a problem. They started http://react.semantic-ui.com/ to fix this for React.
I also love semantic, but another drawback to take into consideration is the apparent lack of upgrading. As far as I know, the current semantic-ui integration with meteor does not use the current semantic-ui version…
FYI, the creator of Semantic UI works full-time on a large Meteor application (at Qualia), so tight integration between Meteor & SUI is indeed possible
At Qualia, we actually don’t use the semantic:ui package. We created a local package where we keep all the SUI files. This gives more control over configuration (super easy to update the version whenever you want) and greatly decreases build times (since rebuilds happen at the package level).
We have a huge library of form components which tightly integrate SUI and Blaze; unfortunately, extracting these components out into their own package is very difficult. But maybe some day…