1. 24
  1.  

  2. 7

    I always found the batteries-included frameworks like Rails to be overwhelming (when they should have the opposite effect) - for me, Phoenix still invokes that feeling enough that I have to use Plug directly. I wish I could get over that feeling, because Phoenix does look very useful.

    1. 2

      The way I see it, Phoenix is absolutely okay with you using Plug directly. Rails/Django feel much more “punishing” when you try to do something that was not predicted by maintainers.

      1. 2

        We’re using Phoenix on my team full time, and I agree. Plug lets you insert your code anywhere in the pipeline without much hassle.

        1. 1

          Well, I’m not using Phoenix - I’m using just Plug with Phoenix.HTML.

          1. 1

            I see. What do you use for routing, for example? Just pattern matching on path_info?

            1. 2

              The macros for get were enough and pretty close to what Express does - those are a part of Plug, at least.

          2. 1

            Using Rack directly in Ruby is actually quite nice, IME.

            1. 1

              Well, if we talk about Phoenix.Controller then in fact it is just Plug generator. You can easily implement such controllers with plain behaviour and keep most of the functionality.

            2. 1

              i agree, i wrote a small app in phoenix and what i found overwhelming was the sheer volume of generated code. i wish it had some sort of sinatra-like mode where ‘hello world’ could be a single file and gradually expand as needed.

              1. 3

                That is why there is Plug, which is almost exactly that.

                1. 1

                  i still want things like channels and presence from phoenix though. i’m not looking for a superminimal framework, i just wish there were a clearer separation between my code and the framework code.

                  1. 3

                    Well, for presence you can use phoenix_pubsub directly. Despite it’s name it do not depend on Phoenix nor any of it’s components, it is really sad that they dumped the name firenest and instead decided to namespace it under Phoenix. For channels unfortunately you cannot go around it as it is very Phoenix-y specific thing. However nothing stops you from using Phoenix only for sockets. It is perfectly valid approach.

                    i just wish there were a clearer separation between my code and the framework code

                    Well, it all depends on you. Recent Phoenix generators highly encourage such approach by encouraging domains separation and split between your_app and your_app_web.

                    1. 1

                      Recent Phoenix generators highly encourage such approach by encouraging domains separation and split between your_app and your_app_web.

                      ah, that sounds awesome! i’ll have to take a closer look at the current best practices.

            3. 5

              Good write-up!

              Phoenix comes with a huge pack of tools and utils (ORM,

              I’d suggest correcting this, one of the things that caused me issues and concerns with frameworks like Django was ORMs, being very familiar with SQL and having a preference for the repository pattern. Ecto not being an ORM is IMO one of the biggest strength of Phoenix.

              Call it a query builder or a SQL query DSL, it’s definitely not an ORM in a functional language that doesn’t have objects. ;)

              1. 2

                Most Go frameworks are like this […] apps built on such a foundation can, given poor governance, slowly evolve into an unsupportable mess of incompatible plugins and mismatched coding styles.

                If there one thing that is not happening to Go frameworks, it’s “mismatched coding styles”. The Go language allows little variation in how code is expressed and go fmt is universally accepted. This has the upside of making code that other people have written easier to read, but frustrates people coming from Lisp and Haskell to no end.

                1. 2

                  I doubt “coding style” meant only superficial formatting :)

                  1. 2

                    If you browse Go code available online, the non-superficial coding style is also pretty similar, or at least not “mismatched”. Compare this to ie. C++, where a wide range of coding styles are used.

                  2. 0

                    Ah well, people coming from Lisp and Haskell frustrate everybody else to no end. (I’m not taking sides, it’s just an observation.)

                  3. 2

                    Can anyone recommend web frameworks for more mainstream languages that do #1 (balance between flexibility and strictness) and #2 (integrated real-time support) as well as Phoenix does for Elixir? Maybe ASP.NET Core?