36 ms·

Phoenix 1.7.0

356 points by thefreeman 4y ago

transfire 4y ago
Verified routes don’t seem to work in components. Is there a reason for that? Can/will it be fixed?
- Liberonostrud 4y ago
  [flagged]
  - sanswork 4y ago
    Which projects?
  - josevalim 4y ago
    It is impossible for new projects to be broken with this change. It is a new functionality which existing apps would have to opt-in to use. I don't understand the need to misrepresent what others have said.
  - biorach 4y ago
    What's with you? You keep jumping in making negative comments only partially based in reality. You don't like Phoenix? Fine, who cares. But please don't keep spouting nonsense.
- sanswork 4y ago
  Check this out https://elixirforum.com/t/can-i-use-p-sigil-in-h-sigil/51986 https://elixirforum.com/t/can-i-use-p-sigil-in-h-sigil/51986
  - josevalim 4y ago
    Thanks for adding a link. In a nutshell, it should work, if not, please follow up in the forum and folks will be glad to provide guidance!
koevet 4y ago
Is there anyone with experience on a large Elixir/Phoenix code base? Is the lack of static type system a problem?
- Liberonostrud 4y ago
  This is another problem of Phoenix. There are some big projects running on it, like cars.com but the code is not public and also they have a team of people who are good programmers and can bug-fix or pay people who can help bug-fix things for them. Watch the presentation of their switch to Phoenix and the gotchas they have encountered - for example how at first they didn't take into account the impact on Phoenix when users of sites like cars.com have opened 10 or 20 tabs (that have to be updated via websockets) instead of just 1 or 2 when they are comparing their dream car and how they thought that switching to Phoenix was a bad idea. Of course, they are smart ()or have money to pay smart programmers) and they solved this problem and now are happy with Phoenix ;). But as I said in previous posts, unlike with PHP that is very forgiving for sloppy code, Elixir does need higher skill level and the barrier to master it much, much higher than PHP.
  - krstf13 4y ago
    You’re misrepresenting what’s being said in this talk (the relevant part of the talk is around the 15 minute mark at : https://youtu.be/XzAupUHiryg https://youtu.be/XzAupUHiryg ). The tldr was that they had patched some of the library code without considering the ramifications of the change. At no point in the talk is it said that “switching to Phoenix was a bad idea”. Also, none of the issues they talk about are related to the lack of static typing.
    - Liberonostrud 4y ago
      https://github.com/laravel/laravel/pull/6010 https://github.com/laravel/laravel/pull/6010
      - krstf13 4y ago
        So? Laravel uses type hinting, ok. This has absolutely nothing to do with your previous post grossly misrepresenting a talk. You hadn’t even mentioned Laravel in it. Type hinting is not equivalent to a static type system, which is what the parent was asking about. Finally, in either cases, it changes nothing to the fact that the pain points mentioned in the talk were not caused by the lack of a static type system (which is not to say it cannot cause pain points)
turbobooster 4y ago
I feel safer with SvelteKit
lpil 4y ago
Congratulations and thank you to the Phoenix team! Stellar work as always.
janandonly 4y ago
I came here because I thought this was about the app called Phoenix. I was wrong. Still, Phoenix deserves some love as well: https://phoenix.acinq.co/ https://phoenix.acinq.co/
pinetroey 4y ago
Has anyone experience with ash framework? I'd like to make an erp in phoenix & liveview. Should I use ash as well? Or avoid it.
- borromakot 4y ago
  Well, I made it, so I'm biased, but one of our most prolific users is a solo dev building a large ERP system with Ash.
pineapple_guy 4y ago
Ships with tailwind? We’re jumping the shark with that
- cultofmetatron 4y ago
  a lot of the community was already using it. plus you can easily overide it.
  - the_sleaze9 4y ago
    I believe a fundamental design tenet for Phoenix is the idea of "do it _this_ way, but there's always an escape hatch if you want/need it."
    - jahsome 4y ago
      I think you just described every single framework in existence. If that's not the way, what signifies a properly designed framework in your opinion?
      - pcthrowaway 4y ago
        Heh.. you haven't tried express.
      - josevalim 4y ago
        I don't think there is a definite answer for "what a property designed framework" is but I can try to explain where Phoenix sits in the possible trade-offs. One possible approach frameworks use to provide escape hatches is configuration. You ship with a series of defaults and, once you want to change it, you need to find out the proper knob to turn. A downside of this approach is finding the proper knobs when you need to tweak it. Another approach is code generation: you generate code (or configuration) and keep the knobs clear to user. There are still defaults (and conventions) but the knobs are laid out upfront in your application. The downside here is that having so many knobs upfront may seen daunting or noisy. Since you mentioned Rails, I will provide references on how Rails and Phoenix use those. Both frameworks leverage both techniques above, but Phoenix errs more on code generation and Rails more on configuration. Here is a practical example. Rails has a middleware stack that is part of all applications. This stack is hidden from you. Here is how the generator file for said application looks like: https://github.com/rails/rails/blob/d0d9e8e576b06c19f850751001d19efadf81df73/railties/lib/rails/generators/rails/app/templates/config/application.rb.tt https://github.com/rails/rails/blob/d0d9e8e576b06c19f8507510... Phoenix has a similar stack (called plug) and the default stack is part of your application. Here is the generator file for it (it is not part of your app but used to generate it): https://github.com/phoenixframework/phoenix/blob/3c27a34c27c075af6c99a05168ea709d5389e4fc/installer/templates/phx_web/endpoint.ex https://github.com/phoenixframework/phoenix/blob/3c27a34c27c... You can look at these approaches and try to compare the pros and cons. --- My biased opinion: I have worked with both and I prefer the Phoenix approach. I understand someone may find having all steps in your endpoint noisy or daunting, but the plus side is that it takes a glance to see all steps a request goes through and you can tweak it in any way you want. When comparing to Rails, if you want to insert a middleware in the middle of the default stack, you need to explicitly say before or after which middleware. If you want remove something, you need to state the negation and say "I don't want to have this". Overtime this makes it hard for you to visualize what your application does, because you need to assemble the pieces in your head and use tools to print the stack for you. This also matters on releasing new framework versions. Because Rails has its own stack, if it changes the default middleware stack in any way, it can slightly change how your code. What if the middleware you were inserting before was moved up? Or removed altogether? Or maybe a middleware you deleted was replaced by another one, with similar functionality. Do you want to remove it too? This can lead to subtle differences of behaviour when upgrading. The code generation approach requires you to opt-in to the new features, which is, IMO, one of the reasons why Phoenix could avoid breaking changes in the last 8 years or so. This is in no way a knock on Rails. I am 100% confident the Rails team is aware of those trade-offs and could equally argue for their choices. It also isn't a binary choice either, both frameworks use both approaches, with some general preferences for one over the other.
Rodeoclash 4y ago
Looking forward to trying this release out soon. I'm not sure I quite grok streams yet (I understand the use case, but not the implementation). Verified routes aren't a game changer but certainly having more things use the compiler to verify themselves is welcome! I've been a Rails/Ruby developer for close to 10 years now I think and while I haven't used Phoenix/Elixir professionally, it's been my go to for a ton of side projects (The backend for my esports annotation tool, https://vodon.gg/ https://vodon.gg/ and its companion app for schlepping large video files to coaches, https://www.fileyeet.io/ https://www.fileyeet.io/). The best way to sum it up would be slightly less magic then Rails, 3rd party libs might take a bit more work / copy and pasting code to integrate them into your existing codebase. You'll likely write a few more lines of code to achieve the same thing in Ruby, but the ability to use the Beam VM, tooling like LiveView more than make up for the lack of magic. Even better, you'll soon appreciate the lack of magic as refactoring Elixir programs is a dream. It basically just boils down to separating out large functions into smaller composable functions. I also must add, the community is also awesome.
- cassepipe 4y ago
  I have no exxperience with Phoenix but I have started learning Elixir on exercism and used the Getting Started page alongside and it made for an enjoyable experience. After reading the previous chapters, I found Streams to be quite clear : https://elixir-lang.org/getting-started/enumerables-and-streams.html https://elixir-lang.org/getting-started/enumerables-and-stre... You are basically stacking functions (your pipeline) next to some data until it's consumed (i.e. the data goes into the pipeline). So I don't know about the implementation but it can't be that mysterious.
  - di4na 4y ago
    It is a different "stream". The OP means the Phoenix Liveview new "stream" feature that allows you to efficiently update a list of HTML components without having to keep the whole list in memory, but only explaining the changes you want to do. The double sense of that name will trip some newcomers for sure. Happy that you like it though!
voicedYoda 4y ago
I've been working nearly exclusively in elixir and Phoenix for the last 2 years, and i love the community, documentation, and passion around this eco system. I'm stoked about this release, and with tailwind built-in, I'm really excited about next projects.
- bluehatbrit 4y ago
  Same here. I just spun up a new phoenix project (mix phx.new) to mess around with some of the new pieces and this really is a brilliant release.
- arrowsmith 4y ago
  Same here, I switched from Rails to Phoenix a few years ago and have never looked back. It solves so many of the frustrations I had with Rails and I love the Elixir language and the community around both. There was a little bit of a learning curve; Elixir's syntax looks like Ruby but the underlying philosophy of the languages is really quite different so it does take some getting used to, especially if you haven't worked with a functional language before. But it wasn't that bad; it's much more accessible than the other functional language I've dabbled in (Haskell). If I was starting a business the main thing that would put me off choosing Elixir would be the relatively small number of people who know it. If you want to have a lot of Elixir programmers in your company then you'll probably need to be willing to hire people people who don't know it yet but want to learn. But I hope this will change as Elixir keeps growing in popularity.
  - lifesaverluke 4y ago
    Got some examples of solved frustrations you had with Rails?
    - arrowsmith 4y ago
      I actually answered this question (kinda) in a comment on another thread a couple of weeks ago. https://news.ycombinator.com/item?id=34858468 https://news.ycombinator.com/item?id=34858468
losvedir 4y ago
Are there any good up to date Phoenix books yet? I have Programming Phoenix, but it feels like these days with LiveView and unified function components, best practices are kind of different now.
- di4na 4y ago
  Have you tried the official guides in the doc? It should be up to date.
- mike1o1 4y ago
  https://pragprog.com/titles/liveview/programming-phoenix-liveview/ https://pragprog.com/titles/liveview/programming-phoenix-liv... Still in beta, but pretty up to date. Even in beta form, I thought it was pretty valuable!
- isodev 4y ago
  I had the Phoenix LiveView Course from Pragmatic Studio, and it recently got an update for Phoenix 1.7 https://pragmaticstudio.com/phoenix-liveview https://pragmaticstudio.com/phoenix-liveview. I really like the pace and the example use cases.
robertoandred 4y ago
[flagged]
- bdcravens 4y ago
  It has been around for 9 years.
- ungamedplayer 4y ago
  Which over elixir framework were you using ?
yeetaway1111 4y ago
There was so much mystery and magic that I felt was happening behind all things generated in Phoenix that I just felt lost.
- Rodeoclash 4y ago
  It might feel like that way to start with when you're new to the framework, but if you spend a bit of time in it you'll find a lot less magic going on then you expect. I know where you're coming from however, I felt the same way when I started.
- ungamedplayer 4y ago
  Is this in regard to 'mix phx' gen commands or something else ?
  - Liberonostrud 4y ago
    I guess he is talking about macros and perhaps the syntax which I also didn't like and is one of the reasons why I consider PHP better (even though the naming and parameters inconsistency could be better). Check for yourself: ``` iex> length([1, 2, 3]) == length [1, 2, 3] true ``` or (taken from the Elixir docs): --- Take the following code: ``` if variable? do Call.this() else Call.that() end ``` Now let’s remove the conveniences one by one: do-end blocks are equivalent to keywords: `if variable?, do: Call.this(), else: Call.that()` Keyword lists as last argument do not require square brackets, but let’s add them: `if variable?, [do: Call.this(), else: Call.that()]` Keyword lists are the same as lists of two-element tuples: `if variable?, [{:do, Call.this()}, {:else, Call.that()}]` Finally, parentheses are optional, but let’s add them: `if(variable?, [{:do, Call.this()}, {:else, Call.that()}])` That’s it! Those four rules outline the optional syntax available in Elixir. Those rules apply everywhere consistently, regardless of the construct you are invoking. Whenever you have any questions, this quick walk-through has you covered. --- I don't like this possiblity to use so many syntaxes good, especially if you deal with mulitple parameters in functions. Elixir doesn't have C-like semicolons or braces like in Lisp so multiple parameters are hard to parse sometimes. The creator of Elixir himself answered that one of the things he thinks he could do better at the beginning was to make the syntax more strict and he mentions the optional () e.g. IO.puts "Hello" vs IO.puts("Hello").
lycos 4y ago
We've been using 1.7.0 as rc for a while now and the verified routes especially have been much more enjoyable to use. Unifying components between controllers and liveview was also a welcome improvement The only thing I really don't like is having the `page_html.ex` and `page_html/index.html.heex` etc files in `controllers` being the recommended workflow. It feels so weird to have the templates live there, luckily you can put them wherever you want so it's not a real problem Haven't used streams yet but it looks interesting and looking forward to play with that as well.
- josevalim 4y ago
  > It feels so weird to have the templates live there, luckily you can put them wherever you want so it's not a real problem It is curious how some topics like template collocation are divisive. :) In any case, Phoenix had employed both collocation for LV and non-collocation for controllers, so it makes sense to unify the default experience. But ultimately you are right that it does not care where templates are defined!
  - lycos 4y ago
    (thanks for all your work!) I understand the reasoning and especially when you put it like that it makes sense, the reason i feels weird to me is mainly because it's just different than many years of development with various frameworks (including Phoenix until this change). So it is more a "I don't like change!" comment ;) For what it's worth, I mentioned that and the fact that you can use it however you want because it's such a fun and customisable framework, but in our production apps we just try to stick to defaults/recommended workflow so we do have all these files in the controller directory now. I do still wonder if maybe the controller directory just needs a new name since it now contains more than just controllers, but I can't think of any good options and naming is hard.
- bongobingo1 4y ago
  >The only thing I really don't like is having the `page_html.ex` and `page_html/index.html.heex` etc files in `controllers` being the recommended workflow. It feels so weird to have the templates live there, luckily you can put them wherever you want so it's not a real problem I have found this (moving them where ever you want) to be a lot simpler to wire up in 1.7 vs the old `use ...` options!
ecmascript 4y ago
I like Elixir and Phoenix liveview. It is a fresh take to web dev in my opinion. However, I have for the past couple of years worked on apps that really push the bounderies of what can be called a web app. So my need for Elixir is limited and even on my spare time projects I find myself having a hard time justifying using Elixir since my invested knowledge in other technologies are so vast in comparison. To get in par it would take me years of Elixir development and I have a hard time justifying it. For example, I want to build an ecommerce site, a perfect suitable case for Phoenix. The issue is, that I find it to be easier, faster and more reliable for me to just spin up a static site and then add some API layer for the checkout process. I kind of want a need for Phoenix, but so far I haven't had a strong case. Unfortunately though becasue I really like the community and spirit it has. I think it is a language and framework that deserves much more adoption than it seems it has.
- di4na 4y ago
  Tbf i think using a static website like you describe is a better use case anyway for this. Phoenix and co are for things that are quite dynamic or personalised to a user. Ecommerce is not that :)
moomoo11 4y ago
Can someone please give advice on how to accomplish the following with phoenix sockets? Say I have processes for each physical device in the world that are moving around (like on water or something). Any time there is an “anomaly” I want to double check by having all nearby processes/devices run the same check again. Is there a way to run a filter by geoquerying without having to rely on storing the coordinates in a separate store and querying for those device/process IDs? I can store the coordinates in each process, and I want to be able to find nearby processes in one go without using a separate system for finding them. I’m quite a noob at phoenix..
- hdra 4y ago
  why do you need the phoenix part? maybe consider a short-distance wireless comm like bluetooth or zigbee and have them broadcast to nearby devices? have the devices respond to the re-check broadcast and physics will take care of the locating nearby devices part
- conradfr 4y ago
  (not sure where the "phoenix sockets" fit into it) 1/ So I guess you're saying one process/GenServer per device, communicating with it. 2/ Use a Registry[0] to store the process names (based on the device id or whatever) to abstract them from their PID. 3/ Have another GenServer (let's call it CoordStore) storing a map of "process_name -> lat/long" (with the related processes sending updates of the coordinates to it) 4/ Use Presence[1] to keep track of the devices and remove them from the CoordStore when needed. 5/ When you have an anomaly on one device ask CoordStore for the nearby devices/processes (using maybe [2]) and ask each one (thanks to the Registry) to run the check. 6/ Done? (sure you can do a barebone version without the Registry or Presence but where's the fun in that?) [0] https://hexdocs.pm/elixir/1.14.3/Registry.html https://hexdocs.pm/elixir/1.14.3/Registry.html [1] https://hexdocs.pm/phoenix/Phoenix.Presence.html https://hexdocs.pm/phoenix/Phoenix.Presence.html [2] https://github.com/yltsrc/geocalc https://github.com/yltsrc/geocalc
- rkangel 4y ago
  Simplest thing is to use Phoenix PubSub. Broadcast an "anomaly at x,y,z coordinates" message. Then each process can calculate whether it is close and needs to do anything. This isn't very efficient because every process will do some work for every anomaly, but unless your system is very large that's probably OK (it as least extremely parallelised). The alternate approach is to create some form of central process registry that has all the coordinates and process ids, so that you can look up in one place and then send messages out to the relevant processes. There are some other replies about this sort of approach.
Liberonostrud 4y ago
If you are an Elixir (or perhaps Clojure) expert, the following doesn't apply. But every other person jumping ship from, for example PHP or JavaScript should think twice. I think Phoenix is overhyped a lot. The barrier to entry is gigantic. The lack of up-to-date resources doesn't help. It's definitely not as polished as Laravel for example. And while there is Pragmatic Studio with their wonderful introduction video, there is nothing like Laracasts where there are new tutorials added all the time. Frankly, it's on another level. Deploying Phoenix is a nightmare when compared to Laravel. In Phx you have to reinvent a lot of things and often, of course, choosing the wrong path. Sure try the chat demo apps Phx is famous for but beyond that it's a pain in the ass unless you are very good Elixir programmer and can bug fix and reinvent-the-wheel things out. Also, Phoenix is bad in environments with bad wi-fi. Think halls, kitchens, factories. So, I wouldn't do a Phx app for some warehouse2customers type of operation a because there are some very interesting out of connection problems, the necessity to constantly ping/"hearbeat" home to the server. For me it is a pass. The experience with 1.6 and 1.7 rc was bad. P.S. One extremely important thing, PHP is made for sloppy web programmers (like me). It will forgive and brute-force-work like hell when needed. Elixir is less forgiving and you can shoot yourself in the foot much easier. That's why I prefer PHP - it's much easier to put up some website that works well even on a cheap hardware and then you can PHP-optimize and tinker if you want. P.S.S. The speed thing is overhyped as well. PHP vs Elixir for web stuff is not as big difference. In Laravel - if you use PHP 8.2 and cache your views, routes, etc. the DB stuff is still the 80% of all of your problems, not the PHP or Laravel.
- sph 4y ago
  > Deploying Phoenix is a nightmare when compared to Laravel. What? These days it even comes with a Dockerfile. Yes, it's harder than copying PHP files, but have you ever administered a server running PHP? These days containers are the de-facto standard for any non-trivial application for a reason. Containerising PHP on the other hand is a bigger pain, as you need to set up Apache, fpm, php.ini and all the myriad of php libraries, THEN your actual code. > Phoenix is bad in environments with bad wi-fi Dude, stop with the misinformation. Phoenix is not Live View, and it's a web framework like any other. Either you're willingly spreading FUD, or you just don't know what you're talking about. This reminds me of a certain HN user deep into Rails that for a couple of years came to shit in every Elixir thread saying learning it is a waste of time and new developers should be learning Ruby instead.

Phoenix 1.7.0

356 points by thefreeman 4y ago

transfire 4y ago

Verified routes don’t seem to work in components. Is there a reason for that? Can/will it be fixed?

Liberonostrud 4y ago
[flagged]
- sanswork 4y ago
  Which projects?
- josevalim 4y ago
  It is impossible for new projects to be broken with this change. It is a new functionality which existing apps would have to opt-in to use. I don't understand the need to misrepresent what others have said.
- biorach 4y ago
  What's with you? You keep jumping in making negative comments only partially based in reality. You don't like Phoenix? Fine, who cares. But please don't keep spouting nonsense.
sanswork 4y ago
Check this out https://elixirforum.com/t/can-i-use-p-sigil-in-h-sigil/51986 https://elixirforum.com/t/can-i-use-p-sigil-in-h-sigil/51986
- josevalim 4y ago
  Thanks for adding a link. In a nutshell, it should work, if not, please follow up in the forum and folks will be glad to provide guidance!

koevet 4y ago

Is there anyone with experience on a large Elixir/Phoenix code base? Is the lack of static type system a problem?

Liberonostrud 4y ago
This is another problem of Phoenix. There are some big projects running on it, like cars.com but the code is not public and also they have a team of people who are good programmers and can bug-fix or pay people who can help bug-fix things for them. Watch the presentation of their switch to Phoenix and the gotchas they have encountered - for example how at first they didn't take into account the impact on Phoenix when users of sites like cars.com have opened 10 or 20 tabs (that have to be updated via websockets) instead of just 1 or 2 when they are comparing their dream car and how they thought that switching to Phoenix was a bad idea. Of course, they are smart ()or have money to pay smart programmers) and they solved this problem and now are happy with Phoenix ;). But as I said in previous posts, unlike with PHP that is very forgiving for sloppy code, Elixir does need higher skill level and the barrier to master it much, much higher than PHP.
- krstf13 4y ago
  You’re misrepresenting what’s being said in this talk (the relevant part of the talk is around the 15 minute mark at : https://youtu.be/XzAupUHiryg https://youtu.be/XzAupUHiryg ). The tldr was that they had patched some of the library code without considering the ramifications of the change. At no point in the talk is it said that “switching to Phoenix was a bad idea”. Also, none of the issues they talk about are related to the lack of static typing.
  - Liberonostrud 4y ago
    https://github.com/laravel/laravel/pull/6010 https://github.com/laravel/laravel/pull/6010
    - krstf13 4y ago
      So? Laravel uses type hinting, ok. This has absolutely nothing to do with your previous post grossly misrepresenting a talk. You hadn’t even mentioned Laravel in it. Type hinting is not equivalent to a static type system, which is what the parent was asking about. Finally, in either cases, it changes nothing to the fact that the pain points mentioned in the talk were not caused by the lack of a static type system (which is not to say it cannot cause pain points)

turbobooster 4y ago

I feel safer with SvelteKit

lpil 4y ago

Congratulations and thank you to the Phoenix team! Stellar work as always.

janandonly 4y ago

I came here because I thought this was about the app called Phoenix. I was wrong. Still, Phoenix deserves some love as well: https://phoenix.acinq.co/ https://phoenix.acinq.co/

pinetroey 4y ago

Has anyone experience with ash framework? I'd like to make an erp in phoenix & liveview. Should I use ash as well? Or avoid it.

borromakot 4y ago
Well, I made it, so I'm biased, but one of our most prolific users is a solo dev building a large ERP system with Ash.

pineapple_guy 4y ago

Ships with tailwind? We’re jumping the shark with that

cultofmetatron 4y ago
a lot of the community was already using it. plus you can easily overide it.
- the_sleaze9 4y ago
  I believe a fundamental design tenet for Phoenix is the idea of "do it _this_ way, but there's always an escape hatch if you want/need it."
  - jahsome 4y ago
    I think you just described every single framework in existence. If that's not the way, what signifies a properly designed framework in your opinion?
    - pcthrowaway 4y ago
      Heh.. you haven't tried express.
    - josevalim 4y ago
      I don't think there is a definite answer for "what a property designed framework" is but I can try to explain where Phoenix sits in the possible trade-offs. One possible approach frameworks use to provide escape hatches is configuration. You ship with a series of defaults and, once you want to change it, you need to find out the proper knob to turn. A downside of this approach is finding the proper knobs when you need to tweak it. Another approach is code generation: you generate code (or configuration) and keep the knobs clear to user. There are still defaults (and conventions) but the knobs are laid out upfront in your application. The downside here is that having so many knobs upfront may seen daunting or noisy. Since you mentioned Rails, I will provide references on how Rails and Phoenix use those. Both frameworks leverage both techniques above, but Phoenix errs more on code generation and Rails more on configuration. Here is a practical example. Rails has a middleware stack that is part of all applications. This stack is hidden from you. Here is how the generator file for said application looks like: https://github.com/rails/rails/blob/d0d9e8e576b06c19f850751001d19efadf81df73/railties/lib/rails/generators/rails/app/templates/config/application.rb.tt https://github.com/rails/rails/blob/d0d9e8e576b06c19f8507510... Phoenix has a similar stack (called plug) and the default stack is part of your application. Here is the generator file for it (it is not part of your app but used to generate it): https://github.com/phoenixframework/phoenix/blob/3c27a34c27c075af6c99a05168ea709d5389e4fc/installer/templates/phx_web/endpoint.ex https://github.com/phoenixframework/phoenix/blob/3c27a34c27c... You can look at these approaches and try to compare the pros and cons. --- My biased opinion: I have worked with both and I prefer the Phoenix approach. I understand someone may find having all steps in your endpoint noisy or daunting, but the plus side is that it takes a glance to see all steps a request goes through and you can tweak it in any way you want. When comparing to Rails, if you want to insert a middleware in the middle of the default stack, you need to explicitly say before or after which middleware. If you want remove something, you need to state the negation and say "I don't want to have this". Overtime this makes it hard for you to visualize what your application does, because you need to assemble the pieces in your head and use tools to print the stack for you. This also matters on releasing new framework versions. Because Rails has its own stack, if it changes the default middleware stack in any way, it can slightly change how your code. What if the middleware you were inserting before was moved up? Or removed altogether? Or maybe a middleware you deleted was replaced by another one, with similar functionality. Do you want to remove it too? This can lead to subtle differences of behaviour when upgrading. The code generation approach requires you to opt-in to the new features, which is, IMO, one of the reasons why Phoenix could avoid breaking changes in the last 8 years or so. This is in no way a knock on Rails. I am 100% confident the Rails team is aware of those trade-offs and could equally argue for their choices. It also isn't a binary choice either, both frameworks use both approaches, with some general preferences for one over the other.

Rodeoclash 4y ago

Looking forward to trying this release out soon. I'm not sure I quite grok streams yet (I understand the use case, but not the implementation). Verified routes aren't a game changer but certainly having more things use the compiler to verify themselves is welcome! I've been a Rails/Ruby developer for close to 10 years now I think and while I haven't used Phoenix/Elixir professionally, it's been my go to for a ton of side projects (The backend for my esports annotation tool, https://vodon.gg/ https://vodon.gg/ and its companion app for schlepping large video files to coaches, https://www.fileyeet.io/ https://www.fileyeet.io/). The best way to sum it up would be slightly less magic then Rails, 3rd party libs might take a bit more work / copy and pasting code to integrate them into your existing codebase. You'll likely write a few more lines of code to achieve the same thing in Ruby, but the ability to use the Beam VM, tooling like LiveView more than make up for the lack of magic. Even better, you'll soon appreciate the lack of magic as refactoring Elixir programs is a dream. It basically just boils down to separating out large functions into smaller composable functions. I also must add, the community is also awesome.

cassepipe 4y ago
I have no exxperience with Phoenix but I have started learning Elixir on exercism and used the Getting Started page alongside and it made for an enjoyable experience. After reading the previous chapters, I found Streams to be quite clear : https://elixir-lang.org/getting-started/enumerables-and-streams.html https://elixir-lang.org/getting-started/enumerables-and-stre... You are basically stacking functions (your pipeline) next to some data until it's consumed (i.e. the data goes into the pipeline). So I don't know about the implementation but it can't be that mysterious.
- di4na 4y ago
  It is a different "stream". The OP means the Phoenix Liveview new "stream" feature that allows you to efficiently update a list of HTML components without having to keep the whole list in memory, but only explaining the changes you want to do. The double sense of that name will trip some newcomers for sure. Happy that you like it though!

voicedYoda 4y ago

I've been working nearly exclusively in elixir and Phoenix for the last 2 years, and i love the community, documentation, and passion around this eco system. I'm stoked about this release, and with tailwind built-in, I'm really excited about next projects.

bluehatbrit 4y ago
Same here. I just spun up a new phoenix project (mix phx.new) to mess around with some of the new pieces and this really is a brilliant release.
arrowsmith 4y ago
Same here, I switched from Rails to Phoenix a few years ago and have never looked back. It solves so many of the frustrations I had with Rails and I love the Elixir language and the community around both. There was a little bit of a learning curve; Elixir's syntax looks like Ruby but the underlying philosophy of the languages is really quite different so it does take some getting used to, especially if you haven't worked with a functional language before. But it wasn't that bad; it's much more accessible than the other functional language I've dabbled in (Haskell). If I was starting a business the main thing that would put me off choosing Elixir would be the relatively small number of people who know it. If you want to have a lot of Elixir programmers in your company then you'll probably need to be willing to hire people people who don't know it yet but want to learn. But I hope this will change as Elixir keeps growing in popularity.
- lifesaverluke 4y ago
  Got some examples of solved frustrations you had with Rails?
  - arrowsmith 4y ago
    I actually answered this question (kinda) in a comment on another thread a couple of weeks ago. https://news.ycombinator.com/item?id=34858468 https://news.ycombinator.com/item?id=34858468

losvedir 4y ago

Are there any good up to date Phoenix books yet? I have Programming Phoenix, but it feels like these days with LiveView and unified function components, best practices are kind of different now.

di4na 4y ago
Have you tried the official guides in the doc? It should be up to date.
mike1o1 4y ago
https://pragprog.com/titles/liveview/programming-phoenix-liveview/ https://pragprog.com/titles/liveview/programming-phoenix-liv... Still in beta, but pretty up to date. Even in beta form, I thought it was pretty valuable!
isodev 4y ago
I had the Phoenix LiveView Course from Pragmatic Studio, and it recently got an update for Phoenix 1.7 https://pragmaticstudio.com/phoenix-liveview https://pragmaticstudio.com/phoenix-liveview. I really like the pace and the example use cases.

robertoandred 4y ago

[flagged]

bdcravens 4y ago
It has been around for 9 years.
ungamedplayer 4y ago
Which over elixir framework were you using ?

yeetaway1111 4y ago

There was so much mystery and magic that I felt was happening behind all things generated in Phoenix that I just felt lost.

Rodeoclash 4y ago
It might feel like that way to start with when you're new to the framework, but if you spend a bit of time in it you'll find a lot less magic going on then you expect. I know where you're coming from however, I felt the same way when I started.
ungamedplayer 4y ago
Is this in regard to 'mix phx' gen commands or something else ?
- Liberonostrud 4y ago
  I guess he is talking about macros and perhaps the syntax which I also didn't like and is one of the reasons why I consider PHP better (even though the naming and parameters inconsistency could be better). Check for yourself: ``` iex> length([1, 2, 3]) == length [1, 2, 3] true ``` or (taken from the Elixir docs): --- Take the following code: ``` if variable? do Call.this() else Call.that() end ``` Now let’s remove the conveniences one by one: do-end blocks are equivalent to keywords: `if variable?, do: Call.this(), else: Call.that()` Keyword lists as last argument do not require square brackets, but let’s add them: `if variable?, [do: Call.this(), else: Call.that()]` Keyword lists are the same as lists of two-element tuples: `if variable?, [{:do, Call.this()}, {:else, Call.that()}]` Finally, parentheses are optional, but let’s add them: `if(variable?, [{:do, Call.this()}, {:else, Call.that()}])` That’s it! Those four rules outline the optional syntax available in Elixir. Those rules apply everywhere consistently, regardless of the construct you are invoking. Whenever you have any questions, this quick walk-through has you covered. --- I don't like this possiblity to use so many syntaxes good, especially if you deal with mulitple parameters in functions. Elixir doesn't have C-like semicolons or braces like in Lisp so multiple parameters are hard to parse sometimes. The creator of Elixir himself answered that one of the things he thinks he could do better at the beginning was to make the syntax more strict and he mentions the optional () e.g. IO.puts "Hello" vs IO.puts("Hello").

lycos 4y ago

We've been using 1.7.0 as rc for a while now and the verified routes especially have been much more enjoyable to use. Unifying components between controllers and liveview was also a welcome improvement The only thing I really don't like is having the `page_html.ex` and `page_html/index.html.heex` etc files in `controllers` being the recommended workflow. It feels so weird to have the templates live there, luckily you can put them wherever you want so it's not a real problem Haven't used streams yet but it looks interesting and looking forward to play with that as well.

josevalim 4y ago
> It feels so weird to have the templates live there, luckily you can put them wherever you want so it's not a real problem It is curious how some topics like template collocation are divisive. :) In any case, Phoenix had employed both collocation for LV and non-collocation for controllers, so it makes sense to unify the default experience. But ultimately you are right that it does not care where templates are defined!
- lycos 4y ago
  (thanks for all your work!) I understand the reasoning and especially when you put it like that it makes sense, the reason i feels weird to me is mainly because it's just different than many years of development with various frameworks (including Phoenix until this change). So it is more a "I don't like change!" comment ;) For what it's worth, I mentioned that and the fact that you can use it however you want because it's such a fun and customisable framework, but in our production apps we just try to stick to defaults/recommended workflow so we do have all these files in the controller directory now. I do still wonder if maybe the controller directory just needs a new name since it now contains more than just controllers, but I can't think of any good options and naming is hard.
bongobingo1 4y ago
>The only thing I really don't like is having the `page_html.ex` and `page_html/index.html.heex` etc files in `controllers` being the recommended workflow. It feels so weird to have the templates live there, luckily you can put them wherever you want so it's not a real problem I have found this (moving them where ever you want) to be a lot simpler to wire up in 1.7 vs the old `use ...` options!

ecmascript 4y ago

I like Elixir and Phoenix liveview. It is a fresh take to web dev in my opinion. However, I have for the past couple of years worked on apps that really push the bounderies of what can be called a web app. So my need for Elixir is limited and even on my spare time projects I find myself having a hard time justifying using Elixir since my invested knowledge in other technologies are so vast in comparison. To get in par it would take me years of Elixir development and I have a hard time justifying it. For example, I want to build an ecommerce site, a perfect suitable case for Phoenix. The issue is, that I find it to be easier, faster and more reliable for me to just spin up a static site and then add some API layer for the checkout process. I kind of want a need for Phoenix, but so far I haven't had a strong case. Unfortunately though becasue I really like the community and spirit it has. I think it is a language and framework that deserves much more adoption than it seems it has.

di4na 4y ago
Tbf i think using a static website like you describe is a better use case anyway for this. Phoenix and co are for things that are quite dynamic or personalised to a user. Ecommerce is not that :)

moomoo11 4y ago

Can someone please give advice on how to accomplish the following with phoenix sockets? Say I have processes for each physical device in the world that are moving around (like on water or something). Any time there is an “anomaly” I want to double check by having all nearby processes/devices run the same check again. Is there a way to run a filter by geoquerying without having to rely on storing the coordinates in a separate store and querying for those device/process IDs? I can store the coordinates in each process, and I want to be able to find nearby processes in one go without using a separate system for finding them. I’m quite a noob at phoenix..

hdra 4y ago
why do you need the phoenix part? maybe consider a short-distance wireless comm like bluetooth or zigbee and have them broadcast to nearby devices? have the devices respond to the re-check broadcast and physics will take care of the locating nearby devices part
conradfr 4y ago
(not sure where the "phoenix sockets" fit into it) 1/ So I guess you're saying one process/GenServer per device, communicating with it. 2/ Use a Registry[0] to store the process names (based on the device id or whatever) to abstract them from their PID. 3/ Have another GenServer (let's call it CoordStore) storing a map of "process_name -> lat/long" (with the related processes sending updates of the coordinates to it) 4/ Use Presence[1] to keep track of the devices and remove them from the CoordStore when needed. 5/ When you have an anomaly on one device ask CoordStore for the nearby devices/processes (using maybe [2]) and ask each one (thanks to the Registry) to run the check. 6/ Done? (sure you can do a barebone version without the Registry or Presence but where's the fun in that?) [0] https://hexdocs.pm/elixir/1.14.3/Registry.html https://hexdocs.pm/elixir/1.14.3/Registry.html [1] https://hexdocs.pm/phoenix/Phoenix.Presence.html https://hexdocs.pm/phoenix/Phoenix.Presence.html [2] https://github.com/yltsrc/geocalc https://github.com/yltsrc/geocalc
rkangel 4y ago
Simplest thing is to use Phoenix PubSub. Broadcast an "anomaly at x,y,z coordinates" message. Then each process can calculate whether it is close and needs to do anything. This isn't very efficient because every process will do some work for every anomaly, but unless your system is very large that's probably OK (it as least extremely parallelised). The alternate approach is to create some form of central process registry that has all the coordinates and process ids, so that you can look up in one place and then send messages out to the relevant processes. There are some other replies about this sort of approach.

Liberonostrud 4y ago

If you are an Elixir (or perhaps Clojure) expert, the following doesn't apply. But every other person jumping ship from, for example PHP or JavaScript should think twice. I think Phoenix is overhyped a lot. The barrier to entry is gigantic. The lack of up-to-date resources doesn't help. It's definitely not as polished as Laravel for example. And while there is Pragmatic Studio with their wonderful introduction video, there is nothing like Laracasts where there are new tutorials added all the time. Frankly, it's on another level. Deploying Phoenix is a nightmare when compared to Laravel. In Phx you have to reinvent a lot of things and often, of course, choosing the wrong path. Sure try the chat demo apps Phx is famous for but beyond that it's a pain in the ass unless you are very good Elixir programmer and can bug fix and reinvent-the-wheel things out. Also, Phoenix is bad in environments with bad wi-fi. Think halls, kitchens, factories. So, I wouldn't do a Phx app for some warehouse2customers type of operation a because there are some very interesting out of connection problems, the necessity to constantly ping/"hearbeat" home to the server. For me it is a pass. The experience with 1.6 and 1.7 rc was bad. P.S. One extremely important thing, PHP is made for sloppy web programmers (like me). It will forgive and brute-force-work like hell when needed. Elixir is less forgiving and you can shoot yourself in the foot much easier. That's why I prefer PHP - it's much easier to put up some website that works well even on a cheap hardware and then you can PHP-optimize and tinker if you want. P.S.S. The speed thing is overhyped as well. PHP vs Elixir for web stuff is not as big difference. In Laravel - if you use PHP 8.2 and cache your views, routes, etc. the DB stuff is still the 80% of all of your problems, not the PHP or Laravel.

sph 4y ago
> Deploying Phoenix is a nightmare when compared to Laravel. What? These days it even comes with a Dockerfile. Yes, it's harder than copying PHP files, but have you ever administered a server running PHP? These days containers are the de-facto standard for any non-trivial application for a reason. Containerising PHP on the other hand is a bigger pain, as you need to set up Apache, fpm, php.ini and all the myriad of php libraries, THEN your actual code. > Phoenix is bad in environments with bad wi-fi Dude, stop with the misinformation. Phoenix is not Live View, and it's a web framework like any other. Either you're willingly spreading FUD, or you just don't know what you're talking about. This reminds me of a certain HN user deep into Rails that for a couple of years came to shit in every Elixir thread saying learning it is a waste of time and new developers should be learning Ruby instead.