Besides updated Shuffle Queue and Filter By Type for XKit 7, XKit 7 now includes the News sections, which I’ll be using to post XKit 7-only news from now on, since compared to XKit 6 / Next users, there is still a very small install base there.

Also, someone asked me about the XKit 6 / 7 / Next trio, and what is going on and why. Since I think it’s an interesting question, and it’s answer kind of a long one, I’m posting it here.

What is going on here?

There are three versions of XKit right now: XKit 6, XKit 7 and XKit Next. Two of them will die out soon, guess which ones. =3

Why did you create XKit Next?

XKit 6 is built upon XKit 4, which was released around 2 ~ 2.5 years ago. I have to admit, I wasn’t good at Javascript(which XKit, and nearly every Tumblr extension is written using, btw.) back then.  

So, the architecture of XKit 6 is broken from start actually. You’ll notice that how you need to refresh the page after installing / uninstalling / changing settings of an extension. This is because XKit 6 can’t actually “control” it’s extensions because of the bad architecture.

XKit Next was an experiment to - as a huge corporation would call it - build the “next generation" of XKit. And it worked well. On survey, ~85% people who used XKit Next said it is faster and less buggier than XKit 6.

And XKit 7 is built upon XKit Next. Around ~45% of the backbone code is actually directly copied from it. XKit 7 can "control” it’s extensions, and if you’ve used it, you probably noticed that you don’t need to refresh the page every time you change an option, and changes take effect immediately. Things like these, in my opinion, makes XKit 7 really easy to use.

The architecture of XKit 7 also separates CSS, settings, storage and the script itself into different groups, which makes it really easy for me to write extensions. It also includes embedded styles and codes which makes it easy to add settings to extensions, and I bet you’ve noticed XKit 7 is much more customizable than XKit 6 ever was.

It also stores, in it’s “framework” part, a lot of code that I use all the time. In XKit 6, I had to reproduce this code for each extension. In XKit 7, I just call them from the framework part. The less time I spend on debugging and writing the same code over and over again, the more time I can spend on writing new extensions and functionality.

Why are you killing 6 and Next?

The answer is simple: I can’t support that much extensions at the same time. I have limited time as it is. Next was an experiment which was successful, it was never meant to be a replacement for XKit 6. And once 7 is released fully, there won’t be a reason to support XKit 6.

Why are you releasing so many versions?

The timeframe between versions differ, I think the version which lived most was version 5. Since 4, 5 and 6 was - backbone-wise - same, they all shared the same weaknesses. I’ve addressed, I think, most, if not all of them on XKit 7, so I’m guessing XKit 7 will live for a long, long, long time.

One of the things I can do with XKit 7, for example, can remotely patch “framework” parts of XKit, which until now, required you to manually update XKit.

What now?

After completing the migration of extensions from XKit 6 to XKit 7, I’ll be killing off XKit 6 and XKit Next. When that happens, you’ll receive a “XKit Mail” on XKit 6, and a notification on XKit Next.