5 ms·

Just for some context, here's how the items under "Ecosystem" on laravel.com break down on free vs. paid: Free: - Breeze - Cashier - Dusk - Echo - Horizon

Just for some context, here's how the items under "Ecosystem" on laravel.com break down on free vs. paid: Free: - Breeze - Cashier - Dusk - Echo - Horizon - Jetstream - Mix - Octane - Sail - Sanctum - Scout - Socialite - Telescope - Valet Paid: - Envoyer - Forge - Nova - Spark - Vapor

aprdm 5y ago
This gives absolutely no context as I have no idea what these funny names are :)
- jw1224 5y ago
  Free: - Breeze: authentication starter kit - Cashier: payment processing through Stripe or Paddle - Dusk: automated browser testing - Echo: real-time broadcasting - Horizon: queue handler - Jetstream: application scaffolding - Mix: frontend asset compilation - Octane: serverless Laravel - Sail: Laravel Docker environment - Sanctum: SPA authentication - Scout: search engine - Socialite: OAuth provider authentication - Telescope: application monitoring - Valet: macOS developer environment Paid: - Envoyer: zero-downtime deployment service - Forge: Laravel hosting via AWS, DigitalOcean, and more - Spark: application scaffolding kit - Vapor: serverless Laravel hosting via AWS
chipotle_coyote 5y ago
You left out Nova, which is also paid. I don't want to come across as "nobody should give Laravel money," to be clear. I'm just observing that Laravel is essentially a commercial open-source enterprise in a way that Rails and Django aren't. Models like this seem to be a bit more common in the PHP world. (e.g., Sensio Labs makes their money by teaching and consulting on Symfony, Laravel LLC makes money from Laravel add-on services, but Basecamp makes money from the SaaS applications they're building on top of Rails and is not trying to monetize Rails itself.)
- unfocussed_mike 5y ago
  Rails very much was a commercial open source enterprise when it started out. It's just that the enterprise was Basecamp and the other 37 Signals apps. They benefited enormously from the extra eyeballs on their framework, not least during the infamous "hey, we built this massive web framework in part around the incorrect assumption that GET requests don't need to be idempotent and then encouraged everyone to use it" time. They had no services to sell but they had a keen commercial imperative.
  - porker 5y ago
    > not least during the infamous "hey, we built this massive web framework in part around the incorrect assumption that GET requests don't need to be idempotent and then encouraged everyone to use it" time. Tell me more. I remember when Rails was first released but missed that entire saga.
    - unfocussed_mike 5y ago
      It is so long ago now that I can't even find stuff about it on Google -- 2006 I think? Basically, well after they'd released the framework they had to change the Rails scaffolding (and I think their own apps) because parts of the scaffolding (CRUD deletes) would use GET to do the action that should only be done as POST. They discovered it about the time link-prefetching was invented ;-) Basically, browsers were pre-fetching all the clever scaffolded delete URLs and destroying records, seemingly at random. I was really impressed with Rails at the time but stayed well away from the scaffolded code in production, and I was gobsmacked by the idea that people talking about a clever, opinionated framework that did the right thing and produced magical, clean, elegant code to rescue you from terrible alternatives did not understand that GET requests should be idempotent. Edit: here is one bit about it: https://dhh.dk/arc/000455.html https://dhh.dk/arc/000455.html The unearned high-mindedness of this still makes me chuckle.
    - deleted 5y ago
      [deleted]
- 5y ago
unfocussed_mike 5y ago
I've just realised that a) I've used precisely none of them, and b) Passport isn't even on the list! I really do need to look at all of this stuff again, because I'm very open to not running my own VMs/services for a couple of apps.

aprdm 5y ago

This gives absolutely no context as I have no idea what these funny names are :)

jw1224 5y ago
Free: - Breeze: authentication starter kit - Cashier: payment processing through Stripe or Paddle - Dusk: automated browser testing - Echo: real-time broadcasting - Horizon: queue handler - Jetstream: application scaffolding - Mix: frontend asset compilation - Octane: serverless Laravel - Sail: Laravel Docker environment - Sanctum: SPA authentication - Scout: search engine - Socialite: OAuth provider authentication - Telescope: application monitoring - Valet: macOS developer environment Paid: - Envoyer: zero-downtime deployment service - Forge: Laravel hosting via AWS, DigitalOcean, and more - Spark: application scaffolding kit - Vapor: serverless Laravel hosting via AWS

chipotle_coyote 5y ago

You left out Nova, which is also paid. I don't want to come across as "nobody should give Laravel money," to be clear. I'm just observing that Laravel is essentially a commercial open-source enterprise in a way that Rails and Django aren't. Models like this seem to be a bit more common in the PHP world. (e.g., Sensio Labs makes their money by teaching and consulting on Symfony, Laravel LLC makes money from Laravel add-on services, but Basecamp makes money from the SaaS applications they're building on top of Rails and is not trying to monetize Rails itself.)

unfocussed_mike 5y ago
Rails very much was a commercial open source enterprise when it started out. It's just that the enterprise was Basecamp and the other 37 Signals apps. They benefited enormously from the extra eyeballs on their framework, not least during the infamous "hey, we built this massive web framework in part around the incorrect assumption that GET requests don't need to be idempotent and then encouraged everyone to use it" time. They had no services to sell but they had a keen commercial imperative.
- porker 5y ago
  > not least during the infamous "hey, we built this massive web framework in part around the incorrect assumption that GET requests don't need to be idempotent and then encouraged everyone to use it" time. Tell me more. I remember when Rails was first released but missed that entire saga.
  - unfocussed_mike 5y ago
    It is so long ago now that I can't even find stuff about it on Google -- 2006 I think? Basically, well after they'd released the framework they had to change the Rails scaffolding (and I think their own apps) because parts of the scaffolding (CRUD deletes) would use GET to do the action that should only be done as POST. They discovered it about the time link-prefetching was invented ;-) Basically, browsers were pre-fetching all the clever scaffolded delete URLs and destroying records, seemingly at random. I was really impressed with Rails at the time but stayed well away from the scaffolded code in production, and I was gobsmacked by the idea that people talking about a clever, opinionated framework that did the right thing and produced magical, clean, elegant code to rescue you from terrible alternatives did not understand that GET requests should be idempotent. Edit: here is one bit about it: https://dhh.dk/arc/000455.html https://dhh.dk/arc/000455.html The unearned high-mindedness of this still makes me chuckle.
  - deleted 5y ago
    [deleted]
5y ago

unfocussed_mike 5y ago

I've just realised that a) I've used precisely none of them, and b) Passport isn't even on the list! I really do need to look at all of this stuff again, because I'm very open to not running my own VMs/services for a couple of apps.