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

PHP in 2022

stitcher.io

Post reply on HN
Print view View original

251–260 of 318 posts

Re: PHP in 2022

#251

Post by aarondf »

jgilias wrote: post #243
aarondf wrote: post #231

A lot of people here have mentioned Laravel. I think one of the key things about Laravel is that the creator, Taylor Otwell, is only focused on Laravel. Imagine if DHH didn't ever have Basecamp (or 37 Signals) and only focused on Rails and the Rails ecosystem. The Laravel team now has several full time employees working on making the entire Laravel experience as painless as it can be. Of course Taylor and the Laravel…

Yeah, curiously, I think Laravel is just getting started in a way. Taylor seems to have a superb vision about what it is that he wants to achieve with it and in what way, and I don't think the 'rest of us' have fully grasped the 'end-game', and what the implications will be. I mean, he took the most popular, but somewhat 'not cool anymore' backend programming language with a huge pool of developers, and proceeded to…

> Yeah, curiously, I think Laravel is just getting started in a way.

That would be amazing. I agree, I think Taylor has good vision. His overriding principle seems to be "make people's lives easier," which makes for a pretty good ecosystem.

Re: PHP in 2022

#252

Post by Loeffelmann »

synergy20 wrote: post #249

As long as wordpress still holds 40% of the sites PHP will be a major language. In my opinion, all the modern 'script' languages are now adding static-typing one way or another, to make they much robust(python's mypy, typescript,PHP, etc). I will pick PHP for backend website development, I just want to avoid the async-node-js as much as I can as it's much worse than other options I feel.

What's wrong with async node js? I think the async API is pretty good.

Re: PHP in 2022

#253

Post by JackWritesCode »

aarondf wrote: post #231

A lot of people here have mentioned Laravel. I think one of the key things about Laravel is that the creator, Taylor Otwell, is only focused on Laravel. Imagine if DHH didn't ever have Basecamp (or 37 Signals) and only focused on Rails and the Rails ecosystem. The Laravel team now has several full time employees working on making the entire Laravel experience as painless as it can be. Of course Taylor and the Laravel…

Love it, Aaron. I've always felt more confident using Laravel knowing that it's backed by a competent entrepreneur. These paid services ensure the longevity of Laravel. We've paid for Spark and Nova, and we have Vapor & Forge subscriptions.

Re: PHP in 2022

#254

Post by 9dev »

snov wrote: post #224
9dev wrote: post #177

Earlier quoted context omitted.

Does anyone really deploy PHP directly on servers still..? Running it in a Docker container is the simplest thing possible, runs anywhere, and has top-notch performance.

I meant Docker. The fact that I needed multiple processes (nginx+fpm) made PHP setup tricky compared with e.g. Java with embedded server.

I know what you mean; that has been a problem in the past. In case you have to again, I'd recommend looking into either Roadrunner or Swoole. That makes it possible to have your application run more or less standalone in a single container, hosted by a native application server. This boosts performance incredibly, and exposes a single HTTP port, as it should be.

For Symfony: https://github.com/k911/swoole-bundle

For Laravel: https://laravel.com/docs/8.x/octane

Re: PHP in 2022

#255

Post by paul_f »

xgb84j wrote: post #240
y4mi wrote: post #159

Earlier quoted context omitted.

> why you’d consider yourself a “lowly” php developer. PHP has always been considered as a somehow bad language in all corporations I've worked at to date. The same applies to other script languages such as python, ruby or nodejs - but PHP was the most undervalued of them all. It's kinda strange because the language is really performant and relatively easy to use. Maybe that's exactly why the big brain architects don…

People dislike PHP because its standard library had many inconsistencies and interesting design decision that no sane programmer would ever even think off, like all random numbers being odd ( https://stackoverflow.com/questions/31612082/why-does-mt-ran... ). Many of these decisions revolve around the authors not wanting their functions to fail under any circumstances. This is nice for beginners but quickly hurts more…

I hear that too, and frankly seems a dumb reason not to use a language. Does it get the job done, can you build value quickly, yes and yes

Re: PHP in 2022

#256

Post by kaba0 »

mojuba wrote: post #241
kaba0 wrote: post #109

Earlier quoted context omitted.

There is no real producticity gain through not having semicolons and somewhat leaner syntax. That was never the bottleneck: ecosystem, libraries are.

There is a real productivity gain when you remove all things that cause a mental tax on reading. After Swift I don't want to look back at the C-like syntax languages any more (just that occasionally I have to).

You may think so subjectively. But there is no objective study whatsoever that would support that.

Re: PHP in 2022

#257

Post by paul_f »

dncornholio wrote: post #180
g19fanatic wrote: post #102

Earlier quoted context omitted.

You have any good simple examples of your backend? Sounds like what I've been attempting to explain to others. How many concurrent requests and what size of data can you run with a setup as described?

Storing stuff in a json file sounds horrible to me. Why would you want that?

PHP supports complex data structures using associative arrays which map to the application requirements. Which can be easily saved in JSON. A SQL database with rows and fields does not always work well with these data structures. Often, as long as the data size is manageable, a json saved in a mediumtext field in MySQL works just fine.

Re: PHP in 2022

#258

Post by lghh »

dncornholio wrote: post #233
Spivak wrote: post #216

Earlier quoted context omitted.

Because your data is teeny tiny, not performance critical, and `json.load` and `json.dump` is easy and usually less brittle then you're language's marshalling library.

Why save 10 minutes on setting up a proper database? Data is never teeny tiny, data is never not performance critical :) These decisions only bite you in the ass.

Setting up a database takes way longer than 10 minutes. Data can be teeny tiny. Data can not be performance critical. You literally know nothing about the commenter’s application.

Re: PHP in 2022

#259

Post by tannhaeuser »

bluetomcat wrote: post #77
mojuba wrote: post #9

Is it just me or PHP's evolution is a bit "too little, too late" for an almost 30-years old language? PHP is not a likable language but it's probably not going away any time soon. Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. Well, Perl and old-style CGI aside, of course. That, and also the fact that it ma…

In its early years up until around 2006, PHP was mostly "HTML on steroids", that is, an HTML preprocessor with lots of goodies like "batteries-included" DB access, form handling, image processing, text processing, all accessed via a single Apache module. You simply rename your .html file to .php, and put some magic between " ". Then came along templating engines like Smarty, and they introduced a new templating langu…

That's exactly what has puzzled me for a long time: a language with HTML templating as unique selling point needs a templating "engine" after all?

smarty.net has a pamphlet up there where pros/cons (but actually only pros) are discussed [1]. Failing to understand that "" syntax is a SGML processing instruction with well-defined ways to embed into a hosting markup language like HTML, they go even so far as to say

> Another issue with PHP tags is that they share the characters of HTML tags. In the application code this isn't an issue, but mixed with HTML, tags are a maddening process to tell them apart from the HTML tags. This also blurs the line between application and presentation separation since any PHP logic can be injected into a template.

Yeah no, now you need new escaping syntax if you ever wanted to have verbatim {$whatever} in your HTML.

Notably missing is a discussion about HTML-aware, injection-free templating such as for preventing {$bla} expanding into alert('Pwnd') when sourced from user input, which is what SGML and other HTML-aware template engines can do, and which in the name of everything that's holy should've been implemented in PHP 2 to save the web from becoming a botnet.

[1]: https://www.smarty.net/syntax_comparison

Re: PHP in 2022

#260

Post by tankorsmash »

dncornholio wrote: post #244
darthrupert wrote: post #237

Earlier quoted context omitted.

You're perhaps joking, but victims of actual racism might not think that's funny.

I'm not joking and it's not supposed to bu funny. It's supposed to be confrontating. Example: Someone saw some bad PHP code once in their lives and think all PHP code is bad. They saw someone say bad things about PHP so they think all PHP is bad. Or they think PHP is bad because they don't like how it looks.

Are you thinking about prejudice instead?
Post reply on HN