For anyone else wondering, it looks like the app is powered by Backbone, D3, and Handlebars on the front-end.
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.
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 agree though, that gif is far too fast.
I'll take another look to see if there's anything that I can do with the gif creation process I have.
If anyone has suggestions for gif recorders that give you control at this level, I'd love to know about it.
It is easier to understand now, but I think you should stay on the last part a bit longer before looping it to make it clear that the animation finished.
and that kinda fucks it up when your shortcuts are:
I know you can remap in your plugin. Which is great. But this is just a small not to let you (and hopefully other plugin developers) know that this is an issue they should be aware of.
On the side note, I really feel that there should be some sort of "package file" on each sublime installation. Something like a bower.json or package.json. It'll help us to sync / move settings easily.
Moreover if it is coupled with a simple command to install all packages in that file, it'll be even better.
Found some info on github, but not much documentation, https://github.com/wbond/sublime_package_control/issues/291
If you can't secure it by downloading over SSL, couldn't you add a hash verification to the installation steps?
Having homepage & issues listed as 'github.com' for most repos isn't very helpful-- maybe show more of the URL?
Thanks for all your hard work, Package Control is a joy to use!
The reason the downloads are truncated to domain is because the URLs tend to be far too long to display in the UI. If you mouse over the domain, you'll see a title attribute with the full URL. This is the same for many elements on the site. Icons, abbreviations and numbers with suffixes all have a title attribute to describe the item in more detail.
edit: Is my tongue-in-cheek opinion really that bad? Am I, too, "very wrong"?
I just don't understand why Package Control isn't part of the standard Sublime Text 3 package by now. Do any Sublime users not use Package Control?
No doubt there are perfectly reasonable business explanations for why Sublime doesn't ship with it, but I wouldn't consider upgrading from 2 until 3 was supported.
Anecdote on why the console code is bad and good: by coincidence this afternoon I decided to try ST3, and before using it spent about an hour trying to get Package Control working via the git repo route  (Sublime was already inside a local repo, so I had to RTFM git submodule stuff to appease the git_binary error); that went... poorly. I [ab]use Git's functionality, but don't grok it's inner workings well enough to feel like I can use submodules without contaminating the super repo, and eventually gave up when I accidentally came across the page that has the new command . Bam it's working without trouble (after modifying it for the corporate proxy). Like magic it just worked, which was awesome, but silly that something so useful would have any barrier to entry at all.
TL;DR: Package Control is an essential element of the joy of Sublime Text, so it's a little mystifying why it's not just built in.
 I can't find the page at the moment. Hopefully I haven't simply hallucinated it somehow.
My guess is that he would prefer to keep them separate for support purposes. If they are bundled then users may have the expectation that Sublime HQ Pty Ltd will support it.
Don't get me wrong, I don't think there are bad intentions here or that you're not doing due diligence to warn users, I just think this type of installation method should be discouraged in general.
Unfortunately I've found the "sync everything" process that you've outlined leads to issues where users end up installing the OS X version of a package on Windows and then wonder why it doesn't work properly.
Additionally, I made pretty liberal use of the title attribute on the site. Most things that are not obvious can be hovered for more information.
ST3 is the default visible tab for the installation instructions.
Many of us have been using ST3 with package control just fine for a while. I really only use it for GoSublime, and it works perfectly on ST3.