NicheLoot

A fair question. The majority of my addons are not original concepts, because most of the truly novel ideas were already proposed and implemented before the game's first year anniversary, but they are all original code. I write them because I want to add functionality to, or increase the efficiency of, the initial concept. The latter is something of a fascination for me, as I like to see just how efficiently something can be written while still keeping adequate maintainability and expandability.

In the particular case of NicheLoot, the differences can be summarized as follows:

NicheLoot prevents the LootFrame from going offscreen by simply calling LootFrame:SetClampedToScreen(true), which allows the UI engine itself to manage the frame position. QuickLoot does not keep the frame from going offscreen at all, and FruityLoots manages the frame's position itself, which is arguably less efficient than allowing the UI engine to handle it.

NicheLoot keeps the LootFrame visible above all other frames by setting its strata to "DIALOG", which is the highest strata layer in the UI at runtime. QuickLoot does not do this at all. FruityLoots uses the same method as NicheLoot and is equal in that regard.

NicheLoot allows the LootFrame to be dragged around the screen. QuickLoot does not allow this. FruityLoots does, but it does not tell the UI to refrain from remembering the LootFrame's position once dragging stops, as NicheLoot does. This means that once you log out, the UI writes the LootFrame's position to your configuration files, and has to read those values back in when you next log in. None of that is necessary, because the LootFrame is always moved to the location directly under the cursor when it is first shown. Also, if you decided to disable the addon, your LootFrame could become stuck wherever its location was last saved.

NicheLoot performs all of its actions without hooking any functions from the LootFrame.lua file. (Hooking functions is rather expensive, programmatically.) QuickLoot hooks two functions, LootFrame_OnEvent and LootFrame_Update. FruityLoots does not hook any functions, instead using Ace2 to perform the necessary actions. This is more efficient than my method, but only if the user is using at least one other addon which depends on Ace2. You would need a lot of Ace2-compatible addons to make the overall memory cost of the library itself worthwhile, but when considering only this limited section of code, it is more efficient. This is because a single function (the Ace2 event dispatch function) can be used to perform actions for multiple addons, where they would normally each need their own function.

Those are all of the differences. A similar list (in most cases much longer) could be conjured for all of my other addons, but the contents are primarily technical details which users don't care about, which is why I leave such comparisons out of the public documentation. In the code itself, some of it is documented with comments here and there, usually to remind me why I wrote something the way I did.

In the end, I'm not looking to "out-do" anyone. I write addons the way I do because that is my personality: I am always looking to improve or expand a current idea, simply because it can be done, not because there is anything wrong with existing concepts.