5 seconds per request isn't anything to shout about in 2023.
Go with PHP
191–200 of 532 posts
Re: Go with PHP
#192Isn't it too much "string oriented"?
Re: Go with PHP
#193> There is no need to compile anything. But I really like compilers, they catch a whole class of bugs, before I run things.
Unit testing
Unit testing is a poor mans compiler. Our medium size rails app has 40,000 unit tests and constantly we have issues where an updated library changed the name or parameters of a method without warning causing breakages.
Re: Go with PHP
#194I was expecting something about Go.
Me too. Some kind of weird Frankenstein of Go mixed with PHP.
Also Roadrunner https://roadrunner.dev/
Re: Go with PHP
#195Also: lets not forget one very important and under-rated side-effect of PHP -- it lets you write server-side code that can leverage a 'public' address. You might think 'well, doesn't everything let me do that?' Not quite. On 'free' VPS servers they usually have 'ephemeral' IPs or IPs that change. So while you get free bandwidth and compute -- it's hard to actually do anything useful with it like run a service if you…
Being able to host for free on dodgy free hosting is hardly a benefit anyone should care about.
Re: Go with PHP
#196I see no argument at all for using Laravel over Django or Rails. PHP was always a mess. Why would I want to come back to it now on the off chance they don't screw things up again?
Exactly. array_filter and array_map, have different order of arguments. ($array, $callback) vs ($callback, $array) A small example of how inconsistent the language is from the ground up. Most people can explain their respective web servers, but I've never heard anyone even come close to what PHP/Laravel is actually "doing". Side Complaint: If you are working with Laravel Queue, it is such a hassle to reload your code…
Yeah, but these things exist across languages. Laravel has collection methods that fix that and they can be used in any php project too.
Re: Go with PHP
#197The problem is this page advertises Laravel, not PHP. Ruby on Rails has many similar "demo worthy" snippets that make complex tasks seem readable and intuitive to the layman. Laravel and Ruby on Rails have something else in common: due to the focus on these "natural" interfaces, they compromise in every other way. Architecture, performance, testability and so on and so on. For those who know PHP, this code is full of…
Making "complex tasks seem readable and intuitive to the layman" is no bad thing - besides other engineers, future you could become a 'layman' easily. Readable, expressive code is something I've come to value highly after almost 20 years And from first-hand experience, while the specific code sample shown on this page shouldn't be treated as a practical example of how to architect a larger application, there's nothin…
I guess I wasn't clear enough? I said "it makes complex tasks SEEM". My point being, they SEEM SIMPLE in a DEMO. But in real application it quickly turns into a quagmire, due to the problems I already listed.
Oh look, you even say so in your own comment: "the specific code sample shown on this page shouldn't be treated as a practical example".
So... you're saying the page makes it SEEM simpler than IT IS, hmm? Is this what you were asking me about "why is it bad"? You don't think parlor tricks in demo code is a bad thing?
So what are you even objecting to here? I said something bad about Laravel, and you use Laravel, so you have to go on the offensive out of loyalty? I don't know why people need to identify so religiously with their tools. If we start picking apart this demo code, you'll probably admit that every line contains an anti-pattern you'd avoid in a real project of more than a modest size.
So what is this demo demoing then? It's essentially misleading people about what it takes to write a good app. If we'll go by simple demos alone, PHP needs no framework at all for a good demo:
This is why RoR declined and it's why PHP with Laravel and WordPress as their poster boys is declining.
PHP itself is no longer as terrible as it used to be, although all the good people seem to have left the internals. But the frameworks people use on it are terrible, incompetent and aggressively misleading people into bad practices for the sole purpose of marketing to newcomers.
Re: Go with PHP
#198Earlier quoted context omitted.
You don't get XSS protection out the box from any language's standard library, nor CSRF.
You do get XSS protection out of the box in most templating languages, though, and PHP is also a templating language. Take this template: {{ title }} In most templating languages, for a title of " alert(); ", the result will end up being: <script>alert();</script> In PHP, which is a templating language, the equivalent seems to be: But this will print the title unescaped, which is a security vulnerability,…
Templating languages are abstractions on top of other technologies. I don't see how PHP is a templating language. I could write that exact same code above in NodeJS and I'd need to use mustache to escape the output. So you can make the same mistakes in Node, Python.
Nobody writes PHP mixing HTML and PHP anymore, and if you do you should run. Shit code is not unique to PHP and I've seen more than my life's share in JS and Python codebases.
Re: Go with PHP
#199> It can handle more than 500,000 orders per month Hilarious because other languages are capable of that per minute not per month
What stack can handle 500,000 orders per minute - 22.3 billion a month - on a $6/month server?
Most of them? 500k per minute is around 8k reqs/sec. $6 will get you 2 vCPU, so each CPU only needs to handle 4k requests per second.
I'd at least expect that to be possible in Node, and would be somewhat surprised if a Go or Rust framework didn't hit that mark.
Re: Go with PHP
#200As someone more familiar with js/react, is there an equivalently mature reactive frontend framework?
Laravel has inertia, livewire or alpine to get reactive/snappy frontends if you want to have an SPA. Inertia lets you use your react while not needing to write an api. Livewire drops the js completely and does the SPA-esque frontend with php, alpine is just a smol lib to make parts of the website interactive.
Generally speaking, if you use PHP to build an API, you can use react still as is.