Live data from Hacker News

Blueprint – A React UI toolkit for the web

blueprintjs.com

181–190 of 214 posts

Re: Blueprint – A React UI toolkit for the web

#181
post #142

Earlier quoted context omitted.

Styling is still "unsolved" with react IMO. 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 an…

I know everyone has their own favorite method, but one that I'm extremely satisfied with is using webpack > sass-loader > extract-text[1] to `include Styles from './MyComponent.scss'` in each component file, and then it all gets bundled up into a single css file per target (also great for eliminating dead CSS!). I use "layouts" at the root of my react hierarchy (under stores and routers and whatnot) and put my global…

This is also my same setup. It is refreshingly easy to maintain.

Re: Blueprint – A React UI toolkit for the web

#182
post #35

This looks really nice. 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 , 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 is still "unsolved" with react IMO. 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 an…

> Inline styles feel wrong

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.

Re: Blueprint – A React UI toolkit for the web

#183
Thanks very much @Plantir for open sourcing React UI toolkit. This already seems to be production ready. Big thanks for the detailed documentation. The amount of time you have spent in creating examples and providing excellent starting point is really great.

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

Re: Blueprint – A React UI toolkit for the web

#186
post #156
post #138

Earlier quoted context omitted.

Not all things are supposed to be mobile. All the products we write are supposed to run on a large display for our case.

That might be so, but the rest of the world cares deeply about mobile, even to the point of caring about mobile first. You should get onboard.

Maybe you should realize not all software are made to be used on 5inch devices, considering Palantir's tools, data exploration and other data intensive sites, it does not make sense to focus on mobile, because your target audience will not use them. Instead of me getting onboard, you should realize generalizing all use cases would not work in real life.

Re: Blueprint – A React UI toolkit for the web

#187

Earlier quoted context omitted.

And the doc has 4.2MB of minified javascript. Jesus christ. Tooks 9 seconds to load the page. All credibility gone. Why would I use components made by people who don't see performance problems?

This makes me sad. I made a CSS library[1] some time ago and recently could fit the whole landing page into 10kb for the a-k-apart competition[2], which I've reverted ever since to about 15kb in total because there were some sacrifices that I didn't want to make. I'm totally surprised when I see those multi-MB Javascript files. [1] Picnic CSS: http://picnicss.com/ [2] 10K Apart: http://a-k-apart.com/

Don't worry, you will knock this site out in terms of search engine ranking and bounce rate.
Post reply on HN