Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Show HN: Smooth UI, a React UI Library for Humans (github.com/smooth-code)
87 points by neoziro on May 28, 2018 | hide | past | favorite | 49 comments


So is the key point here a terse syntax for using actual CSS syntax (as opposed to react CSS) to create component wrappers?

It’s not really clear what this is.

Lack of a giant obvious demo link really annoys me with this sort of thing - “hey look at the code and all these words about our new visual offering”.


The real game changer in Smooth UI is the way to extend components. This is a CodeSandbox example, feel free to play with it! https://codesandbox.io/s/7k8o4x7lj6


Looks nice; very bootstrap-y. With all the component libraries out there today, it'd be nice to know what's different about this one? What does this library solve that others don't.

Great work!


Smooth UI is not better than other libraries like Material UI or Ant UI but the focus is different. Smooth UI put the focus on developer experience, extending a style is very simple. Also it exposes some classes, you don't have to learn any API to extend components, you can simply inspect components and use the classes!

An example of extend: https://codesandbox.io/s/7k8o4x7lj6


Writing !important to something I extend is not what I'd expect, it feels like a hack.


Looks like the example uses that because it would otherwise be overridden by the variant=primary (which seems to be the default) so explicitly overriding that variant would probably be more intuitive and not require the !important hack.


I did not dig into that, but I would expect some intuitive solution if they mention developer experience.


This is a really good point... particularly with React Semantic UI [1] and Material UI [2] having tons of existing components, as well as pretty nice developer experiences.

[1] https://react.semantic-ui.com/introduction [2] https://material-ui.com


Agreed! Also I'd add ant-design [1] and grommet [2] (it is not very active although it works very well)

[1] https://github.com/ant-design/ant-design [2] https://github.com/grommet/grommet


FYI Grommet V2 has been in active development for a while and is now in beta. For styling, they’ve replaced SASS with styled components, which I think is a great move.


It's really nice to see a UI component library that is built on SC. I have multiple applications using React Semantic UI and it can sometimes be a pain to extend / compose its component's styles using SC (typically when working with child elements). Usually if you want to work with SC and vendor UI systems / components, you'll be working with CSS/SASS/LESS/Etc for the vendor components and SC for your own components. With a library like this, most of your components are now all SC (which has other benefits aside from just uniform style composition) :)

Edit: I think a big point that most non-frontend developers miss about these type of libraries is that they're designed to be extended, not necessarily used out of the box. Even if it looks identical to Bootstrap, the idea is to be able to have a nice base set of UI components that we can extend with SC -- the same way we'd extend our own internal components with SC.


I hate X for human tagline


I brought this up on a prominent package recently. You can see the discussion:

https://github.com/pypa/pipenv/issues/2228


I hate so much about pipenv despite it implementing some good ideas. Maybe I'm not with it any more...


This comment would be more relatable if you explained what you didn't like.


Verbose, colourful output by default. Emoji in output (entirely unnecessary). It's essentially a GUI tool, not a CLI tool. The kind of tool that says "look at me! Look how much I'm doing! Aren't I amazing?". Good CLI tools just do their job. Oh and it's also unbearably slow.


Blazing fast framework for Humans in Y!


High frequency calculation for Humans!


So what is this, Bootstrap-remake? Sorry to sound so snarky but I myself have found it a lot easier to just make your own components and not depend on some random 3rd party library. Makes it a lot easier to customize and you might learn a thing or two. Sure it's not so easy to create them but once you learn how it pays off.

Okay now that I browsed through a little bit of the API it's all right, you don't have to invent everything by yourself if you use this. But I'm still adamant that you'd be better off to maybe rather copy the components to your source than use it as a dependency. Also there's no TypeScript support? After a lot of reluctance I've recently come to appreciate how nice TS makes your life when you avoid most of the silly bugs. Yes, sounds funny for most of people who haven't used dynamic languages but well... live and learn I guess.


In fact, components like Radios and Checkboxes are very complex to create. So we use Smooth UI as a base, but it is intentionally very light (no big components).

About TypeScript, I am sorry, I am not a TypeScript user. TypeScript support would be awesome but I need some help on this!


Radio buttons and checkboxes are complex to create? What? Am I missing something here?


They're easy to create with HTML, but complex to create with React. This makes it easy again.


> Radios and Checkboxes are very complex to create

where's that complexity?

It's like a few lines of CSS and folks in our coding bootcamp can do it after watching a YT video.


I think he means making the checkbox components reactive and extendable in React.js.

That's not an easy thing to do.


Not sure why not. And what would you want to extend on a checkbox? It's a boolean switch.


At times I have wanted a tri-state checkbox, as well as a quantum checkbox. To each his own I guess.


set it to display:none and toggle state on mousemove => Schrödinger's checkbox :)


Extendable for CSS purposes.


> I myself have found it a lot easier to just make your own components and not depend on some random 3rd party library

This. Unless you make a very generic project (and if you use React for that, probably you are doing something wrong), you bump into limitations of any CSS-framework sooner or later (later is especially painful, since it is impossible to fix without ugly workarounds).


How did this get to front page?



I really don't like it when "switch" toggles don't let you slide while holding down. if you want a toggle and don't want to implement sliding, just use a checkbox. Sliding toggles have a sliding affordance, and when it's not there, it screws with me. The buttons don't have an :active state either, seemingly, but that could just be limitation of their demo stylesheet.


Anyone else experience odd Textarea resize behavior in the docs for this ? https://smooth-ui.smooth-code.com/#textarea


Transition all is evil, thanks for spotting the bug. https://github.com/smooth-code/smooth-ui/issues/8


That's what happens when you transition width/height.


The first example is of a button with poor padding, I'd fix that ASAP to impress potential users.


I just read (skimmed) through the source code of https://www.styled-components.com

Holy shit there’s a lot of code there. What is it all doing - can anyone summarize?

As far as I can tell it’s main selling point is letting you use pure native CSS in reactjs.

You can do that anyway in ordinary reactjs by writing:

<style>’put your css here’</style>

Put that straight into your react code and you can use any native CSS in ReactJS.


If you can't understand what it's doing from the source code, maybe read the documentation?

I'm not a huge fan of Styled Components, but it's a way to write properly encapsulated styles for just that moment - You write 'regular CSS' that's scoped to exactly that component, so it can't leak out and affect other parts of your site.


I read the source code because I was trying to see how a solved problem needed so much code to implement.


I don't think Scoped CSS is a "solved problem".

Well actually, I think CSS Modules solved it in the most "perfect" way, but I'm willing to believe that others have problems I haven't experienced before :)


Styled Components is a CSS in JS library. It generates classes from your CSS and inject them into components. This is much more complicated than adding a `<style />` tag in your component!


Why is this better than a style tag?

What’s the purpose/benefit of generating classes from CSS versus just using CSS?

Couldn’t I just inject a CSS string into a component and put that string into a style tag?


I will not explain all advantages of CSS in JS. You can find a lot of articles on the subject. An example https://hackernoon.com/all-you-need-to-know-about-css-in-js-...


The core premise for CSS in JS is solved by backticked strings in style tags as shown above.

The backticked string style tag shown above already solves all the issues with CSS limitations in reactjs.

Here’s what the article you linked to says:

“Why does this matter? Not all CSS features can be aliased with JavaScript event handlers , many pseudo selectors (like :disabled, :before, :nth-child) aren’t possible, styling the html and body tags isn’t supported etc. With CSS-in-JS, you have all the power of CSS at your fingertips. Since actual CSS is generated, you can use every media query and pseudo selector you can think of. Some libraries (like jss, styled-components) even add support for neat, non-CSS-native features like nesting!”

All addressed by backticked strings in style tags.


The core premise for CSS in JS is to work around CSS's global namespace. It means you can write styles for a component using a 'local namespace' and have to worry a lot less about accidentally affecting the styles of other parts of your site. Every other language has scoping, so why can't CSS?

This is especially helpful as your site and team scales - you don't need to worry as much about stepping on other people's toes, nor do you need to be as aware of the entire (styling) scope of your website. When you do share/cascade/compose/extend styles, it makes it a lot more explicit in the way you do it.

It's basically taking a concept like BEM and baking it into the language, reducing the mental overhead.


Your solution will pollute the CSS namespace.


Can you explain what it means to pollute the CSS namespace and why it matters?

Are you sure you are correct or are you just guessing?


Just stop being so confrontational. Styled-components enable you to use SASS, not having have to invent any classNames or worry about them conflicting, enables you to easily extend those styles and gives you the ability to mix code with your styles in kinda effortless way. Okay granted that mixing code is not as clean as I'd like it to be but still I haven't found a better option


You name a class ".button" and it will conflict with completely unrelated component's style tags which also have a class named ".button". You don't have this problem with CSS-in-JS. You isolate the styles completely.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: