Hacker News new | comments | show | ask | jobs | submit login
Show HN: Antd – A set of high-quality React components (ant.design)
507 points by _yesmeck on Nov 28, 2016 | hide | past | web | favorite | 104 comments



For those wondering who it comes from, https://ant.design/docs/spec/introduce#Who-are-using-Ant-Des...

The first (and presumably namesake) company is Ant Financial https://www.antgroup.com, which is described as:

> Ant Financial Services Group ("Ant Financial"), was officially founded in October 2014 and originated from Alipay which is the world's leading third-party payment platform founded in 2004.

So basically if Bootstrap came out of Twitter, this came out of Alibaba and Co. Big name behind it.


Alibaba is also working on a ReactNative competitor for Vue, called Weex: https://alibaba.github.io/weex/


we are using Weex for our app on production. Weex is pretty solid platform


Hey, can you tell us more? I'm very interested in Weex :) What make it solid ? what are the pros/cons ? Last time I checked I thought I need to know chinese as 95% of issues are in chinese for example. Is it still a prob ?


> Last time I checked I thought I need to know chinese

Fascinating. This is probably the first time I've seen a huge open source project where a majority of the contributions are in a language that's not English. I've seen plenty of projects from non-native English speakers, but everything was still done in English.

I'm sure there are tons of other big projects in Chinese and other languages, but programming has always been very English-centric. I had heard of programming languages that use other languages or alphabets, but they were all very esoteric.

I've also seen people using foreign languages for class and method names, while all of the framework APIs and programming language keywords were English.

So I guess it's only fair that I should learn some Chinese. Weex does look very good.

I just looked at this issue, for example: https://github.com/alibaba/weex/issues/1746

It's funny how all of the Java variables and keywords, HTML tags, and the CSS is all English (or at least, programming languages based on English words), while the issue details are written in Chinese. It's a really interesting mix.

I wonder if there are transpilers that let people write code in their native language, and then convert everything into English source code. It should be very easy, it's just a search/replace for keywords like "public", "protected", "length", "super", "return", etc. etc.


Wikipedia has a list of programming languages written in other "human languages"[0], but they are pretty obscure for the most part.

At the end of the day, english has "won" as the language of keywords in programming. And while i'm glad that most newer languages have the ability to code everything but keywords in your native language (i've worked with JS that has variables and function names in other scripts), translating the keywords seems like a pointless process that would do nothing but cause incompatibility.

[0] https://en.wikipedia.org/wiki/Non-English-based_programming_...


Hit the demos for Weex and compare them to Ionic 2. It's still day and night imho, whereas Ionic 2 looks very polished.


Can you be more explicit? I just want to make sure i understand you correctly. Do you believe Ionic 2 is better?

I'm looking at the demos now, but my main concern is how these behave on mobile apps. Performance, ease of development, etc. I have little concern for how they behave on my mac, fwiw. (performance on my mac may be related to mobile performance, but due to the very different architecture behind ReactNative style mobile apps, i'm skeptical to compare desktop performance)


Sorry, I actually thought Weex is another HTML5/Cordova thingy, but it appears to be more like React Native and calls native components. I have no experience with Weex running on the device. I just found the web demos unsatisfying.


AFAIK and.design has been used heavily in alibaba for internal applications


This stuff is horrible to use from the keyboard visually, because outlines have been removed without an adequate replacement. Please fix the styles for :focus et al. Make it all obvious, like Microsoft have done in Windows 10 (they have what is pretty much just a 2px solid black outline).


Looks like they're open to contributions: https://github.com/ant-design/ant-design/blob/master/.github...


a11y optimization is in progress, but it is not a high priority job.


I can certainly say that I’m flatly not going to use something that fails at keyboard usability like this, because I myself would hate to use it.


Yeah. I second this. Having non-obvious focus state is a deal-breaker. Obviously, it can be manually added in via CSS overrides on top of this library, but it would be nice for the library itself to have decent focus states.


a11y should be the top priority ... especially if you want to see use in countries where there are penalties for sites not complying with disability discrimination legislation.

Another issue is your DropDown breaks the power user convention of being able to type the first letter (or more) of an item and the dropdown selecting it.


Blueprint is another React UI kit that was posted here recently. They have interesting focus management feature where focus outlines are _only_ shown when navigating via keyboard. This is a nice balance since those active focus outlines can be obnoxious/annoying when _not_ using keyboard navigation.

http://blueprintjs.com/docs/#a11y


I tried using these components in Buttercup (our open source password vault https://github.com/buttercup-pw/buttercup), but immediately regretted it. It's impossible to theme, the less/css files are dirty and not extensible, defaults mess with your current style, etc. At first look, it looks promising and great but not when you actually try to use it.


Antd is an official implementation of the ant design language. If you read their introduction (https://ant.design/docs/spec/introduce) you'll see they target "middleware" products (or 中台应用, which actually should be translated to internal applications) which don't require customized UI and theming.



Has anyone used this? https://github.com/dvajs/dva


`dva` is maintained by the same team as `antd`.

More than 50 system use this framework in Ant Financial.


Not sure why I'm getting downvoted. I think it's a relevant question.

Context: https://ant.design/docs/react/practical-projects


Some really beautiful components like the TreeSelect in there, not trivial to build at all.

That said, the first time I loaded the page sure took a long time. Kind of sad to need Webpack to create chunks just to recreate the old effect of not loading all the content for your website all at once.


It's slow probably because the web server is hosted in China..


Chunking would be preferable in HTTP 2


The site looks pretty bad in a small browser window:

http://i.imgur.com/0xVlHbI.png


I concur. I run browser only in half of the wide-screen monitor (makes sense, doesn't it?), and it's surprising how many websites are broken in this configuration.


Not to mention the horrible things that happen when you switch from full-screen to half-screen and vice-versa.


I like it, there have been a couple projects where this would have cut time in half.

Some of the controls were hard to navigate on an iPad Pro. Time in particular was hard to use, not enough space. This is a fault of the resolution of the pro, but if the targets aren't big enough, I'm scrolling the page instead of the hours.


I was playing with it, great toolkit. The overall design language is neatly done.

Is it possible to convert the remaining site pages [0] into english.

Also, the mobile friendly components [1] also look great.

[0] https://ant.design/docs/pattern/navigation

[1] https://github.com/ant-design/1x.mobile.ant.design


Wow! that's very detailed UI kit. You guys thought all the necessary details when building web apps. It will definitely be my next project's UI kit :)


I was wondering if someone who is good at JS can compare this to BluePrint[1]?

[1] https://github.com/palantir/blueprint


BluePrint is a great UI toolkit. Ant Design is not only a UI toolkit, it's a design guideline which likes Material[1] and antd[2] it a official implement of Ant Design.

[1]https://material.google.com [2]https://www.npmjs.com/package/antd


Blueprint is meant for desktop applications. For example, Electron apps. You'll notice Blueprint tries to give that desktop app feel, versus Antd, which does not.


It isn't, according to their own words[0], they've never used Blueprint in an Electron (or other desktop) app.

[0] https://github.com/palantir/blueprint/issues/202#issuecommen...


I believe they meant desktop-feel as opposed to mobile first (mostly because some consider Material to be a mobile-first decision). Additional Note: Blueprint doesn't go out of it's way to degrade nicely for mobile screen sizes for most components and doesn't provide the grid layout or progressive embeds typically associated with mobile-friendly UI libraries.


I don't know, i think antd is easily suitable for desktop-like applications: http://i.imgur.com/5WN5WHE.jpg


BluePrint is a joke compare to this. Palantir can't create a landing page without crashing my browser.


I believe they fixed that. However, either way, I appreciate the contribution of Palantir. Really do not think it is good to ridicule the company for open sourcing their tech.


Would like a comparison to Blueprint that doesn't include the project's landing page.


Man this site is unusable on mobile


The actual components seem interesting. The odd part of this seems to be the building/requiring process. It seems that there are some implicit dependencies on webpack, which are not well spelled out.

It appears the team chose to make an oddly generically named babel plugin: `babel-plugin-import` which seems to do some manipulation of CSS/SASS/etc styles (which seems out of scope for babel). I assume the generic name was chosen hoping other libraries would embrace a similar pattern, however, I'm not seeing any spec defining how another library should implement this.

https://www.npmjs.com/package/babel-plugin-import


The site has some really good components. The only stopping me from using it is its not designed with mobile in mind. You don't get bootstrap like classes 'col-md-6 col-sm-12'. The grid is percentage based.


How's this compare to material-ui? I like material ui and it looks like you have some nice components, just curious what the x-factor is.

Always up to use a new tool!


antd has more components, about 50+.


For those looking for a cohesive ant design-centered library for Vue, this seems like the react project's counterpart : http://okoala.github.io/vue-antd/#!/components

The project appears to have far fewer features than the react project at this time



Fixed, thanks!


This looks promising! How does this compare to BlueprintJS [0]?

While I did like some components from Antd and intend to look into the source, from a basic overview, a lot of the documentation seems to be in Chinese.

[0] http://blueprintjs.com/


This is the nicest collection of web UX components I've ever seen (better than bootstrap). All of the look and feel (responsiveness and delays) are just right. Animations are not too heavy-handed and add to the experience.

Is this by Stripe? The components look just like their dashboard.


See floatrock's comment :).


Another good stuff by Chinese team. For Vue components, we have support from Ele.me


Great library, and very good to have an alternative to the react date/timepicker widgets out there.

Is someone already working on a bootstrap-themed version of this?


The design is good. It look nice! But it is very heavy compared to native HTML and CSS. It's like taking a space ship, to go visit your neighbor.


It's actually super light, i don't know where you got the impression that it's heavy. This is not a monolith but a modular kit - you only load what you use which makes it different from many other UI kits which give you megabytes of CSS on first load.

Also, this is native HTML and CSS of course, with proper definition, types and handlers laying out what the component can do:

https://github.com/ant-design/ant-design/blob/master/compone...

https://github.com/ant-design/ant-design/blob/master/compone...

Resulting in: https://ant.design/components/button/


It's a weak abstraction with maybe hundreds of nested dependencies and many compile steps. A lot of things that can go wrong ... Just to do this:

  <button>Hello world</button>


"Just"

To "just" use self contained, configurable, property-defined components that can be shared, re-used, filled with state - that isn't trivial. Which is why they're React components. The components themselves are very lean, there's a bit of code, some markup, a piece of CSS and that's that. The code i have linked compiles down to a couple of bytes.


I do not understand the problem with vanilla HTML and JavaScript. I've been doing it for 18 years so I might be "blind".


Has anyone used these: http://themes.getbootstrap.com/

How does it compare ?


Large library, I particularly liked the @mention component, first time i see a library providing that.


There was react wyswyg editor with this function couple of weeks ago here at HN. Was looking for it too. (https://github.com/jpuri/react-draft-wysiwyg https://jpuri.github.io/react-draft-wysiwyg/#/demo?_k=fws8cj - look for editor with mentions)


That editor doesn't allow editing on mobile Safari (iPad). All the examples are non-functional and some are visually broken as well.


And you can only import what you need with https://github.com/ant-design/babel-plugin-import


What's the filesize for this?


The minified version is about 1MB, see https://unpkg.com/antd@2.5.0/dist/ .

But you can import component individually by using this babel plugin https://github.com/ant-design/babel-plugin-import, see https://ant.design/docs/react/getting-started#Import-on-Dema...


This is really well executed, well done. I noticed a link to data visualization and graphics pages, but unfortunately I don't read chinese. Are there plans to wrap that stuff up in React in a similar fashion?


You can try Google translator..



It's so beautiful! Please please make something like this for react native too.


We're working hard on mobile version[1].

[1]https://mobile.ant.design


Thanks!! I did open the link but it was in Chinese. I will use this exclusively when it's released.


Will it be a separate library?


Yep, it's a separate library but also follows Ant Design's guideline, provide both web (for mobile) and ReactNative version.


we use antd component to build our internal applications almost half a year. It improves our efficiency obviously. thanks antd team.


Thanks for sharing! Amazing work!


I don't want to be that guy, and probably will be downvoted for being negative, but why does everything load so slow?

People on this thread are saying it's the network speed thing, coming from china and all, but isn't this supposed to have downloaded all the js modules initially?

I just keep thinking "it would have been much faster and I wouldn't have to wait for these progress bars to finish if it were just a static page".

Why does a documentation need a progress bar anyway?


The minified version of this library is about 1MB but loading individual modules is possible. I haven't checked my own net tab but I presume the site uses chunking in order to avoid downloading the entire library on the initial load.

The data is static and it is probably a SPA, but it's not all loaded on the initial load.


These components look and work great, but unfortunately are a real headache to retheme unless you want to pull in a sass/less toolchain in addition to what you're currently using. This is a pain in the ass if you already have your theme variables set up in one compiles-to-CSS language.

There is a standard for CSS variables and a very functional subset of their functionality can be compiled for older browsers at build time: http://cssnext.io, yet as far as I can tell, all of these component frameworks impose some other nonstandard compiles-to-CSS language or one of many possible APIs for writing inline styles.

Inline styles seem to be a trend at the moment but I can only assume the people driving this movement haven't had the experience of working with 3rd party components (which you may or may not have the source for) and needing to alter something the designers didn't expose and simply having no simple options because the damn inline style can't be overridden even by !important. Now you've got to fork whole the f'ing component, possibly multiple, each of which potentially coming with yet another different compiles-to-CSS toolchain all because you wanted to add a single line of CSS.

Admittedly, antd doesn't use inline styles si the above doesn't apply here, but having to maintain a custom builder for antd in order to change some fonts and a few colors was a frustrating experience. Not sure what a good solution is until CSS variables get more browser adoption, but it'd be great if we could collectively start standardizing on standards.


Theming is on of the big reasons we saw the need to make styled-components[0] (new lib to style React apps and component libraries)

I'm one of the maintainers of ElementalUI, and Glen Maddern, the styled-components co-creator, one of the creators of CSS Modules. One of the biggest downsides of CSS Modules (and, by extension, every other styles in JavaScript library right now) is that theming is simply impossible. Building third-party component libraries is hard enough, but providing an easy-to-theme API wasn't a solved problem in the React world. Nobody has done it properly, and there is no agreed-upon way of doing this!

styled-components has built-in theming support[1] to solve this exact problem. (note: this is CSS-in-JS, not inline styles[2], so overriding is easy as pie too[3]) We're rebuilding ElementalUI with it right now and the next versions of react-toolbox and Belle will be built with it as well.

We also have ReactNative support, which nobody else has done before. Just because you're writing a universal React app with a third-party component library shouldn't mean switching between three or four different APIs to style your app. With styled-components, you can just use styled-components no matter what you're styling!

(If you're reading this, I'd love to have a chat with the Antd people about maybe moving to styled-components! You can reach me on Twitter at @mxstbr, just ping me there!)

  [0]: https://styled-components.com
  [1]: https://github.com/styled-components/styled-components#theming
  [2]: mxstbr.blog/2016/11/inline-styles-vs-css-in-js
  [3]: https://github.com/styled-components/styled-components#overriding-component-styles


Hello!

I've been using Antd components for the last year in some my project. All components are also available here[0] as single modules for better reusability and customization.

Currently, I have solved all my theming goals with Plain CSS. For each component, that I'd like to customize I created a wrapper

   import Slider from 'rc-slider';

   function StyledSlider(props) {
      return <Slider className="my-slider" {...props} />
   }
Then in CSS

   .my-slider .rc-slider-track {
      background: #FFDF66;
   }
(This is a very simplified example, just shows the way).

I have read about styled-components, but I don't understand how it would help me with theming. I don't think that rewriting every component from LESS to styled-components to make possible to use ThemeProvider will be an option because it doesn't give you any benefits comparing with customization guide[1], that also gives you good enough way to override defaults.

   [0]: https://github.com/react-component/

   [1]: https://ant.design/docs/react/customize-theme


We're currently writing some documentation specifically pertaining to theming third-party component libraries, which you can read the WIP of here: https://github.com/styled-components/styled-components-exper...

The TL;DR is that this customization guide will suddenly become really easy. Antd can specify a default theme and users can override the parts of the default theme they want!

All the user has to do is pass a single prop to the ThemeProvier and override what they want:

    import { ThemeProvider } from 'antd';

    <ThemeProvider theme={{ primaryColor: '#1DA57A' }}>
      <App />
    </ThemeProvider>
On top of that different parts of your app can have different themes. Making your sidebar dark but your main component light is not an issue – just wrap them in two ThemeProviders with different themes:

    <ThemeProvider theme={darkTheme}>
      <Sidebar />
    </ThemeProvider>
    <ThemeProvider theme={lightTheme}>
      <Main />
    </ThemeProvider>
It's also all dynamic, meaning you can let the users of your app provide custom themes for your app and it'll automatically apply.

Compare that with the current customization guide, not only do users have to use webpack, they also have to use specific plugins just to make customization of third-party components work! It's also all global, which means styling the sidebar dark and the main area light is impossible since it's all just Less variables applied at build time. This also makes it very hard to have user supplied themes.

Does that make it clear enough how using styled-components would help with theming? :-)


The ability to apply different overrides for some branches in a component tree is powerful. Sure, I will come back to styled-components when I will get that issue.

Currently, I (as well as most users, I suppose) just need to apply some global color overrides to match with company's brand guidelines that I can solve it with old good plain CSS.

Also, for big projects, like Antd, transition to some other CSS-tooling almost impossible, because CSS/LESS code is spread across several repositories and will take a lot of efforts and time.

And finally, the current implementation is better because it doesn't mention styles in Javascript at all, so the library users are able to choose any way to style components without extra efforts from the side of library authors.


You can choose to style styled components any way you want too! You can pass in class names, inline styles, whatever you want just works. No need to be aware of styled-components from the user side at all.

Imagine Button being a styled component, all of the usual methods work perfectly fine:

    import Button from 'antd';

    <Button className="my-global-classname" />

    <Button style={{ color: 'red' }} />
You say "just" apply some global color overrides, but to "just" apply some global color overrides you need to use webpack (using another bundler? Sorry, antd is not for you) and use atool-build or have to configure webpack to work the way they need it to.

Or you create a custom less file, but that means you'll load all the styling for all components even though you really only wanted to use e.g. the Button.

That's not really "just" overriding a global color, is it? ;-)

I'm not saying this is a trivial change at all by the way, I understand the cost of it since I'm doing it for ElementalUI. I don't know if the antd maitainers will consider it worth it, that's another discussion.


A big issue I see with CSS-in-JS at this moment is server-side-rendering and caching. You started working on a babel-transform for extracting static styles but seem to have changed your mind about actually extracting that to a css-file[1]. Requiring a JS-parser to apply the styles is the wrong approach but might be a stepping stone as it's probably an easier problem to solve. Separating JS and CSS should improve performance somewhat as the browsers can run the scripting and styling engine separately. In the end I'd like a transformation that creates one CSS-file per JS-file so that common chunks can be combined by webpack, gaining high cache hit percentage on sites that uses reloads. Transformations should also be applied to the JS so that SSR doesn't have to calculate styles each time.

[1]: https://github.com/styled-components/styled-components/issue...


Would you mind chiming into that issue with what you imagine? I hadn't thought about caching yet, that's a good use-case for a separate CSS file!

We also almost have a proper server-side rendering API[0], in case you haven't seen that PR before. Should be released very soon!

[0]: https://github.com/styled-components/styled-components/pull/...


I think the work you are doing right can be a stepping stone for something great! The advantages of more traditional methods of creating CSS are ahead-of-time-compilation, splitting/bundling (combine common chunks to achieve low cache invalidation, low transfer size, and high cache hits with few files), and no waiting for the JS-engine to parse and convert your internal data structure. SPA-SSR is in general a lot more CPU-heavy than the more traditional approach of instantiating templates. We need to find ways of minimising the redundant calculations performed by the server to regain the performance we lost in the transition from templates to SPA-SSR. A source code transformation that extracts CSS and removes static JS is one such step. The SSR API is a good start but completely trashes cache + creates a large .html each time you reload. The .html returned can most often not be cached so we should strive to minimise its size. The problem of caching/minimising server load is not the easiest to solve but we should be long on our way if we can analyse/signal what parts are static and which are dynamic.


It is not a headache to retheme them. It is pretty easy, the easiest i've seen in a UI kit. You have style and classname overrides in place, scoped css classnames and LESS.

If you use a CSS react-lib like React-CSJS, styling this is easy as pie.


Theming is a difficult problem. Each component has a couple of visual properties which may depend on the state (hover, focus, error, internal variable). Having a separate variable for each visual property would be a nightmare.

I'm currently working on themes for a similar framework. It's still in early stage but you can see it here: http://cx.codaxy.com/v/master/themes/


Today, I was thinking about this problem.

You can separate component Style into - BASE + States classes.

classnames[0] can used to use multiple classes, the classes can be activated using component state. This provides a viable solution for Structure & Style.

[0] https://github.com/JedWatson/classnames


This is useful for structuring components internally, but sadly doesn't help solve the theming issue at all :-(

What you want from theming is a global skin. You want users of your component library to be able to say "I want all of my buttons to be red" without having to wrap the component or pass a prop to every component. (simplified example)

Doing so just with class names is very very hard. It's what we've done for ElementalUI (together with Less), but it just doesn't work – it's a pita for users!


This exact approach is used for Cx components.


I agreed that it's been an unsolved problem, but I've been looking at 'styled-components' and I think it may be the answer.

At least on paper, it solved the issues you raise. Time will tell I suppose.


SCSS (and to a lesser degree LESS) are basically industry standard now, if you are using react, you are almost certainly using one of the two preprocessors.

I don't think your complaint is relevant here, especially since you provide no solution.

It bothers me that this reply is at the top of the comments.


The argument about inline styles is valid, in my opinion. I've had to fork and keep updating from upstream several react components for the exact same reason.


But it's not relevant to the article, since as they don't use inline styles.


I don't really see much of a need for preprocessors w/ css modules, post css, css in js, etc. It seems like preprocessors are becoming less popular, not more.


Looks like their (at least node-sass) popularity is growing: https://npm-stat.com/charts.html?package=node-sass&from=2015...

I use libsass and postcss combined and pretty happy about it.


I fail to understand this criticism. React Components expose a class hierarchy which can be namespaced well by their designers (if Antd isn't already doing this). Extending / theming with your specific CSS pre-processor is then pretty straightforward.


Doing it this way requires overriding every single built-in rule that uses the property you're trying to override… including states like :hover, :before, :disabled, :disabled and :hover, etc which can be easy to miss.

I've had some success with simple find & replace preprocessor but this gets complicated if the CSS uses colour manipulation functions e.g. color: color(var(--color-base) tint(50%)), then you're basically going to be re-implementing their whole stylesheet again.

Also, good luck making sure everything still works if and when the components are updated.

Ideally, you alter theme variables in one place, rather than finding and overriding them everywhere they're applied.


I want to speak generally about new UI components, since this is the 2nd post in a week (about a new library of UI components) that reached front page (that I've seen) which are not addressing what I see as a fundamental issue that future UI libraries should address.

For mobile platforms specifically. Now on the surface you can say that UI libraries these days, more or less, will work similarly if not exactly the same across platforms. I would say for most "types" of components this will be true. But form input field behavior is different enough between mobile platforms that I'm questioning why we aren't moving quickly away from native HTML form input fields.

I totally get the argument for accessibility (probably a lot of accessibility platforms depend on these fields), but even accessibility standards such as ARIA, because of some of these inconsistencies, should be pushing toward this goal (decoupling the form input UI components from native HTML form input fields) I think.

Does anyone else here have a strong opinion one way or another as far as their experience building PWA's on mobile where they've encountered the differences between platforms (I'm specifically familiar with Android vs. iOS)? Do you find the differences to be easy to work around? I'm especially interested in feedback from folks who have required some relatively detailed behaviors, such as consistency in how input fields behave when "tabbing" to the next / previous field, or how the "input type='time'" fields behave differently in terms of when DOM events fire while setting time. Or how native keyboard behaviors / layouts are sufficiently different that you'd prefer to have a way to make the experience within your app more consistent?


I can only imagine. Nothing shows but a blank page when clicking a site link in my iPad.


This looks great! Link doesn't work though...


Which link?




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

Search: