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

PHP: the quiet powerhouse

blog.appfog.com

Post reply on HN
Print view View original

131–140 of 140 posts

Re: PHP: the quiet powerhouse

#131

Post by guard-of-terra »

lucperkins wrote: post #130
guard-of-terra wrote: post #12

You're killing kittens by using PHP. PHP could be a wonderful thing if not for its original sins. It is easy and fast, but it is also bad. It is "good enough", and for many years it prevented just "good" from arising and gaining adoption. I would pick "good" over "good enough" even if it costs me a bit because I think this is fundamentally right.

But how often does trying-to-be-better-and-failing come along and torpedo good-enough-for-the-job?

Would you listen to "good enough" music or watch "good enough" movies? When I ask this, I think, many do. But I don't.

Do you?

Re: PHP: the quiet powerhouse

#132

Post by zzzeek »

techiferous wrote: post #112
ericingram wrote: post #107

Earlier quoted context omitted.

I don't understand this argument. The way I use server side templates is much simpler and more powerful than any demo of client side templating I've seen. I think you're reading a little too much into the hype, otherwise maybe you can share an example of superior Javascript templating patterns because I can't find them.

It depends what you are trying to do. If you are only targeting browsers, and especially if you don't need a lot of responsiveness, it's much simpler to just render views on the server side and optimize your server for speed. It takes a lot of effort to write a thick client. But if you are targeting a browser and a native iPhone app, the view logic lives on the iPhone app. It used to be that you could just serve up a…

I don't think the necessity of writing your app so that it exposes APIs has any correlation to whether or not the traditional web server interface to your app can still serve HTML from the server. It's just as easy to wrap API methods on the server and feed that data into a server side template as it is to call the API from a client side method (well, it's actually much easier, no need to manually futz with the browser URL/history and all that).

Re: PHP: the quiet powerhouse

#133

Post by ericingram »

zzzeek wrote: post #132
techiferous wrote: post #112

Earlier quoted context omitted.

It depends what you are trying to do. If you are only targeting browsers, and especially if you don't need a lot of responsiveness, it's much simpler to just render views on the server side and optimize your server for speed. It takes a lot of effort to write a thick client. But if you are targeting a browser and a native iPhone app, the view logic lives on the iPhone app. It used to be that you could just serve up a…

I don't think the necessity of writing your app so that it exposes APIs has any correlation to whether or not the traditional web server interface to your app can still serve HTML from the server. It's just as easy to wrap API methods on the server and feed that data into a server side template as it is to call the API from a client side method (well, it's actually much easier, no need to manually futz with the brows…

That's exactly what I intended to say but you said it better :)

Re: PHP: the quiet powerhouse

#134

Post by techiferous »

ericingram wrote: post #122
techiferous wrote: post #112

Earlier quoted context omitted.

It depends what you are trying to do. If you are only targeting browsers, and especially if you don't need a lot of responsiveness, it's much simpler to just render views on the server side and optimize your server for speed. It takes a lot of effort to write a thick client. But if you are targeting a browser and a native iPhone app, the view logic lives on the iPhone app. It used to be that you could just serve up a…

I think I see what you're talking about: more non-browser clients exist so the web servers need to be able to expose an API. I agree with that. Besides that, the ability to "template" output on the server is still my ideal way to transform the business API to something the client can read. In the case of a browser, I'm templating for HTML. For a mobile app, we may just pass through in JSON and let the native mobile a…

Well said. I think this is the best way of putting it. I temper my original position of saying that server-side view rendering is "on its way out".

Re: PHP: the quiet powerhouse

#135

Post by ericingram »

Mikushi wrote: post #126
djur wrote: post #95

Earlier quoted context omitted.

"Rails" isn't a language, and PHP has fundamental design flaws that those other languages don't have. It's not that it has flaws, it's that it has unavoidable flaws.

It's something I find interesting. PHP "haters" keep pointing at flaws, yet in almost 10years of doing PHP, the only thing that really ever annoyed me is the string and array parameters order... And I've done a wide range of thing in PHP, including scaling websites to millions of pageviews per day. PHP might have design flaw, but in the end, they don't matter because they actually don't affect the day to day develope…

This is how I feel too. PHP to me has been ideal for getting things done, but I suppose those who harshly criticize it are concerned with some obscure purity that has less to do with getting things done than style preference.

Re: PHP: the quiet powerhouse

#136

Post by mgkimsal »

chaostheory wrote: post #119
mgkimsal wrote: post #91

Earlier quoted context omitted.

I've been working with PHP since 1996 and rarely see eval being used. I've worked with hundreds of companies training PHP developers, seen inside (and written) some very large codebases handling millions of dollars of transactions, and don't recall seeing eval in any of them. "it was easy to see why PHP got big" It's easy to see why it's staying big: 1. cheap shared hosting to get started 2. most hosts offer one-clic…

> I've been working with PHP since 1996 and rarely see eval being used. For some reason most of the major frameworks use it, hence their incompatibility with hiphop; then again I could be wrong. > 1. cheap shared hosting to get started One can argue that all of the major languages have access to this. PHP doesn't have an edge in this area. > 2. most hosts offer one-click installation of any sort of application people…

>No argument here. My points only apply for people starting now, and not for PHP vets.

I wasn't meaning for people - I meant 'the industry' as a whole (or a large segment) - standing on the shoulders of giants and all that.

>> 1. cheap shared hosting to get started

>One can argue that all of the major languages have access to this. PHP doesn't have an edge in this area.

Really? I think there's far more options for people with 'PHP' in the hosting arena. It's not that you can't use other languages/platforms, but ... competition for hosting basic PHP stuff is massive - not so much for Ruby/Rails, Python, etc. along with all the extra stuff you'd need (community libraries and such) - much more is baked in to PHP hosting than you get with the majority of other platforms. Java in particular is expensive to host anything useful because it's RAM hungry.

re: eval - do you have pointers to examples? I just grepped Zend Framework 1.10, and there was 1 eval, in Serializer/Adapter/PhpCode.php, with a warning that it shouldn't be used.

Re: PHP: the quiet powerhouse

#137

Post by lucperkins »

guard-of-terra wrote: post #131
lucperkins wrote: post #130

Earlier quoted context omitted.

But how often does trying-to-be-better-and-failing come along and torpedo good-enough-for-the-job?

Would you listen to "good enough" music or watch "good enough" movies? When I ask this, I think, many do. But I don't. Do you?

No. Sometimes I spend a lot of time and effort seeking out niche genres and digging through blogs and news sites to find "good" music. But sometimes I don't want to put in all that effort, and then putting on "Kind of Blue" or the first Weezer album is "good enough." There is room for both approaches to music listening.

Re: PHP: the quiet powerhouse

#138

Post by Joeri »

LnxPrgr3 wrote: post #106
Joeri wrote: post #31

Earlier quoted context omitted.

The realities of roundtrip time won't go away. Serverside rendering will always delivers worse responsiveness. Blame physics.

http://engineering.twitter.com/2012/05/improving-performance... Discuss.

Twitter is a web site, not a web app. First-page load performance is critical for them. I wouldn't have chosen a client-side rendering architecture.

My perspective is that of web apps. By using client-side rendering I can prefetch more data than the user needs at almost no extra cost, and render it when they click without hitting the server. Not having to contact the server at all beats any server-side rendering architecture. Even web apps that supposedly do server-side rendering will end up with some prefetching for performance (e.g. tooltips and detail panes are already embedded in the page but hidden).

The reality is that the big bottleneck in any web app is not the fetching of data but the fetching of the front-end. The more front-end code (images, js, css) that you can fetch from browser cache or CDN the faster your app. The "ideal" case is not having to fetch anything except the data from the server. You can do that today with client-side rendering combined with far-future expiration or HTML5 appcache. The caveat here is that the performance benefits only start compounding for client-side rendering if you can prefetch data. Twitter couldn't do that, so there was no benefit.

Like any complex technical issue, there is no right answer in general, only a right answer in context. People should just be careful about what they're measuring. The important benchmark is time to load the page, not time to process the page on the server (a huge difference), and measurements should be globally distributed (you should be measuring transcontinental page visits).

Re: PHP: the quiet powerhouse

#139

Post by chaostheory »

mgkimsal wrote: post #136
chaostheory wrote: post #119

Earlier quoted context omitted.

> I've been working with PHP since 1996 and rarely see eval being used. For some reason most of the major frameworks use it, hence their incompatibility with hiphop; then again I could be wrong. > 1. cheap shared hosting to get started One can argue that all of the major languages have access to this. PHP doesn't have an edge in this area. > 2. most hosts offer one-click installation of any sort of application people…

>No argument here. My points only apply for people starting now, and not for PHP vets. I wasn't meaning for people - I meant 'the industry' as a whole (or a large segment) - standing on the shoulders of giants and all that. >> 1. cheap shared hosting to get started >One can argue that all of the major languages have access to this. PHP doesn't have an edge in this area. Really? I think there's far more options for pe…

> I wasn't meaning for people - I meant 'the industry' as a whole (or a large segment) - standing on the shoulders of giants and all that.

Ruby and Python aren't very new. There are giants there as well. If you're going to make that argument, then Java has a bigger advantage.

> I think there's far more options for people with 'PHP' in the hosting arena.

As I've already said, I don't disagree. I just said that this advantage is going away. Personally I'd also rather go for host that's mid-ranged as opposed to hosts that are in the race to the bottom. I don't think paying $10 more a month is exorbitant especially if it buys you a lot of language power and it takes over more sysadmin duties from you.

> re: eval - do you have pointers to examples?

Every major PHP framework uses it. How do I know? To my knowledge you can't use any of them with Facebook's hiphop out of the box. I suspect this is one of the main reason's no one uses hiphop even though it gives you a good deal of performance gains for PHP.

Re: PHP: the quiet powerhouse

#140

Post by mgkimsal »

chaostheory wrote: post #139
mgkimsal wrote: post #136

Earlier quoted context omitted.

>No argument here. My points only apply for people starting now, and not for PHP vets. I wasn't meaning for people - I meant 'the industry' as a whole (or a large segment) - standing on the shoulders of giants and all that. >> 1. cheap shared hosting to get started >One can argue that all of the major languages have access to this. PHP doesn't have an edge in this area. Really? I think there's far more options for pe…

> I wasn't meaning for people - I meant 'the industry' as a whole (or a large segment) - standing on the shoulders of giants and all that. Ruby and Python aren't very new. There are giants there as well. If you're going to make that argument, then Java has a bigger advantage. > I think there's far more options for people with 'PHP' in the hosting arena. As I've already said, I don't disagree. I just said that this ad…

"Every major PHP framework uses it. How do I know? To my knowledge you can't use any of them with Facebook's hiphop out of the box. I suspect this is one of the main reason's no one uses hiphop even though it gives you a good deal of performance gains for PHP."

Zend Framework 1.10 - a fairly high-profile framework - has 1 instance of eval in a component I've never known anyone to use. I suspect hiphop has a few other issues with it, but... even more to the point, I don't think most people think they need hiphop. It's an unknown - it's a compilation step, and adds a couple extra steps of complexity. People can get a lot of performance gains by using Zend Server caching or APC with far less unknowns vs digging in to hiphop.

Additionally, hiphop has had some issues with postgres/pdo, closures, imap and more PHP stuff over the last year or so. It's a nice thing from facebook, but it was written for their own problems, not as a general use tool for everyone. If it can evolve in that direction, the adoption may go up. Until then there's far more well-tested ways to improve your performance of PHP.

Post reply on HN