I haven't used Laravel, but PHP tends to be relatively easy to get a development environment running as well as deploying on shared host type environments. On the flip side, the application becomes ever intertwined with the host environment, and beyond that, PHP libraries and frameworks tend to lack a lot of discipline that you find in other languages (that is, you find yourself pondering things like, "what if I were running this across many boxes, oh it'd just break..."), so 12-factor readiness (which helps when you want to run your app on more than one machine) tends to be an afterthought.
I haven't worked with Phoenix or even Erlang/Beam that much (though I've used Rabbit quite a bit). I think the overall model of the runtime is brilliant, but I'm not sure you need to buy in to the whole ecosystem to benefit from the learnings of it. There are actor systems for a lot of languages (Celluloid and Akka come to mind). Celluloid works nicely for weird long running things. I'm not totally sure how much it matters for your typical web app that would work fine enough with a CGI model (though I guess it's not totally different).
I've only played with Meteor, but I've used Node and React pretty extensively. React in particular is brilliant. It provides a nice way of thinking about the UI of your app in a more functional way. Of course, the devil's in the details, but it works pretty well. I'm less keen on Node as a backend language. A lot of backend code is between the lines, waiting on the DB or dealing with crazy errors. Node and JavaScript aren't very good at those things today. ES7 Async functions have some promise (hah!), but interoperating between libraries can be a little confusing at first.
Rails is an old friend of mine. You can do a lot with Rails, and it's almost sacrilege to say these days, but a well written monolithic, non-javascript heavy Rails app can be a joy to work in. It's pretty good for CMS type content; I've used it a bit to build various web stores to good effect. Things can get hairy when you try and step outside of "the Rails way", but that's less of an issue these days. It can also be a little funky using the asset pipeline with newer frontend libs, but there's that nifty source that packages frontend libraries as gems (the name eludes me at the moment).
PHP is shared-nothing, how is 12-factor readiness something of an afterthought? I've worked on numerous PHP applications and services that are scaled out horizontally with less issues than I've had (with that specific use-case, PHP as a whole still has other issues) in doing the same with Node at times. Basically, I'm curious what sort of libraries you're talking about where horizontal scaling breaks them?
I haven't worked with Phoenix or even Erlang/Beam that much (though I've used Rabbit quite a bit). I think the overall model of the runtime is brilliant, but I'm not sure you need to buy in to the whole ecosystem to benefit from the learnings of it. There are actor systems for a lot of languages (Celluloid and Akka come to mind). Celluloid works nicely for weird long running things. I'm not totally sure how much it matters for your typical web app that would work fine enough with a CGI model (though I guess it's not totally different).
I've only played with Meteor, but I've used Node and React pretty extensively. React in particular is brilliant. It provides a nice way of thinking about the UI of your app in a more functional way. Of course, the devil's in the details, but it works pretty well. I'm less keen on Node as a backend language. A lot of backend code is between the lines, waiting on the DB or dealing with crazy errors. Node and JavaScript aren't very good at those things today. ES7 Async functions have some promise (hah!), but interoperating between libraries can be a little confusing at first.
Rails is an old friend of mine. You can do a lot with Rails, and it's almost sacrilege to say these days, but a well written monolithic, non-javascript heavy Rails app can be a joy to work in. It's pretty good for CMS type content; I've used it a bit to build various web stores to good effect. Things can get hairy when you try and step outside of "the Rails way", but that's less of an issue these days. It can also be a little funky using the asset pipeline with newer frontend libs, but there's that nifty source that packages frontend libraries as gems (the name eludes me at the moment).