[mharroun]

Honestly php seems like the common cold... an annoyance that is everywhere and treated with little seriousness. However every evolution it gets better and stronger and adapts other learnings from other languages. It really shouldnt be treated as a joke any more.

Ps: I love php and jquery... not for any real saas systems but no other tool set allows me to spin up and prototype full web app prototypes in sub 90 min. As a senior tech manager php and Jquery allow me to show functional prototypes quickly and easily get buy in from other department stake holders.

[elric]

PHP hasn't been a joke since PHP 4, when it pretty much supplanted Perl, which until then had been the dominant scripting language for the web. Its deceptive simplicity has been both its strongest and weakest point. On the one hand, it helped draw hordes of young developers into the field. On the other hand, it gave a lot of programming power to a bunch of people with very little programming experience, leading to the image of a buggy joke of a language.

I don't think who has had a serious look at PHP would call it a joke these days.

[monoideism]

> As a senior tech manager php and Jquery allow me to show functional prototypes quickly and easily get buy in from other department stake holders

I totally get it if you prefer to leverage your knowledge of jQuery, but modern JavaScript is just as quick to use. Eg, `fetch`, `querySelector`, and many more. Combined with modern css with flexbox and grid, and prototyping becomes very quick.

[kyriakos]

I think the comparison is not between jquery and native Dom functions but between making something quickly with jquery compared to using angular or react for example

[monoideism]

> I think the comparison is not between jquery and native Dom functions but between making something quickly with jquery compared to using angular or react for example

Probably. I was just making the point that jQuery is no longer needed for most use cases. Lots of folks have no idea what the latest browsers are now capable of.

[mharroun]

I'll admit as I moved into managmemt js has also improved. These prototypes are tossaways so it's just faster for me.to grab jquert.

(Btw I love react and use it in any serious project... but each to definitely has its place)

[skinkestek]

It might be just as quick.

But using modern Javascript frameworks makes you completely dependent on Javascript, unless you want to put in some effort to get server side rendering working). And as every good web developer back in 2009 could tell you this is a bad idea as it makes sure the app can never approach the gold standard: to work in every browser (and work better in modern browsers). In fact it is so bad now that we are repeating the IE6 problems even though all major prowser have all the APIs we could only dream of back in 2009.

Here's a secret: I'd say it is still a bad idea to use Javascript application frameworks on most web sites, and possibly many web apps but it is really nice for consultants, training providers and developers who need job security ;-)

As a full stack developer and a consultant who care about the web and about my clients there are times when I can recommend frontend applications but mostly I just hold my nose, accept what sales have agreed with the customer and try to make the problems as small as possible ;-)

[monoideism]

First of all, I wasn't referring to using any JS framework. I was talking about vanilla JS. Did you know that you can use JS modules now in every major modern browser (Chrome, Edge, Firebox), with no build tool required? Now of course, for production deployment, you'll want to do a build so you can hit older browsers and less common browsers, and/or for performance reasons.

And yes, for "brochure sites", nobody should be using anything except for a static site with bits of progressive enhancement Javascript. Agreed.

On the other hand, you use the word "app". For a true app, you're going to need a JS framework. Trying to build an actual app, like Gmail or Slack, is a fool's errand using only server-side rendering. It's possible, but why would you want to do that to yourself? And even then, the user experience would be awful.

I really think web devs need to do a better job both among themselves and for the clients in differentiating between informational sites and brochureware, and true web applications (usually desktop app replacements, or related). The former should be built using static site generators and just bits of JS, whereas no-one is going to try to build a Slack competitor using a static site generator. There are a few projects I've seen that fall in the middle of the two, but those are relatively rare. Most of the time it's very clear if you're building a site or an app.

[rawfan]

I think you misunderstood. The previous poster meant modern Javascript WITHOUT a framework. These days I would just go with AlpineJS, tbh. It’s a mini-framework that solves the most common problems. Best thing for people who don’t want to write js at all.

[simion314]

>but modern JavaScript is just as quick to use

this is not true. There are many APIs in JQuerry that are shorter, nicer to use and totally missing in pure JS. there are JQuerry methods that workaround HTML5 and old HTML(quirks mode) differences, there are functions like wrap,unwrap, sibling, parents,find,is,css that replace many lines of vanilla JS.

I am not saying that JQuerry is the tool for building a complex SPA , it has it's uses and vanilla JS is inferior for those uses, for a simple form where you want to check the input JS is fine.

[monoideism]

1) It's jQuery, not "JQuerry". I've been using it since 2008, and Prototype.js and script.aculo.us before that.

2) For quick prototypes, I can't imagine why you'd need to accommodate pre-HTML5 HTML. We're discussing quick prototypes, not production sites targeting browsers going back a decade.

3) VanillaJS equivalents are slightly longer than jQuery snippets, mostly because the API names are a bit longer:

css:

    // jQuery
    newDiv.addClass('foo');

    // Vanilla
    newDiv.classList.add('foo');

siblings:

    // jQuery
    const nextElement = $('#wrap').next();

    // Vanilla
    const nextElement = document.querySelector('wrap').nextSibling;

etc etc.

If the extra verbosity bothers you, you can always alias `document.querySelector` as `$`, or `sel`, or whatever. Then you get stuff like:

    // jQuery
    const nextElement = $('#wrap').next();

    // Vanilla
    const nextElement = sel('wrap').nextSibling;

And yes, the jQuery method names are a little shorter, but for quick prototyping, I'd rather use something that I know can be run on any modern browser, with no build step or library required. For production apps, I'll 99% of the time use a framework, either React or Vue.js.

I get that not everyone prefers that. That's OK.

[simion314]

You chose the functions that are the simplest , maybe this are the ones you use but there are many more, like do this in JS. i gave other examples like .is("Lvisible") .parenents , wrap, unwrap, and the one I use a lot .css() .after(), .append() etc . and what makes the API neat is you can chain methods where DOM APIs return special collection that you have to use with for(i = 0; ....

JQuerry might not be the tool for your job but this not makes the fact it's API is nicer, powerful then pure JS . check the anti-jQuerry page http://youmightnotneedjquery.com and you will see that in the end you have to reinvent yor own jQuerry

[monoideism]

> JQuerry might not be the tool for your job

Again, jQuery. I'm a little skeptical that you use either very often if you don't even know how to spell it. `jQuery` is literally the global namespace for jQuery (often aliased to `$`).

> and the one I use a lot .css() .after(), .append() etc

after:

    // jQuery
    (target).after(element);
    // Vanilla JS
    target.insertAdjacentElement('afterend', element);

append:

    // jQuery
    $(parent).append(el);
    
    // Vanilla JS
    parent.appendChild(el);

css:

    // jQuery
    $(el).css('color', 'black');

    // Vanilla JS
    el.style.color = 'black';

That jQuery equivalent page is like 5+ years old. Now, there are easier APIs for the few lengthy vanilla JS that remain on that page.

[simion314]

>el.style.color

is not equivalent with .css()

About my typo , I am not a native english speacker and words like query , queue , still, until are hard for me to remember when to double some letter, spell checker will help but jQuery is not in the dictionary and when I code I use $ and never the full name.

In my use case jQuery is the best tool and I am not sure why you need to contradict someone with daily experience , is so hard to admit that the API is nicer, that it fixes browser differences ? Do you lose some points or pride or other ego related stuff? Do you think you win some credit when you find a typo and use that to attack me? Can you explain what is happening in your mind when you type this ?

Go on that page and look at /is() pr /widthy() and not cherry pick stuff or incomplete implementation like you did for .css()

[te_chris]

Modern JS is a total shit show of competing build tools, APIs that only work in certain ways in certain places, NIH reinventing the wheel. Thankfully there's some standardisation now, mostly due to the heft of Facebook, but it's still some much more work than it needs to be, espeically on the server compared to other web stacks like Elixir Phoenix, Rails, Flask, even Laravel (despite it's frustrating APIs).

[monoideism]

I'm talking about vanilla JS, no build tools.

Totally different than server-side coding.

[dagw]

but modern JavaScript is just as quick to use. Eg, `fetch`, `querySelector`

That's one, trivial, part of JQuery. The real strength of Jquery is the countless UI widgets and libraries built on top of it. I can knock together a quick and easy UI using Jquery, Bootstrap and a handfull of Jquery UI widgets faster than with just about anything else.

[monoideism]

Yes, I know. I used jQuery for 10 years.

Now, after learning new APIs for 2 years, I can put together a quick and easy UI using vanilla UI and CSS as fast as I could with jQuery. Particularly grid and flexbox have made a big difference (they fill the role of the old grid CSS frameworks, including that part of Bootstrap).

Your mileage may vary.

Also, the majority of third-party jQuery plugins are no longer maintained. Most of the JS world has moved on.

[sethammons]

jQuery: include this lib, modify DOM.

Modern JavaScript: traveling menagerie of package managers, compilers, build tools, etc. Now that is all in place, modify DOM.

At least, this is my impression from the outside. The last time I actually wrote js was around a decade or more ago.

[martin_a]

As someone who is not very familiar with JS in its multitude of variations this is what it feels like to me. Somebody told me to try Vue and while reusability of components is surely nice to have I feel kind of lost when all I need is a popup when a "save action" was successful.

What about jQuery? Is it still the go-to for simpler things?

[monoideism]

> What about jQuery? Is it still the go-to for simpler things?

Unless you need to target older browsers (like any IE, really), I'd just use vanilla JS. Vanilla JS means no packaging or build process needed. Just create write a JS file, reference it in a script tag in a basic `index.html`, start a web server (like `python3 -m http`) and you're good to go.

Spend a little time learning about flexbox and grid CSS APIs, and you don't even really need CSS framework if you're a decent designer (if not, use Bootstrap or some other CSS framework).

If you're targeting older browsers, like IE, then yes, it's probably a good idea to use jQuery and some CSS framework like Bootstrap.

Absolutely no need for Vue.js or React if you're just doing a very basic UI (however, note that basic UIs have a tendency to become more complex with time, so for that reason most JS devs start with something like Vue.js even if it's not needed initially).

(I'm a senior software developer working in frontend development exclusively for the past 5 years, but have been using JS since 1998, and jQuery since like 2008 - I left the software industry for a number of years after the dot.com bust and came back a decade later).

[monoideism]

I'm referring to vanilla JS and CSS. Literally just write a file and go. No packaging. You can even use modules on modern browsers.

A lot has changed in the decade you've been away from JS. Yes, there's a whole build infrastructure now for large-scale project, but bare, plain, vanilla JS and CSS have more or less built-in most of the features of jQuery and the old CSS grid frameworks.

[SparkyMcUnicorn]

The parent comment is referring to vanilla JS. Just write and serve .js files.

The tools you mentioned are common for frontend frameworks and such.

[irrational]

One of the biggest complaints I've read about PHP is that many things are not consistently named (having never used PHP, I might be wrong). If this is true, are there any plans to fix this?

[duncan-donuts]

It is true and no I don’t think there’s much talk of changing it. There’s also a problem with inconsistent method arguments. Just look at array_map[1] and array_reduce[2]. This is just the one example that bit me the most, but there are other inconsistencies like this all over the language that require you to constantly look things up.

[1] https://www.php.net/manual/en/function.array-map

[2] https://www.php.net/manual/en/function.array-reduce

[dana321]

Array map takes one or more arrays with a callback, so the arrays have to be on the end.

Array reduce has one array as a parameter, as does most of the other functions and they all have the array as the first parameter.

Its only one function, and its an inconsistency for a reason. Lets not blow it all out of proportion.

[nkozyra]

I remember reading a cogent explanation for this inconsistency but can't seem to locate it.

JavaScript suffers from inconsistent mutation/return of array values in array functions, too.

PHPs design problems are mostly being swept away; it's the legacy that keeps its reputation down.

[aspratley]

Rasmus Lerdorf has talked about it in other videos but this is one https://youtu.be/iGOAQli7tGc?t=1485

Basically, groups of functions are consistent: string,array etc. Their parameter order was usually based on whatever the underlying C API was.

[Moru]

I use an editor that has the php help built in to not get confusing errors. You type the beginning of the command and it directly tells you what part is the needle and what is the haystack.

[cdirkx]

I just encountered this last week.

I had to explain to my fellow non-IT students why I was making loud gasps of confusion.

[conradfr]

In practice it hasn't been a problem for me in a long time (I've been doing PHP since PHP3 so I have some perspective on it).

First the documentation is fine and easily accessible, second your IDE will hint you the correct order and finally in a real world web framework situation you don't even use those functions that much anyway.

My biggest complaint would in fact be the concurrency situation, it's still not easy and relies on external libraries that feel half-hacks. I guess Elixir spoiled me in that regard.

[tpetry]

And when enabling strict types you will get an error anyway if you have the wrong order because the types will not match.

[akie]

"My biggest complaint about this language I've never used is something I'm not sure is true. Is it?"

[irrational]

Well, I have worked as a web developer for 20+ years. I've heard that PHP is inconsistent dozens, perhaps hundreds of times. I've just never verified it myself since I've never used PHP.

[haolez]

Maybe the Hack language?

[pjmlp]

PHP 5 was what made me make peace with PHP.

[oAlbe]

You should try PHP 7 then. Whole other world.

[pjmlp]

I have and can advise it.

[krsdcbl]

It never should have, the treatment php gets mostly feels like people finding it "not cool enough", seldomly I've seen someone have a real reason to avoid it

[heleninboodler]

PHP fans don't do themselves any favors by dismissing the criticisms in this sort of non-substantive way. The "fractal of bad design" paper has a lot of good criticisms, and the standard library is still a horror show of poor API design, in my opinion.

The first embarrassment I could think of off the top of my head is still there, for example:

https://www.php.net/manual/en/function.htmlspecialchars.php

Completely ignoring the fact that that function is a misnomer because it encodes XML special chars, not HTML, the "double_encode" parameter is pants-on-head ridiculous and basically a concession to people who can't be bothered to keep track of whether their string is already escaped or not and want to be able to pass it through this function again "just in case."

This is a bug waiting to happen (or more like a bug that's already happened all over the web), and the type of stuff that makes seasoned programmers who appreciate a well-designed ecosystem dismiss the entire thing as amateur hour.

[takeda]

When I used the language (around PHP 5) in the past it felt very inconsistent, and many functions were nearly 1:1 PHP interfaces to C functions. The type coercion also was bad, or the stupid idea of having form variables appear as variables in the language (I believe the defaults were changed to disable it in 5).

Learning the history of the language (and that initially PHP was not supposed to even be a language) explains why things were the way they were.

Anyway the language worked, it wasn't specifically bad, and if you didn't use other languages (excluding JS which has similar issues) you might not even see any problems with it.

Anyway, later they started fixing many of these issues and looks like the language is becoming more consistent (note I don't know if this is entirely true, since I haven't have chance of using newer versions, but that's how it feels from outside.)

[Beldin]

My pet peeve: http://phpsadness.com/sad/47

TLDR: checking passwords in php used to rely on using the correct comparison operator. Using the'==' operator would introduce subtle flaws. Using '===', you're fine.

[stef25]

Doesn't javascript have even more subtle flaws? Perhaps other languages as well, not familiar with many.

[rsynnott]

Yeah; PHP and Javascript are in the same general category of completely insane languages. As was (pre-.NET) Visual Basic, though for slightly different reasons.

[philjohn]

You should never have been doing that in the first place, checking password hashes should use a constant time equality check to prevent timing attacks.

Just so happens there is now one in PHP - hash_equals, but even before that you could do a constant time equality check trivially by hand.

[tudorw]

That's in the instructions.

[jorams]

Documented insanity is still insanity. A very clear example that was luckily removed quite quickly: php_check_syntax.[1]

> Check the PHP syntax of (and execute) the specified file

This function's name and its documentation suggest completely different use-cases. In fact, it apparently does the one thing I wouldn't expect it to do based on the name. It's insane, and it cannot be excused just because the insanity is documented.

The example given by GP is a lot more subtle, but this is not a good argument to make.

[1]: https://www.php.net/manual/en/function.php-check-syntax.php

[tudorw]

I accept that, but I still don't really understand the issue, which programming language can I pick where I don't need to read about what does what, I don't feel any language is intuitive per se?

[tudorw]

Seriously, I've worked with coders where English is a second language, they literally had no idea that the combination of letters making up words we recognise were anything but symbolic of the function.

[dvdkon]

Having to read those to see if a working program is fully correct is a failure on the language's part.