The PHP I’ve once used is probably not even remotely close to the PHP people use today. The issue is, once you lose the trust and confidence, it’s hard to gain it back. All the people who consistently shit on PHP have also probably not tried it in a very considerable amount of time
Languages don’t die. That’s a misnomer. They have long tails of diminishing use and no junior programmers entering the space. If you’re one of the experts in the language left around, you can make a shit load of money.
And the jobs are rarely worth the stress of picking apart the terribly designed, chock full BizDev rushed ads-on features due to foolish promises, and a manager that’s stressed out due to how few experts they’re are that’s going to try and micro-manage you because his skip-level is breathing down his neck about when something is going to be fixed.
This was nearly a decade ago. I worked at a small app company (5-10 developers) for a bit that used Ruby on Rails for our product. The product was in active development, but was available to customers so it was “done”. We were hiring a senior level dev to oversee the team and we interviewed this guy (maybe in his 40s?, a but older than most people in tech) and he said his first order of business if hired would be to refactor the entire code base to php. I don’t think he was joking. I’m not sure why he interviewed.
Since the beginning, GitHub.com has been a Ruby on Rails monolith. Today, the application is nearly two million lines of code and more than 1,000 engineers collaborate on it daily
django and flask are python btw and people wanted to learn python or perl from like 15 years ago, the popularity of python 2 and its “Issues” led to robust dev on python 3, not to mention it being a default for many linux distros since a long time ago
Were people saying PHP was dead in 1995, the year it was released? I guess maybe?
But who was suggesting abandoning PHP for Django in 2003, two years before the latter was publicly released? I suppose the person who made this must’ve read that Django development started in 2003 and gone with that; most of these years correspond with when the respective project started.
So, the reason Perl (which remained more popular for web development than PHP or any of these things into the early 2000s) isn’t on the list must be because it actually predates PHP.
It’s hard to justify using anything other than JS or if you wanna be fancy, Web Assbly, for the FE.
Any other front end language involves generating Javascript from your language, which inevitably ends up with you making a weird Frankenstein project that mixes the two.
I’d rather just use stuff like Webpack or Vite to compile my JS front-end out of JS (or TS) from the start. It always ends up being a cleaner result.
My backend though can be whatever the fuck I want it to be.
But if you ever think dynamically compiling/transpiling a JS front end on the fly on demand is a good idea, instead of simply just delivering static pre-compiled/transpiled pages, you’re part of the problem for why the web is so slow and bloated.
It’s wild how crazy of projects people will build that take 3 entire seconds to just deliver a 500kb static form that doesn’t even need angular to do anything. They turn a couple hundred kb into several mb for no useful reason, it’s wild.
I find that the only reason for SSR existence is to be able to just move a JS frontend to the backend for SEO/client performonce reasons with almost no effort. If the frontend really needs to be highly interactive then yeah, a FE framework makes things easier. But then you are locking yourself to using JS in the backend. Voluntarily locking yourself to use an objectively bad language.
Then there are the react/angular/other people, who build everything in these frontends.
I really hope tools like htmx gain traction, since it looks like a model able to solve the current JS madness.
I’m not liking htmx, I checked it out, it seemed promising, but it has giant gaping security holes in it so I can’t endorse it.
I have been sticking to using Ejs with html-bundler-webpack
The combo is lightning fast and gives me a solid usability of html partials so I can modularize my front end in re-useable chunks.
It compiles to the static site fast for iterative development, it has everything I need baked in for common needs (minification, bundling, transpiling, cache busting, integrity, crossorigin, tree shaking, etc etx)
I like how it let’s me just focus on actually writing the html + js + css and not have to muck around with thirty boilerplate steps to just make the app run.
If I need a lot of reactivity I’ll use vue or angular but I so so rarely need that.
And now with the template element, half the time reactivity can just be done with those.
Only time I actually need react/vue is when I have to frequently mutate/delete in the DOM.
But if I purely am additive, adding things to the DOM, template elements are plenty.
Could you elaborate on the htmx security holes? I only know about xss attacks, and for those it’s trivial to sanitize in the backend.
I too gravitate towards just templating for static or simple interactivity, but for pages that need SEO and interactivity I’m still wondering what’s a good solution that doesn’t involve SSR and a js framework. For a recent project I had I generated the html in php and sent a lot of pure js for dom manipulation
Htmx has a bunch of logic that basically completely bypasses Content Security Policy stuff, as it has its own pseudo baked in “execute inline js” logic that executes arbitrary javascript via attributes on html elements.
Since this gets executed by the HTMX logic you load in from their library, it effectively allows an attacker to arbitrarily execute js via manipulating the DOM, and Content Security Policy won’t pick it up because HTMX parses the attribute and executes on behalf of it (and you have already whitelisted HTMX in your CSP for it to function)
Result: It punctures a giant hole in your CSP, rendering it useless.
There’s technically a flag you can flip to disable this functionality, but its via the dom so… not reliable imo. If I could pre-compile HTMX ahead of time with that functionality completely disabled to the degree it doesnt even get compiled into the output .js at all, then I would trust it.
But the fact all the logic is still technically there in the library I have loaded and I am purely relying on “this flag in the dom should block this from working, probably”, I don’t see that as very secure.
So until that gets fixed and I can compile htmx with webpack or vite in order to completely treeshake that functionality right the hell out of my output, I aint gonna recommend anyone use it if they want an iota of security on their site. It’s got literally baked in security bypasses, don’t use it.
Hell Id even just be happy if they released a “htmx-lite” package I could use, that just doesnt have that functionality baked in, thatd be enough to make me consider it.
To my understanding, you can’t really use WebAssembly for the frontend - it doesn’t support manipulating the DOM, so you still need to offload a lot of the work to JS. It’s an uncontested language when it comes to web frontend.
It does support it, it’s just slower than JS. WA is faster in other aspects though, so frameworks that compile to WA (like the Rust framework Leptos) still end up being faster than a lot of JS ones.
But yeah, I mostly blame the project managers that encourage this behavior, it’s wild how much overengineering goes into basic stuff like making mostly static websites.
Same, plain old HTML, and if I need some reactivity then Stimulus. And if need even more reactivity, then VueJS / Alpine. If the form can’t be submitted via a regular submit button, it infuriates me.
Not sure if it was the first, but PHP still beats a lot of other “platforms/framework” because thats what some of these items on the list are in terms of ease of embedding code directly into what you see what you get frontend code (HTML). It inserts backend code into HTML like javascript and that was very convenient and easy to learn, still easier than figuring out some of these platforms different templating shortcodes, that and its constant development and community support. I used to live on the PHP docs comments… it was a great community.
That’s possible with some java frameworks, no? The “insert code into the html file”? I remember doing that in college (~2010), but I don’t remember the framework we used
Honestly, despite my experience in standalone programming and algorithms, my experience in web development is limited. I’ve had experience with ASP dot NET, Actix (Rust framework Lemmy is powered by) with Diesel ORM, and PHP. ASP is limited in .NET ecosystem, and the primary IDE to develop ASP dot NET apps is proprietary, not something I want to work with. Actix is doing pretty good, it uses Tokio internally, one of the fastest and most robust async frameworks in the wild. I’ve been using Rust for more than 2 years, and I’d be honest: it was designed for medium- and large-scale application development. For making prototypes, you probably want another programming language. And I see PHP as one of the easiest ways to prototype.
For Django, I’ve never used it, maybe I’ll have to use someday. Nevertheless, I see Python as a rather bloated (in terms of overlapping language features) language which suffers from similar problems as PHP, like no type checking (by default). Also, Python packages are tied to some exact version of Python, which causes a large dependency mess when using multiple packages (Rust also has this problem, but at much smaller scale, and developers of packages often use conditional compiling of language features). Meanwhile, I think that some Python problems could be resolved using a package manifest file, like Rust does.
If you have something to add, go on, because I’m always thinking what server language/framework I should use for my Next Big ProjectTM.
On the server-side PHP is used by 76.8% of all websites (a large chunk of that being WordPress). It is not going anywhere, soon. Looking at this statistics, nothing else seems to be even in the same league from a pure usage point of view.
I have yet to see a reason why it should change. Serious question: What is the disadvantage of using the tried and tested PHP8 compared to the alternatives, if you already know PHP?
Serious Answer: PHP in itself is not that bad, despite some discussable decisions in function naming and arguments order to name a few. The biggest problem, is that it has a settings file describing how it works (php.ini) and that sh*t will bite you in the rear when you move apps from server to server, where all the libs are different etc…
PHP never works out of the box when moving something on a new server, that is the worst part of the language.
Maybe the issue in your example isn’t related to “how bad PHP is” but is to “how bad the code you’re referring to is”. Never had those kind of issues and yes obviously you’ve to know what extensions an application is using, but once again, modern PHP applications usually use composer as dependency manager and will gave those specified inside the project.
Good on you to not have to maintain legacy code (15years+).
Also, as a comparison, with JAVA, I have a legacy JAVA 1.5 to maintain, as far as you have the runtime, that stuff works, and that’s it. This is how it should be.
Easy example. Have they fixed file upload behavior yet? Do they store the entire file in memory by default instead of chunking it and storing it as it comes in?
If not it’s like the worst memory usage of any language possible.
If you have to go change the php.ini to adjust file upload sizes, it’s not really moving forward and is decades behind other languages.
Easy example. Have they fixed file upload behavior yet? Do they store the entire file in memory by default instead of chunking it and storing it as it comes in?
Are you in 1995? PHP dynamically decides how to manage uploaded files, it will generally store a few MB on RAM and move it to disk after that point. It also support streams so the backend can take the incoming data live and do stuff with it without storing it first as usual in the classical model. There are also plenty of higher level solutions to deal with chunked uploads, mobile clients disconnecting such as https://tus.io/ that are used by large companies like Vimeo.
File upload behavior is actually determined by your web server (unless you’re launching PHP in listening mode) so apache is probably who you want to blame here.
Other languages behind reverse proxies from apache httpd or nginx do not have the same memory hit. You can still blame php. Not my fault they tied their language to the webserver in a way that uses tons of extra memory.
Poor performance, execution model limitations, lack of static typing (although they seem to be working on that), and general legacy cruft.
Don’t compare PHP to Node, Ruby or Python, they also have problems. I think Go is currently the best choice for a web backend; an objective evaluation of PHP and Go would certainly put Go ahead. If you know PHP, you can pick up Go in a day or two, so I don’t think that’s a great reason to keep using PHP either.
Usage statistics are a highly misleading, software projects take several years to develop and a majority will fail. Looking at current usage tells you the most popular choice from 5 years ago, not today. Over 90% of video games published in the last 5-10 years use Unity or UE4, but these probably aren’t the best choices today.
I think Go is currently the best choice for a web backend; an objective evaluation of PHP and Go would certainly put Go ahead. If
Yes for performance running code, for performance as in “developer time” PHP is way faster. Go is solid but developer take more time implementing stuff with it. Use PHP for everything business related except for that one or two cases where you really need the performance that Go provides and where it is worth the extra dev time.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
The PHP I’ve once used is probably not even remotely close to the PHP people use today. The issue is, once you lose the trust and confidence, it’s hard to gain it back. All the people who consistently shit on PHP have also probably not tried it in a very considerable amount of time
2023 is the year qbasic comes back i can feel it
I used to think the same about Perl, PHP is not dead because it needs someone to kill it, but I think it won’t gonna happen
Languages don’t die. That’s a misnomer. They have long tails of diminishing use and no junior programmers entering the space. If you’re one of the experts in the language left around, you can make a shit load of money.
And the jobs are rarely worth the stress of picking apart the terribly designed, chock full BizDev rushed ads-on features due to foolish promises, and a manager that’s stressed out due to how few experts they’re are that’s going to try and micro-manage you because his skip-level is breathing down his neck about when something is going to be fixed.
No thanks, not again.
This was nearly a decade ago. I worked at a small app company (5-10 developers) for a bit that used Ruby on Rails for our product. The product was in active development, but was available to customers so it was “done”. We were hiring a senior level dev to oversee the team and we interviewed this guy (maybe in his 40s?, a but older than most people in tech) and he said his first order of business if hired would be to refactor the entire code base to php. I don’t think he was joking. I’m not sure why he interviewed.
Is there anything serious still running on a Ruby codebase nowadays? In PHP however…
Isn’t Mastodon Ruby?
GitLab is Ruby at least, I don’t immediately remember any others but there probably are some
Github too or a least when you look at the github enterprises source code
What can they do tho?
Does Redmine count as serious?
Only people supporting legacy regret.
Ruby was never good. It just got memed enough to make it way into some medium business
I know of a bunch of less famous ones, but those are a few of the bigger ones that I’m aware of.
django and flask are python btw and people wanted to learn python or perl from like 15 years ago, the popularity of python 2 and its “Issues” led to robust dev on python 3, not to mention it being a default for many linux distros since a long time ago
This is an irritating meme.
Were people saying PHP was dead in 1995, the year it was released? I guess maybe?
But who was suggesting abandoning PHP for Django in 2003, two years before the latter was publicly released? I suppose the person who made this must’ve read that Django development started in 2003 and gone with that; most of these years correspond with when the respective project started.
So, the reason Perl (which remained more popular for web development than PHP or any of these things into the early 2000s) isn’t on the list must be because it actually predates PHP.
But then what is up with Python in 2022?
I also appreciate that you’re supposed to learn Django 19 years before you learn Python.
Flask too
Yeah, plus PHP was very popular circa 2011-2016 and laravel was loved by many around that time and beyond. It’s always been a useful language.
It’s hard to justify using anything other than JS or if you wanna be fancy, Web Assbly, for the FE.
Any other front end language involves generating Javascript from your language, which inevitably ends up with you making a weird Frankenstein project that mixes the two.
I’d rather just use stuff like Webpack or Vite to compile my JS front-end out of JS (or TS) from the start. It always ends up being a cleaner result.
My backend though can be whatever the fuck I want it to be.
But if you ever think dynamically compiling/transpiling a JS front end on the fly on demand is a good idea, instead of simply just delivering static pre-compiled/transpiled pages, you’re part of the problem for why the web is so slow and bloated.
It’s wild how crazy of projects people will build that take 3 entire seconds to just deliver a 500kb static form that doesn’t even need angular to do anything. They turn a couple hundred kb into several mb for no useful reason, it’s wild.
I find that the only reason for SSR existence is to be able to just move a JS frontend to the backend for SEO/client performonce reasons with almost no effort. If the frontend really needs to be highly interactive then yeah, a FE framework makes things easier. But then you are locking yourself to using JS in the backend. Voluntarily locking yourself to use an objectively bad language.
Then there are the react/angular/other people, who build everything in these frontends.
I really hope tools like htmx gain traction, since it looks like a model able to solve the current JS madness.
I’m not liking htmx, I checked it out, it seemed promising, but it has giant gaping security holes in it so I can’t endorse it.
I have been sticking to using Ejs with html-bundler-webpack
The combo is lightning fast and gives me a solid usability of html partials so I can modularize my front end in re-useable chunks.
It compiles to the static site fast for iterative development, it has everything I need baked in for common needs (minification, bundling, transpiling, cache busting, integrity, crossorigin, tree shaking, etc etx)
I like how it let’s me just focus on actually writing the html + js + css and not have to muck around with thirty boilerplate steps to just make the app run.
If I need a lot of reactivity I’ll use vue or angular but I so so rarely need that.
And now with the template element, half the time reactivity can just be done with those.
Only time I actually need react/vue is when I have to frequently mutate/delete in the DOM.
But if I purely am additive, adding things to the DOM, template elements are plenty.
Could you elaborate on the htmx security holes? I only know about xss attacks, and for those it’s trivial to sanitize in the backend.
I too gravitate towards just templating for static or simple interactivity, but for pages that need SEO and interactivity I’m still wondering what’s a good solution that doesn’t involve SSR and a js framework. For a recent project I had I generated the html in php and sent a lot of pure js for dom manipulation
Htmx has a bunch of logic that basically completely bypasses Content Security Policy stuff, as it has its own pseudo baked in “execute inline js” logic that executes arbitrary javascript via attributes on html elements.
Since this gets executed by the HTMX logic you load in from their library, it effectively allows an attacker to arbitrarily execute js via manipulating the DOM, and Content Security Policy won’t pick it up because HTMX parses the attribute and executes on behalf of it (and you have already whitelisted HTMX in your CSP for it to function)
Result: It punctures a giant hole in your CSP, rendering it useless.
There’s technically a flag you can flip to disable this functionality, but its via the dom so… not reliable imo. If I could pre-compile HTMX ahead of time with that functionality completely disabled to the degree it doesnt even get compiled into the output .js at all, then I would trust it.
But the fact all the logic is still technically there in the library I have loaded and I am purely relying on “this flag in the dom should block this from working, probably”, I don’t see that as very secure.
So until that gets fixed and I can compile htmx with webpack or vite in order to completely treeshake that functionality right the hell out of my output, I aint gonna recommend anyone use it if they want an iota of security on their site. It’s got literally baked in security bypasses, don’t use it.
Hell Id even just be happy if they released a “htmx-lite” package I could use, that just doesnt have that functionality baked in, thatd be enough to make me consider it.
To my understanding, you can’t really use WebAssembly for the frontend - it doesn’t support manipulating the DOM, so you still need to offload a lot of the work to JS. It’s an uncontested language when it comes to web frontend.
It does support it, it’s just slower than JS. WA is faster in other aspects though, so frameworks that compile to WA (like the Rust framework Leptos) still end up being faster than a lot of JS ones.
On that last bit. I agree with you, but people are getting paid to produce, and since they probably just know angular, they use angular everywhere.
I prefer html personally :x
But yeah, I mostly blame the project managers that encourage this behavior, it’s wild how much overengineering goes into basic stuff like making mostly static websites.
Same, plain old HTML, and if I need some reactivity then Stimulus. And if need even more reactivity, then VueJS / Alpine. If the form can’t be submitted via a regular submit button, it infuriates me.
Not sure if it was the first, but PHP still beats a lot of other “platforms/framework” because thats what some of these items on the list are in terms of ease of embedding code directly into what you see what you get frontend code (HTML). It inserts backend code into HTML like javascript and that was very convenient and easy to learn, still easier than figuring out some of these platforms different templating shortcodes, that and its constant development and community support. I used to live on the PHP docs comments… it was a great community.
That’s possible with some java frameworks, no? The “insert code into the html file”? I remember doing that in college (~2010), but I don’t remember the framework we used
Javascript, perhaps?
No, it was something that used JSP (java server pages), you didn’t use a single line of javascript. Maybe it was pure JSP, I don’t remember, really.
Eww
Honestly, despite my experience in standalone programming and algorithms, my experience in web development is limited. I’ve had experience with ASP dot NET, Actix (Rust framework Lemmy is powered by) with Diesel ORM, and PHP. ASP is limited in .NET ecosystem, and the primary IDE to develop ASP dot NET apps is proprietary, not something I want to work with. Actix is doing pretty good, it uses Tokio internally, one of the fastest and most robust async frameworks in the wild. I’ve been using Rust for more than 2 years, and I’d be honest: it was designed for medium- and large-scale application development. For making prototypes, you probably want another programming language. And I see PHP as one of the easiest ways to prototype.
For Django, I’ve never used it, maybe I’ll have to use someday. Nevertheless, I see Python as a rather bloated (in terms of overlapping language features) language which suffers from similar problems as PHP, like no type checking (by default). Also, Python packages are tied to some exact version of Python, which causes a large dependency mess when using multiple packages (Rust also has this problem, but at much smaller scale, and developers of packages often use conditional compiling of language features). Meanwhile, I think that some Python problems could be resolved using a package manifest file, like Rust does.
If you have something to add, go on, because I’m always thinking what server language/framework I should use for my Next Big ProjectTM.
I personally like Axum over Actix, less macros and more clever trait magic.
Who said that, exactly?
The dude trying to push Django in 2003
This year is finally the year of Python, I can feel it!
I’ve been waiting so long for people to realize they should be using the second best language at everything.
https://w3techs.com/technologies/overview/programming_language
On the server-side PHP is used by 76.8% of all websites (a large chunk of that being WordPress). It is not going anywhere, soon. Looking at this statistics, nothing else seems to be even in the same league from a pure usage point of view.
I have yet to see a reason why it should change. Serious question: What is the disadvantage of using the tried and tested PHP8 compared to the alternatives, if you already know PHP?
Serious Answer: PHP in itself is not that bad, despite some discussable decisions in function naming and arguments order to name a few. The biggest problem, is that it has a settings file describing how it works (php.ini) and that sh*t will bite you in the rear when you move apps from server to server, where all the libs are different etc… PHP never works out of the box when moving something on a new server, that is the worst part of the language.
Maybe the issue in your example isn’t related to “how bad PHP is” but is to “how bad the code you’re referring to is”. Never had those kind of issues and yes obviously you’ve to know what extensions an application is using, but once again, modern PHP applications usually use composer as dependency manager and will gave those specified inside the project.
Good on you to not have to maintain legacy code (15years+). Also, as a comparison, with JAVA, I have a legacy JAVA 1.5 to maintain, as far as you have the runtime, that stuff works, and that’s it. This is how it should be.
I do, the difference is that, unlike Ruby code bases, it happens to be supported languages that evolved and perform better today.
Easy example. Have they fixed file upload behavior yet? Do they store the entire file in memory by default instead of chunking it and storing it as it comes in?
If not it’s like the worst memory usage of any language possible.
If you have to go change the php.ini to adjust file upload sizes, it’s not really moving forward and is decades behind other languages.
Are you in 1995? PHP dynamically decides how to manage uploaded files, it will generally store a few MB on RAM and move it to disk after that point. It also support streams so the backend can take the incoming data live and do stuff with it without storing it first as usual in the classical model. There are also plenty of higher level solutions to deal with chunked uploads, mobile clients disconnecting such as https://tus.io/ that are used by large companies like Vimeo.
Most new PHP apps I know implement chunked uploads themselves
File upload behavior is actually determined by your web server (unless you’re launching PHP in listening mode) so apache is probably who you want to blame here.
Other languages behind reverse proxies from apache httpd or nginx do not have the same memory hit. You can still blame php. Not my fault they tied their language to the webserver in a way that uses tons of extra memory.
Poor performance, execution model limitations, lack of static typing (although they seem to be working on that), and general legacy cruft.
Don’t compare PHP to Node, Ruby or Python, they also have problems. I think Go is currently the best choice for a web backend; an objective evaluation of PHP and Go would certainly put Go ahead. If you know PHP, you can pick up Go in a day or two, so I don’t think that’s a great reason to keep using PHP either.
Usage statistics are a highly misleading, software projects take several years to develop and a majority will fail. Looking at current usage tells you the most popular choice from 5 years ago, not today. Over 90% of video games published in the last 5-10 years use Unity or UE4, but these probably aren’t the best choices today.
Yes for performance running code, for performance as in “developer time” PHP is way faster. Go is solid but developer take more time implementing stuff with it. Use PHP for everything business related except for that one or two cases where you really need the performance that Go provides and where it is worth the extra dev time.
Symfony, Laravel & other PHP based frameworks are going strong. PHP isn’t going away anytime soon.
PHP is dead, learn javascr… no
Yowch, Django was 20 years ago? That hurts.
It shouldn’t hurt at all IMO
It’s still a very mature framework, works with client side apps via DRF if that’s your thing, and has only gotten more quality of life improvements.
There’s things to be desired especially with async but IMO old != bad
Also the last one is “learn python” which… Django is python…
There are two kind of programming languages: