Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A look at modern PHP

lwn.net

Post reply on HN
Print view View original

141–150 of 610 posts

Re: A look at modern PHP

#141

Post by hnarn »

oblio wrote: post #127
s1k3s wrote: post #112

The amount of misinformation, false claims and unsupported statements in this thread is mindblowing for the quality that I've been used to see on HN. Here are some facts: - Symfony was the backend framework with the most contributors in 2019 [1] (yes, out of any backend framework written in any language) - PHP has more active contributors than it ever had [2] - Laravel is one of the most used frameworks in the world…

I'd assume that Django and Ruby on Rails can't be that far off.

We can all assume things.

Re: A look at modern PHP

#142

Post by mrkeen »

72deluxe wrote: post #92

I still can't see how it can be "mature" if it offers an iterable returnable type like in the article example yet doesn't indicate the type of the object it is returning! It has type hints for function parameters and return types but not for arrays. This makes it useless to me. I know everybody will say "just add comments so an IDE can interpret it" but this should be a feature of the language. Just adding comments t…

I still can't see how C++ can be "mature" if you have to indicate the type of object it is returning!

I know everybody will say "just add a type declaration so the compiler can interpret it" but this should be a feature of the language. Just adding type declarations to hint to a compiler is not a real solution.

Re: A look at modern PHP

#143

Post by realharo »

hu3 wrote: post #132
realharo wrote: post #103

Earlier quoted context omitted.

In such a manual workflow ( "you can SSH a file into a server" ), you still have to setup at least URL rewriting in nginx for any PHP app using routing (which is basically everything using any PHP framework or micro-framework). Plus if the deployed app has its own domain/subdomain, you need to set that up, set up TLS certs etc., so it is really no different in the end. You either configure nginx to proxy all requests…

URL rewriting in nginx for PHP is about copying 5 lines from a google search. If using a popular framework the documentation usually provide these lines. And surely you must be joking when comparing Kubernetes' complex configuration to anything else.

>URL rewriting in nginx for PHP is about copying 5 lines from a google search.

So is setting up a `proxy_pass` to a locally running container that exposes a port to localhost (https://nginx.org/en/docs/http/ngx_http_proxy_module.html#pr...).

Literally, just start `docker run` with a proper restart policy, set up a proxy_pass on nginx and you're good to go (unless the app requires external services, databases, etc., but you have the same problem with PHP).

Plus you don't have to worry about things like "do I have the correct PHP version for all my apps?" or "do I have the necessary PHP extensions installed in the system-global PHP?

>And surely you must be joking when comparing Kubernetes' complex configuration to anything else.

Setting up a Kubernetes cluster is indeed complex. Installing apps into an already configured cluster (e.g. ordered as a service from someone) is not (unless the app itself is complex of course).

I was comparing it to the automation tools that "traditional" webhosts have for installing and managing application deployment, replying to a comment above ("They had to write an installer ecosystem..."). If you just want to have one VPS with nginx on port 80/443 and run apps there, you don't need any of that stuff. The container images are the same either way.

Re: A look at modern PHP

#144

Post by valand »

simion314 wrote: post #37
Svip wrote: post #14

Even with PHP7, PHP still feels like it is playing catch up. There is nothing new or revolutionary in PHP7, just adopting features present in other major languages. Adopting as other newer languages like Go and Rust seems to be moving beyond those features. A catch up into a world that's on its way out, if one will feel so blunt. PHP's raison d'être remains its ease of getting an instance running on a webserver. But…

Most of the time you do not chose a language or ecosystem because it has some cool syntax or some new feature. As an example if you need to do X you look at what solves X the best, if I can do X by installing say ffmpeg and write a bash script I will do that and not cry that bash does not have some cool feature. I think languages like PHP, Java, C++ appeal for people that solve hard problem where the fact that you ha…

X sometimes stands for problems above technical problem, such as:

- Existing team is comfortable with using PHP - Existing project is tightly coupled PHP monolith - Existing project cannot be migrated to other language fast enough if needed

All are valid and justifiable reasons. Learning new language is not the easiest and we should think of the people.

I must emphasis though, all party must not freeze in time. They should learn to adapt. PHP is getting smaller. The decline is slow enough to let people migrate or jump ship but fast enough that it is recognizable.

Demands are growing for languages and environments which provide more than PHP, simplest examples would be granular websocket connection control, explicit process control, whitelist-by-default security, rise of cloud and edge computing, and of course, trends, "cool new stuffs" which is not always good for everybody, but always exciting especially for the naives.

There might be a day Java is getting replaced due its huge memory usage or its tendency to be verbose and hard to read. Golang is a contender for the memory usage side of the spectrum, NodeJS is the contender for the ease of use side of the spectrum.

There might be a day C++ is getting replaced due to its "harder to write secure code". C++20 is quite cool, but there's a new cool kid Rust where you most probably won't write bad code, can be actually faster than C++ / C in some cases, and can run on browsers.

May all programmers of old languages survive and thrive and in the new world.

Re: A look at modern PHP

#145

Post by fredsted »

I wonder if most developers that trash on PHP for trivial issues like seen in this thread haven't been using it for many years, or had a bad experience (e.g. maintaining a legacy app).

Some developers live in a kind of technical vacuum where, I guess they assume, the technical features of their programming language are what makes the difference in the value of the business they're building.

In reality, the difference is in how easy it is to hire developers, the package library, overall ecosystem and developer experience, or: how can I make a great product.

Re: A look at modern PHP

#146

Post by 411111111111111 »

mekster wrote: post #121
fetbaffe wrote: post #100

Earlier quoted context omitted.

Wait, Go hasn’t had any revolutionary change since it arrived 10 years ago. It is still basically the same language/package. I’m not saying that is bad, but why does a language need to be constantly revolutionary if it solves what it sets out to solve well? Catch up to other languages? You can easily argue the opposite, that other languages has finally catched up to PHP, ease of deployment, ease of horizontal scaling…

Other languages haven't caught up on PHP about ease of deployment. If you need a fast hot reload, it isn't trivial in other languages. PHP does it with no effort. Save and refresh runs the updated code instantly, not to mention asking people to run PHP app is far easier as every general hosting provider has PHP installed. On the other hand, language structure is quite behind others but can't blame when it had been ar…

Thats hot patching, not reloading as I've come to know it in the web development world.

Hot reloading works the same for all languages I know, which is a hardcoded port pushing notifications to clients that they should reload the browser.

The client is mostly a js library or a browser plugins. Either works.

I know it's also used differently in some contexts, but they wouldn't apply here as far as I can tell. There aren't any long running processes that need to reload the code after all. It's only read when is actually executed. Which is never unless you use the hot reloading I was talking about earlier... Or trigger it manually, making it a regular reload.

Re: A look at modern PHP

#147

Post by hnarn »

s1k3s wrote: post #112

The amount of misinformation, false claims and unsupported statements in this thread is mindblowing for the quality that I've been used to see on HN. Here are some facts: - Symfony was the backend framework with the most contributors in 2019 [1] (yes, out of any backend framework written in any language) - PHP has more active contributors than it ever had [2] - Laravel is one of the most used frameworks in the world…

> And last, people compare it to languages like Rust or Go since they consider those are "innovative". I hope everyone understands that a language is fit for a certain type of task. PHP was created for website development, and in that area neither Go or Rust are even close to matching it in terms of maturity.

I'm not disagreeing with you, but "website development" is a very broad category. For example, if you definitely need a website with server-side logic and database connections, yes, that's where PHP will shine. However, if you need a more or less static website for your restaurant or portfolio, is it really as straightforward to say "PHP is for website development, write your website in PHP"?

I want to be very clear that I'm differentiating between use cases here, but for something like a technical documentation website, a status page or something similar that does not require server-side logic and databases, I would much prefer using Hugo or some other type of static site generator, and not because PHP is bad but because we're still talking about "website development" but just not necessarily the kind of website that PHP was made to build.

That being said, there are of course static site generators in PHP as well (and probably every other language out there), but Hugo has a special place in my heart just because of the speed of it.

Re: A look at modern PHP

#148

Post by mekster »

creshal wrote: post #105
fetbaffe wrote: post #100

Earlier quoted context omitted.

Wait, Go hasn’t had any revolutionary change since it arrived 10 years ago. It is still basically the same language/package. I’m not saying that is bad, but why does a language need to be constantly revolutionary if it solves what it sets out to solve well? Catch up to other languages? You can easily argue the opposite, that other languages has finally catched up to PHP, ease of deployment, ease of horizontal scaling…

> why does a language need to be constantly revolutionary if it solves what it sets out to solve well? That's a very big If in PHP's case.

What is the problem of admitting PHP solves the problem of quickly deploying web sites?

Re: A look at modern PHP

#149

Post by stephenr »

echelon wrote: post #15

For web backend, being able to ship a single binary, such as what Rust and Go can provide, is really nice. I don't see PHP as a more compelling solution than either of those languages. Scripting and command line automation is executed better by Python and Ruby, which excel for writing Unix scripts and tools. I do not see what the use case for PHP is in 2020. PHP has one of the most abhorrent language syntax designs t…

> being able to ship a single binary, such as what Rust and Go can provide, is really nice

Unless you're distributing your binary to 3rd parties, why?

If you really don't want to deploy changes to e.g. a single/small number of controller or template files as independent file changes, build your PHP app into a .phar archive, and deploy that.

I don't specifically think PHP, when run (IMO) the best way it can be, is "easier to deploy" but I also don't think it's harder either.

I'm going to ignore your other comments because they're personal opinions and while you express them as facts, I realise you probably mean them as statements of opinion.

But the last part, I just don't understand:

> I really wish PHP would just die. Continuing to drag it along like the dead carcass it is wastes so much human effort. The longer it exists, the longer we have to support it.

Who is the "we" in this statement? You clearly don't like it personally, so why does it affect you, at all? I'm not a huge fan of Java, but I don't go around claiming that it should "die" or that humanity is somehow worse off because it exists.

There's no such thing as a client-side PHP application, so it doesn't even compare to e.g. genuine concern over tech choices that are 'forced' upon users of a website (e.g. Flash, SilverLight, ActiveX, javacript bloat, etc). If the backend part of the system does what it needs to do, the language/framework/runtime it's written in/with is meaningless.

Re: A look at modern PHP

#150

Post by thdrdt »

nsomaru wrote: post #101
thdrdt wrote: post #17

I've been using PHP for over 15 years and always liked it. There is no other webserver language that's so easy to use and so deployable while still being fast. But for larger projects the available frameworks are just okayish. I think Symfony is closest to what a good framework should be. But every time I use it I wish it would be like .NET Today .NET core is also available on Linux and very easy to deploy so I don't…

What if you’re looking for a great way into .net web dev on Linux? I’ve been struggling to find a good guide that combines dev env, deployment and a good web framework. Any advice? I have quite a bit of xp with Python (Django/flask) and less with php.

Maybe this is a good place to start: https://dotnet.microsoft.com/learn

Most can be done via de command line but an editor like VisualStudioCode could be handy. Personally I use Jetbrain's Rider as IDE on Ubuntu.

Deploying can be done via the `dotnet publish` command. But tools like Teamcity can also be very useful. When you built a webapp it includes the Kestrel webserver. So it is just a matter of running the app and navigating to the port it listens to.

.NET core is a complete set of tools to create console apps, (web)APIs and webApps. This includes the .NET framework.

Post reply on HN