I hear you. We use ViewComponent on my current job and its ok, what I really dont like is that we use haml.
Going from heex + vscode plugins to haml is pretty sad, the developer experience is so much worse
cpgo
1
sodapopcan
Not to derail this thread too much but I used to be really into Slim until I wasn’t. One of my biggest problems was that back in a pre-Tailwindeque world I couldn’t tell my markup from my css at a glance—they had an almost identical shape!
1
cjbottaro
I’ve been doing Rails since 1.x. I like to tell people new to Phoenix that it’s most like Rails 2.x. Kinda back when Rails was simple (routes that sends requests to a controller/action, and also the whole “restful resources” thing).
That said, I’m also starting to fall more and more into the camp of everything should be LiveView; there’s no point in doing controller/actions anymore (aside from APIs), even if you’re just making basic CRUD pages. Even beyond no point, I actually think it’s easier to make basic CRUD pages in LV now.
To get people’s foot in the door with LV, I do a 10 min live coding session where I make a route, then setup a basic LV and show how to do assigns and wire up the HTML, etc. Then try to show the difference between connected? mount and dead mount and how it relates to progressive loading.
5
sodapopcan
I’m in the “everything should be a LiveView” camp as well so long as your page doesn’t need to work without JS. Making forms work without JS in LiveView is a pain and not worth the effort imo. But otherwise, I don’t see the point in not doing everything as LiveViews. I agree that basic CRUD feels simpler in LV.
4
kanishka
I think blitzjs or remix gets you about the same simplicity, just using js/node instead and no websockets needed (I may be wrong on websockets). I haven’t used them, so this is just an abstract observation.
1
cpgo
arrowsmith
I worked full-time with Rails for around five years before switching to Elixir and Phoenix. Haven’t regretted the decision for one second - I don’t miss Rails at all.
If you’re coming to Phoenix from a Rails background, then the best course in my humble opinion is the one I wrote: Phoenix on Rails. I apologise for the self-promotion, but you can use the code ELIXIRFORUM to get a $10 discount.
To answer your question more directly, some of the main things that helped me were:
-
Taking the time to learn Elixir itself before diving into Phoenix. Elixir is much more different from Ruby than it appears at first; the languages use similar syntax but their underlying design is very different. I initially tried to learn Elixir “alongside Phoenix” but it was confusing and too much to learn at once.
-
Understanding that (as someone else said above) Phoenix isn’t nearly as opinionated as Rails is. If all you know is Rails, your initial reaction to solving a problem is often to try and figure out the “Rails way” of doing it - like there’s a single best practice that everyone should follow. This isn’t the case nearly as often in Phoenix. In particular, your “context” modules are just regular Elixir modules. In Rails, you build a Rails app; in Phoenix you build an Elixir application where Phoenix just happens to be the part that handles the “web” side of things (and Ecto handles data persistence/validation etc.)
This might seem like a bad thing, but I think over time you’ll come to appreciate Phoenix’s flexibility. If anything Rails is too opinionated - it’s too inflexible, and the “Rails way” breaks down and becomes a mess as soon as you try to do something that doesn’t fit neatly within Rails’s conventions.
-
Before I learned Ecto I already had a good knowledge of SQL and knew how to write a complicated SQL query. This definitely helped me understand
Ecto.Query, as its DSL follows SQL quite closely.
I think Ecto is the hardest thing to learn when coming from Rails - not because it’s difficult on its own terms, just that it’s very different from ActiveRecord; probably the part of Phoenix’s stack that feels the most unfamiliar to a Rails dev. (I also think that Ecto’s MUCH better designed than ActiveRecord and leads to far cleaner and more maintainable code, but that’s another post.) Before you try to build a complicated Phoenix app, I recommend sitting down with the different parts of Ecto and getting to grips with how they work, and how to do in Ecto the basic things you already know how to do in ActiveRecord. (For starters, I wrote this cheatsheet) for learning Ecto.Query when you know ActiveRecord.)
Some other small things that are bound to trip you up, so be aware:
- in HEEx you need to write
<%= ifinstead of<% if. - uniqueness validations work differently; look up
unique_constraint. - Ecto associations aren’t loaded by default (you need to explicitly
preloadso you can’t accidentally introduce an N+1 issue, as is far too easy in Rails.)
I’d also recommend taking the time to understand Plug sooner rather than later. At a glance Plug is similar to Rack, except Rack is kind of hidden from you and you can spend years using Rails without ever needing to think about Rack. Plug is much more “up front and centre” in Phoenix and an important part of your stack - you don’t need to understand it from the very beginning, but don’t neglect it.
That’s all I can think of for now. (As for the book Phoenix for Rails Developers that was mentioned above - I read it when I was getting started but honestly I was very disappointed by it, not least because it’s very out of date. Phoenix has changed a lot since 1.3. My disappointment with that book was one of the reasons why I eventually decided to create Phoenix on Rails.)
2
egeersoz
It has been years since I wrote any Ruby code, but one thing I do miss to this day is being able to do stuff like 1.day.ago to get a date object that represents yesterday. Coding patterns/structures that resemble natural language are such a simple yet powerful concept that I’m surprised more languages haven’t tried to implement them.
1