Live data from Hacker News

I still love PHP and JavaScript

the.scapegoat.dev

331–340 of 402 posts

Re: I still love PHP and JavaScript

#331
post #4

PHP 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.”

I really like the vercel and co approach to the dev cycle. It's as easy as (if not easier) PHP and you get a huge boost of monitoring / infra tools for a minor cost. I think we are seeing a lot of the "yeet and get shit done" approach with vercel and netlify that we used to with PHP.

Re: I still love PHP and JavaScript

#332
post #162

Earlier quoted context omitted.

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.

Do you really though, or are you being a bit hyperbolic? It's really not that complicated or arbitrary. If you find yourself hitting idiosyncrasies so often you've got the docs open you might just be doing it wrong. There's also some learning to do for any language, no language is so intuitive that you know it without any effort or learning.

All the above said, do enough real work in any language and you'll find cases where the idioms of the language don't map to your work.

Re: I still love PHP and JavaScript

#333
post #4

PHP 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…

> 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…

With both Drupal and Laravel it's very easy to overload the database. It's shocking when you start using some tool that gives you insights in to this and it tells you you're running 6000+ queries every time your homepage loads.

In Laravel it's not too hard to avoid this problem but a lot of noobs don't get the lazy / eager loading thing and then you end up like this.

Drupal seems to add hundreds of queries for every module you add.

Re: I still love PHP and JavaScript

#334
post #245

Earlier quoted context omitted.

I've used Python, C#, Java, JavaScript and PHP, and in my experience Python is the most unpredictable of these languages. Just to name a few: - mutable default arguments - late binding closures - typings that are purely documentation instead of being enforced Labeling these things as "gotchas" doesn't make them predictable imo.

Python less predictable than PHP? In what world? In PHP standard library functions silently take a null instead of a string, even though they are string handling functions, hiding that mistake for the user of the language, until a later point in time, when the context has been lost and one needs to do silly debugging, until one finds the place where the null first was handled, while it should have raised an error. Su…

These problems were fixed in PHP 8.0 and 8.1

https://wiki.php.net/rfc/engine_warnings

https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_a...

Re: I still love PHP and JavaScript

#335
So do thousands of people, because they're pragmatic and useful. They're the Honda Civic of the working software world. For people doing real work, you have a whole host of great languages available, and there's no sense in pretending that one of them isn't PHP just because you think you're still doing comp sci at uni. There's definitely better languages than PHP, no doubt. But we're in the trenches now, getting stuff done, and people have been getting great things done in PHP for years.

Re: I still love PHP and JavaScript

#336
post #330
post #4

PHP 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…

The issue I have with php, having started building websites in the early 2000s with it, is that it is a language that doesn’t push you to write better code and progress. I am much more of a fan of static langages where the IDE guides you a lot more, gives you live feedback so that being curious is cheap, you don’t have to dive into some documentation to know what the other methods, parameters and overloads are, you c…

I think PHPStorm has been very helpful as an IDE for over a decade.

One of the things I do like about PHP is that while most legacy codebases out there are lousy (even when good developers are involved), and often lousy for totally legitimate reasons, PHP with its "don't even try to do clever" approach makes many things easier.

Of course, I only dealt with so many legacy applications. My worst experiences have always been with python legacy code because there were strata of conflicting "better code" approaches piled on top of each other.

Once you start abstracting into patterns, and you don't have the experience needed to get a sense of good architecture, it's easy to make a real tangled mess.

Re: I still love PHP and JavaScript

#337
post #162

Earlier quoted context omitted.

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.

My approach (very similar than when I write C or raw JS) is to use a few "cleanup" APIs or libs that hide the nasty stuff (string handling / array iteration / SQL building), because I know I don't want to deal with all the footguns. There were rarely is a performance argument that would need me to do otherwise.

Re: I still love PHP and JavaScript

#338

Earlier quoted context omitted.

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.

> in the docs comment section. A classic boiled frog statement. __It's not undocumented, someone posted a comment about that bug...__ I will quietly place my face in my hands and weep to the memory of php coding I did 20 years ago. Seems the same nonsensical masochism is still going strong.

To me the comments section is one thing that sets PHP apart from other languages. Need to learn a new function? Go read about it on php.net, then skim the comments for edge cases.

Need to do something new in Node? Sift through a bunch of search engine spam, read a few dissenting answers on stackoverflow that refer to a previous version, eventually find a library that does what you want, written by skullM4ster2004, plug one's nose and install it.

Re: I still love PHP and JavaScript

#339
post #4

PHP 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 also think there is something unique about PHP documentation. It has plenty of real life examples, and the ability for users to leave comments allows you to hear directly from others "gotchas" that people have experienced. I feel like PHP documentation is very undervalued.

I think it's the best documentation out there, and that part of the reason it's easy to document, is because the language uses a standard library, and functions, as opposed to the structure of the language, itself, to provide most of the utility. Functions are easy to document.

They do a good job of "cleaning out the cruft," as well, so that there isn't much in the way of "no longer applies" stuff.

Part of it, too, is that the language probably supports stuff all the way back to 4. They tend not to deprecate, and accrete, instead (not always a good thing). That means that examples and discussions maintain relevance, even years later.

One of the biggest issues that people tend to have with PHP, is that it allows you to write bad code.

I came from a C++ shop (another language that people love to hate). If you think you can write bad code in PHP, C++ says "Hold my beer."

I am a big believer in Discipline. With Discipline, we can write excellent, maintainable, code in any language. I have written stuff in Assembly, FORTRAN, Pascal, PL/1, Perl, Bash, BASIC, C, C++, ObjC, and Swift, that is quite well-structured, maintainable, and well-documented.

Re: I still love PHP and JavaScript

#340
post #333

Earlier 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…

With both Drupal and Laravel it's very easy to overload the database. It's shocking when you start using some tool that gives you insights in to this and it tells you you're running 6000+ queries every time your homepage loads. In Laravel it's not too hard to avoid this problem but a lot of noobs don't get the lazy / eager loading thing and then you end up like this. Drupal seems to add hundreds of queries for every…

I feel this is more a "classic" ORM problem. Wordpress is absolutely egregious here as well. I wrote up my strategy in another post, but I usually develop using the ORM (often, ORM for writing, SQL builder + ORM for querying, because I hate ORM filter/join abstractions).

I do think very hard up front what the product will require in terms of: - static content - dynamic content that is cacheable and which keys can be used to cache it

Static content can use ORM as much as it wants, cloudfront will take care of it. dynamic content that is rarely hit doesn't really need much help either if there are no UX latency requirements. dynamic content that is hit very often (usually only a couple of endpoints) can be rewritten into manual SQL.

If you think about it, most page hits with dynamic content can be rendered basically by the DB + templating engine, and no other logic should be involved.

Post reply on HN