No it doesn't. I hate PHP with a passion, but there are lots of PHP devs out there who will welcome it if your project solves some problem they have, and they will contribute.

Don't change the language of your project just because of popularity. Use node, python, ruby only if the end result will be a significantly better then the current is. When I say significantly I mean compared to the time you will spend to convert it.

In terms, of end users, those that will actually use the dashboard. They don't care what language you use.

What's the purpose of open sourcing it?

Do you (or your company) want to be running a project and getting patches and contributions back? Who is the target audience?

In the last year or so I've open-sourced a project I did for a state agency (done in Java) - every single request I get from people about the code is "is it in php? can i install it like wordpress or moodle?"

PHP is going to give you a huge pool of potential users and contributors simply because of its reach. Whether that's who you're aiming at or not is a different question.

The purpose is simply to give back and hopefully have wider user than ourselves to build a better tool besides our explicit use-case.

Since we're using AngularJS+D3+Symfony specifically, I figured others could at least learn the same way I did by seeing a real application using these technologies rather than the usual example apps.

The target audience consists of users like me, which need a simple live dashboard to see high-level metrics and tell (1) if anything may be wrong and (2) if performance is improved for a custom application using MySQL, Postgres or MongoDB.

It's not meant to be a BI solution like QlikView (which the company uses internally and is awful), but something light, embeddable, and doesn't require `for..each`ing custom SQL queries and mapping it to D3 just to make sure the last deployment didn't break anything.

I'm very surprised that users wanted something in PHP or as installable as Wordpress. The installable part is pretty simple, and most configuration is done on the client-side. I just wasn't sure if a Node backend would be more accessible to this audience.

I'm not at all surprised. Average every day people are asking for this, not professional coders. The uptake of projects has a lot to do with installability - if they can't install it, they can never use it or tell others to use it.

"The target audience consists of users like me" and "we're using AngularJS+D3+Symfony specifically" = you're not really an average developer - certainly not an average PHP developer, and certainly not an end user who might want a dashboard.

Personally, I'd say keep it with PHP for now. If it gets users and grows, so be it. If not, and you have time to branch out in to other tech based on real business needs, branch out at that point.

I agree with keeping it PHP for now. Take a Lean Startup approach and think of this as your MVP. When you have actual users they will help you decide what other languages/technologies you can use to improve performance etc. but don't optimize prematurely. PHP will be just fine.

Perhaps you'd be better splitting it in to two projects: client and server. That way you can easily add support for other languages.

Personally, I'd love to see a Node version as I'm currently writing a (sort-of) CMS using node.js and angularjs, I've been looking for something to help with graphs on my dashboard and there's not much out there at the moment.

Node would likely get you fewer eyes on the project than PHP. There's nothing wrong with PHP, and I think you're overvaluing the 'stigma' associated with the language.

PHP is not beautiful or elegant, but it gets the job done.

> PHP is not beautiful or elegant, but it gets the job done.

I'm confident your mind can be changed on that. Mine has :) (WordPress vs. Symfony is a good example "normal" PHP to "elegant" PHP code)

Symfony makes PHP about as elegant as Java.

I've never heard anyone argue that Java is elegant.

Elegance to me is strong types & classes, decoupled. Elegance to you may be more about loose types and flatter structure?

What about providing multiple backends? I've seen some projects like that where it's heavily front end driven and they provide a few different backends to let you choose.

That may work! The one downside is that the backend is caching much of the data to prevent round-trips, so that logic would be repeated for each.

To your point, it still isn't that much to reimplement, since the architecture would be quite similar for each backend.

yeah i agree. make the backend lightweight and modular so it can be swapped out as needed