Any reason to avoid Meteor + Semantic UI?


#1

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?

Thanks


#2

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.

There are a few quirky things to look out for, like the fact that SUI uses class name order and meteor strips dup classes, or that you will need to call $('.ui.modal').modal('refresh') after populating a modal with dynamic content that changes the modal size.

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!


#3

Thanks :slight_smile: 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!


#4

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.


#5

Speaking of components, I missed out on this calendar for quite a while. There is a thread here with semi-instructions and a bit of history.

Do we need a SUI tips and tricks thread?


#6

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


#7

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.

Otherwise semantic is a fine choice


#8

Heh, your comment made me browse their github repo even further. It seems there are quite a few components on the limbo between dev and official: https://github.com/Semantic-Org/Semantic-UI/issues?utf8=✓&q=is%3Aopen%20label%3A"UI%20Component"%20sort%3Acomments-desc%20


#9

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.


#10

Yes. I really hate the “responsive” thing in Semantic with unconsistent sizes.

Do you know another good css framework?


#11

Yes my site looks Nice, but on safari : iPad iPhone iT is too small…


#12

What I ended up doing to include a sass-grid package to wrap each semantic
component. It worked remarkably well


#13

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.


#14

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.


#15

Here’s how I did it, it might not be optimal, but it works:

Your semantic component here will be 4 cols wide on tablets and higher
Your semantic component will be 8 columns wide on tablets and higher

#16

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…

Best,

JJAP.


#17

Oh! Could you please share a snippet for that?!

Best,

JJAP.


#18

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 :slight_smile:

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…


#19

I will try to track down that code but it’s been a while since I’ve used it.


#20

Thanks @veered,

Not sure how to read this, is this good or bad news fo SUI since you have your internal package? Will SUI keep seeing updates?