Hacker News Reader

Comment by mharroun | Hacker News Reader

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.

View on HN

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.

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

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

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

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)

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).

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

Totally different than server-side coding.

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.

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.

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?

> 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).

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.

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

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.

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

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

>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()

> >el.style.color is not equivalent with .css()

How is it not equivalent? Please be specific.

> In my use case jQuery is the best tool and I am not sure why you need to contradict someone with daily experience

Dude, you're the the one who challenged me, and suggested I was lying or uninformed. jQuery is fine to use, I totally understand someone who wants to leverage their background in it. By the way, I also have daily experience, used jQuery for 10 years, am a senior frontend dev.

But it's misleading to new developers to claim that modern JS doesn't have the same capacities. Making this claim spreads misinformation.

> is so hard to admit that the API is nicer,

Disagree. It's more or less the same. I get you're used to one, but there's not a huge difference between the two.

> that it fixes browser differences ?

Yes, it fixes old browser differences, and I made that point repeatedly elsewhere in the thread. For production apps (apps, not sites), if someone is stupid enough to avoid using a framework like Vue.js or React, and you're targeting browsers going back a decade in time, then it's wise to use jQuery. jQuery is also good for progressive enhancement on brochureware sites if you have to support very old browsers (for those kinds of static sites, no need for a JS framework).

But none of that applies to the discussion we were having. The discussion was about quick prototyping.

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

Sure. Mostly, I'm annoyed at being corrected about jQuery by someone who can't even bother to spell "jQuery" correctly. I speak several languages, and make an effort to use them correctly. Also, language mastery is irrelevant: it's frankly surprising to meet a developer who has such trouble with basic syntax issues.

All the criticisms you threw up in that last paragraph, also apply to you. Do you even realize that? You're the one challenging my perspective. I'm defending it.

Also, in terms of cherrypicking, I'm using the example you chose. So if anyone is cherrypicking here, it's you.

OK, I will try to calm our discussion down.

The .css() function can be used as a getter or setter , so if you do something like

el.css('font-size') it will not only do the inline style check as your example, if that is missing it can get the computed css style. Also if you check the MDN page https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement... you will see that IE is mentioned because it is a bit different in behavior.

So here is what I see as facts, let me know what fact is wrong and why

- pure JS most of the time you need more lines of code to do the same thing, more lines makes the code less readable

- pure JS does not chain nicely as jQuery, the code is such less elegant and harder to read

- to solve the above you probably consider writing your own mini jQuery, your version will probably be smaller but it will probably miss corner cases and your code will be harder to read for other developers.

You are probably imagine I am wrinting some horible jQuery code to create complex web pages, I am not using it like that(I think React is something that would fit complex GUIs and server side templates in any language for simple stuff ). The problem I am solving is this: the input is any html from the web, fill with garbage and broken tags, I need to do something like "Reader mode" to clean it up (I use the Moziila library for this) but add some more cleanup on top, then I need to transform it in a more strict version of html because my output needs to pass some validator, so I need to find and remove illegal elements/attributes duplicated IDs, fix different garbage ... ideally all the garbage is removed and you get pure text and images, only P,span and img tags (it is more complicated). I also want to present the result on screen and let the user customize some styling.

For new simple project pure JS is enough, for more complex SPA you probably want a framework, there might be some cases where jQuery can work fine, maybe server side rendering where you need a bit of JS for small interactivity (not on SPA) also there are still some good jQuerry UI widgets around,

Can you tell me where is the anti-jQuery sentiment is coming from and if you feel the same for lodash or similar helper libraries?

Sorry for my language I am not as good as others with some of english weird syntax and is harder to write my thoughts

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 ;-)

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.

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.

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.

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.

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?

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

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.

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.

I just encountered this last week.

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

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.

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.

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.

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

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

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.

Maybe the Hack language?

PHP 5 was what made me make peace with PHP.

You should try PHP 7 then. Whole other world.

I have and can advise it.

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

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.

That's in the instructions.

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

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

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?

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.

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.

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

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.

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.)

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.

Reply on news.ycombinator.com