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

21–30 of 489 posts

Re: PHP in 2019

#21

Post by coblers »

Maybe it isn't, but other languages/frameworks have improved the past ten years as well. I don't see the selling point in building something in PHP in 2019 when you have similar if not better/more mature languages/frameworks at your disposal.

Won't your prototyping be faster in Go/Python/Node/Ruby anyway, with a more stable surface to build upon it? I really fail to see where PHP has its place in 2019. For your "build a minimally viable product fast", the above win. For enterprise stuff, the good old Java/C# win.

Re: PHP in 2019

#22

Post by jbrooksuk »

scandinavian wrote: post #14

php > echo count(get_defined_functions(TRUE)['internal']); 1196 They should clean up the global name space, but that will never happen, so I'll continue not using PHP.

Why does the number of methods in the global namespace bother you?

* Genuinely interested in the rationale behind this. Sure, it's a lot, but why does that matter?

Re: PHP in 2019

#23

Post by gog »

johnday wrote: post #5

Thanks for sharing. The thing that I am most concerned about with PHP is not, strictly speaking, the language itself. The syntax is slightly odd but otherwise fine. And the semantics are much the same as any similar language. The real problem that I find with PHP is that the designers seem (from an outside perspective) to take a similar approach towards language backward-compatibility that, for example, C/C++ have. T…

The amount of legacy applications being run on the internet is huge. Breaking stuff would put a great financial burden on the companies running those.

It is a sensible approach IMHO.

What kind of bad stuff are you talking about? If you talk about function names and parameter ordering not being consistent that is not an issue for developers using the language daily, most of them are using an IDE so it doesn't matter as much as people who don't use it say.

Re: PHP in 2019

#24

Post by imtringued »

scandinavian wrote: post #14

php > echo count(get_defined_functions(TRUE)['internal']); 1196 They should clean up the global name space, but that will never happen, so I'll continue not using PHP.

Yeah and they should add basic features like lambdas and rewrite the entire standard library to support that while they are at it and when they are done with all of that could they potentially provide a separate syntax similar to facebook's reason? It's no longer the same language anymore if you change everything and therefore there is no reason to waste time improving PHP.

Re: PHP in 2019

#25

Post by jbrooksuk »

coblers wrote: post #21

Maybe it isn't, but other languages/frameworks have improved the past ten years as well. I don't see the selling point in building something in PHP in 2019 when you have similar if not better/more mature languages/frameworks at your disposal. Won't your prototyping be faster in Go/Python/Node/Ruby anyway, with a more stable surface to build upon it? I really fail to see where PHP has its place in 2019. For your "buil…

> Won't your prototyping be faster in Go/Python/Node/Ruby anyway, with a more stable surface to build upon it?

One of the most understated pros of PHP (IMHO) is that it's so easy to get setup with. You can start hacking on something so quickly. In my experience, Go has not been like that. Node.js also was never as quick.

Re: PHP in 2019

#26

Post by SXX »

gog wrote: post #18
SXX wrote: post #15

Earlier quoted context omitted.

> Composer, the package distribution system, really needs work and is incredibly slow, but other than that—I'm really happy. It's also use abysmal amounts for RAM for some reason. I managed to use Chrome headless for my app with only 512MB, but not Composer.

How long ago was that? There were some issues if you had xdebug enabled, but AFAIK that has been fixed.

Just few months and I did not use xdebug on that server. To clarify it's was just CRUD app on Laravel with few small dependencies on top of it. Composer used like 700MB RAM to install it for whatever reason.

Re: PHP in 2019

#27

Post by nickjj »

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…

There are comparable things with other frameworks too.

For example I wrote a course on building a SAAS app with Flask. It's available at: https://buildasaasappwithflask.com/

It covers everything about user registration, profiles, subscription billing, 1 time billing, invoicing, and about 50 other things you would likely want to do in a SAAS app or any application really.

The course comes with the source code along with 15+ hours of video explaining every line of code in stages, life time free updates and life time support for close to half the price of what Spark charges just for the source code for 1 site license (with the Flask course you can use the code in however many projects you want).

Spark's business model seems interesting though. I don't use it personally but do you just get the source code and nothing else? How do they limit you to 1 site if you end up with a local copy of the scaffolding / code base?

Re: PHP in 2019

#28

Post by cntainer »

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 tooling that follows the KISS principle. In PHP you have Laravel, in Java/SCala you have PLay, etc.

I need to add that, because of the job, I did a lot of PHP, Ruby, Java, Javascript with many different frameworks and I can say that Rails is still the best for me when it comes to dev experience if you need to move fast. Laravel has come a long way but it's still not at the same level of maturity in terms of tooling and ecosystem. As a bonus with Rails you use Ruby which is designed for programmer productivity and fun.

Anyway, whatever language/framework you use just keep it simple, that's the most important decision you can make for the health of your project.

Re: PHP in 2019

#29

Post by noname120 »

scandinavian wrote: post #14

php > echo count(get_defined_functions(TRUE)['internal']); 1196 They should clean up the global name space, but that will never happen, so I'll continue not using PHP.

While parent's comment seems to attract some downvotes, there is a good point hidden beneath: PHP (mostly) keeps backward compatibility. This means that old and unsafe functions that should not be used anymore are not removed from the language and are still available to use.

Coupled with a lot of outdated documentation and tutorials that advocate using these functions, it becomes a big issue. For example, many tutorials use "==" when "===" should be the default. Deprecated functions are used in many tutorials as well.

Re: PHP in 2019

#30

Post by tannhaeuser »

Rather than chasing MVw or OO trends of the JavaScript ecosystem and become more like JavaScript or Java, so to say, why don't the PHP developers identify and build on the unique strengths of PHP? Which are IMO: the large installed base in classic web hosting, and the original purpose of PHP as a high-level scripting language embedded in otherwise static HTML as in "". There is a huge room for improvement there since PHP's quick-and-dirty hackjob of a page-embedded language isn't HTML-aware and thus prone to injection attacks, which has caused uncountable attacks, botnets, and other problems for PHP and non-PHP sites alike, in particular when coupled with PHP's target demographic. This is especially painful because PHP embeds via SGML mechanisms (processing instructions), when SGML has all the features needed for context-aware, injection-free templating. If PHP can improve that story, and stop becoming the language of unintended consequences and usage-outside-its-comfort-zone, then it might earn a lot more respect and consideration.
Post reply on HN