IMO you cannot even compare PHP and the ecosystem what it was a couple years ago to what it is now. It has come a long way.
I still love PHP and JavaScript
161–170 of 402 posts
Re: I still love PHP and JavaScript
#162Earlier quoted context omitted.
> - no "unknown unknowns". it's so tried-and-true, there's no surprises This part is laughable. People who have been programming PHP for 20 years (several of them at my company) still routinely discover hidden bugs, quirks or general behavior that is totally unintuitive and nowhere found in the documentation.
I’ve been using PHP since 2003 and it’s my full time job and this doesn’t ring true. Very, very rarely is a gotcha not in the docs comment section.
That’s just it. I have to code with the PHP docs open like some kind of arcane recipe book.
Re: I still love PHP and JavaScript
#163Earlier quoted context omitted.
>Typescript only aids this point Though, being optional, it creates its own problems that are time consuming. I have spent a fair amount of time trying to find the right versions of npm dependencies and accompanying @type/whatever packages that work together and aren't saddled with open vulnerabilities, etc.
An @type package is dev time only and contains only exploit free definition files.
That's not what I meant. What I meant was finding a matching/working pair of xyz and @type/xyz that were new enough not to have either vulnerabilities (in the main package) and also worked with other packages that were new enough also. It introduces new dependencies and into an already chaotic chain.
Like 1.2.3 of xyz has issues (or dependencies with issues), and you need 1.2.4, but the @type package won't yet work with 1.2.4.
Also, not just vulnerabilities. Bugs, whatever.
Re: I still love PHP and JavaScript
#164PHP has so many hidden benefits: - it's stateless by design (much easier to scale) - it was "serverless" before Serverless - surprisingly performant - no "unknown unknowns". it's so tried-and-true, there's no surprises - deployment is so simple, just drop a file on a web server. No middleware needed. - No long compile times because there is no compiling needed. EDIT: why the downvotes? If you don't agree, just reply…
I won't downvote you, I think it's kinda crappy when people just do that without explaining. Also an opinion isn't something we shouldn't downvote, we should downvote poor responses.
In any case, I definitely agree with all those pros. What I dislike about PHP is that as you start growing a codebase, especially with includes, your attack surface just grows and grows and grows. In other frameworks where a stack is involved attack surface generally grows as well, but since any PHP script has access to the request, it's much much worse.
Re: I still love PHP and JavaScript
#165PHP has so many hidden benefits: - it's stateless by design (much easier to scale) - it was "serverless" before Serverless - surprisingly performant - no "unknown unknowns". it's so tried-and-true, there's no surprises - deployment is so simple, just drop a file on a web server. No middleware needed. - No long compile times because there is no compiling needed. EDIT: why the downvotes? If you don't agree, just reply…
I’ve always wondered why the more respectable dynamic languages, like Ruby and Python, don’t have a web framework with the PHP deployment model of “just upload this file to the server and refresh your browser to see changes.”
They do. It's just that everyone seems to have collectively decided that cgi shouldn't be used anymore.
Re: I still love PHP and JavaScript
#166Earlier quoted context omitted.
> it's stateless by design (much easier to scale) I noticed being stateless made it difficult to scale for any complex app. It’s been 7-10 years since I used it but Drupal used 60-128MB+ plus per request. As it was stateless it had to do a full bootstrap for every request coming in, set up a new database connection, module discovery etc, all which was heavy to do for every request. Most people scaled Drupal by puttin…
> I noticed being stateless made it difficult to scale for any complex app. It’s been 7-10 years since I used it but Drupal used 60-128MB+ plus per request. As it was stateless it had to do a full bootstrap for every request coming in, set up a new database connection, module discovery etc, all which was heavy to do for every request. It doesn't make scaling hard, it makes scaling very easy because you can just horiz…
Ok, it makes scaling technically easy with horizontal scaling for the web tier, ignoring the DB.
In practice it makes scaling hard for financial reasons if you require 128MB+ per request. A 32GB server will struggle with more than 256 concurrent requests at 128MB+ per request. A 32GB server is an extremely large server for such low request numbers.
If you can bring the memory usage down stateless works well. I use a bit of rust on aws lambda with the lowest memory settings so pay fractions of a cent and can handle more traffic than I ever need. I do set up persistent connection pools for the life of the lambda and only bootstrap once to bring down latency per-request but treat it as an ephemeral horizontal scaled service.
Re: I still love PHP and JavaScript
#167Earlier quoted context omitted.
That's an issue of design. You can't really blame the language for bad programming practices
You absolutely can and should. The language is responsible for the programming practices it promotes.
This is just so far from the truth. I can just as easily push tons of logic down into templates in erb/jsp/jinja etc... at some point it boils down to the programmer's level of expertise, but also to the programmers' opinions as there are still a lot of varying opinions on what exactly are best practices.
Re: I still love PHP and JavaScript
#168Earlier quoted context omitted.
> I noticed being stateless made it difficult to scale for any complex app. It’s been 7-10 years since I used it but Drupal used 60-128MB+ plus per request. As it was stateless it had to do a full bootstrap for every request coming in, set up a new database connection, module discovery etc, all which was heavy to do for every request. It doesn't make scaling hard, it makes scaling very easy because you can just horiz…
Ok, it makes scaling technically easy with horizontal scaling for the web tier, ignoring the DB. In practice it makes scaling hard for financial reasons if you require 128MB+ per request. A 32GB server will struggle with more than 256 concurrent requests at 128MB+ per request. A 32GB server is an extremely large server for such low request numbers. If you can bring the memory usage down stateless works well. I use a…
The problem there isn't scaling - it scales perfectly - the problem is low performance.
Re: I still love PHP and JavaScript
#169Earlier quoted context omitted.
You absolutely can and should. The language is responsible for the programming practices it promotes.
This is just so far from the truth. I can just as easily push tons of logic down into templates in erb/jsp/jinja etc... at some point it boils down to the programmer's level of expertise, but also to the programmers' opinions as there are still a lot of varying opinions on what exactly are best practices.
> I can just as easily push tons of logic down into templates in erb/jsp/jinja etc...
Not just as easy if they don't allow you to insert arbitrary code at arbitrary points as PHP does.
Personally my preferred approach is Wicket where you can't have any logic in your markup at all, all of your logic lives in code and the only thing you can put in the template is IDs for where the code can insert child components or plain text. (OK, it's not quite that strict, but it gets pretty close in practice).
> at some point it boils down to the programmer's level of expertise, but also to the programmers' opinions as there are still a lot of varying opinions on what exactly are best practices.
That's neither here nor there; "programmer's level of expertise" is just abdicating responsibility, when in fact a programmer at the same level of expertise might produce much better code in one language than another.
Re: I still love PHP and JavaScript
#170In 2022 there is no reason to prefer these dynamically typed languages over statically typed ones for production code. When languages like PHP, Ruby, JS blew up the knock against statically typed languages was the verbosity of the resulting code, slow development cycle and general cruft, these languages solved a real problem at that time. That is no longer true today- TypeScript, Go, C# code feels as fluid as a dynam…
"No reason", at all? Have you seen how much standardized legwork is done with a backend framework like Rails and Django? How much easier that is to work with other developers because everyone is following known conventions? With Django, there's also the huge benefit of millions of data libraries an import away. When I search for client libraries to do something, anything under the sun has a Python client. Much much l…
You lost me at Java. Web development was popular in Java well before it took off for Python, and it's been one of the most popular programming languages period since it's inception. There's been multiple supported clients for anything I've ever wanted to connect to.