The Laravel framework[1] is a good place to start, it's quite well designed and elegent. It requires at least PHP 5.4.
PHP is ubiquitous on shared hosting platforms, there aren't that many "shared" Rails hosters out there. Morts still use shared hosters.
Exactly the kind of things I don't want to be bothered with. I'm just saying that traditional web hosts suit my needs perfectly and DigitalOcean is no replacement.
traditional web hosts provide a level of management that isn't present in VPSes. You may be able to get turnkey instances, but you still have to be responsible for managing them and maintaining them. Vs a traditional webhost where you don't have to worry about all that.
You can claim that its "outdated" and "akin to using tables for layout", but its also still a very valid workflow for a lot of people who don't want to be sysadmins in addition to developers
Kiro quotes two items from the parent, and says he doesn't want to be bothered with "those" things.
Kinda implies he doesn't use git, since that was one of the two items quoted.
Leaving aside the whole "PHP sucks" vs "PHP is great/fine for my purposes" thing, this is really breathtaking. The fact that you can just FTP up your folder does not mean that's a sensible best-practice way to deploy anything, PHP, Ruby, Brainfuck or whatever you like. It isn't. FTP is insecure[0]. If you're balking at 'git push', then presumably you're balking at source control, which involves a lot of that sort of thing. That is just entirely unprofessional.
And 'no replacement'? FTPing a bunch of stuff into a public folder allows you to deploy something quickly and easily. So does the GP's suggested workflow. It is, exactly, a like for like replacement - except that it's a more secure and less fragile workflow.
I repeat - this has no bearing on the pro/anti-PHP holy war (I lean towards anti, but there's good PHP code out there, whatever. Hopefully a proper language spec will shove things in the right direction). If your argument for PHP is that it allows you to easily evade responsible working practices in software development, however, you're getting dangerously close to the anti-PHP stereotype of the average PHP developer.
[0] http://en.wikipedia.org/wiki/File_Transfer_Protocol#Security
Even if I can configure it down to two clicks it still comes with the cost of having to worry about maintaining a VPS.
Really [0]?
>however, you're getting dangerously close to the anti-PHP stereotype of the average PHP developer
I think you're getting dangerously close to coming off as condescending and insulting.
Despite what you may think, plain old fully managed shared hosting is still massively popular, especially here in the UK.
Our client base are design and development houses who want a reliable, tinker-free fully managed, predictable and secure environment. These folks aren't as backwards as you think, they already have a development workflow that works just fine. They push their stuff to their htdocs folder (via FTPS) and it just works. We even support WebDeploy (also secure) on the Windows platform so they can build MS deploy packages and push them up.
Most of our clients do use source control, they're not that naive but not all of them have drank the Github Koolade. They're happy with their own private source control arrangements.
It's an environment and process that's tried and tested so they can get on with building apps that pay the rent and keep the lights on without futzing about with dynos and droplets and the like. Not only that they can pick up the phone and within two rings get access to an experience frontline engineer who will fix a problem or answer a question within a couple of hours.
I can speak about this from experience as an engineer who works for a UK shared hoster. Admittedly we're not a bulk shared-hoster like GoDaddy, our services are tailored towards the needs of business clients, not someone's granny deploying a Wordpress site with pictures of cats.
[0]: http://en.wikipedia.org/wiki/File_Transfer_Protocol#FTPS
Frameworks and languages are a lot like databases. They all achieve the same thing, they're just all slightly different and good for different purposes. I sometimes use MySQL, other times I'll use PostgreSQL, sometimes I might use a graph database like Neo4j or other times I might even use something like MongoDB.
The Rails community has been around a lot longer than Laravel's community, so you can't even compare them. The only community worthy of being compared to Rails is Codeigniter's and at the peak of Codeigniter's popularity, I would argue Codeigniter had the bigger community. Laravel is a mere couple of years old, the community is already pretty strong. Lets reevaluate soon when the right amount of time has passed and then see where the community is at. You only have to look at the amount of Github stars to see how popular it is.
MySQL vs PostgreSQL vs MongoDB vs Neo4j are all data stores with very different principles and goals. To say they all "achieve the same thing" is like saying an airplane is the same as a speedboat because they both get you from point A to point B.
I certainly believe that frameworks and libraries are tools for different problems and there isn't a one size fits all approach, I just have trouble discerning what problem Laravel is solving better than other frameworks or what makes it advantageous to use.
... using mostly 3rd party components, the majority from Symfony. So no, it's not "built by one guy".
It would be in the best interests of Laravel for Symfony to succeed, but you have to realise they're targeting two different subsets of users. I think what makes Laravel more appealing to me as a developer is it takes the good from the likes of Symfony, takes the great documentation and accessibility aspect from Codeigniter all while remaining a relatively soft opinionated framework, it provides you with a structure but the IoC container means you can structure it however you want. The Blade templating system is fantastic, the ORM is feature-rich and very powerful and the addition of database migrations right out of the box.
There isn't a lot of different between Laravel and Symfony considering they share similar components and the unique selling points of Laravel are components that can be used within a Symfony 2 application. I think Laravel gives you a little more out-of-the-box, whereas Symfony makes you add what you need and I can see the benefits from both sides of the fence. If you want to compare frameworks, a real comparison would be Laravel and Silex.
One aspect I like about Symfony is the ability to define routes 4 different ways; YAML, PHP, XML and Annotations in a controller. Compared to Laravel's routes.php file. If you're a developer that wants to customise absolutely every single aspect Symfony is probably a better choice, if you're happy with the guiding hand Laravel gives you out-of-the-box and don't care what format your configuration files and routes are written in (amongst other aspects), Laravel is the better choice. The learning curve of Symfony is far higher than Laravel due to the amount of configuration it allows you to do and the fact it is completely unopinionated.
So, while Taylor didn't build every aspect of the framework (a very well-known fact), there are certain aspects he did build specifically for Laravel. He also took the time to piece all of the components together from Symfony and other authors to create what is arguably one of the most developer friendly PHP frameworks since Codeigniter hit the scene in 2007. Before Laravel came along, I can't recall anyone else attempting to make a consumer friendly framework, can you?
Laravel on the other hand is exactly where Codeiginiter was: easy to pick up, and easy to write crap code in. The whole Facade nonsense is already being abused to no end, not to mention the ORM, Eloquent. Similarly to CI, if you want to do something remotely advanced with it, you end up reading the code constantly, because the "great" 10 page documentation is only for absolute beginners.
The best example has to be the templating languages used. Blade is a weird port of ASP.NET MVC's Razor syntax and I've never understood why anyone would use it over Twig (or even just raw PHP).
It's weird that a framework so self-consciously dedicated to 'best practices' would ignore what's considered one of, if not the, best templating systems in PHP. Particularly given the extra benefits twig provides out of the box (automatic escaping, a function sandbox, hooks for writing your own plugins and parsers, etc.)