Refute against forge discord's forgevsfabric trick

Debate

Minecraft Forge and FabricMC both have similar infrastructures: mod loaders, mod api, gradle build tools, deobuscation tools.

Mod loader: supposed to just load mods in Minecraft and deobfuscate the game.
Mod API: Offer events, loaders, hooks (e.g. model loading systems, config systems, standard energy API)
Gradle build tool: The gradle plugin that is used to build mods
Deobfuscation tool: Converts obfuscated Minecraft to deobfuscated ones so that modders can understand what they are modding

Minecraft Forge:
 - Mod loader: Forge (more exactly, fmllauncher source set since 1.13, previously FML)
 - Mod API: Forge (previously Forge and part of FML)
 - Gradle build tool: ForgeGradle
 - Deobfuscation tool: Provided by ModCoderPack
FabricMC:
 - Mod loader: Fabric loader
 - Mod API: Fabric API (has multiple modules)
 - Gradle build tool: Fabric-loom
 - Deobfuscation tool: intermediary, yarn, etc., provided by FabricMC itself

Fabric was started up as an experiment project, but as it gains exposure not only among usual modders and modded Minecraft players but also among technical Minecraft users and vanilla code investigators, asiekierka has assumed a responsibility to carry on just like Forge does. Forge supporters believe fabric managed to get a foothold in the community because Forge took the opportunity to rewrite everything during the 1.13 development cycle; however, the project existed meantime at 1.13, Rift, failed to gain as much exposure or popularity, so the missing of Forge is not the essential reason. Meanwhile, many fabric participants cite the dictatorship of Lexmanos over the decision-making in Forge (e.g. addition of energy API without any discussion) as a reason for moving to Fabric. The role of asiekierka and modmuss50 as Internet celebrities may have contributed to Fabric's fast expansion after its initial announcement on FTB subreddit.

Forge creates hooks and events for mods to use, this is so that mods can exist together and be compatible. Fabric (loader) has developers create their own hooks (which you can do in Forge, however it's preferred you PR them to get it into Forge.) which, if misused, can cause issues. However, with the existence of Fabric API, such conflicts have been greatly reduced, and Fabric modpacks of 250+ mods exist (e.g. AllOfFabric). Fabric API has a similar feature-addition process via PR on GitHub.

Fabric is a lot lighter in comparison to Forge because Fabric knows to cut loader and API clean (unlike the 1.7.10 FML which includes quite a few events and hooks in addition to the basic mod-loading logic, while Forge has drastically improved with the introduction of fmllauncher source set that specifically take care of mod loading for 1.13+). Without an API, you can still create whatever you want to, it just offers less as a base (Like why people would prefer plugin APIs like Bukkit or Sponge over making Forge/fabric mods or NMS, as APIs tend to offer a sturdy base). The simple structure of Fabric's loader is partly why Fabric is able to update much quicker, as Fabric loader is always immediately ready after intermediary mappings have been updated. Keep in mind, Forge can update in less than a day as well (updating the API part), and the "months behind" argument isn't valid. Same goes for Fabric API; but frequent updates to large APIs add significant maintenance costs. Indeed, Fabric is not faster in porting compared to Forge's capabilities; however, Fabric knows which parts should be prioritized so that the most valuable results are derived from the same amount of work (e.g. Fabric API's component system allows porting more important basic APIs like core events and resource management before fancy Indigo renderer or world generation/dimension APIs, while Forge must port the whole thing wholesale before it makes a release). It is correct that compatibility issues across Minecraft versions/snapshots are a common occurence and Fabric mods need to be updated frequently. However, for some tiny utilities (e.g. hot patches like my pathsuggestion mod), as long as vanilla does not change that portion of code, modders can save a lot of efforts from updating. For a "same mod", modders can try to contribute to Fabric API to speed up its porting to new Minecraft versions so as to retain inter-mod compatibility.

Forge is relatively more closed than Fabric, given Lexmanos' role in Forge development over any other's decision and his temper (he does not allow people to ping him for stuff related to him!). Fabric, in comparison, has two leaders: asiekierka and modmuss50, both of whom are more amicable; the voice of other team members (Grondag, sfPlayer1, etc.) and outsiders (like me) can persuade the leaders as well. Fabric devs often address good points from anyone in PR reviews, while Lexmanos rarely refers people's comments in PR reviews as the decisive factor for merging a pull request.

Another point is about ModCoderPack and Fabric Yarn. ModCoderPack is indeed proprietary; though Optifine and Sponge (as well as probably tonnes of other projects) use them, they are mostly using the MCP mappings shipped in forge jars in the environments whenever possible as to avoid possible troubles; Lexmanos is, de facto, the one who decides if a project is allowed to ship ModCoderPack mappings within its distribution. Many Forge-Spigot hybrids have been threatened by Lexmanos for shipping direct mappings from Spigot to Searge names (which makes them run faster as they don't need to reflect from Spigot to mojang obfuscated and then to Searge)! MCP allows downloading data directly from website (export.mcpbot.bspk.rs), but it's unrealistic that all running instances of Minecraft will have (reliable) Internet access (e.g. in mainland China). Even this legal data is simply between Mojang obfuscated names and MCP; other users, such as Forge-Spigot hybrids, still need to use computer CPU and memory to compile the Spigot to Searge mapping, which is troublesome. Moreover, ModCoderPack has a few weaknesses over Yarn: ModCoderPack cannot change class names once they have been decided in a version while Yarn can; hence, MCP is forced to map all classes when it updates, slowing it down. Yarn is more user-friendly to update as FabricMC has maintained Enigma for updating Yarn mappings (which some MCP contributors have started using as well), and can filter out bad names with PR reviews (MCPBot submissions have no restrictions and bad names can come in easily)

After all, Fabric does not intend to replace Forge from its onset. Fabric does not worry too much about Fabric-Forge or Fabric-Spigot compatibiliy as well, as there are more important jobs for Fabric (e.g. more APIs, better build tool, improving Enigma).

This is a refutation of the gist offered by JojoModding in the forgevsfabric trick from Forge discord guild. Written by liach, who does not represent FabricMC.

Jojomodding's explanation

They're both mod loaders but very different.

Fabric was created mostly as an experiment/personal project, it managed to get a foothold in the community because Forge took the opportunity to rewrite everything during the 1.13 development cycle.

Forge creates hooks and events for mods to use, this is so that mods can exist together and be compatible, Fabric has developers create their own hooks (which you can do in Forge, however it's preferred you PR them to get it into Forge.) which, if misused, can cause issues.

Fabric is a lot lighter in comparison to Forge because of this, (read: you can still create whatever you want to, it just offers less as a base). This is partly why they're able to update much quicker. (Keep in mind, Forge updates in less than a day, the "months behind" argument isn't valid) This doesn't mean it's faster or anything in particular, just that you would have to potentially write a lot more to create the same mod and possibly suffer compatibility issues.

Another thing being circulated around is that Fabric is open whereas Forge is closed, which is completely false. A common argument is "The mappings Forge uses (MCP) are proprietary and you can't use them." This isn't true, in fact Optifine and Sponge (as well as probably tonnes of other projects) use them. What you can't do, is redistribute them. As that would mean there's multiple (conflicting) versions which are incompatible.

Lastly, no it's definitely not a replacement for Forge nor do they work together, the stance of the Forge team is "We don't care.", Forge is not going to give special treatment or change what they're doing, if Fabric wants to be compatible with Forge, it's on them.

There is a lot more I could go into but that is the gist of things.
Please note: THIS IS NOT AN OFFICIAL EXPLAINATION

Hello
So, let's start..
First of all, this is actually not my explaination. Unnoen created it, and I just added it to the bot. For context, anyone can add things to the bot and it's most oftenly used to add short-to-medium length explainations for common questions users often ask (like "What about Fabric?", "Can you comment on fabric", "Can my mod work with fabric"..). Unnoen also made an effort to write said explaination without bashing one or the other.

Second, thank you for your feedback.

Edit: Also, Forge does not actually use the MCP scripts anywhere really. We have MCPConfig now, and ForgeGradle which can do all the things MCP used to do.

That being said, I am happy to change the text if you were to offer constructive criticism about what it says. I don't think it needs 'refutation', nor do I think you actually offered 'refutation', given your gist does not point out any concrete falsehoods, just a (somewhat) different perspective. As for why Fabric took off and Rift didn't, IDK.

IMHO Forge also isn't dictatorial, I haven't had any problems getting good PRs merged. Things get discussed, although mostly in the discord instead of on github. Also there is supposed to be a triage team, whose job is to look at RPs and offer feedback.

Forge also has beta versions (for example there still is no 'official' 1.14 support, it's all beta), which are usable although missing in features which are still being worked on. Nontheless they are used, there even are modpacks for it. It's just that things might break when new features require it. You may have realized that 'less important' API parts of forge are still in process of being ported (IE Fluids, which are a huge mess in 1.14).

Finally, MCP mappings are the way they are based on historic experience. Most of us consider the fact that class names (and method/field names, once set) remain static for the remainder of one Minecraft versions's live a feature, not a bug. We were also in the process of rewriting the bot to a more modern version so that mapping suggestions were to become easier and potentially peer-reviewable (that is now likely moot because Mojang's mappings). Also no one is putting insults or similar stupid stuff into our mappings, and if that would happen, there are people with admin access who can undo it.

Note that as far as I can see, the Forge team doesn't actually hold any grudges against Fabric as a project. Judging from their experience, they expect it to end up as a tool that, because it is more flexible, will support snapshots and lighter, less game-changing mods (ie a minimap, an inventory sorter, things like that). Fuethermore, from their point of view, Fabric's a prime target for these kind of mods, while we expect (as in 'I guess that will happen') feature-grade mods (ie Thermal Expansion) to be easier to write against a huge, maintained compatibility API like the one Forge provides. Most of us do however find it sad that there are some people who have formed the mindset 'Forge bad' without understanding the complicated historic reasons for why most of Forge's tools and policies work the way they work.

As for compatibility, because there are different APIs and different concepts between Forge and Fabric, a compatibility layer would be a massive undertaking, and as we can see, no one is really willing to write such a tool. Which is also OK, we expect Fabric mods by their nature as coremods to potentially break forge and most forge mods anyway.

Again, I'ld be happy to incorporate constructive criticism of my/Unnoen's trick. So far none has been offered to me/Unnoen directly. If you/someone else wants something reworded, just tell me, I'll adopt it if it's reasonable.