Thanks! I enjoyed playing around with a bunch of front end stuff on the site. I wanted to have a very fluid experience, so in addition to using Backbone with pushState and doing partial page renders, I felt the need to provide some sort of loading indicator. It uses CSS transitions combined with AJAX ready states to animate the loading, and the visuals were modeled after the Chrome loading bar from Android.
I've also got some other subtle touches like when you go from one of the main site pages to a page about a package, I fade out the Package Control logo so it does not compete with the package name.
I'll be posting the website up on GitHub in the next day or two. On the server side it is Bottle.py running on Python 3.3 and using pybars for templating. I used coffeescript with Backbone, D3 and Handlebars as you mentioned, although I did not use the model or collections parts of Backbone. I constructed the beginning of a lightweight framework that feel somewhat declarative in the frontend router so that adding new pages doesn't require any real setup. You write the model code in python to pull data out of the database, then write a handlebars template to display it and then throw in some JS to add interactive elements client-side.
Since I use pybars on the server side and handlebars on the client, I can pre-render the initial page view and then let the client render further screens using just one set of templates. The only downside of using pybars and handlebars is duplicating the helpers.
The other part of the site I am pretty happy with is the search. I use postgres as the database, so I started with the full text searching, but then added some custom functions and triggers to nicely split and weight different parts of the package info. One implementation detail that I think ended up working out decently was weighting results with shorter names higher. This was based on the idea that shorter names mean a larger percentage of the name is a match to the search terms.
The pre-rendering I am referring to is the contrast between server and client side page rendering. On my site with the first page load the server sends you a full HTML page so you don't have to wait for the JS to load, then the JSON to be fetched and then the HTML to render.
However, on all further navigation (if you are using anything but IE9 or less) I just request the JSON data from the server and I use handlebars via JS to render each page.
I've also got some other subtle touches like when you go from one of the main site pages to a page about a package, I fade out the Package Control logo so it does not compete with the package name.
I'll be posting the website up on GitHub in the next day or two. On the server side it is Bottle.py running on Python 3.3 and using pybars for templating. I used coffeescript with Backbone, D3 and Handlebars as you mentioned, although I did not use the model or collections parts of Backbone. I constructed the beginning of a lightweight framework that feel somewhat declarative in the frontend router so that adding new pages doesn't require any real setup. You write the model code in python to pull data out of the database, then write a handlebars template to display it and then throw in some JS to add interactive elements client-side.
Since I use pybars on the server side and handlebars on the client, I can pre-render the initial page view and then let the client render further screens using just one set of templates. The only downside of using pybars and handlebars is duplicating the helpers.
The other part of the site I am pretty happy with is the search. I use postgres as the database, so I started with the full text searching, but then added some custom functions and triggers to nicely split and weight different parts of the package info. One implementation detail that I think ended up working out decently was weighting results with shorter names higher. This was based on the idea that shorter names mean a larger percentage of the name is a match to the search terms.