Does MAL suck because of PHP?

I do not wish for such a "modernized" UI.

It seems you talk about GUI, but UI is more than just graphics, it includes the entire interaction concept with all the inputs, their functionalities and outputs, so it has much to do with back end.

@Zarutaku Every input, their functionalities and output is entirely handled by the frontend, after the backend sends packets of data over the HTTP request. Everything you see on MAL is a product of HTML and Javascript. You could swap whatever language is used to program the API behind the endpoints at no visibility to the end user. PHP literally has nothing to do with this.

The only flaw of PHP as far as end user is concerned is that the syntax makes it easier to write anti-patterns that enable SQL injection and cross-site scripting attacks, which is how MAL had issues before where a spammer gives a fake link that stole MAL mod passwords when they clicked on them, or maliciously changed various things in the database. Yet, a competent developer should avoid these issues. So it's still not a case that PHP causes an outdated frontend.

MAL's frontend is a design choice.

There are plenty of functionalities that require server-side information and in that case PHP is already involved on MAL.
Modernizing the UI can include to implement new features and that can require server-side changes involving PHP.
They are interconnected systems, so changing one of them can also require changes in the other.

@Zarutaku I disagree. They are decoupled and of separate concerns. That's why APIs exist in the first place, to act as an interface (i.e. a "contract", if you will) for the data that is returned.

I think you're mistaking several things:

1. It can be argued that UI features require changing the API architecture, but that has nothing to do with PHP itself. PHP can do everything every other language can do, whether Javascript, Java, C++, Go, C#, Ruby, Python or whatever, with respect to building a web backend.
   
2. OP is talking about visual design elements, not database or data design. OP has not said that any specific additional information needs to be presented in a particular format.
   
3. The whole point of an API is so that it doesn't become tightly coupled such that changing one necessitates changing the other. If the API is properly designed and the endpoints correspond to the data required for user actions, then only the frontend changes to reflect user interaction.
   

Please give an example of how you think the data needs to be restructured to facilitate any UI feature that you think might be relevant. Bonus points if you can come up with a feature that PHP can't actually implement, and what language you think could.

@Zarutaku I disagree. They are decoupled and of separate concerns. That's why APIs exist in the first place, to act as an interface (i.e. a "contract", if you will) for the data that is returned.

I think you're mistaking several things:

1. It can be argued that UI features require changing the API architecture, but that has nothing to do with PHP itself. PHP can do everything every other language can do, whether Javascript, Java, C++, Go, C#, Ruby, Python or whatever, with respect to building a web backend.
   
2. OP is talking about visual design elements, not database or data design. OP has not said that any specific additional information needs to be presented in a particular format.
   
3. The whole point of an API is so that it doesn't become tightly coupled such that changing one necessitates changing the other. If the API is properly designed and the endpoints correspond to the data required for user actions, then only the frontend changes to reflect user interaction.
   

Please give an example of how you think the data needs to be restructured to facilitate any UI feature that you think might be relevant. Bonus points if you can come up with a feature that PHP can't actually implement, and what language you think could.

God, what a hilarious thread. MAL doesn't suck, and not because of php.

They just have relatively large site, heavily dependent of their tech stack and dev expertise - php it or not, doesn't matter. Major changes are always expensive/risky as hell, because it's always either breaking what works or maintaining two systems in parallel god only knows for how long.

No pragmatic manager will approve that, unless they face a threat such as more technologically advanced and feature-rich competitors taking MAL's market share bite by bite. Is it the case? If not, don't expect miracles, it will remain a bit legacy, to everyone's good, I would say.

I mean it's always a matter of priorities and budget, not technology behind that. I wish they have spent a few bucks on adding more features to mobile version and tuned up mobile styles, but they, apparently, don't have resources/motivation even for such a small thing. That's a bit upsetting.

@LoveYourSmile ANILIST ACCELERATIONISM! But yeah that's a reasonable take I guess

God, what a hilarious thread. MAL doesn't suck, and not because of php.

They just have relatively large site, heavily dependent of their tech stack and dev expertise - php it or not, doesn't matter. Major changes are always expensive/risky as hell, because it's always either breaking what works or maintaining two systems in parallel god only knows for how long.

No pragmatic manager will approve that, unless they face a threat such as more technologically advanced and feature-rich competitors taking MAL's market share bite by bite. Is it the case? If not, don't expect miracles, it will remain a bit legacy, to everyone's good, I would say.

I mean it's always a matter of priorities and budget, not technology behind that. I wish they have spent a few bucks on adding more features to mobile version and tuned up mobile styles, but they, apparently, don't have resources/motivation even for such a small thing. That's a bit upsetting.

God, what a hilarious thread. MAL doesn't suck, and not because of php.

They just have relatively large site, heavily dependent of their tech stack and dev expertise - php it or not, doesn't matter. Major changes are always expensive/risky as hell, because it's always either breaking what works or maintaining two systems in parallel god only knows for how long.

No pragmatic manager will approve that, unless they face a threat such as more technologically advanced and feature-rich competitors taking MAL's market share bite by bite. Is it the case? If not, don't expect miracles, it will remain a bit legacy, to everyone's good, I would say.

I mean it's always a matter of priorities and budget, not technology behind that. I wish they have spent a few bucks on adding more features to mobile version and tuned up mobile styles, but they, apparently, don't have resources/motivation even for such a small thing. That's a bit upsetting.

@LoveYourSmile
Two systems is retarded as to why the hell they mutilated the forum for a secondary view just because one noob who never used the site and left asked for it to be Reddit lol and i still dont get why they made a mobile site and an app both usually sites do one or the other.

@traed Two systems is a necessity for migration because unlike your home-made site, they can't just update everything and have everyone switch to the new site without expecting any problems to occur. For a site this massive any changes must be carefully planned.

As a very basic example, suppose it takes 24 hours for CDN caches to expire so site changes only get propagated after some time. You, the user, enter "myanimelist.net" in the browser, which likely redirects you to the nearest CDN. MAL makes changes and makes one sweeping upload, but you still see the old version of the site because the CDN hasn't propagated. Now what happens when you do something that writes to the database? It might attempt to write to the new database using the old schema, which might cause an error. Or, it could mess up the database or even become a serious security vulnerability.

@traed Two systems is a necessity for migration because unlike your home-made site, they can't just update everything and have everyone switch to the new site without expecting any problems to occur. For a site this massive any changes must be carefully planned.

As a very basic example, suppose it takes 24 hours for CDN caches to expire so site changes only get propagated after some time. You, the user, enter "myanimelist.net" in the browser, which likely redirects you to the nearest CDN. MAL makes changes and makes one sweeping upload, but you still see the old version of the site because the CDN hasn't propagated. Now what happens when you do something that writes to the database? It might attempt to write to the new database using the old schema, which might cause an error. Or, it could mess up the database or even become a serious security vulnerability.

@LoveYourSmile
Two systems is retarded as to why the hell they mutilated the forum for a secondary view just because one noob who never used the site and left asked for it to be Reddit lol and i still dont get why they made a mobile site and an app both usually sites do one or the other.