5 ms·

The main comparisons I have are building sites with Ruby/Rails and doing JS front ends attached to REST APIs. All three types of project have their own pros and

The main comparisons I have are building sites with Ruby/Rails and doing JS front ends attached to REST APIs. All three types of project have their own pros and cons.

cies 5y ago
The fair comparison: PHP/Laravel to Ruby/Rails... How is PHP/Laravel better? I'm of the opinion it loses hard in every aspect.
- jacquesm 5y ago
  There is one aspect where it wins hands down that trumps almost every other concern that you might have: availability of developers. This is a hard problem to solve.
  - aeonflux 5y ago
    Raw number of developers doesn't matter at all. The ratio of offers to developers out there determines how easy the hiring actually is. I've tried to hire some quality PHP developers and it's as hard as Ruby/Python if not harder. First thing is, that you always get all the Wordpress people, who fixed one plugin and claim to have 10 years of PHP experience. Then you have to filter out all the 10 YoE who actually have 1 YoE done 10 times. For some reason all this is less of a problem in less popular stacks.
    - jacquesm 5y ago
      It does if the number is '0' vs 'some'. It usually depends on how and where you do your hiring. For those that only want to hire local developers it is very well possible that there are no local Rubyists, it is also possible that it is the other way around. Typically there are a lot more proficient PHP programmers than Ruby programmers around here, but if a company were open to remote workers the situation would right away change considerably. There is also the price factor to take into account. All in all, more often than not developer availability works itself into these choices.
  - cies 5y ago
    A good dev with only PHP skills becomes a better dev when he/she has other experiences. Ruby or Kotlin would not be off by too much. In my experience they productive in days and are up to speed in a few weeks. It's a small investment. Having your code in PHP is a liability considering great free alternatives exist. If you can do it in Kotlin and have your code in a well types language, that is a bit win down the line.
    - jacquesm 5y ago
      I'm not religious about languages, I probably used to be, but I grew up and grew out of it. Having your code in PHP is no more a liability than having it in any other framework/language combo if you don't know what you are doing, and people that don't know what they are doing abound in any eco system. PHP is just a tool, Ruby is just a tool. If you haven't spent an equal time in both you are probably not in a very good position to judge either. I've done a lot of PHP work, I've done a lot of Ruby programming and I dislike either with roughly equal passion to the point that if I never have to code up another website back end my life will be measurably better. The same goes for Python, Java, .Net, Go and whatever else we use to cobble together websites. All of these are broken and leaky at multiple levels and the 'perfect' solution to build websites doesn't exist, in fact I don't think there is even a half decent one. This is a direct consequence of trying to shoehorn application development into a platform that was never meant to be used that way, but that's another discussion entirely. So you pick whatever is least offensive to you and your team, and probably you'll pick that which you are most familiar with or that seems to come closest to a fit for the kind of problem you are trying to solve.
- jensensbutton 5y ago
  Ruby allows you to do even more stupid things than PHP does. It's also slower.
- heurisko 5y ago
  I'm more of a fan of PHP/Symfony rather than PHP/Laravel. But you know what? I would expect I would like Ruby/Rails as well, as it follows the similar kind of philosophy, which is server-side rendered templates with Javascript sprinkles. I think Rails and Symfony both have the benefit of being a fairly consolidated solution. You don't seem to have the same proliferation of packages, as with Javascript. What I'm not a fan of, is Javascript SPAs where there is no reason for using them.
- aarondf 5y ago
  I think one of the key things about Laravel is that the creator, Taylor Otwell, is only focused on Laravel. Imagine if DHH didn't ever have Basecamp (or 37 Signals) and only focused on Rails and the Rails ecosystem. The Laravel team now has several full time employees working on making the entire Laravel experience as painless as it can be. Of course Taylor and the Laravel team have paid products, but they are all 100% focused on the Laravel ecosystem and developer experience! Some of the things that the Laravel ecosystem has as first party packages / services: Paid: • Vapor - Serverless Platform. Run your vanilla Laravel apps on Lambda. • Forge - Server Management. Builds Laravel ready servers on any cloud. • Envoyer - Zero Downtime Deployment. Deploy your apps with push-to-deploy. • Nova - Administration Panel. Completely code-driven admin panels. • Spark - SaaS App Scaffolding. Basically a SaaS starter kit. Free: • Horizon - Queue Monitoring. Like Sidekiq • Jetstream - App Scaffolding. SaaS starter kit with teams, invitations, api, etc. • Echo - Realtime Events. Think Pusher, Socket.io, etc. • Sail - Local Docker environment. • Valet - Dev Environment for Macs. • Mix - Webpack Asset Compilation. A sane wrapper around webpack. • Cashier - Subscription Billing Integration. Stripe + Paddle. • Dusk - Browser Testing and Automation. First party browser automation for tests. • Sanctum - API / Mobile Authentication. • Laravel Scout - Full-Text Search. Wrapper around Algolia, Melisearch, or full-text database searching • Socialite - OAuth Authentication. Log in with GitHub, Google, etc. Dozens of community packages as well. • Telescope - Debug Assistant. That's all first party. It's unbelievable to me how many batteries are included. Then you start looking at the surrounding ecosystem beyond that and it gets even crazier. Laravel as a community is an extremely welcoming place, and I have found that most people care deeply about their code and architecture, but don't pick each other to death on details that don't matter. I think all in all it's a pretty pragmatic group.
- ramesh31 5y ago
  >How is PHP/Laravel better? I'm of the opinion it loses hard in every aspect. Performance. Ruby (with the official implementation) is brutally slow compared to PHP on Zend Engine [0], which is probably only behind the JVM in terms of VM performance and optimization for any language. PHP, if done properly, is a really great choice nowadays for a scripting language that can approximate C++/C#/Java levels of performance. [0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/ruby-php.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - cies 5y ago
    > PHP, if done properly, is a really great choice nowadays. Same for Ruby. I found them both slow compared to compiled to native langs. JVM is also slow (especially startup)

The main comparisons I have are building sites with Ruby/Rails and doing JS front ends attached to REST APIs. All three types of project have their own pros and cons.

cies 5y ago

The fair comparison: PHP/Laravel to Ruby/Rails... How is PHP/Laravel better? I'm of the opinion it loses hard in every aspect.

jacquesm 5y ago
There is one aspect where it wins hands down that trumps almost every other concern that you might have: availability of developers. This is a hard problem to solve.
- aeonflux 5y ago
  Raw number of developers doesn't matter at all. The ratio of offers to developers out there determines how easy the hiring actually is. I've tried to hire some quality PHP developers and it's as hard as Ruby/Python if not harder. First thing is, that you always get all the Wordpress people, who fixed one plugin and claim to have 10 years of PHP experience. Then you have to filter out all the 10 YoE who actually have 1 YoE done 10 times. For some reason all this is less of a problem in less popular stacks.
  - jacquesm 5y ago
    It does if the number is '0' vs 'some'. It usually depends on how and where you do your hiring. For those that only want to hire local developers it is very well possible that there are no local Rubyists, it is also possible that it is the other way around. Typically there are a lot more proficient PHP programmers than Ruby programmers around here, but if a company were open to remote workers the situation would right away change considerably. There is also the price factor to take into account. All in all, more often than not developer availability works itself into these choices.
- cies 5y ago
  A good dev with only PHP skills becomes a better dev when he/she has other experiences. Ruby or Kotlin would not be off by too much. In my experience they productive in days and are up to speed in a few weeks. It's a small investment. Having your code in PHP is a liability considering great free alternatives exist. If you can do it in Kotlin and have your code in a well types language, that is a bit win down the line.
  - jacquesm 5y ago
    I'm not religious about languages, I probably used to be, but I grew up and grew out of it. Having your code in PHP is no more a liability than having it in any other framework/language combo if you don't know what you are doing, and people that don't know what they are doing abound in any eco system. PHP is just a tool, Ruby is just a tool. If you haven't spent an equal time in both you are probably not in a very good position to judge either. I've done a lot of PHP work, I've done a lot of Ruby programming and I dislike either with roughly equal passion to the point that if I never have to code up another website back end my life will be measurably better. The same goes for Python, Java, .Net, Go and whatever else we use to cobble together websites. All of these are broken and leaky at multiple levels and the 'perfect' solution to build websites doesn't exist, in fact I don't think there is even a half decent one. This is a direct consequence of trying to shoehorn application development into a platform that was never meant to be used that way, but that's another discussion entirely. So you pick whatever is least offensive to you and your team, and probably you'll pick that which you are most familiar with or that seems to come closest to a fit for the kind of problem you are trying to solve.
jensensbutton 5y ago
Ruby allows you to do even more stupid things than PHP does. It's also slower.
heurisko 5y ago
I'm more of a fan of PHP/Symfony rather than PHP/Laravel. But you know what? I would expect I would like Ruby/Rails as well, as it follows the similar kind of philosophy, which is server-side rendered templates with Javascript sprinkles. I think Rails and Symfony both have the benefit of being a fairly consolidated solution. You don't seem to have the same proliferation of packages, as with Javascript. What I'm not a fan of, is Javascript SPAs where there is no reason for using them.
aarondf 5y ago
I think one of the key things about Laravel is that the creator, Taylor Otwell, is only focused on Laravel. Imagine if DHH didn't ever have Basecamp (or 37 Signals) and only focused on Rails and the Rails ecosystem. The Laravel team now has several full time employees working on making the entire Laravel experience as painless as it can be. Of course Taylor and the Laravel team have paid products, but they are all 100% focused on the Laravel ecosystem and developer experience! Some of the things that the Laravel ecosystem has as first party packages / services: Paid: • Vapor - Serverless Platform. Run your vanilla Laravel apps on Lambda. • Forge - Server Management. Builds Laravel ready servers on any cloud. • Envoyer - Zero Downtime Deployment. Deploy your apps with push-to-deploy. • Nova - Administration Panel. Completely code-driven admin panels. • Spark - SaaS App Scaffolding. Basically a SaaS starter kit. Free: • Horizon - Queue Monitoring. Like Sidekiq • Jetstream - App Scaffolding. SaaS starter kit with teams, invitations, api, etc. • Echo - Realtime Events. Think Pusher, Socket.io, etc. • Sail - Local Docker environment. • Valet - Dev Environment for Macs. • Mix - Webpack Asset Compilation. A sane wrapper around webpack. • Cashier - Subscription Billing Integration. Stripe + Paddle. • Dusk - Browser Testing and Automation. First party browser automation for tests. • Sanctum - API / Mobile Authentication. • Laravel Scout - Full-Text Search. Wrapper around Algolia, Melisearch, or full-text database searching • Socialite - OAuth Authentication. Log in with GitHub, Google, etc. Dozens of community packages as well. • Telescope - Debug Assistant. That's all first party. It's unbelievable to me how many batteries are included. Then you start looking at the surrounding ecosystem beyond that and it gets even crazier. Laravel as a community is an extremely welcoming place, and I have found that most people care deeply about their code and architecture, but don't pick each other to death on details that don't matter. I think all in all it's a pretty pragmatic group.
ramesh31 5y ago
>How is PHP/Laravel better? I'm of the opinion it loses hard in every aspect. Performance. Ruby (with the official implementation) is brutally slow compared to PHP on Zend Engine [0], which is probably only behind the JVM in terms of VM performance and optimization for any language. PHP, if done properly, is a really great choice nowadays for a scripting language that can approximate C++/C#/Java levels of performance. [0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/ruby-php.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- cies 5y ago
  > PHP, if done properly, is a really great choice nowadays. Same for Ruby. I found them both slow compared to compiled to native langs. JVM is also slow (especially startup)