At the same time, there's many legitimate cases in which you want to optimize for desktop. For example: consider an IDE, where you have lots of panels and toolbars. In some cases it's unclear how you'd be able to support both desktop and mobile without significantly degrading the experience. Even Google struggles with this. How usable is Data Studio [0] on mobile? It's pretty terrible and unusable. But that's perfectly fine, because the desktop experience is great! I can't speak for others, but I can't imagine myself wanting to use a mobile device to get any work done.

Kudos to Palantir for open sourcing their UI toolkit.

[0] https://datastudio.google.com

But for external projects/webpages in 2016, where atleast 1/3 of usage can come from mobile devices, having a lack of mobile support is a complete, 100% nonstarter. And there are plenty of competing React UI frameworks with mobile support already.

Citation needed.

In all honesty though, good quality UI frameworks with good mobile support are on the top of my "#want" list.

This is especially valuable for teams that don't have the design talent necessary to generate something as visually rich and feature complete as Blueprint. But you're right, a mobile framework it is not.

However, what I really want for React is a style-agnostic component library that basically extends the regular set of HTML elements, but comes with no "visual" styling (other than really basic styling like the browser's default styling for <input>, <select> and the like). Only styling that is necessary for the component to function should be included.

Of course, optional themes would be fine. Also, non-visual styling should be completely inlined. Themes could inject "visual" styling via context. User-defined styling would be passed via class or style props.

Inline styles feel wrong, CSS alone isn't encapsulated enough to work with components correctly, CSS modules are TOO encapsulated which makes global styles and themes a royal pain, and adding another layer ala SASS or LESS feels like more of a "patch" vs a real solution.

And none of them really solve style inheritance in any way that I'd call elegant.

I end up using SASS and overriding default styles with weird hacks like using `.button.button.button` or (even worse) using `!important`, but it still feels wrong and doesn't scale very well at all.

I haven't run into a situation using this setup where I felt like I needed a dirty hack to make something work. It does add a layer of complexity to the build, but if you can get it working once you can just copy paste it into every new webpack config, and It feels very natural and tends to organize itself.

I am really not a fan of this new "css in your js" approach that the cool kids are using, but I guess I'm just getting old.

[1] output of the following config will be:

  dist/
  |_app/
    |_bundle.js
    |_bundle.css
  |_admin/
    |_bundle.js
    |_bundle.css

  const webpack = require("webpack");
  const ExtractTextPlugin = require("extract-text-webpack-plugin");
  const ExtractCSS = new ExtractTextPlugin("[name].css");

  module.exports = {
    entry: {
      "./dist/app/bundle": "./app.js",
      "./dist/admin/bundle": "./admin.js",
    },
    output: {
      path: __dirname,
      filename: "[name].js"
    },
    module: {
      loaders: {
        test: /\.scss$/,
        loader: ExtractCSS.extract(["css", "sass?sourceMap"])
      }, {
        test: /\.js$/,
        loader: 'babel',
        exclude: /node_modules/,
        include: __dirname
      },
    },
    sassLoader: {
      includePaths: "source/styles",
      sourceMap: true
    },
    plugins: [ ExtractCSS ]
  }

  .my-component {
    &_component-item {
      &--open {
      }
    }
  }

  .my-component {}
  .my-component_component-item {}
  .my-component_component-item--open {}

Care to elaborate? I've been using in-line styles in multiple production projects and to me it feels like the way styling was meant to be done all along. The purpose of React is to be able to define your UI as a function of application state and let the library resolve the UI automatically at run-time. Styles are a part of that UI, so it's only natural that they should be included. What most people end up doing is using CSS and doing something like "state => classes => styles" rather than the simpler "state => styles", but the main benefit to that whole abstraction has always been re-usability, and components already solve that. So what exactly are we gaining by using said abstraction?

Of course, that's only in theory. In practice, we gain pseudo-selectors (which are unavailable for use in in-line styles for obvious reasons), which is a noticeable pain point. In my experience it is fairly easy to work around as I only make a lot of use of :hover (which is all of a few lines to implement), I can see how it might be troublesome to others though. The other solution is of course to use a mix of in-line styles and classes, which usually involves writing in-line styles for component-level styling and classes for global themes and anything requiring pseudo-selectors. That approach seems quite popular on the React IRC channel.

It's just that people are now trying to componentize everything, including styles, so it's a new requirement we didn't have before. Put another way, one could say that now that we have a good solution for client side rendering, we then turned to good old global, cascading, hard to maintain CSS to try and fix that guy next.

I will not claim to be a JS expert by any means. In my basic usage of HTML, JS and CSS; I find that I can manipulate the look and feel easier with Jquery. When I add in React, I get a really elegant MVC system, but loose the ease of adding and removing classes of different HTML elements.

Maybe I'm doing it wrong, but that's just my experience.

They're going to move to JSS.

[1] https://github.com/oliviertassinari/a-journey-toward-better-...

[2] http://www.material-ui.com/

Each component has multiple style props, lest you resort to "div > div > div:nth-child(2)" in your own CSS.

Each "style" prop now has to be diffed by React too.

Doing things like hover on mouse/touch events seems like it will never be as efficient as using ":hover".

And when doing universal rendering, the amount of markup you send is huge. And you have to disable the browser-prefixing of style props.

Having said all that, the material-ui library is still great.

How about this simple way to decouple styling from components using CSS Modules (no inline styles needed):

  components/
  |__FooComp/
     |__FooComp.jsx
     |__FooComp.css
  css/
  |__components/
     |__FooComp/
        |__styleOne.css
        |__styleTwo.css
        |...

Inside FooComp.jsx:

  import defaultClasses from './FooComp.css';

  const FooComp = props => (
    <div className={`${defaulClasses.wrap} ${props.className.wrap}` } >
      <img className={`${defaulClasses.img} ${props.className.img}` } />
    </div>
  );

  export default FooComp;

  import FooComp from 'components/FooComp/FooComp';
  import FooComp$styleOne from 'css/components/FooComp/styleOne.css';

  <FooComp className={FooComp$styleOne}>

> "CSS modules are TOO encapsulated which makes global styles and themes a royal pain"

You can still use:

  @import '../someGlobals.css';

  .someClass { 
    composes: anotherClass from "./someFile.css";
    color: green;
  }

  .someClass { 
    @apply --anotherClass;
    color: green;
  }

  .someClass {
    background: var(--brandPrimary);
    color: green;
  }

There are plenty of options especially with PostCSS.

I'm amazed by the state of our tooling in front end web development.

It's "unsolved" in the sense that all the current solutions feel wrong (but work great), and if that's the biggest problem front-end development currently has, then it's in a pretty damn good place.

But it just seems like we are all stuck on this collective transe of needlessly complicated, overly fashionable tools that struggle with the basics.

From what I've seen (granted, not much), animation and styling look like an after thought, which is surprising. But I'm weird, I still write bare CSS to this day whenever the decision is up to me. SASS is cool, but not enough to justify adding another lever to the machine, IMO.

[0] https://github.com/StreakYC/react-menu-list

I really enjoyed and excited to see your take on Color Theme. Like bootstrap, I don't think sites created using Blueprint will look same. With minimal changes in variables,layout and using your wide ranging color theme wonderful results can be achieved in no time.

Big Thumbs up!!

I have created a small overview videos about various UI component available. (No installation or tutorials, only shown their various artifacts).

https://www.youtube.com/watch?v=ky7ec5Sh2kM

Just a note - we didn't intend to heavily publicize the project quite yet. For example, the docs site is still a WIP, so apologies if it causes issues for you on mobile devices.

Otherwise no issues (older laptop i5/chrome), so I guess you guys mostly fixed that by now.

[0]: https://github.com/palantir/blueprint/issues/122

I really like blueprint! Although I think it's a bit ambiguous in the documentation that there are some elements under 'components' which are not react componentsp per se. You are referring to this as they have a 'CSS API' (like navbar). It' not a big deal but if you are doing a react app it's good to have an overview of the actual building blocks. Maybe they should be under another section?

[0]: https://css-tricks.com/snippets/css/a-guide-to-flexbox/ [1]: http://purecss.io/customize/#individual-modules

[0] http://cx.codaxy.com

http://cx.codaxy.com/fiddle/?f=vwyHzOO1

http://cx.codaxy.com/starter/dashboards/sales

https://codaxy.github.io/state-of-js-2016-explorer/

https://mstijak.github.io/tdo/

  Blueprint is an open source project developed at Palantir.

I'm not sure why this is repeated on HN all over and over.

https://youtu.be/VBbejeKHrjg?t=9m32s

Google uses https://gaming.youtube.com/

IBM uses https://console.ng.bluemix.net/catalog/

SkateJS seems a bit nicer and also produces WebComponents.

I particularly enjoyed the piano example: http://blueprintjs.com/docs/#components.hotkeys

Presumably since React Native a solid mobile alternative, but shouldn't 2016-vintage web UI frameworks be responsive?

I guess if you're a big company like Palantir, you have the resources to do native mobile, so I see why they aren't making it a priority.

That feature is a drag-n-drop UI construction mechanism that would basically allow the user to glue together UI components (I call them UI parts) and write code only as a fill-in-the-blank task to complete the application.

I think React, Angular and similar paradigms might eventually make this possible. In the future building web applications, especially typical business crud applications with simple workflows wrap around a UI should not require more than familiarity with a development product and basic programming.

Edit: It looks amazing. (Still the performance issue is reproducible easily)

[1] Picnic CSS: http://picnicss.com/

[2] 10K Apart: http://a-k-apart.com/

Feel free to make a PR to improve things boubiyeah, we just haven't gotten to this issue yet.

What kind of answer is this?

I don't think "boubiyeah" is working for you, nor has signed up for contributing to your project.

When you publish something to a public forum, even if you it is an open-source project, you open yourself to criticism(actually criticism is a great tool to help you improve your project), so my suggestion would be to be open and positive about the feedback, even if it is not all back-patting.

PS: You have done great work on the toolkit, thank you for making it open source.

[1] http://github.com/franciscop/

[2] https://github.com/umbrellajs/umbrella/issues?utf8=%E2%9C%93...

I appreciate that it's open source, so inviting PRs and general contributions is cool, but there does seem a bit of a dearth in understanding of the problem.

This makes me cringe. Sure, encourage us to make a PR to implement a tri-state radio button if it doesn't exist. Don't encourage us to make a pull request to reduce a 10 second documentation page load time.

Just as a caution though, the library, in general, is intended for desktop web applications. We haven't made mobile-compatibility a priority, although at the very least, yes, we would like the docs site to be at least usable on mobile!

    var gt = document.getElementsByTagName('meta');gt[3].content='';

hahaha

This is a common problem with landing pages that promote things. Developers should pay more attention to optimizing the main page that promotes the libraries in question, as it can turn down potential customers ;)

I was looking at the other pages from this UI framework (docs), and they're not as near as heavy as the main page, so why not pay more attention and make the landing page lighter.

Other than that the components look very refined and worth taking a look.

As mentioned elsewhere in this thread, this page was released a little too early while we were still playing around with animations in the header. I've gone ahead and disabled them for now, so you should see leaner CPU utilization now. Thanks for your comments.

That being said the screenshots don't look so bad. The bootstrap style with lots of rounded corners and gradients doesn't really look like leading edge design, though.

I didn't think that the same is going to the machine performance requirements, though. I still hope the web,will remain usable without maxing out a dual GPU setup.

Performance is 100% acceptable and fluid on an iPhone 7 in Safari.

Having worked with both Desktop UI (Swing/GTK) and Server based UI toolkits (JSF), the value of ReactJS is a standard Component Life cycle.

I would propose having a ReactUI component specification with a standard version. The current specification [0] is not decoupled from implementation. The separate spec and implementation numbering will enable multiple implementations - ReactJS from Facebook being one.

I am thinking similar to Reactive-Streams [0] specification and Reactive Extensions [2] which have multiple implementations.

[0] https://facebook.github.io/react/docs/react-component.html

[1] http://www.reactive-streams.org

[2] https://github.com/ReactiveX

Some of us were out in the wilderness building GWT components back in 2009/2010. And although compiling to JS was a pretty weird option at the time, it mostly worked. Your app looked terrible if you just cobbled together GWT's default components, but if you built your own components with custom CSS, you could end up with a really nice looking application. We even used immutability and one-way data flow where we could, though it wasn't culturally ingrained the way it is in the React community.

I understand why GWT idn't become mainstream. Java was really disliked in the JS community, even more than it is now. But having a big, maintainable web app using DI and all other sorts of fun things was actually kind of fun 6-7 years ago. I like React and Angular 2 better now, though.

Styling in React needs some sort of consistent way forward.

Given that it's from Palantir, is there any way this could become a security attack vector at scale?

Though I admit it is confusing since the "Let's Get Started" section of the homepage[1] does not mention including the global css.

[0] http://blueprintjs.com/docs/ [1] http://blueprintjs.com/

One question: I couldn't find advanced form components, and specifically dropdown/multiselects. (a bit like this: https://selectize.github.io/selectize.js/, or this: http://wenzhixin.net.cn/p/multiple-select/docs/#the-basics1)

Do you plan to implement this kind of components?

What is Qt without a GridLayout?

- bootstrap contains a grid layout

- semantic-ui contains a grid layout

- bulma contains a grid layout

- purecss contains a grid layout

- tachyon contains a grid layout

- skeleton contains a grid layout

- milligram contains a grid layout

- spectre contains a grid layout

and the list goes on.

Description: Sites whose addresses have been found in spam messages.

No demo's

Having bugs is ok. Failing at mobile and performance is not. It melts away your credibility because doing these things right is table stakes.

This is all compounded by the fact that it's a toolkit that serves as base for other developers, rather than just a slow app.

Finally, your flippant response to criticism gives the impression that you don't understand or care about craftsmanship.

However, thanks for making the contribution. Look forward to trying your next major release.

For others, it's an equally bad idea to limit your toolbox based on an irrelevant criterion.

1). Mobile is not just about 5" devices. It's also about tablets, and even about working well on larger iOS devices like the iPad Pro 12.9".

2). Data tools can be fantastically useful on mobile when adapted to make best use of the form factor. Lots of the data exploration/analysis tools out there have nice solutions.

3). Your target audience would use them. I'll bet you money it would take less than a day to sketch a few mobile scenarios, based on your own software, that a focus group of your users would rate as "very useful".

Disclaimer: I'm a designer at Palantir and have been using it for quite a while.

Seriously guys, it's 2016 and you still don't have a favicon. Not having a favicon on your docs page is plain bad for a few reasons:

1. I have zero context about your page. If I don't have that 20x20 square on my tab anchoring me to reality, my 2 second attention span will have made me forget where I am even before I load your page on my internet-connected toaster oven's 7 segment display. Not. Cool.

2. No support for 7 segment or e-ink displays. WTF?? How am I supposed to use this for IoT applications, like my toaster oven[1] or my dishwasher.

3. This is how it shows up on my kindle: http://67.media.tumblr.com/tumblr_lhw2rvgsnu1qzhofn.jpg ARE YOU INCOMPETENT??

[1] See bullet point 1

[2] https://static.googleusercontent.com/media/research.google.c...

[3] http://jepsen.io/

[4] https://palantir.com/spying-on-my-shit

This is the sort of knee-jerk dismissal that the Show HN guidelines ask you to avoid when commenting here:

https://news.ycombinator.com/showhn.html

Favicons have their importance but it's just rude to swipe someone's entire work off the table this way.

Edit: Doh. Carry on.

https://news.ycombinator.com/item?id=9238739

I'd agree that pokebowl's comment is a suboptimal way of getting that point across.

Oops. I completely missed that.

This is what comes of moderating in haste.

https://news.ycombinator.com/newsguidelines.html

https://news.ycombinator.com/newswelcome.html