Blueprint – A React UI toolkit for the web
blueprintjs.comI see a few comments bringing up mobile. There's already many mobile-friendly UI frameworks; not everything has to be mobile-first. Yes, in many cases it makes sense to go for a mobile-first approach, especially with consumer-facing applications. Mobile is huge and apparently it's still continuing to grow.
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.
For internal projects/webpages (similar to Google Data Studio as mentioned), where you would expect the user to only be using it on a desktop, having no mobile support is fine.
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.
> 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.
There are a bunch of bootstrap components ported to React in the Reactstrap project.
I'm not sure how you come to this distinction between internal/external. The delineation is much simpler and more obvious. Is Blueprint made for mobile use cases? No. Therefore it's highly optimized for non-mobile use cases. Despite the buzzword focus on mobile applications, there's still plenty of work being done (and left to do!) outside of that. For those uses, Blueprint is great!
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.
Such As?
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 <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.
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 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 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 styles there.
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 ] }That is what we do as well, but if you use a UI toolkit that includes it's own styles, you'll need to override them. That's where the fun hacks like .button.button.button come in to override the included styles.
Oh yeah, I see what you're saying. I just don't bother with toolkits since I find that once you factor in said fun, you aren't really saving much time, and you might end up with a lot of jank. I just roll my own based on the needs of the project and keep my cascade very flat and specific. Sass makes this really easy using BEM style naming, where you can do this:
and you get a nice, flat output:.my-component { &_component-item { &--open { } } }
I wish framework authors would adopt this approach as it completely eliminates specificity conflicts..my-component {} .my-component_component-item {} .my-component_component-item--open {}
I've done the same thing. An issue I run into is it's easy to end up with lots of the same media query littered over the place, which can harm performance and feels quite messy.
You can use some more advanced-ish sass features to help with the maintainability, but it can still kill perf if you over use it.
This is also my same setup. It is refreshingly easy to maintain.
> 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.
Yes, thank you. This has been my biggest problem with React as well. It feels like they are fighting against some of the most natural ways to use CSS in code. Which is too bad, b/c CSS is awesome, and React is awesome. But together it feels like they don't play well.
Why? They actually can play well, at least, just as well as standard HTML + CSS.
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.
Perhaps it's a CSS issue. I've just noticed that when working only with CSS adding and removing classes in JS it's simple. All of the React frameworks feel like they don't meld well with that.
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.
I saw this[1] recently by one of the guys from material-ui[2].
They're going to move to JSS.
[1] https://github.com/oliviertassinari/a-journey-toward-better-...
I really like material-ui but am constantly bummed about their use of inline styles.
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.
We just wrote all our own inline styles to override their stuff. It turned out to be not that bad. We just set up a context object like theirs, and wrapped all the components we used.
Yep... Settled for CSS modules for now; Works well enough.
You may want to have a look into CSS @apply - https://tabatkins.github.io/specs/css-apply-rule/ (currently supported only in Chrome trough).
> "Styling is still "unsolved" with react IMO."
How about this simple way to decouple styling from components using CSS Modules (no inline styles needed):
FooComp.css contains only the very basic formatting for the component which is needed for displaying it correctly out of the box. No styling/theming, just some raw universal formatting/structuring (if necessary at all). FooComp.jsx loads and applies FooComp.css internally using CSS Modules like this:components/ |__FooComp/ |__FooComp.jsx |__FooComp.css css/ |__components/ |__FooComp/ |__styleOne.css |__styleTwo.css |...Inside FooComp.jsx:
styleOne.css and styleTwo.css contain different (external) styles for FooComp. Now if you need to use FooComp with an external style you load both FooComp.jsx and the external style (again, using CSS Modules to load and apply the styles):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;
and put them together like this:import FooComp from 'components/FooComp/FooComp'; import FooComp$styleOne from 'css/components/FooComp/styleOne.css';
This way you can easily use the same component with different styles.<FooComp className={FooComp$styleOne}>> "CSS modules are TOO encapsulated which makes global styles and themes a royal pain"
You can still use:
or:@import '../someGlobals.css';
or:.someClass { composes: anotherClass from "./someFile.css"; color: green; }
or:.someClass { @apply --anotherClass; color: green; }
or ....someClass { background: var(--brandPrimary); color: green; }There are plenty of options especially with PostCSS.
React is supposed to be the "next big thing" and yet styling is still an unsolved problem.
I'm amazed by the state of our tooling in front end web development.
I know it's fun to scoff at "those front end guys" and act like you know all the answers, but if you do know the "one true solution" to this please tell us.
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.
I really don't know the answer. I'm a front end guy too.
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.
I tried to do something like that with react-menu-list[0]. Its components come with minimal styling, and it's recommend for users to create wrapper components which pass some default props to add their own application's CSS classnames / styling.
Well, you could use something like Reactstrap (https://reactstrap.github.io) which assumes Bootstrap classes, and simply not include the BS4 visual styles/themes
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).
Hi all, I work at Palantir and worked on Blueprint (although I'm currently working on a different project). Happy to answer any questions you have about it.
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.
Just a nitpick, but when looking at the docs, I can't move with Page Up/Page Down unless I click in the "content column/area", kind of annoying when one navigates using the left bar and then can't move around (on no-mouse setups, e.g. trackpoint + keyboard). So you might want to look at that.
Otherwise no issues (older laptop i5/chrome), so I guess you guys mostly fixed that by now.
Good catch, we'll take a look at this. I've filed an issue to track it [0].
hi,
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?
Hi! I'm not a web developer, I work on server side, native mobile and desktop, but I'm very impressed with your framework and want to give it a try for creating UIs. What I really don't like about web development is it's overcomplicated approach to laying out the elements. Do you have any kind of layout helpers in your framework?
Thanks for the kind words achikin! Blueprint doesn't include anything to simplify layout. However, if you're able to only support relatively modern browsers, flexbox [0] is a great CSS feature that really makes layout easier. If you're looking for something like the traditional CSS library grid, you can always grab it from a different library, like PureCSS [1], and use it side by side with Blueprint.
[0]: https://css-tricks.com/snippets/css/a-guide-to-flexbox/ [1]: http://purecss.io/customize/#individual-modules
Thank you very much for your help!
This might be a little bit outside Blueprint, but, I cannot not take the opportunity to ask - how is the reactions internally at Palantir now when the chairman and co-founder now also is part of the Trump transition team?
Ah, memories. http://blueprintcss.org/
That was the first CSS grid framework I remember coming across. Last updated in 2011, it's not responsive at all it seems. Completely staggering how far things have come in 5 years.
Me too also. I used BlueprintCSS for quite a while, it was pretty good.
Your homepage pushed my CPU to 75% and resulted in an early click on the red cross of the tab. (latest chrome stable/osx 10.11) You should do better.
Same thing happened to me (latest chrome/ubuntu 14.04)
Yes, the 3D logo made me immediately think this library had performance issues.
Looking at chrome task manager, webgl seems to be the problem (logo at top of the page)
Loaded fine on edge..
This is very slick. It's similar to my own project http://cx.codaxy.com/docs/widgets/date-fields, however, it seems that they went one step further.
Impressive work.
Thanks. Here are a few more links for things implemented with Cx:
http://cx.codaxy.com/fiddle/?f=vwyHzOO1
http://cx.codaxy.com/starter/dashboards/sales
This is impressive, I can cover lot's of UI scenarios with it. I also like the first class CSS/HTML API that they have, so I could use them without React. And they seem to have Accessibility covered (need to dive in a bit more), but this is super important. And at last, I dig the visual style, which has good affordances. A nice contrast to Material Design.
Blueprint is an open source project developed at Palantir.Haha, I'm sure some intern at Palantir is now also writing a Java SWT to Blueprint translator. The poor soul.
Notice that this toolkit is written in TypeScript.
I wish web based UI-toolkit creators would focus on WebComponents. They can easily be used as leaf-elements in almost any framework.
+1 for web components and Polymer https://beta.webcomponents.org/
A lot of people go on about Polymer, but no one actually uses it?
Hm, some of the biggest enterprises in the world and industry leaders use it.
I'm not sure why this is repeated on HN all over and over.
BTW, Chrome browser's: PDF reader, download listing, new settings are Polymer afaik.
Google uses https://gaming.youtube.com/
Theres tons more. Btw. "main" youtube is also switching to polymer.
I tried it, but it was too clunky for my taste.
SkateJS seems a bit nicer and also produces WebComponents.
The thinking of - Learn once write everywhere does not apply to WebComponents.
If someone wants to be an exemplary citizen, rendering all of the components on to a single page for us on mobile would be amazing.
Yes, I was looking for a "kitchen skin" page and was disappointed not to find one.
This looks great. Nice to see a complete UI toolkit with context menus, sortable tables, hotkeys and editable text along with all the normal tooltips, navs, and UI widgets. Bonus points for both sass and less support. Looking forward to trying this out.
Is this page written in Blueprint? It makes my Firefox consume 100% CPU.
I am using latest FF too. Very lag
Same problem here. Win10 FF49
Despite the sluggishness, there's a lot of really likeable stuff in here and it is beautiful (or, a lot more beautiful than I, or most developers, could ever come up with without a team and some pro designers on staff).
I particularly enjoyed the piano example: http://blueprintjs.com/docs/#components.hotkeys
Documentation is unusable on mobile... I hope that was due to someone making some CSS mistakes with their page code and not the framework's code.
The framework, while polished, lacks any responsive grid components. A bit of a glaring omission imho, in this age of Bootstrap and Semantic-UI giving you a responsive grid out of the box.
Maybe just me but I'm having a hard time seeing how this is substantially different from or better than bootstrap or foundation with some react-based wrappers like reactstrap. Seems like performance is an issue and you're just as tightly coupled to the framework as with bootstrap/foundation. Am I missing something?
I tried to look at the site on my S7, but it ground it to a halt. Tried on my i7 laptop, same result :/
Unfortunately, mobile support is not on the roadmap: https://github.com/palantir/blueprint/issues/105#issuecommen...
> Just as a caution though, the library, in general, is intended for desktop web applications. We haven't made mobile-compatibility a priority https://news.ycombinator.com/user?id=jasonkillian
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.
Yes, I would really like to use this but don't have the time or resources to build and maintain a separate mobile UI. With bootstrap/react-bootstrap, things usually turn out OK/good on mobile without me having to really think about it.
I am the developer of HiveMind (crudzilla.com), I am currently stuck on what I think would be the final feature of the platform that would fulfill my vision of what a modern web application platform should be about.
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.
Not to sound like a bummer here, but I'm not sure what kind of computer is needed to open this webpage. Simply scrolling up and down that website causes my computer to almost freeze. Firefox 49.0 user here. I would profile it, but I'm afraid of having to restart the computer as a result.
Edit: It looks amazing. (Still the performance issue is reproducible easily)
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.
Oh, but it's an app, not a website. There is absolutely no way to display static documentation and a few widgets without 4MB of code. None. It's just impossible. Get along with the times, dude.
We're aware of this: https://github.com/palantir/blueprint/issues/39
Feel free to make a PR to improve things boubiyeah, we just haven't gotten to this issue yet.
> Feel free to make a PR to improve things boubiyeah
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.
In my experience[1] the best way to get contributors is exactly the opposite, you have to leave the easy and cool parts for new people and do all the grunt work by yourself. Making a new feature is something fun that other contributors can try to do and learn a lot, while optimizing your website is something that mostly only saves you money (as contributors could do that virtually anywhere else and learn the same). See an example of what I mean: [2]
[1] http://github.com/franciscop/
[2] https://github.com/umbrellajs/umbrella/issues?utf8=%E2%9C%93...
I think given the gp, this is quite a perfect reply. 4.2mb of js on a text-oriented docs page is either an infrastructural problem or it's by design. Dismissing it casually as something that can be considered a simple "issue" solvable with a PR or two seems a pretty clear sign of "people who don't see performance problems".
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.
"Feel free to make a PR."
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.
Is there a demos section? Tried to load http://blueprintjs.com/docs/ on mobile (chrome and Firefox on Android), most of the page is cut out due to scrolling restrictions
That's the right place to see examples - sorry that it doesn't work well on mobile yet.
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!
The meta viewport is breaking the docs site.
Fixes it for those in a rush to see it. There is a "view source" app in the AppStore that allows you to inject js.var gt = document.getElementsByTagName('meta');gt[3].content='';
iPhone safari doesn't show the docs overview page in view (cropped pretty bad) + can't scroll the page at all.
"I agree that HN and other devs will be ruthless when it comes to perf."
hahaha
The funny thing is, so many people don't seem to realise that ordinary end-users will be, too. End-users care about performance. Not all of them necessarily understand that what they care about is performance, but it all contributes to the experience. Even back I need the 90s there was much statistical evidence that the slower a website was, the lower engagement it received.
There's an interactive animation in the header that really makes the page lag a lot when scrolling, spiking the GPU (look at the devtools, also scrolling is being tracked somehow)
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.
Although the docs don't seem to be responsive either.
Hi folks, I'm one of the developers of this project -- we hear your perf concerns loud and clear and are tracking the issues :)
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.
Even now, it's still pretty sluggish, all around. My machine is, I think, as big as can be expected (current gen i7, 16GB), though I am on a slow 4G network. But, as others note, it is gorgeous, and the API appears well thought-out, and very complete (or, at least, complete for the kinds of systems UIs I build).
Weird, because on my iPhone 6, it works fine with no detectable performance issues at all.
There still seems to be some display issues on the header, this is how it looks like on my phone: http://oi64.tinypic.com/125miwj.jpg (and it's blinking).
Looks like a great project, but the landing page is still very scroll-sluggish for me on a 2015 MBP with Chrome.
What might all this say about Palantir's development processes in general?
This is what happens when you only test your web app in super fast internet on a maxed out MacBook using Chrome.
I'm running a core i5 @4 ghz + 16 gb of ram and it's till slughish as hell on FF.
You guys should upgrade to Chrome.
It crawls on my Chrome with i7
Just having the page open kicks my CPU to 4.6 GHz and I can hear my fan going crazy, Chromium 56. Doesn't happen in the documentation or checking the examples.
Mac, chrome and an i7 here (early 2011 though). Seems fine. A little jerkier than other sites but not particularly bad.
It would be like death itself on Firefox, consider it an upgrade
Upgrade to PC and Windows.
Well this site is at best sluggish in both Firefox and Chrome on a Xeon with a relatively beefy AMD GPU.
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.
For what it's worth... it ran fairly fast with no hiccups on a Pixel phone. I never really looked into the specs for the phone so... good job Google for matching the performance of web browsing on a MacBook Pro.
2016 and igpu performance is still bad compared to dedicated. With browser rendering supporting GPU accel these days, I'd still never spend money on a computer without dedicated graphics, even for productivity.
Doesn't give me confidence that they've done much cross-browser testing...
Thanks for pointing this out foo303! We're aware of this and tracking it: https://github.com/palantir/blueprint/issues/108
Yeah Safari on iOS 10 has a hard time with it. The documentation page doesn't display correctly.
Same here, almost hung Firefox on my ultrabook.
I used to think that games ate the forefront at the GUI, and mainstream will emulate their approaches.
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.
I opened the page and noticed my brand-new laptops fans started screaming. Open Top -> FF is at 106% of CPU. Wth?
Works fine on my laptop in chrome on Linux. Perhaps it's using something that's less optimized in Firefox?
Just to add another anecdotal experience:
Performance is 100% acceptable and fluid on an iPhone 7 in Safari.
No performance issues here with Chrome and a Macbook Air 2012 (i5 & 4GB RAM).
This is why I use Dart. When you work at small software house doing plenty of LOB apps, you don't waste customer paid time on manual tree shaking.
Mobile safari works for me on an iPhone 7. Maybe it's a Firefox-specific issue they didn't test for?
I'm seeing the same issue in Safari on iPhone 6s running iOS 10.
It's almost unusable on Firefox, rather slow on Edge but fast on Chrome for me.
I had the same issue as OP on mobile Chrome.
No issues on Windows 10 Build 10240 with either Chrome Version 54.0.2840.71 m (64-bit) or Firefox 49.0.2.
Yeah.. docs are also weirdly truncated on chrome/android.
The documentation page does render legibly on mobile. It looks nice but that doesn't bode well for the library...
Question for Palantir devs: is this currently being used in production?
I'm a designer at Palantir (also write some code), and yes, it's used pretty much everywhere.
Could you please show us a few screenshots? Thanks!
You can see some designs here https://dribbble.com/palantir
ReactJS enlightened web developers with Component based functional/thinking/development model, which brought some order in front-end UI development. And it has been one of the best things with community behind it.
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
React wasn't the first. :)
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.
This looks really nice and well set up. I love the fact that you chose typescript and bundle a good definitions file. I totally understand homepage performance was not on the agenda yet, and its really no big deal to me, but I have to agree with others on the mobile support: this sadly crosses blueprint of my list for 99% of my work, if not all. Will be coming back to see where to project is going though!
Coincidentally I was watching "ReactNL 2016 Max Stoiber - Styling React.JS applications" https://www.youtube.com/watch?v=19gqsBc_Cx0
Styling in React needs some sort of consistent way forward.
Maybe I need to take a few layers of tinfoil off the old hat, and I suspect it's just good old fashioned open source generosity, but..
Given that it's from Palantir, is there any way this could become a security attack vector at scale?
Fortunately, it's open source, fully open to code review!
A little bit slow on my mobile
A little bit slow on my laptop, nevermind mobile. Not good signs.
Wanted to say this as well. Definitely a deal breaker.
Not too far off the average SPA experience.
That makes me sad
Fairly certain that this is due to the animation on the marketing page and not the components themselves.
Same here on mobile, completely unusable. I wonder if the logo (unnecessary) animation is the culprit.
More than a little for my LG G3
It seems you may have to include the css for the whole library on every page[0]. I would have much preferred it if the css for each component is included on your page as you require the component.
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/
Impressive.
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?
This look exceptional ! It's full featured (datepicker, tree) and professional looking. It's also seems to by typescripted. But the slider needs work on touchscreen.
What I like the most is that the UI is just really nice and clean
There is also http://react.semantic-ui.com/ which I have found to be very useful.
Those themes are gorgeous, where I can find those theme?
The design looks amazing. I love how easy it is for "programmer ui design" to look quite good these days.
Great work, it looks very nice! One thing I always find missing from most of these React toolkits is a TreeTable component. This is a component that I often require in business applications, and I suspect other will too. Is this something that you would consider adding in the future?
I wonder why all the UI toolkits always come without some form of layout support.
What is Qt without a GridLayout?
I see your point. Having the mobile layout Grid thing is quite handy. There is another toolkit for React I've been using for an admin backend that has proven useful, not quite as polished but has more of a complete toolkit for what I need. npm rebass, relfexbox, react-geomicons was on Hacker News as well -> http://jxnblk.com/rebass/
Because flexbox has been around long enough and allows you to hit 97.12% of the market with prefixes and 85.11% unprefixed.
What are you talking about?
- 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.
That's nice but their idea of grid is to hand you a bunch of fixed-sizes CSS you can slap on elements. That has very little to do with the actual layouting a UI toolkit like Qt provides for.
I don't know anything about Qt but if it's so good, why hasn't someone made something equivalent for web that just generates the underlying HTML/CSS?
I don't think you understand what is a grid layout as defined in QT,GTK+,WPF ... we're not talking about CSS grids with CSS box model.
This is very well done. If they provided a React Native one as well, that would be even cooler.
Docs are utterly broken on mobile.
Everything looked good until the grid/table. Those are vastly underpowered/featured versus other solutions (kendoui, devexpress, etc) we are currently using/have evaluated.
Cool/interactive logo on the web page -- how is that done ?
Canvas.
My RT-AC68U router flagged this website as having malware. Seems more related to email than the website though.
Description: Sites whose addresses have been found in spam messages.
For some reason this page is really slow on Firefox.
Site is super slow and jaggy on a macbook pro..
No demo's
I was about to give up, but I found in documentation, one of the last link on the side bar, is Components, there you can see a demo of good list of components. http://blueprintjs.com/docs/#components
Since you guys are taking a lot of insults here I want to try and offer you something constructive.
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.
Not all things are supposed to be mobile. All the products we write are supposed to run on a large display for our case.
I still can't imagine tying yourself to a system that precludes mobile. That seems like a terribly bad idea at this point.
For certain applications, you're right that's an awful idea.
For others, it's an equally bad idea to limit your toolbox based on an irrelevant criterion.
I question how truly limiting that is. I mean, if you have a framework or library that has the restriction that it won't work well on mobile -- unless there is a really good reason for that restriction -- it seems to me that that framework/library probably isn't ready for prime time and will either gain mobile support, or will soon disappear.
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.
Respectfully, you are wrong on these points.
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".
why did you publish this on Saturday??? now i have no excuse to try to replace react-material...
This is really slick and fresh looking. Almost inspires me to build something with it
You should go for it! It actually feels good to use, which is one of those rarer qualities to come across in these sorts of libraries.
Disclaimer: I'm a designer at Palantir and have been using it for quite a while.
very neat, i am definitely going to be trying this out on a new side project
Not loading on safari ios 9
The text is garbled (on top of eachother) on safari ios.
Trying to load that site is slowing down my browser.
Is it possible to use this without React/NPM?
Smooth as butter in safari on my iPhone se.
Very impressive! Keep up the good work.
Thanks for this I see a great value on this, you got my github star.
This is amazing!
This looks amazingly good and well thought through.
Renders and scrolls slow
I saw no favicon and closed this thing immediately.
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...
> I saw no favicon and closed this thing immediately. Seriously guys, it's 2016 and you still don't have a favicon.
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.
I mean, it's obviously satire, and it's taking a shot at something you've previously said is damaging to HN.
https://news.ycombinator.com/item?id=9238739
I'd agree that pokebowl's comment is a suboptimal way of getting that point across.
> obviously
Oops. I completely missed that.
This is what comes of moderating in haste.
Safe to say it sux.
Please don't post uncivil, unsubstantive comments to Hacker News. We ban accounts that do this repeatedly.
Cool stuff
TBH, I expected more from what's supposed to be a Palantir project. I mean come on, why is the site not mobile-first?
99% of our use cases are desktop-only – we build analytical tools. Our focus is on making those experiences great.