[marstall]

Rails fanboy since 0.9. Great framework. It's just such a ... comfortable? space to be in. Highly recommend it even after all these years - though now I use it mostly for modern SPA-style apps where rails simply provides an API. Which it is, yup, great for!

[Okawari]

You hit the nail on the head there!

Ive been tinkering with rails since Rails 4, but in my dayjob I use Laravel a whole lot. At this point I have spent way more time in Laravel than Rails.

Yet pretty much every time I have to work with Laravel, I wish it was rails instead. Rails being "comfortable" is quite apt, and definitly something I'm missing.

[cyrialize]

Could you go over the differences between Rails and Laravel? I'm thinking of picking up a framework for myself.

I very much enjoy the Laracasts videos and I work in PHP currently so I've though about starting their Laravel learning series.

On the other hand, I create a RoR application for my university and I've always loved Ruby - but it's been a long time since I've done anything with Ruby.

[Okawari]

I realize that this comes down to preferences but here are some of the things I can come up with of the top of my head. Again, most of these changes are in the comfortable category.

To be very brief

* PHP. This comes up everytime we talk about Laravel. Its the same reasons a lot of people dislike it. I think the language is just kind of jank. * A lack of the powerful metaprogramming aspects of Ruby makes the Api to bootstrap and use features in Laravel feel clunky and akward compared to Rails. For example the laravel router having a lot of its features requiring you to pass arguments using associative arrays which does not get autocompletion for example.

* Ability to inject code using function calls gives you very nice ways of defining validations on the model itself instead of a request validator that is located in the controller. I think it makes more sense for them to be there. The syntax for defining them is a lot slicker and less cumbersome.

* I dont like observables and how they can affect code somewhere else without being referenced in the location where they are mutating an object. I feel like i loose track of laravel projects earlier than rails as lines of code increase. I find it easier to follow where the code is going with rails.

* I think the templating system of Laravel is poor compared to just plain embedded ruby. I know you can just use normal php. But a lot of blade helpers are then disabled and the documentation for them are subpar as the developers expect you to use blade. I think the need for special syntax (@directive) makes things harder to parse, and I dont like how @stack lets you effectively push code to somewhere earlier in the file/code. It makes things harder to reason around because as you read the code you cant really reason about what a stack actually contains. And if you read a component that pushes to the stack then you dont know exactly where that ends up. I think normal embedded ruby templates is way cleaner and better. As I said you can use plain php instead of blade. But it is not that well supported, documentation is poor. It is probably quicker and easier to just use blade components, but using blade features sparingly.

For me it primarilly comes down to these kinds of small grievances I have with it the project that just makes me wish I could just write them in ruby instead.

[djitz]

Using the Laravel debugbar or telescope toolbar gives you a clear picture of what’s rendering where.