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.
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.
> 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]
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.
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 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.
