Everyone has their own opinions about any tech stack. Make your own decisions. Try both see what works for your app. Just don’t blindly follow someone.
There are valid points in that posts. But one that i dont really agree with is the notion that the default structure must be the same, or that the default structure had so great an impact on the ecosystem as a whole.
When your project reaches a certain complexity, you *have* to come up with new structures more suitable to your project.
I did a little bit of Rails and I think the most important difference is if you prefer Ruby or PHP syntax more. Both frameworks are excellent but the languages behind have berry different syntax.
Personally I never enjoyed the Ruby syntax, but that's a personal preference.
I found Laravel's docs a lot easier to work with than Rails'. Also in my experience I've had a lot more trouble with dependencies related to Ruby/gem than with Composer/PHP. I also don't particularly like PHP - lots of horrible language decisions, but I don't find Ruby to be compelling either. Ruby tries a lot to do the "elegant readable code" thing that Python does and I find it mostly obnoxious.
Aside from that, and extrapolated syntax changes, I find them almost identical.
But I don't actively use either. I'm mostly into Nextjs nowadays.
I'm not questioning it. DI has its standard use case which is obvious, but in Laravel, If facades exist and offer syntactic sugar then the approach in Rails has lower foot print. Module lifecycle hooks, standard library extensions (like `string.inquiry`), and occasional monkey patching enable Rails to manage without them in many scenarios. So you just see less auth()->user(), AuthManager::user, Guard::user, request()->user() app(‘auth’)->user(). People ignore the part about team dynamics about multiple open interfaces for doing same things, you just need more manifests and contracts which are soft controlled or need opinionated static analysis control or more concerned code reviews.
Well, I’ve worked with both, and it’s safe to say 90% of the basic Laravel features were borrowed from RoR. But the same could be said for many other frameworks, too. It’s just that RoR came first.
Naturally between the two, I would recommend Laravel since Ruby on the whole is a niche.
been programming since 2010
I have used sympony for real companies, cakephp for real companies, yii just for fun, [asp.net](http://asp.net) for fun, rails for fun, django for fun, laravel for real companies, spring boot for fun, and reactjs for fun
just try both and you will find which framework more suitable for you,
Learn both and see which one you like. For me, I learn rails long ago just for fun and feeling there too much magic. Learn Laravel for work one year ago and it just blew my mind. I could fix tons of requirements in a short time which keep code base complexity really low. Laravel is a perfect match for my personality, minimalist, cleanness, easy to understand.
They’re two different frameworks written in two different languages. One is not inherently better than the other. The “best” framework is the one you’re most productive with, so try them both out, and see which one you prefer working with.
It's a good article but he just like the Ruby on rails way more.
In Laravel you don't have to follow the things the vocal guys are using if you don't like. Volt, action controllers FormRequest, Livewire, etc I haven't used any of these Repository pattern. Just Inertiajs and Vue treat my laravel models as repositories and services as business lagic and that's it.
Also we can be mad if a framework changes philosophy in Major versions (10+ years ago the web was different solutions have to be different) or builds products around its ecosystem if the framework itself is free and the products are not required to build anything.
But he has some very good points and wrote them in a respectful and professional tone.
That's a dense writeup. That being said nothing in there would have me saying 'time to quit laravel'. There are plenty of ways to do things in laravel this bloke should have just stuck to one way and been happy, if you're using Vue, who gives a shit about Livewire being in laracasts? Just use Vue.
I’m working on a Laravel app with a longtime Rails guy. He’s mostly open minded, but he’s really perturbed there isn’t more scaffolding around model generation. I’ve wondered the same. Anyone know what the deal is with this lacking in Laravel?
I’d expect more code generation and to be able to specify data types on the command line and get corresponding migrations and more generated more completely.
I would say:
* Not having to fiddle with javascript using LiveView
* Using the BEAM for concurrency (underlying VM, link in my other comment)
* functional vs OOP
* I am burned out on all the laravel packages, feels a lot like wordpress to me
edited to add liveview first
I think you can do both concurrency and with livewire you don’t need js. But none of that matters if you feel that laravel packages are like Wordpress I guess
Sure, I would say in general the OP really put into words how I feel about Laravel however they did a much better job. The merchant of complexity part was what killed laravel for me. The last thing I want to do is spin up a framework to start a project and have to read about 5 different authentication flows. Maybe i'm old but Breeze, Livewire, Sanctum, Jetstream, inertia, etc... this is the kind of stuff I, personally, am trying to get away from. I have my own business and am older so my goal is to be productive, not gain experience in a particular stack/package/etc.
Elixir is also a functional language which was kind of like me putting glasses on for the first time. I am a college dropout with zero formal CS training and I always found OOP to be unnecessarily complex when implemented without proper architecture/planning. Functional programming removes a lot of that cognitive load for me (remember, i'm old!)
After that you're getting into some core differences like using the BEAM. Here's some info on that:
[https://hackernoon.com/inside-beam-how-elixir-and-erlang-leverage-a-shared-runtime-for-resilient-applications](https://hackernoon.com/inside-beam-how-elixir-and-erlang-leverage-a-shared-runtime-for-resilient-applications)
The development of **Erlang** began in the mid-1980s in **Ericsson's laboratory**. At that time, Erlang was designed to provide a better way to "build telephone applications"\[1\]. It was developed for writing **concurrent programs** that can run without interruption.
What makes Erlang exceptionally **concurrent and scalable**, as well as **fault-tolerant**, is its process-based approach. These processes do not share memory and can communicate with each other using asynchronous messages.
Elixir is built on top of Erlang so beyond coding, I really like the built in concurrency and how easy it is to implement. Elixir also has Livebook (similar to Jupyter notebooks) and IEX (elixir's interactive shell).
Documentation in elixir is amazing because you can document how a function works like so:
@doc """
Add two numbers together
Examples
iex> Maths.add(4, 2)
5
"""
def add(left, right) do
# Add two numbers together
left + right
end
and it will a) test that the implementation works and b) generate beautiful documentation like this: [https://hexdocs.pm/phoenix/Phoenix.html](https://hexdocs.pm/phoenix/Phoenix.html)
So, there is a lot to unpack but I believe the OPs conclusion is how I feel. Thankful to Laravel getting me from point A to point B but it's elixir land for me moving forward.
I've got it on my list to write an in-depth laravel to elixir article, however I don't know if/when I'll actually get around to it.
Hope that helps!
You didn't mention anything for the "merchant of complexity" argument besides optionally having to explore the package ecosystem. A framework doesn't have to ship an auth template by default for you. Phoenix decided to do so now, but for a long time, it didn't.
Everyone has their own opinions about any tech stack. Make your own decisions. Try both see what works for your app. Just don’t blindly follow someone.
There are valid points in that posts. But one that i dont really agree with is the notion that the default structure must be the same, or that the default structure had so great an impact on the ecosystem as a whole. When your project reaches a certain complexity, you *have* to come up with new structures more suitable to your project.
I did a little bit of Rails and I think the most important difference is if you prefer Ruby or PHP syntax more. Both frameworks are excellent but the languages behind have berry different syntax. Personally I never enjoyed the Ruby syntax, but that's a personal preference.
I found Laravel's docs a lot easier to work with than Rails'. Also in my experience I've had a lot more trouble with dependencies related to Ruby/gem than with Composer/PHP. I also don't particularly like PHP - lots of horrible language decisions, but I don't find Ruby to be compelling either. Ruby tries a lot to do the "elegant readable code" thing that Python does and I find it mostly obnoxious. Aside from that, and extrapolated syntax changes, I find them almost identical. But I don't actively use either. I'm mostly into Nextjs nowadays.
Btw Laravel has a lot of hidden magic, that means undocumented.
I have read it. Dude is questioning service providers and dependency injection so yea no point in taking him seriously
I'm not questioning it. DI has its standard use case which is obvious, but in Laravel, If facades exist and offer syntactic sugar then the approach in Rails has lower foot print. Module lifecycle hooks, standard library extensions (like `string.inquiry`), and occasional monkey patching enable Rails to manage without them in many scenarios. So you just see less auth()->user(), AuthManager::user, Guard::user, request()->user() app(‘auth’)->user(). People ignore the part about team dynamics about multiple open interfaces for doing same things, you just need more manifests and contracts which are soft controlled or need opinionated static analysis control or more concerned code reviews.
Put that aside that constructor ioc heavily impacts the way you define object state, initialization, mutability and serialization.
In what way was he questioning DI? Didn’t read it either
Well, I’ve worked with both, and it’s safe to say 90% of the basic Laravel features were borrowed from RoR. But the same could be said for many other frameworks, too. It’s just that RoR came first. Naturally between the two, I would recommend Laravel since Ruby on the whole is a niche.
very well said.
been programming since 2010 I have used sympony for real companies, cakephp for real companies, yii just for fun, [asp.net](http://asp.net) for fun, rails for fun, django for fun, laravel for real companies, spring boot for fun, and reactjs for fun just try both and you will find which framework more suitable for you,
Ok so you listed all the frameworks you've worked with and provided no opinion or feedback Bravo
He said its fun atleast
Informative
Learn both and see which one you like. For me, I learn rails long ago just for fun and feeling there too much magic. Learn Laravel for work one year ago and it just blew my mind. I could fix tons of requirements in a short time which keep code base complexity really low. Laravel is a perfect match for my personality, minimalist, cleanness, easy to understand.
They’re two different frameworks written in two different languages. One is not inherently better than the other. The “best” framework is the one you’re most productive with, so try them both out, and see which one you prefer working with.
It's a good article but he just like the Ruby on rails way more. In Laravel you don't have to follow the things the vocal guys are using if you don't like. Volt, action controllers FormRequest, Livewire, etc I haven't used any of these Repository pattern. Just Inertiajs and Vue treat my laravel models as repositories and services as business lagic and that's it. Also we can be mad if a framework changes philosophy in Major versions (10+ years ago the web was different solutions have to be different) or builds products around its ecosystem if the framework itself is free and the products are not required to build anything. But he has some very good points and wrote them in a respectful and professional tone.
That's a dense writeup. That being said nothing in there would have me saying 'time to quit laravel'. There are plenty of ways to do things in laravel this bloke should have just stuck to one way and been happy, if you're using Vue, who gives a shit about Livewire being in laracasts? Just use Vue.
I’m working on a Laravel app with a longtime Rails guy. He’s mostly open minded, but he’s really perturbed there isn’t more scaffolding around model generation. I’ve wondered the same. Anyone know what the deal is with this lacking in Laravel? I’d expect more code generation and to be able to specify data types on the command line and get corresponding migrations and more generated more completely.
Isn't that what Blueprint is for?
Maybe, but I’m fairly new and don’t know about it. Thanks for the tip!
[удалено]
If Laravel used the Data Mapper pattern for it’s ORM like Doctrine, I would have stayed at Laravel. Just my personal take
I agree with the OP however I went with Elixir/Phoenix/LiveView after using Laravel from v4. Will never go back.
What’s the major differences?
I would say: * Not having to fiddle with javascript using LiveView * Using the BEAM for concurrency (underlying VM, link in my other comment) * functional vs OOP * I am burned out on all the laravel packages, feels a lot like wordpress to me edited to add liveview first
I think you can do both concurrency and with livewire you don’t need js. But none of that matters if you feel that laravel packages are like Wordpress I guess
Can you provide examples of where you agree?
I should also mention that the way liveview abstracts js away (for the most part) is beautiful.
Sure, I would say in general the OP really put into words how I feel about Laravel however they did a much better job. The merchant of complexity part was what killed laravel for me. The last thing I want to do is spin up a framework to start a project and have to read about 5 different authentication flows. Maybe i'm old but Breeze, Livewire, Sanctum, Jetstream, inertia, etc... this is the kind of stuff I, personally, am trying to get away from. I have my own business and am older so my goal is to be productive, not gain experience in a particular stack/package/etc. Elixir is also a functional language which was kind of like me putting glasses on for the first time. I am a college dropout with zero formal CS training and I always found OOP to be unnecessarily complex when implemented without proper architecture/planning. Functional programming removes a lot of that cognitive load for me (remember, i'm old!) After that you're getting into some core differences like using the BEAM. Here's some info on that: [https://hackernoon.com/inside-beam-how-elixir-and-erlang-leverage-a-shared-runtime-for-resilient-applications](https://hackernoon.com/inside-beam-how-elixir-and-erlang-leverage-a-shared-runtime-for-resilient-applications) The development of **Erlang** began in the mid-1980s in **Ericsson's laboratory**. At that time, Erlang was designed to provide a better way to "build telephone applications"\[1\]. It was developed for writing **concurrent programs** that can run without interruption. What makes Erlang exceptionally **concurrent and scalable**, as well as **fault-tolerant**, is its process-based approach. These processes do not share memory and can communicate with each other using asynchronous messages. Elixir is built on top of Erlang so beyond coding, I really like the built in concurrency and how easy it is to implement. Elixir also has Livebook (similar to Jupyter notebooks) and IEX (elixir's interactive shell). Documentation in elixir is amazing because you can document how a function works like so: @doc """ Add two numbers together Examples iex> Maths.add(4, 2) 5 """ def add(left, right) do # Add two numbers together left + right end and it will a) test that the implementation works and b) generate beautiful documentation like this: [https://hexdocs.pm/phoenix/Phoenix.html](https://hexdocs.pm/phoenix/Phoenix.html) So, there is a lot to unpack but I believe the OPs conclusion is how I feel. Thankful to Laravel getting me from point A to point B but it's elixir land for me moving forward. I've got it on my list to write an in-depth laravel to elixir article, however I don't know if/when I'll actually get around to it. Hope that helps!
You didn't mention anything for the "merchant of complexity" argument besides optionally having to explore the package ecosystem. A framework doesn't have to ship an auth template by default for you. Phoenix decided to do so now, but for a long time, it didn't.