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.