New in PHP 8
stitcher.io
stitcher.io
[1] https://mobile.twitter.com/antirez/status/122328600521977446...
* If you wanted to scale it horizontally, it was ready to do that 15+ years ago
* No problem running it completely stateless
* Deploys are completely sane and predictable, it's just a bunch of files, and even when composer came along it didn't really change that too much
* Performant enough as far as the interpreted web languages go
* No problem writing a RESTful backend in it and fronting completely "modern" client facing tech on the top if you want
* Server side rendering since day 1
Like, it came down to people complaining about some function names / param orders as if it were the end of the world. I think a certain subset of people (shall we call them hipsters?) are just keen on finding new ground where they can rewrite the same boring things instead of working hard to improve the ecosystem of something existing.
I moved on from PHP aeons ago because it got this undeserved bad rap, but I still follow it and would welcome the chance to run it again.
I mean, your listed points are arguably correct, but this sentence is quite incorrect.
edit: downvoted by PHP fans. It's OK, I get it, nobody likes it when others dunk on their favorite language. :)
FWIW though, you're absolutely right - there was (maybe still is?) an enormous amount wrong with PHP. The only real rebuttal core-questions needs is a link to the classic essay, "PHP: a fractal of bad design" [1], which lists far, far more problems than just issues with function names or parameter order, and does it more comprehensively and with more style than you or I could hope to.
[1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
Edit: I can also imagine this design decision must have had context. Perhaps it was a common technique in low-level programming, as a practical way to save time/space.
On the other hand, if you’re trying to nerd-snipe me into a debate over the meaning of the word “classic”... :)
I’ve gotta disagree with your characterization. At least in the field of jeremiads, surely the criteria can’t solely be timelessness - that’d imply that an essay that successfully inspires change couldn’t be a classic (not that that’s what happened here, I’m not directly attributing anything to anyone). Words are hard to pin down, but I think when it comes to screeds, what’s “classic” could be, in fact, whether it provoked some kind of change - if at the time it won hearts and minds. Or, what’s “classic” could be not necessarily about the specific thing it’s arguing against, but instead about the underlying principles guiding that argument. Or maybe it’s about the style, panache, humour, or clarity with which those principles are argued. Maybe some combination of all of the above.
No one programs with gotos much anymore, but “Go To Statement Considered Harmful” is probably safe to call a classic. America is an independent nation and King George no longer holds the British throne, but nevertheless the Declaration of Independence is certainly a classic text. For reasons of style, persuasiveness, its underlying principles (I think anyone designing a PL should have read it), and its widespread popularity and influence at the time it was written, I think the PHP essay counts as a classic too. YMMV.
If you've got some counterpoints or arguments, please give them. Going "lol php bad" is just dumb.
It's a problem for some use cases, and even in the web use case, reusing connections to databases and services can be a pain with PHP because it's completely stateless.
pgBouncer and ProxySQL are going to give you a better bang for the buck than a stateful web app will.
You can have an awful implementation of a connection pooler, sure, but opening an authenticated socket is more expensive by far than just referencing one.
Less so for a unix socket/named pipe- but still much slower than a memory lookup.
Of course you probably don’t care until you hit a certain scale or number of backend system accesses.
I'm not arguing for a truly stateful webapp, but the connecting pooling you get for free (or some library wrangling) with a long-lived process does a lot for performance and scalability.
It’s funny folks pick on the “Magic” in PHP, yet overlook all of it in Ruby. I’m not a PHP guy anymore really (now Python/Rust/Java/Ruby mainly), but I’m still continually annoyed reading Ruby code. Here’s an example:
- find a method being called on a class, so want to find out details on said method
- grep through codebase, find no definition for said method
- grep through all gem dependencies, find no definition for said method
- search web, don’t find any obvious leads
- cry in despair
- finally find that method is handled by a method_missing on a dynamically generated class and never has anything related to the method name even as a string
- flip desk and go home for the day
It succeeded, as it's often the case in IT, not because it was the best, or even very good, but because it was easy to adopt and had a killer feature.
"Messy Api" is discussed above ("it came down to people complaining about some function names / param orders as if it were the end of the world") so I won't comment.
"terrible default": would be interested in specifics here
"wonky typing": every scripting language had wonky typing 15 years ago, and many of them still do today. This has never been a valid criticism of PHP when comparing to it's primary competitors.
"no namespace": THIS is a very valid criticism. PHP really wasn't a sane language before they added namespaces. But... they added namespaces 11 years ago.
Magic quotes would be the first one I can think of off the top of my head, which incidentally, was made a default because the mysql api in PHP was so prone to sql injections, that PHP decided to automatically escape all user input as a way to protect inexperienced programmers.
Pretty much everyone agrees magic quotes were a bad idea and they were eventually deprecated in 5.3 and removed entirely in 5.4.
Or multi-byte compliant methods that are a variants, and not the standard method, thus biting anyone who just thought utf-8 would be default.
"terrible default": the poster child for this is register globals, which it took ages to have off by defaults. That's just a single line to set it properly, but that was part of the boilerplate that could have been avoided way earlier.
Overall developing for PHP meant to defensively remember a ton a weird stuff, just like javascript was for a while. I am so glad we mostly got past that, even if I am not in PHP anymore.
String encoding though is, again, something other languages had similar gotchas with. Remember we're comparing PHP to its popular alternatives at the time, not to our hypthetical ideal runtime.
The bad defaults you and a sibling commenter are referring to (magic quotes) are, again, from 11 years ago.
Sure, 15 years ago PHP had serious issues, but here we are today acting as if they didn't fix most of them over a decade ago.
Recall that the defense of PHP in this tree leads with "There was never anything wrong with PHP, really."
That's because the context was the state of PHP 15 years ago.
Looking at the Python standard libs vs the PHP standard libs, PHP used to be a bad mess. Other than that, it's still brilliant.
How many scripts continue to prohibit apostrophes in passwords because there used no way to reliably instruct devs on how to handle apostrophes in strings? People named O'Brien still can't enter their names in forms and expect to get it back despite magic quotes being gone years ago.
Nowadays, modern php is conservative but fine. But it was really a terrible choice in its early days, when every one of its selling points was a misfeature.
Thankfully this problem was solved back in 2004/2005, but unfortunately shitty code was already pervasive and the “right way” wasn’t heavily communicated enough.
Broke in 7.x because it would now warn now... I don't remember what it returns now but that was a thing...
When I switched from PHP to Python it was an amazing, liberating feeling for me that I will never forget.
"That is the difference between having to look something up" PHP (for 15 years?) has had IDEs that fill it in for you.
https://www.python.org/dev/peps/pep-3000/
No one had to have any problems with the transition. If they did, they had to willingly ignore the in-your-face documentation on the migration process.
I am not against making something not backwards-compatible. I am in favor of throwing old, bad things away even at the risk of having to rework some stuff... But how crazy legacy is at every damn company is just making it so frustrating. They will happily just wait it out for 14 years and then complain about their Python2 being desupported
This release is another step in resolving these problems.
The first Java web shop I worked for had a homegrown version of magic_quotes_gpc. That’s when I realized that those who had gone through making PHP installs and apps secure had very valuable experience.
This was absolutely the killer app for PHP. It was lucky enough to be well integrated with Apache, and crucially could run as a non-persistent per-user interpreter behind the web server. This made it exactly ideal for deployment in shared hosting environments. The fact that you can't do this with e.g. Node forces all sorts of containerisation yak-shaving on us.
People tried to do this with a few other languages, such as Apache mod_perl, but PHP was the one that thousands of cheap shared hosting providers made available, letting people get started with web development.
Arrays go (needle, haystack). Strings go (haystack, needle). There might be a couple of exceptions but that's basically it.
- the way mutable default arguments are handled
- the weird behavior of closures referencing loop variables
- leaking variables out of if/for/with (yes, i know it's convenient, but can bite sometimes)
- GIL stuff
- exec not being able to introduce new local variables (yes, i know code-objects have their local variables decided at compile time, but it's surprising if you don't care about that implementation detail)
other than that i can't think of many "insane" behaviors that can bite you. i'm curious what you're referring to!
and sure, i'd change a lot of the language to make it more FP-friendly if i could, but being what it is, the semantics seem pretty unsurprising most of the time
Yes, nice you can have Python-adapted editors where ident levels can be tuned, but no, it's still a big defect
Your editor can help you with the editing. (And the problem you mention are exactly the same, if you write production code in other language. Your teammates will hopefully insist on consistent indentation in C or Java as well.)
There was plenty of wrong with PHP. There were very unsafe defaults, poor API choices, poor coding standards, inconsistent syntax, paper-thin C bindings that didn't provide the level of abstraction you'd expect from a scripting language etc... If you've forgotten what PHP used to be you can just take a trip down memory lane by browsing through this classic: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ . Lest we forget PHP was started as a templating engine that evolved haphazardly into a full fledged programming language, and it showed.
If you think PHP is a good language today then say that, but let's not pretend that the complaints and ridicule were always undeserved.
It's a question of when do you let that go?
The bitter truth for PHP stans is that it is what it is, you can get things done, and you can have valid reasons for using it (like legacy reasons, job market, etc.), but it's rightfully trending down and will continue to.
Btw, I do agree with most of the changes Facebook's Hack made to PHP.
This isn't contrasting Ruby to PHP, this is contrasting the web that was with the web that is.
And actually, even when Rails was founded the PHP stack was inadequate for this -- which is why current practice includes all the parts that antirez is complaining about? Gems? PHP has composer, barely any serious project doesn't use it. Rack? Granted, once the PHP server is setup you don't have to account for an abstraction layer. Rakefiles? I don't think there's a standard task runner for PHP, but e.g. Laravel has envoy and I would assume that almost any project needs some kind of shim there, even if it's just shell scripts. YAML? Well, erm, ok, I won't defend that…
The times where PHP means directly accessing a `.php` file for every "page" have passed by. If you look for simplicity there, oh traveler, beware…
It's not even a Rails app. No idea what he was complaining about exactly, but certainly not Rails.
Looking at the original app, the Rakefile for example seems mostly to be there to start Redis? How would we have done this in the olden days of the *AMP stack, assuming the task has to run on both Windows dev machines and the Linux server? Heck, we might not have been able to do this at all, if we just had file and not shell access...
> rake
As you say it's a simple task runner like make. Maybe use a shell script instead, but appart from that, hard to be any simpler.
> rack
That's just an interface, the equivalent would be mod_php & co, not any simpler in my book.
> gem
Not sure what's there is to complain about here. It's a fairly straightforward package manager. Unless you stick to the stdlib, I doubt PHP packages are any easier.
> yaml
Many people hate it, but for simple configuration it's not any worse than JSON or XML. Matter of taste I guess.
I'd be happy to hear or more detailed complaint from antirez, but I don't think anything can be inferred from that single tweet. This reads like someone who hasn't worked with Ruby in a while, and is grumpy he has to figure a few things out again.
Wait, are we really calling Ruby/Rails the "is" of web development in 2020?
It has a heap of problems due to mistakes made in the past and - perhaps more worrying - a LOT of misinformation posted on the internet. Then there's the trope of PHP developers always building their own frameworks and CMSes and the like.
And I'm dealing with a big legacy codebase where the original author did not understand separation of concerns (or sql injection for that matter), with constructs like a switch returning a different SQL query depending on a string value, globals to store the result in (which is concatenated XML transformed to JSON at the bottom of the 5000 line file, which in turn includes thousands of lines of additional code). And the project was started in 2012, when modern PHP and frameworks were already a thing.
I'm doing new work in more neatly organized classes at least.
I've also started looking at Flask and Django of Python, can't help the feeling, that the Python frameworks are a bit more mature in terms of breaking changes.
- Everything is either built-in or can be enabled from an OFFICIAL repository (like functions for bc,xml,etc). No more trusting sketchy npm packages or having to pull in a ton of dependencies that might stop working some day.
- It's so fast and elegant to consume a (SOAP or REST) webservice. Visual Studio insists on creating tons of files, obscure web.config settings and other misc. stuff. PHP handles this in a couple of lines.
- Development feels natural, every file can be a single class if you want and there are plenty of highly matured frameworks available.
I estimate I've slashed development time in half compared to C#, less bugs and less security issues (verified through two independent code auditors). Even large projects are easier to work on in PHP compared to C#
If I'm going to consume a web service, I am going to write the models in C# and let a JSON deserializer like Newtonsoft.JSON map everything. To me, there's nothing better than having a fully modeled web service. I learn a bit about how the service works when writing the models. I know what the data looks like before I start working with it in my own application.
Regarding your web.config note, I guess I don't understand what you're trying to get at. .NET projects tend to throw configuration items into, well, a configuration file. Again to me this is far superior to doing the PHP-industry-standard of having a config.php and chucking a bunch of global variables into it. Putting configuration items behind a parser in a document that you expect the user to edit is good practice.
Development feels natural, every file can be a single class if you want and there are plenty of highly matured frameworks available.
Maybe this is a note more for the NodeJS space, but a single file per class is the general guideline for C#/.NET. Additionally, I've generally found that the .NET framework and libraries written against it tend to be of much higher quality, are more secure, and are more production ready than most I've worked with in PHP land.
On top of that, Visual Studio is a wonderful IDE and is pretty much the gold standard of our industry. I've not had a better experience as a developer than being able to create a .NET Core MVC web application and hit the ground running. I've written anything from 5 line Azure Functions to working with 100k+ line web applications and I'm not sure I could have done it without the excellent debugger available and the very context-aware Intellisense typeahead. In contrast, other than PhpStorm, I find PHP environments to be extremely messy and a bit of a hack to get working properly. If I didn't have some sysadmin background I'm not sure I'd move outside of "debugging" using var_dump().
I was a PHP dev primarily from ~2009-2017 and have been working almost exclusively in C# since.
Unless you've a solid proof, this is just.. blatant lie. How did you measure the security and quality? Was it "ok, this seems nice" or was it literally reading the code, running the tests and hitting the lib with a pentest suite?
See, it's one thing to compare languages (which is silly) and completely another to let your subjective feel get in the way of objective analysis.
Stating that libraries which contain more than 1 class per file are more secure and robust is just a nice wish, but nothing more than that. It's simply not true to the point it's funny :)
> On top of that, Visual Studio is a wonderful IDE
It sure is, top notch IDE.
> In contrast, other than PhpStorm, I find PHP environments to be extremely messy and a bit of a hack to get working properly.
You've PHPStorm and there's VSCode. PHPStorm is better. It works almost flawlessly. What's an IDE got to do with environment? Why are they a hack?
I'm a dev who started with PHP in 1998. and have been using it since (among many other languages). Reason I'm writing this (despite hating it) is to nullify your experience as any sort of valid argument.
Unless you can provide actual, hard proof for what you wrote - it's merely how you'd like it is.
Now, is any of that important? It's not. You use C# and you're satisfied. That's all that matters. If some other guy says PHP is better - you know that it's not, in your particular case. And that's great.
IMO, as a PHP dev, I consider C# an excellent language. As a sysadmin, I hate Windows and its ecosystem from the bottom of my soul.
Yes. Additionally features of .NET binaries such as signing tends to be a bit more favorable to me.
> Stating that libraries which contain more than 1 class per file are more secure and robust is just a nice wish, but nothing more than that. It's simply not true to the point it's funny :)
That's not what I was stating. I was stating that 1 per file is common in .NET land and I personally believe that it leads to more organized code.
> You've PHPStorm and there's VSCode. PHPStorm is better. It works almost flawlessly. What's an IDE got to do with environment? Why are they a hack?
VS Code isn't an IDE, really. It's a text editor with extensions. I was speaking more to the fact that setting up a proper development environment with PHP is a chore. If you're using an *AMP, you've got one shared environment across all your development projects. Things like debugging two PHP projects at once can't happen. Edge case stuff sure. Using vagrant or another VM solution is a super heavy way to accomplish something that should be simple. Using Docker is nice, but has its own pitfalls. I agree PhpStorm is fantastic. It's always been one of my favorite tools. A bunch of its editing features are leagues ahead of VS. Unfortunately, it's not a complete solution to a dev environment. And yeah, I'm aware you can launch `php` directly from PhpStorm. I usually find that to be a nightmare in its own way.
Again, I started as a PHP dev and it holds a certain place in my heart. I'm not sure I could ever find an instance to use it over any other platform, though.
Also, you should try to give .NET Core a try. It's a pretty fantastic platform. Like PHP, I would never choose to start a project with .NET Framework.
We do have config files too - global variables in some config.php was already frowned upon 10 years ago, much more so today. In times of autowired DI, you have a parsable, user-editable config file just like any other project. Had you used PHP since like 2013 or newer, you'd be aware of at least Symfony, which does this since forever.
I don't know a single reason why you would put multiple classes in a single file, especially in times of PSR-4 autoloading. Nobody does this since years, much rather decades, ago.
I also really don't know which libraries you use, but the composer ecosystem is one of the most mature, best maintained out there. There are countless projects of excellent quality out there, used in production on millions of servers every day.
Speaking of IDEs: you mention PHPStorm but still claim there's practically no good IDE for PHP. That doesn't make any sense: PHPStorm is a top-notch IDE, it has virtually anything you have in VS.
And lastly, why would anyone still bother with setting up an environment on their box if we have Docker? It's 2020, there's really no more reason not to.
I would never choose PHP to consume a SOAP webservice if I could use C# or Java instead. And I say that as someone who's been consuming SOAP with PHP since 2001, from travel industry suppliers, major CRMs/ERPs and a bunch of quirky services.
PHP's SOAP library just isn't very good. From what I recall it doesn't support some of the security extensions natively, struggles with namespacing, has small changes to data structures when serializing/deserializing (I recall attributes/values being a pain to setup) and worked with some endpoints but not others. That could be the endpoints' fault, but when Microsoft is producting it - I sure expect the endpoint to work with PHP's bundled SOAP library.
Multiple times I fell back to constructing the XML myself (sometimes with the DOM builder, other times with handcrafted XML strings that were tested in SOAP-UI until they worked and given placeholders for data.
Last week I had to investigate ow a service had got the wrong data, and neded to load the XML response again to see the data in our app. The PHP XML extensions give a different structure to the SOAP extension; to get back the result you have to mock the response in a subclass of SoapClient, feed in your XML and let the extension parse it. That works, and is elegant in a way - but it could be so much better.
Rant over ;)
Currently it places #11 on the famous framework benchmark:
https://www.techempower.com/benchmarks/#section=data-r18&hw=...
swoole is co-routine based, having a much better lifecycle and resource sharing as a consequence. Which leads to much more throughput.
Btw. Swoole is not written in PHP. It's C++. It's compiled as an extension for PHP.
#11 in Single Query is: Swoole, PHP, mySQL
Swoole => Not default PHP but a highly specialized framework Single Query => This is not about fast language/runtime but fast DB driver
While still definitely impressive, Techempower Plaintext is more specific (runtime + http server). Here Swoole/PHP is #60. The Swoole/PHP mysql driver (that is not default PHP mysql driver) is very optimized compared to e.g. the .NET Core postgreSQL driver. The result => Swoole/PHP is wicked fast (~ 15% delta) but .NET Core beats Swoole/PHP Plaintext (~ 75% delta).
Plain traditional PHP is not one of the fastest language/runtime. But Swoole is a wicked fast framework.
Good thing however: Indeed, the JIT will improve the PHP language/runtime. And Swoole shows what is possible if you make some radical design decisions (same what happened with .NET). And this is good for PHP.
In most cases, though, you care a lot more about the 95th or even 99th percentile response times than you do the mean; I'd trade quite a bit percentage-wise off my mean response time if it brought the 95th percentile way down.
(This isn't to hate on PHP; PHP is fine. But you shouldn't choose it because the "single query" benchmark says it's fast.)
Is it fair in the comparison? Nope. Comparing oranges with apples is always bad. The question however is whether you want an Apple or an Orange?
TechEmpower has to be read like that: plaintext ensures the HTTP server stack and the base runtime. Json is about json encoding and emitting. Single query and multiple query about streaming data through. The benchmark is gradually testing your platform. .NET Core was bad at Plaintext. Now they are top 10. Now they realized the default json library (Newtonsoft.Json) of .NET is very nice but too slow. So they built a new one (System.Text.Json). Now the PostgreSQL Driver sucks. So they find and support the driver project. Like that you built a platform which is top notch.
I think you confused "single query" with "single request". The goal of the benchmark is to make one query to the DB per request. The number of requests (clients) is in the hundreds of thousands.
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.
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.
Basically, groups of functions are consistent: string,array etc. Their parameter order was usually based on whatever the underlying C API was.
I had to explain to my fellow non-IT students why I was making loud gasps of confusion.
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.
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.
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.
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.
(Btw I love react and use it in any serious project... but each to definitely has its place)
Totally different than server-side coding.
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 tools you mentioned are common for frontend frameworks and such.
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).
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.
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.
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');
// jQuery
const nextElement = $('#wrap').next();
// Vanilla
const nextElement = document.querySelector('wrap').nextSibling;
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;
I get that not everyone prefers that. That's OK.
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
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);
// jQuery
$(parent).append(el);
// Vanilla JS
parent.appendChild(el);
// jQuery
$(el).css('color', 'black');
// Vanilla JS
el.style.color = 'black';
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()
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.
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
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 ;-)
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.
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.
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.
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.
> 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
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.
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.)
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.
I don't think who has had a serious look at PHP would call it a joke these days.
Most developers seem to like them (brevity, locational grouping of concerns), so they tend to get treated as a default, but they're not the only option or the only one treated as a first-class choice. Like much of new-PHP, this also seems to be something largely borrowed from the Java world, it's hardly something new or invented by PHP.
unless you've got CPU bound PHP code... it seems like a complete waste of effort
Edit: to clarify, PHP processes in fastcgi persist across multiple web requests. So seems reasonable to me that a JIT would do useful work here. The JIT could even run while the PHP process in a fastcgi pool is idle waiting for next job.
Well, this is where the chaff separates from the wheat. There's no small amount of crappy code out there which will WSOD after this. Or actually print the exception because they couldn't even bother to switch display errors on... Of course, no even remotely sane codebase will be affected, but... Make no mistake, this is a good change but it will cause some teeth gnashing.
But I will not be surprised to see some people say things like “PHP 8 broke my code”. Of course, what those people might not realize is that PHP 8 did not break their code, the code was always broken, and PHP 8 is now going to surface the brokenness of that code.
But even with code that people refuse to fix, this sort of change will make the brokenness of that code more apparent to others, and so the number of people that use that broken code will cease to grow. If not entirely, then at least reduce in pace of growth.
That is good for the ecosystem of computing. As a proponent of correctness in computing, this makes me happy :)
We all write bugs, but everything our tools and languages of choice can do to help us reduce the number of bugs and the severity (impact on security) of our bugs, the better.
Personally, I think a lot of these design decisions which some people abhor is why PHP became popular in the first place. In that perspective, turning it into yet another "big bureaucratic language" is very much against the spirit of its existence.
To stop the warnings, configuration would need to be changed in PHP config, or those warnings be silenced by the developer.
Any decent webapp has had this issues resolved a long time ago.
I would suggest that websites that will be effected probably will not migrate to PHP 8 that quickly.
But there are a million questions on the internet about this 'error'. And the answer is almost always: turn the errors off.
And I believe this is the biggest problem with PHP. A lot of inexperienced users with questions that get very bad answers.
For a development and staging website you do want notices and warnings displayed. For a production website possibly only when testing something.
Just SSH in and tail the log. Dealing with unexpected output from errors clobbering your headers isn't worth the trouble.
You can also try something like FirePHP [0] if you need the errors in the context of the current page.
Undefined variables will now be warnings (and one might expect PHP 9 to reclassify them as exceptions).
Interesting. There are still some legitimate (well, “legitimate”) use cases for that behavior e.g. with PHP’s native XML extensions.
However you could just catch Exception. Not sure why a parse error is a "Fatal error".
A xml parsing error in the SimpleXmlElement constructor is not a fatal error - it throws an exception.
An uncaught exception is a fatal error.
This is amazing to see. So many languages these days agree that functions are good. Now they're all adding type systems of one sort or another.
PHP has always been a bit behind the curve but good on the developers for pulling in a cool feature like this.
## Union types
Specify multiple types
public function foo(Foo|Bar $input): int|float;
Just in time compiler for improved performance
## Static return type
Return static of class
class Foo
{
public function test(): static
{
return new static();
}
}
Prevent blocking of garbage collection for improved memory usage when needed
private WeakMap $cache;
Get class type from object like get_class($object)
$foo = new Foo();
var_dump($foo::class);
When you don't care about division by zero
fdiv($x,0);
Math takes precedence in string concatenation.
// this
echo "sum: " . $a + $b;
// evaluated as this
echo "sum: " . ($a + $b);
- Create DateTime objects from interface
- Type annotations for internal functions
- Variable syntax tweaks
- Breaking changes
- Consistent type errors
- Reclassified engine warnings
- Reflection method signature changes
* Note: HN pretty please get improved mark down parsing
Things I remember I didn't like about/around PHP:
- too many aspects of the language were dependent on config/php.ini.
- it had errors and exceptions. I just wanted exceptions.
- was not very interesting/useful/great outside web backend.
- mb_* functions were not enabled by default
- it had no decent REPL.
- "reference" libraries had bad APIs or were over-engineered.
I'm not sure about the state of these issues now, but frankly I never felt the need to look back. Good to hear there's still progress though.
It makes doing functional stuff in PHP a lot of fun.
PHP evolved significantly since version 4. Version 5 was the "big" deal, with good object oriented features. Version 7 brought the performance in, so we could get rid of Facebook's crappy HHVM (thank you PHP team). Version 8 brings JIT, however most of the workload isn't CPU bound but I/O bound.
So, here's something for PHP devs:
Swoole. http://www.swoole.co.uk -> this is an extension for PHP which brings in the same primitives available to people using Node.js or Golang - coroutines, async I/O, channels, event loop control and much more.
What it essentially does is turn ALL I/O from synchronous to asynchronous. Without any code change or control structure in form of async/await or promises. Write synchronous code, get asynchronous performance.
From my own experience (I've been running swoole in production for 18 months), the performance gain I saw was minimum 500% to a maximum of 2000% (the numbers aren't a joke).
As for PHP - it's a programming language. You can use it right or you can use it badly. This rule applies to almost any language. There's no language in this universe that can turn a bad programmer into semi-ok programmer or even good programmer. If you haven't got the habits and knowledge, there's no language that can rectify it. I've seen way too many people thinking the language of their choice is to blame, but it was always the person in the chair.
PHP performs well. Ecosystem is quite large and luckily there aren't competing standards. Composer, the package manager, is wonderful. There's plenty of frameworks to choose - for web and for CLI usage. Features are being added, slowly but steadily.
I use PHP with Laravel + nginx, next to Nuxt + Vuetify + TypeScript for frontend stuff. Personally, I really like how the mentioned tech can be utilized to create great apps fast - with structured code, that look good and work quick.
Edit: one of the best and most powerful features in PHP (starting with 7.4) is the FFI - foreign function interface. The option to utilize libraries or entire software, without the need to write PHP extensions, is what's amazing for me (I also need it due to nature of my work).
PHP is way more powerful than people give it credit for. But I guess that's what happens when opinions are formed by looking at titles and number of "likes" or other meaningless numbers designed to mislead.
There is also a complete application server that supports php servlets, message queue, persistence etc. that is well-supported. Its free, open source.
A team that supports Magento, Typo etc. based in Germany wrote it.
You can use either the PHP-FPM or the more interesting is the servlets, because the data is kept in-memory - probably much in the same way as swoole functions.
Its basically enterprise Java for PHP.
Swoole is entirely different beast, it's like comparing a skateboard (appserver) to intergalactic starship (swoole). It's not just about the performance as it is about exposing OS primitives and having fine control over I/O and processes.
Excellent find, but luckily - the current tools we've got at our disposal are even better. No offense to people using or working on appserver, some projects are just that - toys that help people learn more.
Having input from you with production experience of Swoole would be _fantastic_.
I always assumed that HHVM is what brought JITs to PHP originally, followed by PHP itself.
I just hope the core maintainers evaluate true async/await constructs for PHP. I also hope that the JIT leads to more significant advancement in PHP and how it manages memory. For all it’s improvements it’s still really prone to memory leaks easily
Coroutines would also be a genuine improvement
Its not trivial to just upend an entire system.
Many of the latest RFCs accepted (while I agree are great steps forward for the language) may actually reduce it's foothold going forward. That is, they are not a good fit for the community. I see no compelling reason to choose PHP for a greenfield project if, when used in a production environment with a stable framework, you are writing essentially the same code as you would for Java/C#. There is hardly a feature where an ASP.NET core C# project isn't still miles ahead of the same Symphony/Laravel back-end. Hell, with the new Razor-Pages template, you are essentially writing "PHP" in C#... where you get all of the bells, whistles, helpers, type-checking, generics, pattern matching, LINQ etc that C# already offers!
IMO (emphasis on the "O") they are missing the point. I don't want my PHP application to "look" just like a Java/C# app. I don't want a `Controllers` directory and `RepositoryInterface`s everywhere... I don't want all of the same ceremony it takes to develop a .NET Core/Spring app copied into PHP. What I want is a composition of "scripts" (functions)!
PHP should focus on and develop towards it's strengths not it's weaknesses. Lean in to include. Lean in to $GLOBALS. Lean in to a more functional approach. These are the things that have made PHP so dead-simple/approachable over the years.
You want more features? Fine. Add pre-processing directives (akin to .razor). Allow for files to truly be treated as modules. Simplify/abstract templating into the language better. That is, instead of focusing on the kinds of "features" that better-enable OOP (and move away from a composition of "scripts"), focus on making it easier/better to compose "scripts". Make _that_ safer, clearer, more ergonomic. There are _plenty_ of ways to dramatically improve PHP (as a platform) without simply updating the language semantics. The language was _never_ the draw!
As many of the comments in this thread indicate/imply, PHP isn't chosen because it is such a great language, rather, it is chosen because it offers an extremely convenient development paradigm. PHP is very-much "batteries included" when compared to its contemporaries[0]. _This_ is why people reach for it over and over again. So instead of changing the vehicle (PHP), how about we give it more/better batteries instead?
/devil's advocate
How'd I do?
[0] I have always found the whole "framework vs raw PHP" debate in the community a bit humorous. The "framework" crowd never seems to really understand that, in many ways, raw PHP is a framework. What other scripting languages automatically parse HTTP requests for you as part of the runtime? Or come with a default "routing" scheme? Or offer built-in templating semantics? PHP gives you all three out of the box.
T|null
function foo(string $bar = null): void
function foo(?string $bar): void
function add(string $a, string$b){}
function add(int $a, int $b){}The code looks similar to Java code, how classes are constructed, extra type modifiers, type access levels etc.
That seems like a nonsensical litmus test.
I personally don't see anything wrong with it, but it does resemble Java to me.
More languages really need to adopt union types.
Let's dissect your post a bit: you had to google how to send GET/POST/PUT TO PHP or FROM PHP? Regardless, PHP doesn't care what you send it, you can send JSON or base64 encoded string. It's completely irrelevant. If you used PHP for 3 years and are unaware of basic HTTP communication - how's PHP to be at fault here? The real problem here is that you imagined something, it didn't work like you wanted it to and the next logical step is to blame the language. This is such a bad way of thinking, I genuinely feel sorry for you.
I could pull several projects that deal with input via HTTP in PHP, and they do it more than nicely. Issue is that you're simply - mediocre. And there's no language that can fix it. Btw. my intent is not to insult you, even a mediocre programmer can become a superstar.
- Create a .htaccess file that rewrites /api/x/y/z to /api/index.php/x/y/z
- Read $_SERVER['PATH_INFO'] for the /x/y/z
- Read $_SERVER['REQUEST_INFO'] for the HTTP method (GET/POST/etc)
- Create the response starting with some calls to `header()`
- 'echo json_encode($resp);'
That's it. It's not a lot. They're 2 super simple arrays.
PHP can also work from command line where $_REQUEST/$_POST/$_GET are unavailable. You can also entirely ignore the existence of the above variables. You can read from standard input and treat input as JSON - options are endless. This merely means that the example shown is not entirely correct - it's not "how it works in PHP". It's merely one of the ways. But the real problem is: no one bothered to research it and you blindly assumed that's how it works.
Laravel (Http/Kernel library) standardized the interface towards the dev and that's great. But the input itself isn't as tied to PHP core as your comment makes it seem.
It saves a lot of typing when I have to trace brackets after auto completion to add the semicolon instead moving to the next line.
In all other places it isn't necessary anymore.
They don't insert the semicolons automatically as it can't tell if it's the end of line or I'm about to invoke a chained method etc.
Not sure what the down votes are about as it literally increases 2 to 3 letters of extra typing just to append the semicolon after auto completion.
> In JavaScript the automatic semicolon insertion is almost universally reviled.
Why? There's literally no need except on a rare occasion. My IDE happily gets rid of JS semicolons and it's far easier to type.
Ruby and Python don't need one. Just feels tedious compared to other scripting languages.