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

PHP in 2019

stitcher.io

Post reply on HN
Print view View original

321–330 of 489 posts

Re: PHP in 2019

#321

Post by cbdumas »

DCoder wrote: post #315
cbdumas wrote: post #275

Earlier quoted context omitted.

Often when there is a post about PHP I read over these treads sort of subtly trying to figure out how a language with such a large user base has remained basically invisible to me. And I don't think I live in the HN bubble, though I do use a lot of Python, in my consulting work I've also done plenty of work with .NET, JVM to a lesser extent and other "boring" tech. But PHP has literally never come up, even as a sugge…

Right here! PHP and JS/TS is what I do every day. PHP has its tentacles all over the web: WordPress and Drupal are immensely popular for simplistic sites and short-lived promotionals, Magento and WooCommerce attract many e-commerce users, and Symfony/Laravel handle the custom stuff. I've worked with all of these and have the scars to show for it. All popular projects have swarms of consultants offering advice, prebui…

So I get the sense that PHP is sort of the tool of choice for web development at small or medium businesses which are not primarily software businesses, but are looking to create a website and maybe do some ecommerce? Is that right? If so I guess it makes sense that I wouldn't have seen it, most of my consulting work has been at relatively large enterprises.

Re: PHP in 2019

#322

Post by Supermancho »

Kiro wrote: post #304
reallydude wrote: post #273

Earlier quoted context omitted.

Laravel and Symphony, in particular, have the terrible code smell of elongated toolchains, that are specific to the frameworks. > php artisan serve # laravel > symphony server:start # symphony Same poor thinking that NodeJS introduced, albeit less offensively integrated. If you need additional toolchains, you're not using PHP per se, but another meta-language. There's literally no good reason to do this other than to…

Never met a Laravel developer who actually uses php artisan serve. Sounds like you're fighting windmills.

> Sounds like you're fighting windmills.

Every Laravel developer uses artisan to do something. They were highlighting the names of the magic binaries.

Of course, every Laravel howto starts with a quick guide telling you to use artisan serve, illustrating the point.

Re: PHP in 2019

#323

Post by akie »

stephenr wrote: post #289
ryeguy wrote: post #262

Earlier quoted context omitted.

The vast majority of people using a package manager in the PHP ecosystem are using composer. It makes sense to call it "the" package manager.

I’d argue that the only “the” is one that’s distributed with it, which is PEAR. I’m not saying PEAR is used more or that it’s better, just that it’s the only one close to “default” with the language distributions.

I literally know no one who uses PEAR.

Re: PHP in 2019

#324

Post by codedokode »

brightball wrote: post #54
cntainer wrote: post #28

Earlier quoted context omitted.

Agreed, Laravel provides the best dev experience in the PHP world. The funny thing is that Laravel basically took the Ruby on Rails philosophy and applied it to PHP. Just looking at their site it's clear they have a very similar vision: simple, fast and fun. One can always find differences but the basic principles are the same. IMO this is great kudos to the Laravel guys, whatever language I use I always look for the…

Yep. Laravel is basically PHP on Rails. They do a great job with it too.

I don't like their code and architecture though. The code is ugly because it is built around static methods instead of proper OOP, and uses magic methods a lot. It is not easy to read.

Also, they love to invent their own names for existing things. For example, they named a folder with interfaces as "Contracts", although there are only interfaces.

You are using "Ruby on Rails" as some sign of quality, but if it uses magic and static methods like Laravel, I would consider it ugly too. Also, I remember reading somewhere that they were hotpatching imported modules. Luckily in PHP you cannot do it.

Re: PHP in 2019

#325

Post by EGreg »

cntainer wrote: post #28
owenwil wrote: post #2

I've actually been really impressed with Laravel after switching back to PHP for a few projects. Not only is the developer tooling experience some of the best I've experienced, it's just really the only framework I've ever experienced with a high quality ecosystem of tools—from Forge[1], which makes it dead-simple to deploy a Laravel app into production to things like Horizon, for managing Redis queues. A great examp…

Agreed, Laravel provides the best dev experience in the PHP world. The funny thing is that Laravel basically took the Ruby on Rails philosophy and applied it to PHP. Just looking at their site it's clear they have a very similar vision: simple, fast and fun. One can always find differences but the basic principles are the same. IMO this is great kudos to the Laravel guys, whatever language I use I always look for the…

It's funny, I remember when I started working on my first PHP framework, I knew about Drupal, CodeIgniter, Kohana, Symfony and Ruby on Rails. Back then, Symfony was the Ruby on Rails applied to PHP. And I wanted to have a more "php-like" approach to everything. That's when I made phponpie.com (the early attempt).

Fast forward to now. After 10 years there is https://qbix.com/platform . If you're reading this and know PHP / LAMP, I would encourage people here to try it and give me feedback. I've never really spent time growing the community or popularizing it like Laravel. But at every turn, it's made decisions that are as close to PHP and standards as possible.

In particular, the Db module may be better than Doctrine, for example.

Re: PHP in 2019

#326

Post by zerocrates »

xrd wrote: post #290
xrd wrote: post #231

I think the way to analyze a language and framework should be: "what does this framework permit the worst developer on the team to do?" I think the story for Php in this regard has not been a good one historically. You can put processes like PR review, and add coding standards, but getting things done will always trump those things, especially when you are bootstrapping. If you can tell me modern PHP is better than t…

For example, coding standards: `There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.` https://github.com/php-fig/fig-standards/blob/master/accepte... A language that has to permit this kind of thing (or thinks it has to) is just going to lead to developer infighting. This is an important issue because GitHub PRs are going to be unreadable if one…

I'm not sure what this has to do with PHP as a language... barring the few languages with a very strong default formatting convention like Go, code style differences are both a fact of life and not terribly problematic (set rules for the project and enforce them automatically).

Re: PHP in 2019

#327

Post by astrodust »

codedokode wrote: post #324
brightball wrote: post #54

Earlier quoted context omitted.

Yep. Laravel is basically PHP on Rails. They do a great job with it too.

I don't like their code and architecture though. The code is ugly because it is built around static methods instead of proper OOP, and uses magic methods a lot. It is not easy to read. Also, they love to invent their own names for existing things. For example, they named a folder with interfaces as "Contracts", although there are only interfaces. You are using "Ruby on Rails" as some sign of quality, but if it uses m…

If you think Rails is ugly you're going to have to frame this with what you think is beautiful so we know where you're coming from.

Rails does take a lot of established concepts like MVC and mangles them pretty badly, but the Rails version of MVC works well in practice if you're willing to overlook how unconventional it is. The beauty is not in the adherence to dogma, but the day-to-day experience of using it when you know how it works.

It takes surprisingly little code to do some complex things in Rails. I'm working with GraphQL now and it's stupid easy to build out an API with Rails.

Laravel might seem all sorts of "wrong" to someone who has expectations of "how things should be", but the Laravel way, when accepted for what it is, works. It provides structure and cohesion which in the PHP world is in extremely short supply.

Re: PHP in 2019

#328

Post by chipotle_coyote »

codedokode wrote: post #324
brightball wrote: post #54

Earlier quoted context omitted.

Yep. Laravel is basically PHP on Rails. They do a great job with it too.

I don't like their code and architecture though. The code is ugly because it is built around static methods instead of proper OOP, and uses magic methods a lot. It is not easy to read. Also, they love to invent their own names for existing things. For example, they named a folder with interfaces as "Contracts", although there are only interfaces. You are using "Ruby on Rails" as some sign of quality, but if it uses m…

The static methods you are seeing are by and large facades -- convenience methods -- but Laravel is still absolutely "proper OOP."

https://laravel.com/docs/5.8/facades

"Contract" is not a term they invented; it's a term from "design by contract programming," and Laravel enforces the "contracts" through interfaces.

https://en.wikipedia.org/wiki/Design_by_contract

(And, no, they did not invent the term "facade," either.)

Re: PHP in 2019

#329

Post by stephenr »

akie wrote: post #323
stephenr wrote: post #289

Earlier quoted context omitted.

I’d argue that the only “the” is one that’s distributed with it, which is PEAR. I’m not saying PEAR is used more or that it’s better, just that it’s the only one close to “default” with the language distributions.

I literally know no one who uses PEAR.

Which is literally irrelevant to my point.

Re: PHP in 2019

#330

Post by barbecue_sauce »

juangacovas wrote: post #276
gwbas1c wrote: post #257

Earlier quoted context omitted.

The thing that I like about PHP is that I can mix HTML, code, and database queries into a single file. This is incredibly useful when learning basic web development, even though it doesn't scale for more complicated applications. It's also incredibly useful when trying to bang out a simple experiment.

And many of us took the jump and refused to do things that way. You're wrong, PHP scales and you CAN do separation of concerns and have pretty, maintanable code, using a framework or not: just a matter of knowing what you are doing

It's pretty clear that he meant mixing HTML, code, and database queries into a single file was what didn't scale, not PHP itself.
Post reply on HN