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

Go with PHP

gowithphp.com

Post reply on HN
Print view View original

221–230 of 532 posts

Re: Go with PHP

#221

Post by deanc »

zelphirkalt wrote: post #210
deanc wrote: post #201

Earlier quoted context omitted.

I googled SXML and it appears to be have implementation libraries in lots of languages. This is not the core language's standard library.

What do you put as the distinguishing feature between "core language standard library" and "comes with the language at installation"? Some example: https://www.gnu.org/software/guile/manual/html_node/Reading-... (no installation of anything third party required)

Alright, let's go with widely-used programming languages for now - I've been programming for over 20 years and never heard of Guile.

I am not against the idea of having native protections built into stdlib, we can agree there, but it's disingenuous to suggest that this problem is unique to PHP as the parent comment suggested. It's the same in all of the major programming languages used to spit out HTML as far as I can tell.

Re: Go with PHP

#222

Post by _the_inflator »

janmo wrote: post #38
nstart wrote: post #9

Earlier quoted context omitted.

Just made the same comment and deleted it seeing that you already stated it. Protecting against all of these is hard and no tech is going to automatically protect for all of this on its own. Such a weird statement to make that takes away from the message of the site entirely.

I worked for a company and we used the PHP ORM Propel. So in theory no SQL injections you would think, WRONG. We used a function like findOne() (I don't recall exactly). It looked like this: $resetTokens->findOne($GET['password-reset-token']); The issue was that findOne would accept wildcards, so one could use ?password-reset-token=% in the URL and reset the password of any random users.

I totally agree with everyone before me here on the issue of security.

If an app stands the stress test against say for example this comprehensive list(1), it can consider itself somewhat safe or at least benchmarked. Otherwise, only vague and unsubstantiated claims, which does not help PHP nor any other programming language or framework.

[1] https://github.com/payloadbox/xss-payload-list

Re: Go with PHP

#223

Post by xigoi »

sourcecodeplz wrote: post #213

The fact that you can build a whole app inside just one index.php file is highly underrated and I understand how newbies finding this out are getting excited. I remember when Rails first launched and I wanted to try it but it was so complicated to get started.

You can do that with any language using CGI.

Re: Go with PHP

#225

Post by hparadiz »

rob74 wrote: post #159
naiv wrote: post #82

Earlier quoted context omitted.

The documentation for Laravel is still unreadable. Guess that is why selling Laravel tutorials seems to be a fruitful business.

The documentation for Laravel is readable, in the sense that if you read it from beginning to end, like a book or tutorial, you will get a pretty good understanding of what Laravel does. But [supreme being of your choice] help you if you just want to find out what the possible values for a specific parameter of a specific method can be...

Nah. It's pretty bad. They only document like 5% of the features. What they do document is good but other than that you have to read the source on GitHub or Google for code snippets and I say this as an expert that studied the docs for help in documenting my own orm. They just straight up don't document most of Eloquent's features and class methods in the docs at all and it's super frustrating to me.

Re: Go with PHP

#226

Post by RadixDLT »

simonhamp wrote: post #142

If you're looking for a great CMS and were bitten by WordPress back in the day, you should take a look at Statamic ( https://statamic.com ) It's a Laravel package and it's the best CMS I've ever used (from a dev perspective). v4 just dropped the other day

WordPress is not your grandmas CMS anymore, its a full fledged framework and very secure.

Re: Go with PHP

#227

Post by hparadiz »

rob74 wrote: post #164
mhitza wrote: post #79

Earlier quoted context omitted.

That 300ms initialization time sounds like a cache-free execution (aka dev mode). I have symfony projects light on ORM usage (I dislike Doctrine from the bottom of my hearth, but what can you do it's the blessed symfony ORM) and after a cache warmup it handles requests under 100ms. Yes, the frameworks have obscene (java-like) class dependencies that build up during initialization (I'd prefer if there'd be a lighter f…

Well, that's the problem with all PHP frameworks: they're written in PHP! Yes, PHP has gotten faster thanks to OPCache and other tricks, but still, the less time your application spends executing PHP code, the faster it will be. And frameworks like Laravel just pile on additional PHP code to execute like there's no tomorrow. I mean, just look at the callstack when an exception happens...

I was running tens of thousands of jobs an hour with an asynchronous AWS SQS job dispatcher written in php that would launch php sub processes on the CLI. Super fast. Was able to get by with a very modest ec2 instance ($20/month) handling jobs for 300k users. Was auto scaling too.

PHP 8.x has a ton of performance improvements that make what you're saying sort of not relevant anymore. I prefer PHP over Python these days on the Linux CLI. The code is cleaner.

Re: Go with PHP

#228

Post by cutler »

nstart wrote: post #9
janmo wrote: post #6

> Your website is automatically protected against XSS, session hijacking, CSRF, SQL injection, host header attacks, and other vulnerabilities. That's quite misleading however

Just made the same comment and deleted it seeing that you already stated it. Protecting against all of these is hard and no tech is going to automatically protect for all of this on its own. Such a weird statement to make that takes away from the message of the site entirely.

Rails does a pretty good job.

Re: Go with PHP

#229

Post by BulgarianIdiot »

lostdesign wrote: post #208
BulgarianIdiot wrote: post #168

The problem is this page advertises Laravel, not PHP. Ruby on Rails has many similar "demo worthy" snippets that make complex tasks seem readable and intuitive to the layman. Laravel and Ruby on Rails have something else in common: due to the focus on these "natural" interfaces, they compromise in every other way. Architecture, performance, testability and so on and so on. For those who know PHP, this code is full of…

> , they compromise in every other way. Architecture, performance, testability and so on and so on. Architecture: The default structure of the app is good to start out and can be changed at any time. You are not locked into that. If you apply your fancy patterns, you can do whatever you want. It's rather a devs fault than the frameworks fault. Performance: Guess depends on what you compare it to. Surely a rust servic…

If you use facades there's no fixing that unless you reconstruct and reweave every component in your application to pass relevant context in and out, instead of lazily reaching into globals for it.

What you call "full DI" in Laravel is still globals in disguise, because there's a single global container.

Most defense of Laravel comes from people who have no idea how to write a good app. And unfortunately, due to bad frameworks, the number of those people is multiplying. I blame Spring and RoR. So much pain came from them. Laravel is just a pale copy.

Re: Go with PHP

#230

Post by gumballindie »

znpy wrote: post #215
gumballindie wrote: post #155

Earlier quoted context omitted.

PHP has matured and has been a nice language for a decade now. But PHP developers havent. Cargo culting “good practice” and lack of creativity plagues the community. Frameworks have become so heavy that you spend more time configuring them than actually adding value. Oh and some still argue over setters and getters.

But that’s kinda their point… you spend time configuring the framework instead of reimplementing from scratch and doing the plumbing yourself.

The issue is that there is so much configuration that it’s basically coding. PHP frameworks are all bloat. It would have been much better to abstract things in a way that you actually spend time on features not thousands of configs.
Post reply on HN