>>93415Wrong. If only you knew, you'd know tinyboard has a horrible design. They tried to take something with poor foundations and extend and scale that into becoming the reddit of imageboards (infinitechan fork).
Why is Tinyboard bad?
• The SQL schema is insanely schizophrenic and practically unfixable because of the drugs Michael was on.
Imagine you have a table that represents the data of each reply to a post, with the following fields:
post_id (integer)
name (string)
subject (string)
sage (boolean)
body (string)
Ok, good start, but it's missing some things, such as number of files, paths to files, flag and so on.
What would you do to fix that?
You can either:
A) add more fields, which has the minor drawback of mandatorily using a dozen extra bytes of space per record because these are all optional fields ("nullable").
B) create separate tables containing those other fields that point to the post_id's in the other table, which has the minor drawback of a performance penalty (generally IO-bound) of doing SQL JOINs.
Almost always option B is considered better practice as it reduces "redundant data", and it still ends up less costly to perform SQL JOINs that exclude irrelevant rows during the query execution, thus retrieving a more focused dataset, instead of doing option A where you would handle NULL checks in PHP by fetching one large table with all the possible data in a single query, then filtering rows in PHP based on whether certain fields are NULL. But honestly, option A isn't really that bad, it's workable and not that much slower even if a bit amateurish by showing lack of experience in database design, and you could always redesign this later to go to option B with an "upgrade patch" for the next major release of Tinyboard/Vichan to transfer the table fields into the new separate tables for the new SQL schema.
So what did Michael decide to do?
He chose: option C) cram a shitload of these fields into a JSON blob, because why not, and cram it all into a string field called "files" for each record (thus being forced you to write several parser functions in PHP to check for and copy each field), as well as some deranged choices like cramming "flag" information at the end of the "body" field (???) that would be later parsed by PHP.
I shit you not, if you query the "body" of a post that contains a flag, you don't just get:
ur a faggit
Instead you get:
ur a faggit
<tinyboard flag>character-anime-frieren-ubel</tinyboard>
<tinyboard flag alt>Character - Anime - Frieren - Übel</tinyboard>
Michael's one-of-a-kind database design already adds significant IO and CPU latency for every single post in a thread that is being constructed by PHP and written to an HTML file, for no reason other than Michael's shroom-induced decisions.
• It unnecessarily uses a PHP template engine called "Twig", adding a complex wall of abstraction between PHP and HTML and making debugging infinitely harder
Everyone hates Twig, you can find countless complaints in vichan's github issues tracker complaining about Twig, I think Fredrick also said it was horrible but it was so entrenched in the design of Tinyboard that it's too late to realistically rip it out of vichan/infinitechan. The two main problems with Twig are that it does a lot of things behind your back because of its complexity and that it's extremely difficult to debug it whenever anything goes wrong. You don't need a template engine, PHP by itself is good enough (and much better).
• It has a shroom-induced design of a custom URL "router" (especially in the mod panel) that no one can understand, even Fred and czaks don't fully understand how it works, that even a 10-year-old could design a better URL router, making extensibility and debugging infinitely harder, seriously, you can find beginner's tutorials of writing your own PHP router that are a million times easier to understand and work better than this craziness that Michael designed
I could go on, but I need to get going now, I haven't even gotten to how bad the caching mechanism is (whose horribleness compounded by the even more horrible SQL schema design), how terrible the design of "mod.php" is and how disjointed it is from the rest of the software, and so on.
Also you didn't mention how Josh's "infinity-next" was actually worse than "infinitechan" (8ch.net fork of Tinyboard/vichan) and could only handle a fraction of the requests per second that infinitechan could handle, which is why it was scrapped in the first place and how Josh was hated for a while for "gypping" the donations to write the failed software that was meant to replace infinitechan. It was entirely predictable with his choice of using Laravel as a framework but that's not the only reason of its slowness, he made countless design flaws that didn't address the flaws of Tinyboard/vichan/infinitechan. Or how you didn't mention that apparently Josh caused the slowdown of infinitechan in the first place according to Ron because of a performance-destroying captcha implementation (though I honestly don't blame Josh for this because it's near impossible to debug, log and profile Tinyboard/vichan/infinitechan because of Michael's design decisions mentioned about, it's a tower built on sand that is near impossible to inspect for issues, it's not surprising this performance issue by this small piece of code was undetected for years).
