Ewww, You Use PHP? (2010) | Hacker News Reader

Ewww, You Use PHP? (2010)

blog.mailchimp.com

90 pointsyarapavan44 comments

My company's product backend is written in PHP. I'm currently rewriting it, and when I started the process, I tried doing it in Node.js because 1) the possibility of client/server code sharing and 2) that's what all the cool kids were doing. That lasted all of a few weeks before the async nature of Node made my head nearly explode. I scraped that and went back to PHP where you can depend on code being executed line-by-line, synchronously, without hacks.

As a language, PHP definitely has some warts. But, it's come a long way, and it keeps getting better all the time.

Personally, I don't think it deserves all the hate it gets. Some criticism is warranted, but definitely not all of it. I think a lot of it stems from the fact that the language is so easy to learn and lets you do things your own way, which (at least in the early days) led to a lot of newbies writing insecure code. See: register_globals (since removed).

That all said, I love PHP. It's simple, yet powerful. It grows with you, and most importantly, it gets the job done.

I agree with the sentiment, but people still write horribly insecure code in PHP because it is so easy.

"the possibility of client/server code sharing"

I have yet to see a good example where this was worth even considering. Model validation seems to be the only real use case and there are so many potential non-JS based clients that you'll likely need a more general solution for that problem anyway. And even for JS based clients, usually the big pain is the UI logic for showing users the errors and helping them correct it, stuff you won't use on the server side.

I had one example of client/server sharing with C#. It was ASP.NET on the server and Unity3d client: all the data model objects were shared and serialization in both direction was a breeze.

In client/server settings with a .NET frontend and a .NET WPF client you can get a lot of code sharing. But in typical web apps with javascript frontend and a a Javascript server I don't think there will ever be much sharing.

It's useful for views, I've done it with React. But yes more for demo apps than in production, at some point things break down because you can't write both server-side and client-side code handling for every UI state.

> you can't write both server-side and client-side code handling for every UI state

I'm interested, what do you mean? Can you give an example?

As far as I can tell, whatever you serve to the client is also available server-side. You render it there, send it down the pipe as static HTML and hydrate it client-side seamlessly.

Except for specific cases where client's local storage has a significant amount of data, of course, but that seems more like the exception than the norm.

Like if you have an error saying "no results for this book title", you'd have logic that sends JSON and checks that, and on the server side you'd need logic that checks the POST request and checks that (and there'd be subtle differences in the variable format between the JSON & regular HTML POST data), and then maybe the way the UI element would be displayed in JS vs in the server-side HTML is also different. I think if you try to be very fastidious about making everything work without JS you will have two code paths for many things.

Not sure I agree with the example at all. Maybe I didn't understand?

> you'd have logic that sends JSON and checks that, and on the server side you'd need logic that checks the POST request and checks that

Sending != receiving. That's not duplicate code, it's just different functionality.

> (and there'd be subtle differences in the variable format between the JSON & regular HTML POST data)

I don't see why.

> and then maybe the way the UI element would be displayed in JS vs in the server-side HTML is also different.

Why would you do that? Inconsistent UI is bad. I'd expect the same UI whether I got the page via URL or via AJAX.

What JS code sharing gives you is the same server-side and client-side rendering. E.g. you can send fully rendered HTML or just JSON depending on the Accept header, saving on data and full-page refreshes but still having SEO (and not having to wait for client-side to render).

You can also share the same model in both environments (like having the same Book class, which you'd have to code twice in JS and whatever server-side language you use).

Trust me, although I've written a tutorial about this[1], it's not that straightforward to do for a live site :) To put it another way, making the same app work with and without JS isn't made much easier even if you use React server-side rendering. But if you make something like that I'd be happy to check it out (contact info in profile.)

[1] https://medium.com/@firasd/quick-start-tutorial-universal-re...

We share model validation, internationalisation functions / string parsing and formatting values (language strings, datetime formats, currencies, etc), access rules, configuration settings, views and constants at least.. I've also had a few situations where we've moved client side code to the server, and not having to rewrite from scratch is nice.

None of these are huge issues to solve with a separate language on the server. But for our projects it's been a time saver.

Doing operation transform (OP) on ODF in WebODF uses JS code that can run in the client in peer to peer mode or on the server.

You can make nodejs front facing, use the same code for views on server and client, and still defer your real backend (any language, probably APIs only) behind nodejs.

Syntactically, PHP is atrocious. But it has a lot of very good qualities as a web environment, which has nothing to do with the syntax of the language.

Easy to use documentation. "Batteries included" standard library that specifically caters to web dev. Shared-nothing architecture. No separate compilation step. Easy deployment via source code. Ability to use PHP files as configs and templates. In more recent times, autoloaders and APC cache.

As far the language goes, I also like their approach to dynamic invocations via __call. Very simple and powerful.

> Syntactically, PHP is atrocious.

Saying "<PHP's syntax> is atrocious" has always been spurious (or simply mischaracterized as "I like X better"). Compared to what? C or Erlang or Haskell? It's really damaging to credibility to start with flamebaiting.

He likes PHP, but its syntax is not the best. It's not a matter of taste, because its syntax is inconsistent.

See http://www.phpsadness.com/, specifically Inconsistency and Cruft.

Hey, I like PHP too. And inelegant syntax is not the end of the world.

> the async nature of Node made my head nearly explode.

There is a reason that paradigm exists, other than to make development frustrating. How do you avoid thread exhaustion in PHP if you synchronously block on a line that could take a really long time to complete? (Making a request to an external HTTP service, for example)

Job server + reasonable timeout/retry limits

> My company's product backend is written in PHP

If it's a pure API (no HTML templating involved) I would use Go today. I personally find nodejs async programming obnoxious. Go isn't perfect (the type system is extremely limited, though It can be cheesed through reflection) but you have access to powerful concurrent constructs without having to write callbacks, promises and all that bullshit. Async programming is fine when it comes to GUI programming (it makes sense to write click event handlers). Having to perform an HTTP request in the backend asynchronously does not. Gimme threads,queues and pools and let me think synchronously.

Now if your backend is about serving some HTML files and forms, keep using PHP,there is very little reason to rewrite it in another language, that's where PHP shines.

Tend to echo your thoughts here. I spent a lot of time in PHP and even though I don't use it much anymore, it does not deserve all the hate it gets.

Expounded on that in this bit that HN picked up a while back: http://www.brightball.com/articles/no-such-thing-as-real-pro...

I wonder why people limit themselves to PHP, Python, Ruby, and Node, While Java has good presence in sync & async world.

Honestly, I think just because it's so exceptionally un-cool. PHP may not be that cool either, but Facebook uses (has used?) it, and it's at least not as strict and "enterprise-y" as Java.

Because they use what they know and those tool works for them (solve their problem).

While Java devs are fighting with the eclipse issue of the day, generating wsdls, deploying wars, making annotated glorified structs for typed json/xml/both (except in some cases when they just go with a Map<Map<....,String>,String>), and so forth, those other dynamic languages get out of the developer's way and let them solve their problem with less fuss.

Java's not a terrible option. But it's rarely the best option, especially for Right Now, though it may become the best option later when enough competing concerns have cropped up.

You should check out Spring Boot.

Example: http://spring.io/guides/gs/accessing-data-rest/.

Here you don't even have to write code for controllers or db connections for basic CRUD HATEOAS REST service. Spring takes care of it. The model still needs getters and setters, but you can avoid this with Lombok

Java development today is different.

If all you need is a basic CRUD service, there are even easier options in the PHP/Rails/etc. world. If you have a schema for your data, it's pretty much one command away to generate such a CRUD service. Some of them even give you a nice looking out of the box web interface too. So you're not really selling me... And my day job is in Java, we're pretty modern with Java 8, Jetty 9, Spring, etc. but it still ends up being something like this: https://ptrthomas.files.wordpress.com/2006/06/jtrac-callstac...

Spring Boot may be a bit nicer than the most out of the way method I used years ago (now at https://github.com/stoicflame/enunciate/wiki) which did use Spring for some things, but it's really still far away from what dynamic languages and their ecosystems offer.

It's just that you are used to PHP. Async callbacks can be flattened with either ES6 generators or async/await by using TypeScript (Both of which require transpiling. nodejs alone would understand ES6 without it though.)

It's far better to do background tasks with its parallel capability.

The bigger concern is nodejs app server holds states between requests unlike PHP and as such when you define a static property on a class, it's held between all subsequent requests not giving you a clean state.

I'm trying to get used to nodejs for frontend as well but you should delegate db logics down to database triggers, so you don't have to duplicate logics between different languages if you have multiple or change language later on. Same goes for keeping config files in ini format or other language agnostic format.

> Async callbacks can be flattened with either ES6 generators or async/await by using TypeScript (Both of which require transpiling. nodejs alone would understand ES6 without it though.)

Sounds like a tempting option amirite

I'm no stranger to Node.js. We use it in production for all of our real-time/async stuff. The new ES6 features async/await are cool and all, but it's a late addition to a language that was clearly not designed for synchronous code. If you use them, you just end up with bloated, complex code. For an API, I think Node.js is the wrong tool for the job, personally. PHP is a better fit, IMHO. For real-time/async stuff, it's a different story.

What do you mean by "end up with bloated, complex code"?

You only add '*' and 'yield' (or 'await' and 'async') and write like any synchronous code once you wrap it under co module and such.

async/await is for ES7. TypeScript already has an implemention though.

* Update (12/9/14): We’ve grown a lot since this post was written 4 years ago. Currently, our 7 million users send 400 million emails every day, which works out to just north of 12 billion emails a month. And yes, we still use PHP.

Related slack php usage thread, Taking PHP Seriously, is at https://news.ycombinator.com/item?id=12703751

Thanks for posting this. Some great discussion going on there.

Facebook also uses PHP and has written some great open source tools to speed it up, as well: https://code.facebook.com/projects/backend

Today is apparently PHP day on the HN front page. I'm happy to see a different take on it than the normal hate I see it get.

It might be a sign that after churns of programming languages (explosion) in the last 2 years, people get bored re-writing solved-problems and started to focus on the real thing: solving newer problems and/or making money.

Or... could be a sign that the community is maturing :)

> It’s always been difficult for us to hire really good developers, just because of where we are. Our office is here in Atlanta GA [...]

A lot of talented developers are looking for remote jobs.

It would be economically sensible to take at least a 10% haircut on my salary to not have to commute, just based on the time-value of my labor. I look at a commute the same way I look at travel: it is a cost to me and I expect to be compensated for that.

As a decent dev with a decent CV, it would make complete economic sense for me to work for a company remotely.

Link to dailymotion php deployment usecase - http://engineering.dailymotion.com/php-7-deployment-at-daily...

PHP might be getting better. But have you considered that most programmers just don't want to use it? They've already invested in learning better langauges and they aren't waiting on them to get better. The most important choice you can make when starting a project is picking the right tools for it, and PHP probably isn't the one. Lots of other tools are just as capable, and often more so.

It would be interesting to see what PHP 7's speed can do for them.

Speed and lower memory utilization are great, but PHP7 really is just full of goodies:

* Scalar type declarations

* Return type declarations

* null coalescing operator (the real MVP)

* spaceship operator

* introduced Throwable, big improvement to error handling

* removed PHP4 style constructors

* removed the old mysql extension

Most modern PHP codebases should be able to upgrade from PHP5.6 to PHP7 seamlessly

> * null coalescing operator (the real MVP)

I'm glad someone appreciates it that much! Since helping introduce it, I haven't found as much use for it as I expected.

25 uses in my current codebase vs 5 for spaceship

It's not so much about the count though, but the beauty of it:

$id = trim($options[$longCamelCaseID]['abcdefg'] ?? "");

A real godsend

Reply on news.ycombinator.com