I totally expected it to be a troll site. It's actually sensible advice.
But, really, I suggest using other tools. We have nicer tools now.
But, really, I suggest using other tools. We have nicer tools now.
Especially Laravel + Lighthouse, which is an extraordinarily neat GraphQL layer considering the huge deployability you get with PHP.
PHP is progressing towards a nicer language in a way that JavaScript, IMO, is not. And taking tens of millions of programmers with it.
I'm currently using Nuxt/Vue (static) on the front end, with Apollo (this latter bit I will probably swap out).
What is nice about Lighthouse is that it is schema-first. I am far less fond of the "auto schema" approach that e.g. WP-GraphQL uses. (Though WP-GraphQL is not bad; I'm also using that in a project).
Debatable really. Within the web development space the options are rather limited in my opinion.
Options:
* Spring based apps - Downside JVM is a Resource hog
* Python, Ruby, etc - The web frameworks are in my opinion not as full featured. Same with CMS systems. Also requires more resources. Also have limited OO features.
* Go, Rust, etc - Really good choices for APIs but their web frameworks are also really lacking.
The tooling around PHP is really good and stable. The language itself, the downsides are very limited and the main one that remains valid is inconsistency of function parameters. The issues with bad code are generally the same ones that can be done in another langauge.
Usually one would have an IDE's auto completion to take care about function parameters, and in any case PHP8 has named parameters now to reduce whatever confusion (especially when optional parameters come into play) remains.
I'm actually very interested in your dev setup. Do your devs use Linux machines? What IDE?
We have two deployment modes:
- lambda
- ec2 instance
Depending on how you would like to target Lambda you have multiple options. On ec2 too.
We use VS Code on both Linux and MacOS. The tooling is kind of meh at the moment, Ionide is not ready for prime time we run into issues frequently with it. We are considering to switching to Rider soon.
https://www.jetbrains.com/help/rider/F_Sharp.html
* I do not have time to write your a detailed answer but I promise to get back with an article sometime this month.
I still use EC2 for everything, I haven't explored Lambda yet. I look forward to your article, thank you. Is dev.l1x.be where it will be posted?
They are sane languages with large ecosystems and solid frameworks for web-dev.
I've spent a lot of time using PHP professionally and then coding all my personal stuff in Python/Go/Scala/Kotlin/etc. I know the downsides of PHP and I know the upsides and I often prefer coding in other languages but PHP really does have it's place.
I'm sorry? Compete on what parameters?
Almost all frameworks win, hands down, in developer-friendlyness from WordPress. Many, if not most, modern CMSes can easily compete on security or performance. Many CMSes will win in user-friendlyness - for distinct use-case even more so. Many web-frameworks win easily in versatility: there's no way you can build a solid payment-service-provider in WordPress, build a Bookkeeping app, CRM, project-management, etc in WP. Yet these are fine in Java, .net, Rails, Django or even Rust.
The only place where I consider WordPress king, is for standalone, reasonably simple, blogs. This is a giant niche.
* standalone: not integrated into CRMs, or editorial workflow software. reasonably simple: no complex editorial and publishing workflows. blogs: anything slightly more than simple brochureware, but simpler than an avera CMSes.
I was saying this exact thing: WordPress is just a CMS, which severely limits what you can sanely do with it. You won't build a PSP in a CMS. That was my point.
> not many systems can compete with Magento/Spryker/Sylius
I have to disagree. The JVM is one of the biggest pluses and might be one of the most battle-tested pieces of software out there.
> The web frameworks are in my opinion not as full featured.
Again, have to disagree here. Django is by far one of the most full-featured, well-documented web frameworks out there (IMO).
> The tooling around PHP is really good and stable. The language itself, the downsides are very limited and the main one that remains valid is inconsistency of function parameters. The issues with bad code are generally the same ones that can be done in another langauge.
I agree here and I think with PHP 8 incorporating JIT compilation, I think the future looks bright for PHP. I think the biggest foot guns these days are to be found in the JS ecosystem...but again, IMO.
Your points don't seem to conflict with the fact you need more resources to run a mimimal Spring Boot application than you would a Go application, a Python applicaton, a PHP application, etc. Because the JVM by default by the nature of how it operates needs more resources. I'm not saying anything other than that.
The fuck are you smoking? The JVM is one of the most mature, resource efficient, and fast language runtimes out there.
See, this is why nobody can take you people seriously.
As someone who has actually read the JVM specifications many times, has actively worked on a JVM implementation, and has a pretty good grasp on virtual machine design, I beg to differ.
But hey, I'll take the bait, what makes you think the JVM is a 'resource hog'?
That said, many Java applications themselves are resource hogs. Even my preferred IDE, the Jetbrains suite which I love, are resource hogs. Perhaps I'm simply not configuring it properly, but arguably I wouldn't ask an end user to tune JVM parameters any more than I would ask a car buyer today to set his timing or tune his mixture.
Ok, so you're saying that because a large, complex desktop application uses a lot of memory and is also written in Java that therefore the JVM is a memory hog?
Well then, given how much of a memory hog Chrome is, I guess we can all shitcan C/C++ as well.
Look, in any reasonable apples-to-apples comparison the JVM blows anything PHP has out of the water, including haxe, hiphop, etc.
And even if you write a PHP-to-bytecode compiler (e.g. https://github.com/jphp-group/jphp) then there are certain limitations to how fast and efficient any dynamically typed language can be. Look at all the shit V8 has to go through to do field lookups: https://v8.dev/blog/fast-properties
And then there's so much useless request-level overhead to PHP, even with pre-cached bytecode, you're never going to get even close in terms of latency to a well tuned JVM running something like spring boot.
And if you really hate Java as a language, you can always use something like Kotlin.
Actually, no. They said they didn't believe that.
> And then there's so much useless request-level overhead to PHP, even with pre-cached bytecode, you're never going to get even close in terms of latency to a well tuned JVM running something like spring boot.
I think the point you need to specifically define that the JVM needs to be well tuned kinda shows you know there is a grain of truth to the fact that you dislike so much.
And really comparing performance of a compiled language to an interpreted language is kinda cheating. Compiled should be faster.
From my experience I can run a Go application with the same performance requirements as a JVM application with less resources. For example, for the same requirements I had 50mb of ram assigned to a Go docker and 250 mb assigned to the JVM. I'm sure we all agree 250MB is not so much but that adds up. Then we get on to the fact it's quite common in the real-world to see lots of apps built on the JVM needing lots of resources, sure you can say that's the devs problem and if they just did it properly it wouldn't be the case but if so many people are doing it wrong then maybe it's being the JVM makes doing it wrong so easy. (Which was PHP's problem so many years ago)
You don't need to tune it to beat the pants out of a PHP-based solution.
Honest question, have you ever owned a large-scale, low-latency service in both Java and PHP, and have you compared latency characteristics between both runtimes?
No, if I've worked at a shop with a large scale low latency PHP app, they aren't not bothering their ass with Java, no need. They clearly have a highly comptent dev team who know their tools.
The only time I've dealt with Java is when companies are moving away from Java because their Java app is bloated beyond hell. They have a dev team that aren't highly comptent and think switching languages will help.
If I was dealing with the two, I would most certainly expect the Java one to handle scale better. But if I'm at lower level scale I would expect the PHP one to require less resources. Once PHP starts to scale up it can be a resource hog.
The reality is the comptency level of your dev team is the most important thing.
A think you need to remember, the JVM can scale massively well but the majority of systems don't need to scale well.
See Ken Thompson, Reflections on Trusting Trust, 1984 https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
Please, don't ruin "JS bad" thread with facts. It's rude.
With PHP you can have your cake and eat it too. Have the productivity of a dynamic language, no compile step and a really smooth gradual typing experience with great tooling and linting.
I really can't think of anything other that familiarity why one would prefer JS/TS for server side stuff. Maybe async story but PHP 8 got fibers now so it might be catching up soon as well.
This is very strange to hear. Typescript error messages will show you a type mismatch and explain why one type isn't compatible with the other. What's an example of a cryptic typescript error message?
The problem is that the type system in TS can get crazy complex and has many uncommon features like structural typing. You need to have a really good mental model of how TS works to be able to make sense of what TS tries to tell you.
Won't this sentiment hold true for Rust as well? You need to have a good mental model of how Rust works, with all its borrowings and lifetimes, to understand what its errors are trying to tell you, and especially how to fix the problem?
The difference is that errors do a great job and telling you what went wrong and how you can fix it. You just fix one error after another and the borrow checker will guide you to the correct solution.
For example you get an error like:
error[E0433]: failed to resolve: use of undeclared type `Environment`
--> src/main.rs:9:19
|
| let mut env = Environment::new();
| ^^^^^^^^^^^ not found in this scope
|
help: consider importing this struct
|
| use foobar::test::Environment;
|
You obviously need to know the basics of systems programming to effectively program in Rust and some type errors get tricky, still it is a more interactive experience and you can just jump in while in TS just jumping in does not really work and the level of type safety relies on your skills as a developer.
Type 'Record<string, any>' is not assignable to type 'T'.
'Record<string, any>' is assignable to the constraint of type 'T', but 'T' could be instantiated with a different subtype of constraint 'Record<string, any>'. (2322)
While I would not be able to figure out the solution to this problem from the error message alone, I would gather from it that typescript is telling me here that it cannot guarantee that it will satisfy the type contract, i.e. that the function will return a thing of the same generic type T as it received. This is useful information in debugging the type declaration of the function.
How npm works and the policies by company behind it.
PHP composer is much more sane than npm.
And all the different package controversies like leftpad.
Lots of bogus and malware packages.
Have you actually tried using for Nim for building a scalable web service or even just complex websites with auth of your choice? Nim does not even come close to what PHP has to offer in terms of solutions for every need you may have.
I'd say Rails is a very nice DSL for building web applications that's written as an extension of Ruby.
We have two dimensions here, one for how easily a language allows you to build a website, and how expressive, consistent and error-proof a language is. It's easy to build a simple website with PHP (as it was with ASP and JSP, or even Cold Fusion). I actually like that approach, that maps running scripts to state transitions. But I also like the consistency and expressiveness of Python, Java, Scala, or C# (which I have used). As languages, they are "nicer" (and that's completely subjective) than PHP, and that niceness more than compensates for being unable to write code inside templates.
PHP has supported strict typing for a while now, making it also fairly consistend and error-proof.
There is nothing at all wrong with PHP and it's rapidly moving in the right direction.
The implication of the question is that there's something designed into PHP that makes it better for working with web things. Why does the language need to be designed to work with the web? That part of any language can be filled out with a framework quite easily, and arguably that means it's much easier to change how the language is used. That seems to be the case with every major PHP application anyway - most use Laravel or Cake or Symphony or something. Just as most Ruby web projects use Rails, and most backend JS projects use Express, and Rust web projects use Poem, and so on.
I don't think there's a good reason to design a language specifically for web projects. If that's how PHP works these days (I haven't used PHP in a decade or so), I'd suggest that might be a bad thing. It's very rigid, and if the language gets anything wrong that compromises the design of every project that uses it. Languages should provide simple primitives that frameworks and libraries build on.
That has always been the goal of PHP, to be a web framework in itself (and now we have frameworks on top of that framework). It's trivial to read POST data as understanding POST requests are built-in into the language. With Rust or JavaScript you either will pull down a external library to handle that for you, or write a ton of code to make it easier for yourself. With PHP, it's literally one-line of code.
It is not as rigid as you might believe, as we have frameworks on top of the native PHP framework already. That's not to say PHP is without compromises, it's not suitable for a bunch of different projects (you wouldn't write mobile/desktop apps with it for example). But if you have a simple CRUD application that just needs to output some HTML data and persist stuff to a MariaDB/MySQL database without wanting to pull down a bunch of 3rd-party dependencies, PHP will make that effortless compared to basically any other language.
I think the popularity of PHP for web development speaks for itself, it basically conquered that segment of development when it first appeared, and is still more-or-less king, even with its warts.
As a last word, I like that languages specializes in different things, not every language has to be a general-use language, and I hope we see more of that in the future. Darklang specializes in building backend APIs for example, others specializes in being for UIs and so on. As every language more or less looks like C today, there is plenty of room for innovation in programming language design (and no, not talking about TypeScript which is basically just C# that compiles to JavaScript, but more different languages).
This is untrue. PHP was a templating language and form-handler first and foremost[1]. It took a long time for it to move out of that (I'd argue up to 5.6) and become an actual programming language rather than a template language on steroids. Edit: we still have to move out of template mode in every file by adding a <?php at the top of our files - and don't ever add a whitespace char before that, or else.
So, essentially, we now have web-frameworks built in a templating language. With, ironically, template languages written in that templating language. Nice, if you like recursion though.
[1] Early PHP was not intended to be a new programming language, and grew organically, with Lerdorf noting in retrospect: "I don't know how to stop it, there was never any intent to write a programming language - https://en.wikipedia.org/wiki/PHP#Early_history
> PHP development began in 1994 when Rasmus Lerdorf wrote several Common Gateway Interface (CGI) programs in C,[16][17] which he used to maintain his personal homepage. He extended them to work with web forms and to communicate with databases, and called this implementation "Personal Home Page/Forms Interpreter" or PHP/FI.
He was working on his homepage (on the web) and wanted to make it easier to handle forms and communication with databases. That's basically everything the early web could do, and PHP aimed to make that easier.
My reply was more to explain why I think it is not a framework, but rather a language, to handle web-stuff. But looking at it from other perspectives, that can be "framework" just fine.
But no harm done, thanks for clarifying yourself :)
With Python and any of the Python frameworks, it's two lines. And one is most likely not explicitly bringing in HTTP request parsing, but just connecting all the plumbing.
> With PHP, it's literally one-line of code.
In that narrow domain, few things are simpler than Cold Fusion. If you go further, the Zope application server offers lots of nice ways to iterate over datasets that involve almost zero code.
> As every language more or less looks like C today
You seriously need to play more with other languages. I suggest you learn one or more of the "weird" ones, such as APL (avoid the ASCII notation, dig deep into the symbols), Erlang, or Lisp. It'll bring in a lot of perspective for you.
Yes, but in the case of PHP, PHP itself is the plumbing. You literally write `$_POST['param-name']` and you have the data. Using Python would require you to either write a bunch of logic enough to abstract it to have it like PHP, or require a 3rd-party library (or framework) for it to be one line.
> You seriously need to play more with other languages. I suggest you learn one or more of the "weird" ones, such as APL (avoid the ASCII notation, dig deep into the symbols), Erlang, or Lisp. It'll bring in a lot of perspective for you.
I'm saying this as someone who does play with lots of languages almost every day and my day-job is writing Clojure code (for both backend and frontend work). I might have missed a "As most of every new language" part in my previous statement. I'm not saying all languages are C-like, they're obviously not. But most of the popular new language do have a syntax-heritage stemming back to C (compared to languages with S-expressions), like Rust, TypeScript/JavaScript, Java, C++, C#, Python, Ruby, Golang and more, and they are mostly focusing on being general purpose useful.
Btw, I don't think lisp-like languages are the weird ones, the C-like languages are the ones that are weird. You should play around with more languages and you'll see why :)
IMHO this is still too much HTTP, as I'd prefer to keep the entire HTTP out of my app, but after your routers, there's nothing "Web": it could all be "domain specific".
Ruby, the language, is, indeed, hardly "Web" at all. Ruby stdlib has some HTTP stuff but that is both lacking and optional.
Consequence of that is that every other language is de facto is dominated by one framework provider that you almost always have to use. That in it self is the basis for a stagnant community.
Frameworks solves a general problem, you on the other hand solves a specific problem, sometimes those two are aligned, but many times they are not and then you are on your own.
> I don't think there's a good reason to design a language specifically for web projects
It definitely is because web has some unique properties and I think that one of the reason why we are unnecessarily shuffling JSON from backend to frontend where it is then transformed to HTML by async JavaScript (which gives a rather disjointed user experience), instead of sending a proper HTML document immediately from the server, because most backend languages suck when it comes to doing proper web.
Thus the industry creates these band aid solutions that constantly makes both the web and web development worse.
> language gets anything wrong that compromises the design of every project that uses it
Language design is overrated when it comes to producing customer value. What is important is how the general architecture works
* memory model (shared, per request, etc)
* request model (by the app or by the web server)
* resource model (mapping URL to file)
* compilation/build step
* deployment
* hosting
* tooling (IDEs, linters, testing, package manager, etc)
* how to scale
* available programmers
* community
But if you want to have some fancy language feature to print out a proper HTML document, or what is more likely a JSON blob, go ahead, but it does not improve the end user experience at all.
This had tons of disadvantages.
Say CoolLang is such a language. Since is msall CoolLang has a micro standard library so has no DateTime or JSON, so you have a package manager and maybe 1 repo where 15 different JSON packages, you decide to use JSON_A but you also want to integrate with Amazon and they used JSON_B in their API and you also need to integrate with other API and this guys used JSON_A2 witch is an incompatible version of JSON_A. So now repeat for each web related function you have to decide for what package to use, if is compatible with whatever you use and review all it's dependencies, in the end you notice you depend on 100 packages and 3 years alter you have issues upgrading.
You maybe now will complain that JSON is included and the solution is to use the CoolFramework_V13 for CoolLang, with is incompatible with previous versions and is based on 100 packages that could explode when some dev decides he had a bad day and purch is package.
Isn't Poem just... several months old? Your examples of frameworks for other languages are mature and established. Is the Rust ecosystem moving that fast?
Citation needed.
For folks not wishing to switch frameworks and tooling every year, you can get a lot done with PHP.
I really like Django as an opinionated framework. I have also used Flask, Falcon, and FastAPI, all with good results in their own niche. I also like Play and Scala and Spring Boot with Java.
> For folks not wishing to switch frameworks and tooling every year, you can get a lot done with PHP.
You can also get a lot done with wood and nails, but that doesn't mean it's the best tool for all kind of jobs.