№5739[Quote]
>>5738 (OP)This website uses php just fine
№5756[Quote]
>>5738 (OP)php is fine. just don't use insanely outdated versions of raisin and you'll be okey
№5764[Quote]
>>5738 (OP)Backend in typescript go or rust would be better overall but php is fine if you're not a retard about it
№6173[Quote]
>>5738 (OP)4chan was one written in 2006 style.
№7811[Quote]
>>5738 (OP)no it all comes down to unreadable jeet code which is possible in any programming language but most common in PHP because it's so jeeted
moral of the story: yeet the jeet
№7813[Quote]
>>5738 (OP)> i just find it comfymost projects will never scale either way so PHP + vanilla JS will always be peak comfy
on a side note: the stack should always be chosen based on requirements and not on popularity.
because if you have proficiency in one programming language and it's concepts you can learn any other programming language or framework in a matter of weeks.
>t. TRVKE №7814[Quote]
>>5738 (OP)>now i'm kinda worriedWhat do you think?
their issue wasn't PHP but unintentionally allowing PDF/ghostscript upload.
№7816[Quote]
No. Back when Facebook was PHP/Hack it was snappy and highly extensible (remember their game platform?). Now that it's React it's a hideously slow mess.
№9210[Quote]
>>>5738 (OP)
>no it all comes down to unreadable jeet code which is possible in any programming language
not in fp languages tho
№9214[Quote]
>>5738 (OP)if you care about security, and actually do try your best to improve it, it is not that bad. Problem with 10 yars old anything facing the public is that some publicly known security vulnerabilities will emerge.
№9247[Quote]
>>5738 (OP)That xitter guy who made all the remote working websites just uses php too, if you're doing basic raisin it just werks.
№9255[Quote]
Modern PHP (that is, PHP 8) is a fast, safe, decent language. But PHP has been around for decades, early versions of PHP were awful from a security perspective, and most existing PHP code is written using these legacy versions.
There's no reason to avoid using PHP in modern projects, though you will be mocked by other programmers who are just parroting a "PHP is unsafe" meme without understanding it.
№9292[Quote]
>>9255The PHP hate is just a redditism, a sound-bite for midwits to parrot to "fit in" within the community.
It's actually been fine for a lot longer than PHP 8, it's more the case that it just didn't have as many guard rails for slop code that could create potential vulnerabilities. Not PHP fault as much as bad devs.
Note they never say the same raisin about the C language because that's too spoopy and esoteric for them and don't want to look stupid, despite it being the "cause" for every security issue in the past 50 years, including those in PHP.
№9428[Quote]
can someone explain what the point of php is? why is it the defacto backend language when other languages exist?
№9505[Quote]
why would someone willingly learn this garbage language?
№9515[Quote]
>>9292Early versions of PHP really did have some weird and unsafe defaults. Like the fact that it allowed you to include remote PHP files by default. Is there a single legitimate use case for a site running a PHP script from another site? It is a feature that was practically designed to allow for remote code execution vulnerabilities.
The fact that it didn't use to have type checking was also a big hassle because you have to explicitly cast your variables if doing something like an SQL query (and back then there were no prepared statements).
№9581[Quote]
>>5738 (OP)Depends on what you're doing it's perfectly fine, despite nu-webdev trannies seething about it for no reason other than cargo-cult faggotry.
Just try to do things right and avoid jeeting it up.
№9641[Quote]
>>5764>typescriptkill yourself
№9642[Quote]
>>7816facebook is still php
№9869[Quote]
>>5738 (OP)when I was in CS school, I remember developing a website with php. first I went for plain, then I tried to write my own MVC and ORM, then I ditched the later for doctrine, then rewrote everything in java/spring …
№9873[Quote]
>>5738 (OP)In one screenshot alone I saw it grabbing salts from a directory under /www (both insecure and unnecessary) and interpolating variables into SQL query strings instead of using binds as well as using a heavily deprecated MySQL driver. The version of PHP wasn't doing it any favors but the coder was brain damaged (these practices were out of date well before the 2015 handover).
№9881[Quote]
>>9869>MVC Some of us use centralized auth systems where permissions are dependent on actual directories not faked paths. MVC lives in a world where applications handle their own auth which is a rude shock when you get a job developing apps in an org that rightly won't let you do this.
Reinvent no wheel and let no programming pattern dictate your app's structure.
№9884[Quote]
>>9881>???MVC pattern doesn't enforce any auth mechanism… you can make your own auth system, use oauth/jwt or sso
№9970[Quote]
>>9869>>9884Also I'm trans btw, and yes that really changed my perspective on how I ended up approaching this whole thing.
№10005[Quote]
It really depends on what kind of webapp you're building. I've found that language decision usually comes down to which 3rd-party packages are available. If I'm writing an app which connects to other apps via oath2, for example, oftentimes the other app's developers will publish oath2 clients in JS/TS, and so if I use that same language, it saves me significant development time. If I'm writing a data analysis app for a statistician, I will most likely use Python because of the availability of NumPy/SciPy.
For some hobby or toy website, it really doesn't matter. PHP is totally fine and can even do all that async/await raisin that JS/TS can do, although the syntax is not as nice.
№11890[Quote]
>>10005>For some hobby or toy website, it really doesn't matter. PHP is totally finethis. for internally (company) faced sites/tools which are allowed to break from time to time and where input checks aren't relevant because everything is logged either way and you know everyone's identities speed of development is paramount where PHP shines
№11900[Quote]
>>5738 (OP)PHP is just fine, of course you can write unsafe code in it if you are retarded.
4chan got fucked because it used some outdated image thumbnail library that had an mistake in it causing an exploit, not because of PHP.
Safety in PHP and in fact any coding is sanitizing inputs.
Sanitize all inputs and you will be fine, always.
№11902[Quote]
>>9515>Like the fact that it allowed you to include remote PHP files by default.Again, not a problem if you sanitize all inputs, as you always should. It really is that fucking simple to stop ALL exploits. Sanitize inputs.
Just because a language has extra training wheels so retarded jeets and disabled troons cant make stupid mistakes doesn't make it better.
Safety scissors are safer than metal scissors, yes, but I'm an adult and not a retarded jeet nor a disabled troon.
№11905[Quote]
>>9642Facebook is React and GraphQL, do you know what's the backend?
№11912[Quote]
>>5738 (OP)just like any language, you can write good code, or you can write bad code
№12069[Quote]
There’s nothing wrong with PHP. 4chans obvious deficiency was opsec and inflexible deployments which caused them to enter a state of “fuck it” when it came to maintaining their raisin.
I don’t care much what front or back end are written in, I just don’t want to be creating my own lower level constructs. I want to implement business logic and get immediate feedback. So I use Elixir, which amazingly is pretty troon-free. I want to like Gleam but it is about as troonish as a language can get