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.

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

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.

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.