The original code base was in PHP. Very, very terrible proceduralish PHP. Since we have to continue to maintain the current system while we rewrite we can implement once and port that code (if necessary) to the new system with minimal effort.
Could I switch us to Rails? Yes, but I don't see the point. We're a PHP shop and in my professional opinion (having used both extensively) Symfony 2 is virtually on-par with something like Rails and switching at this stage of the game would be project suicide.
* If you're using Rails, and like it - stick with it.
* If you're using a good PHP framework like Symfony 2 or Zend Framework, and like it - stick with it.
You'll be just as productive and successful either way.
I agree. My primary languages are C# and PHP. My C# background heavily influences the way I write PHP code using heavy OOP principals and even type-safety (using instanceof) where needed.
I avoid using associative arrays as return objects when arrays of real objects (or type-safe collections of objects) are better suited.
So I think that you can write really nice code with PHP and a good framework. It's more about the software architecture than the language.
Sounds like a perfectly normal professional stack to me: solid tried and proven technology at the foundation for the generic solutions, more hot new stuff around the edges to optimize for specific cases (and let's face it, sometimes just for the hell of it).
It's only the inexperienced unprofessional wannabees that bitch about anything that doesn't use all the cool new toys top to bottom, and try to solve every problem using the coolest tool instead of the most appropriate.
And the only thing "wrong" with PHP is that it's inelegant and inconsistent as language. 90% of the people bitching about PHP couldn't put two solid arguments together.
The argument that it attracts the worst programmers is no longer true since Ruby's "coolness" started attracting large numbers of less than mediocre programmers, proving publicly on Github that you can write crappy code in even the most elegant of languages.
Even if it were true that "90% of the people bitching about PHP couldn't put two solid arguments together," not only is that irrelevant to PHP's merit or lack thereof, it leaves a whole lot of people with valid arguments.
Further, "the only thing "wrong" with PHP is that it's inelegant and inconsistent as language" is your opinion. It is most certainly inconsistent, yes. It also grows and changes in strange, illogical ways, has a history of horrendous built-in defaults and security practices (e.g. REGISTER_GLOBALS, which had a very long life and is likely still enabled on a whole heck of a lot of servers). There are many reasons to avoid PHP.
There are also reasons to avoid most other languages. I and many other people, however, believe that PHP is so far ahead on that list as to be a liability in and of itself.
You're making even more unsupported assumptions regarding what attracts people to Ruby, and I don't know whether this is false dichotomy or some other logical fallacy, but "you can write bad code in Y as well as X" says absolutely nothing about X.
In the end: Yes, if you're careful and skilled, you can probably write solid, secure code in PHP. However, there are more roadblocks to this pursuit in PHP than in any other language I've worked with (9 years of experience in PHP, 6 in Python, less in various other relevant languages).
While there's nothing wrong with PHP per se, it's not like Python/Django or Ruby/Rails is any less 'tried and proven' tech than PHP/Symphony. I would only through stuff like Node.js into the 'hot new stuff' category.
You can tell someone who hasn't had broad professional experience when they are aghast at the idea of a multi-technology stack like this. The reality is any company bigger than startup size is going to be using lots of different technologies for lots of different things, for a variety of reasons. Hopefully all good but sometimes not so good.
I'm curious about the choices that lead to doing the API in PHP/Symfony as opposed to Node, though. I've written APIs in both PHP and Node and it seems to me that Node has the advantage in terms of being more lightweight for the task. So I'd love to hear what Jarrod sees as the advantages PHP presents that make it a better fit.
EDIT:
Got the following response to the question on Twitter, for anyone else curious:
> I have but honestly I'm just not comfortable enough yet w/ Node to a jump. :) We're capable and productive w/ PHP. Maybe in time.
> We're rebuilding an internal app from scratch and it needs to be blazing fast and real-time.
At risk of dragging the OP into a framework/language war...if you're building an internal app from scratch...why use Symfony? Is it because the rest of the Apple internal apps are in PHP/Symfony and it doesn't make sense to have the internal app group write in different frameworks?
(I'm assuming different languages isn't a huge deal, since the OP mentions using Ruby to handle deployment)
OP commented here, but didn't respond to you. They most likely went with Symfony since the original codebase was PHP. Porting to Symfony2 gives modern MVC web app framework tools and structure but has the same environment requirements. So there is very little cost as opposed to switching languages. The Ruby deployment methodology most likely uses Capifony a special extension to the Capistrano ruby gem for deployment built around Symfony and Symfony2.
Compared to Backbone it's a lot more magic. You'll need to write less code, but it may be more difficult when you want to do something a bit more custom.
I'd also say that Ember has a steeper learning curve than Backbone.
Interesting. I don't work for quite so sexy a company as Apple, and positions aren't going to get you working on much hot new tech, so I'm not sure I'd post "we're hiring". I assume most people here have no desire to work at boring old companies, hence the "Wtf php? Are you a noob?" type comments.
Many "boring old companies", well, aren't. I work in Cable and could have written the same job post (subbing Ember for AngularJS in our case). In a culture where results count, and fast results count more, you may be surprised where you can look for jobs.
Edit: It's actually remarkable how close my tech stack lines up. CodeIgniter (php), node.js, JRuby, AngularJS, socket.io, d3 & highcharts, memcached (reddis soon, I think). It's a good time to be a polyglot in the enterprise space.
I assume most people here have no desire to work at boring old companies
That's a really bad assumption. It's actually very difficult to find jobs with established companies because they maintain such a low profile. I wish they would be better at promoting themselves.
Monster.com and the company website usually have a bunch of job listings for the older companies. If you want to work at IBM, Intel, Comcast, Microsoft, Oracle, HP, etc. it isn't hard to find job listings. I'm not sure if if posting on HN is going to attract more applicants for them.
Perhaps those weren't the type of companies you thought I meant, but I work for a company in that category. If you like c#, c++, or Java and love rain 8 months out of the year, we might have a place for you in Oregon...
Not to pick on you specifically but I really wish that (ab)using the word "sexy" for describing companies/products/widgets/thingamajigs starts seeing the same derision as when using "rockstar" to describe developers.
I must've missed the who's hiring thread. I'll tack it on here.
If you want to get in to Ember, we've been using it in production since 0.6. We'll be actively hiring people pretty soon.
Deets are: We're in Manhattan, NYC. We're a team of 3. Use Ember.js, Rails, D3.js and a bunch of crazy backend things including custom stuff. Have lots of paying customers. Lots of money in the bank and we're on our way to be cash flow positive this year.
My contact info is in my profile. We hire opportunistically so while we're not actively looking to fill a position, if you'd be an amazing person to join us, I'd hire you.
The original code base was in PHP. Very, very terrible proceduralish PHP. Since we have to continue to maintain the current system while we rewrite we can implement once and port that code (if necessary) to the new system with minimal effort.
Could I switch us to Rails? Yes, but I don't see the point. We're a PHP shop and in my professional opinion (having used both extensively) Symfony 2 is virtually on-par with something like Rails and switching at this stage of the game would be project suicide.
* If you're using Rails, and like it - stick with it.
* If you're using a good PHP framework like Symfony 2 or Zend Framework, and like it - stick with it.
You'll be just as productive and successful either way.