Most search engines assume the user knows what they are looking for, but for many research tasks this isn’t true. Having easy access to facets in a search UI helps address this problem, and sometimes the numbers are actually more interesting than the search results. For my SSL search engine, the facets are various attributes of X.509 (i.e. https) certificates, so you can use the facet counts to determine what the deployment footprint of a security feature is, where people buy their certificates, who has a site subject to a class of vulnerability, etc.
I’ve chosen to default to returning all records when it first loads. I think this helps you to see what type of data you’re going to get, and for a tool you haven’t seen it’s psychologically more difficult to deal with a blank slate than a poor result. With a poor result, you can say “no, that’s not quite it, but if I change this…”
When I built this, I investigated using React Router, is supposed to help you make specific pages URL addressable, e.g. you should be able to link to a page with specific facets in it. The problem with putting facet values in a URL is the URL length, and I haven’t solved this to my satisfaction yet. One option might be to assign numeric identifiers to the facet values, and use the IDs in the URL, so it would remain quite short.
I’ve also tried to make the UI for this load quickly, and avoid the bloat that many websites seem to now have. While I was working on this, React 15 was released, and upgrading removed all the span tags React generated and halved the size of all the pages. I also use the three popular React-isms for performance: PureRenderMixin, the PRODUCTION flag, and the webpack minification. The minification in Webpack is to removed dead code and leads to a relatively small download payload. In the future I’m going to change how I do library imports because if you use ES6 imports it should only include the parts of a Javascript library you actually use1.
I also initialize all images with their size in CSS so there is no flicker when they download. This is also required to support Accelerated Mobile Pages2.
Currently the initial page load downloads 321k, but 1/3 of this is because React needs to load all of it’s data after it loads, to sync state. I set up server side rendering but React can’t bind its events to page elements on the server side, so it needs to download the data after the page loads and do a setState. This seems like a dumb design but I found that dumping the JSON payload into the page was even worse. It is large enough that the parsing time kills any benefit you’d get from server side rendering. I think the ideal solution is build an object containing all the page events and manually re-bind them on the initial page load, which would avoid the first setState call.
A binary format for data transfer may also help, e.g. Transit3 or Protocol Buffers4.
One the build tool side, I started this project wanting to determine whether Browserify or Webpack was the better for new projects. The two seem similar but the React team is pushing Webpack, so if you’re using React Webpack gets new features more quickly. The most compelling novel development feature is Hot Loading, which makes your pages load as you change code (bonus points for having your IDE save when it loses focus). There are interesting unit testing developments to watch in this space – with the right tool orchestration, you could get a UI automatically set up in a variety of user states5.