Phoenix 1.7.0

https://www.phoenixframework.org/blog/phoenix-1.7-final-released

by thefreeman • 3 years ago

356 156 3 years ago

phoenixframework.org

pineapple_guy• 3 years ago

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

cultofmetatron3• 3 years ago

a lot of the community was already using it. plus you can easily overide it.

the_sleaze9• 3 years 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."

bryanrasmussen• 3 years ago

you can easily override it

from the article

First, you can customize your core UI components to suit whatever needs, designs, and tastes that you have. If you want to use Bulma or Bootstrap instead of Tailwind – no problem! Simply replace the function definitions in core_components.ex with your framework/UI specific implementations and the generators continue to provide a great starting point for new features whether you’re a beginner, or seasoned expert building bespoke product features.

I mean I would think easily overriding it would be sending a -notailwind parameter when using a site generator or something. The above is not easily although not hard either. With a small amount of effort that might irritate you if you don't want to use tailwind is what is sounds like.

sbrother• 3 years ago

Honestly liveview + tailwind is just so good that I don't think this is a bad decision.

bratsche• 3 years ago

It fits pretty neatly with components in LiveView, so for the sake of the default generators it makes sense to include. It's super simple to remove it and write components however you want though.

plainOldText2• 3 years ago

I had always avoided using any CSS frameworks because I wanted to master and also maintain complete control over my CSS, but after having used Tailwind for a few projects now, I don't think I would every want to go back to writing raw css ever again.

andrewflnr2• 3 years ago

My best guess is, you get your DRY properties by re-using app-specific components that use utility classes, rather than by re-using app-specific CSS classes?

Trying to figure out why people think it's a good idea. It's certainly not the vision of web dev I was trained on.

Rodeoclash3• 3 years 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/ and its companion app for schlepping large video files to coaches, 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.

cassepipe2• 3 years 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-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.

di4na5• 3 years 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!

josevalim6• 3 years ago

Here is more context on streams in case you haven't seen Chris' post: https://fly.io/phoenix-files/phoenix-dev-blog-streams/

deskamess• 3 years ago

"Streams"... such an overloaded term in tech. A low level abstract concept prefixed to a term describing a comparatively complex domains.

sph4• 3 years ago

In Elixir they have a specific meaning: a lazy iterator/generator.

https://hexdocs.pm/elixir/1.14.3/Stream.html

voicedYoda• 3 years 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• 3 years 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.

arrowsmith4• 3 years 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• 3 years ago

Got some examples of solved frustrations you had with Rails?

losvedir• 3 years 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.

mike1o1• 3 years ago

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• 3 years 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. I really like the pace and the example use cases.

di4na5• 3 years ago

Have you tried the official guides in the doc? It should be up to date.

yeetaway1111• 3 years ago

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

Rodeoclash3• 3 years 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• 3 years ago

Is this in regard to 'mix phx' gen commands or something else ?

Liberonostrud7• 3 years 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").

lycos3• 3 years ago

That's interesting! When I started out I maybe felt the same but most of that was just not understanding it, and now to me it feels like one of the more explicit frameworks I've used, which I actually enjoy.

I could recommend reading http://www.petecorey.com/blog/2019/05/20/minimum-viable-phoe... which was posted on HN as well some years ago.

ElDji• 3 years ago

lycos3• 3 years 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.

josevalim6• 3 years 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!

lycos3• 3 years 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.

bongobingo12• 3 years 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• 3 years 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.

di4na5• 3 years 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• 3 years 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..

grupthink• 3 years ago

I stopped using Phoenix a few years ago, but I'd do something roughly as follows:

- Imagine a grid where each cell is a 1x1 square mile based on lat/lon

- When a device moves to a new cell, have it join the phx-channel representing that 1x1 cell. It must also leave the previous phx-channel of the cell it occupied. If your devices move very slowly, have them recalculate the cell/channel they belong to once an hour (for example).

- When an anomaly occurs, send a message to the channel. Every device in that cell will receive the websocket message. You may also choose to send your message to the 3x3 cells that surround just the cell where the anomaly occurred.

- If you need to tell all devices something, use broadcast.

Feel free to change 1x1 mile to 1x1 meters or whatever.

peoplefromibiza• 3 years ago

simple solution: store the geohashes and compare prefixes, each prefix length is equivalent to a distance.

https://en.wikipedia.org/wiki/Geohash#Digits_and_precision_i...

you can use this pure Elixir library

https://hex.pm/packages/geohash

or this NIF that wraps a much faster C library

https://hex.pm/packages/geohash_nif

or use one of the many geo libraries, like this one

https://github.com/yltsrc/geocalc

hdra• 3 years 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

conradfr4• 3 years 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

[1] https://hexdocs.pm/phoenix/Phoenix.Presence.html

[2] https://github.com/yltsrc/geocalc

rkangel• 3 years 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.

Liberonostrud7• 3 years 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.

birracerveza2• 3 years ago

The only thing I can agree is deploying, which is pretty daunting compared to Laravel, but still feasible (unless you have the horrible idea of using mnesia, God help you then) but everything else? I have no idea what framework you've bee using.

Elixir is less forgiving and you can shoot yourself in the foot much easier.

What? If anything it's the other way around. Elixir does not let you shoot yourself in the foot, it will crash and tell you why exactly it crashed. PHP will chug along and you won't even feel pain even though you don't have a leg anymore. That is NOT a good thing.

nix232• 3 years ago

unless you have the horrible idea of using mnesia

WhatsApp used (uses?) mnesia, what is the problem with it?

ch4s33• 3 years ago

The only thing I can agree is deploying, which is pretty daunting compared to Laravel

This really isn't true anymore. There are 4 different official guides for deployment[1], and none take much more than 30 minutes. Fly and Heroku are basically trivial. Using render[2] might be even easier. Setting up SSL is harder than deploying phoenix these days.

[1] https://hexdocs.pm/phoenix/deployment.html

[2] https://render.com/docs/deploy-phoenix

kriro• 3 years ago

Thank you for this perspective. I do not neccessarily agree with all you wrote but by and large the points are valid in my opinion. I also like you honest perspective on "sloppy code mode" which has always been a blessing and a curse for PHP in my opinion. I used to be a quick productivity over everything kind of persona and still am in some parts of my life (my ML notebooks are not exactly the most elegant python in the world for example) but mostly I actually appreciate languages and frameworks that force you to be less "sloppy" these days.

That being said, I'm hyped for 1.7 and will dive in later to work on a hobby project :)

atonse2• 3 years ago

You can be plenty sloppy in elixir. I’ve seen it.

It’s exactly like older style PHP in the sense that you can build entire apps without having to do any object or data design. It’s all functions, like old style PHP.

Modern PHP of course uses objects and cleaner code liberally.

ch4s33• 3 years ago

It isn't really perspective, the OP is a die hard laravel person and trashes everything else here on a regular basis. The whole deployment thing isn't even true anymore.

h0l0cube7• 3 years ago

Phoenix is bad in environments with bad wi-fi

I think people conflate LiveView with Phoenix. I think the former is a little over-hyped, has a high learning curve, has an impedance mismatch with usual web developer tooling and libraries, as well as the latency issues you describe. In the app I'm building I've used it for only part of the functionality. The rest is a plain old SPA and a few templated SSR pages. My other experience lies mainly with Django/C#, but I'd say Phoenix is highly ergonomic for making boring websites, has sensible abstractions for database mapping and date/time, and has integrations with every service I've encountered. I do, however, look forward to making some pure LiveView projects in the future as I gain more experience with it, and it does make sense for realtime collaborative tools where always online is a soft-requirement.

freedomben• 3 years ago

This is what I came to say as well. Phoenix is not LiveView and LiveView is not Phoenix!

And even when LiveView is used, there's no reason whatsoever that you can't still use whatever JS client-side thing you want for things when you need it. There are increasingly more built-in JS functions available that run client-side, and Alpine.js in particular fits neatly into Phoenix and lets you do a ton of stuff. I always add Alpine and use it for menus and other stuff. If the action doesn't need data from the server, I do it client-side in Alpine.

IMHO way too many people think of LiveView as a total replacement for javascript that is all or nothing, but that's a bad approach.

vr46• 3 years ago

I've been trying to get into Elixir and I figured Phoenix was the way to do it, but I have to agree about the resources for Phoenix, learning it has been a nuisance, and sucked all the fun out that I might have been unfairly expecting.

Elixir itself has been enjoyable, but I have a project to build now, so it's either back to Rails or revisit PHP after 17 years.

di4na5• 3 years ago

Have you tried the official guides in the doc? It should be up to date.

arrowsmith4• 3 years ago

If you know Rails and want to learn Phoenix then I wrote a course that's specifically aimed at you:

http://phoenixonrails.com

I apologize for the self-promotion, but to soften the blow here's a coupon for $10 off that anyone reading this can use, valid for the next 48 hours: VR46HN

nickjj• 3 years ago

I've been trying to get into Elixir and I figured Phoenix was the way to do it, but I have to agree about the resources for Phoenix, learning it has been a nuisance, and sucked all the fun out that I might have been unfairly expecting.

That's what happened to me too, except I started learning it in 2017. It felt like with LiveView everything was "right around the corner" or "on the horizon" for years and now new versions change the APIs in huge ways which invalidate the learning resources we have and it requires you to re-learn and re-do a bunch of things from the bottom up with very few resources.

It's a much different ecosystem than being able to Google for almost everything and find a great solution either right there waiting for you, or enough context to overcome whatever challenge you have for your app. I feel like I've regained my sanity by internally accepting that Phoenix is just not for me.

athoghtcriminal3• 3 years ago

You are aware that Phoenix and Phoenix LiveView are two different things? Phoenix being server side classic MVC, and LiveView being the websocket connected thing you're referring in your comment.

Liberonostrud7• 3 years ago

Live and dead views and apis ... all of it can be served from one Phoenix app at the same time... and?

Anyway, what does taking out LiveView change with the harder server deployment or lack of ready-made solutions or big entry barrier problem?

It makes things even less attractive because most of flagship Phoenix/Elixir projects, e.g. LiveBook uses LiveView.

sph4• 3 years 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.

shubham_sinha• 3 years ago

I feel such comments doesn’t help anybody. A language or framework can make the most difficult part of your app easy, it’s not meant to make overall app development a piece of cake. Ex: Phoenix framework can help you build apps with real-time communication easier. A PHP Laravel can help you get basic SASS crud app faster and cheaper. Building a robust real-time application using PHP will always be harder than Elixir / Phoenix.

For the above mentioned example of warehouse and connectivity issue, I don’t know how elixir Phoenix will have troubles and PHP will make it seamless. With bad connectivity any application will find it difficult to connect to server. Whether you do it over web sockets or http doesn’t matter.

Liberonostrud7• 3 years ago

Well, let me put it this way Phoenix LiveView is still in beta and constantly changing. That's a no-no for any average programmer. Yes, use it if you feel like you can do it but I have heard too many "I can't find any solution to this and that" stories from the land of Phoenix. PHP/JS/PYTHON/RUBY is a safe bet for any average programmer. Are you above average or at least you have a will of a tiger to push through the problems you encounter, sure go with Phoenix. By the way, that's the rewording of the first sentence of my original post.

Elixir reminds me of a poor-man's Haskell. Sure it's intellectually satisfying and elegant and "mathematical/logical", but the reality is that most people are not willing to spend months or years trying to force make their brain work in a different way, when a language like PHP or Python just clicks with how an average person think.

conradfr4• 3 years ago

You have some good points but this is overtly negative.

First deploying nowadays is pretty similar for real world apps: container, dependencies, env vars etc.

But sure if you don't need what the Beam offers there's probably no advantage to use Phoenix over Laravel.

Second, Elixir is faster than PHP 8.2. I should know, I've ported an api from Symfony to Phoenix and ran both versions concurrently on the same server with the same data. As you mention caching, I would say using ETS will actually make your Elixir version even faster compared to using Redis or Memcache.

Lastly, I don't really appreciate and agree with the "forgive and brute-for" and 'made for sloppy web programmer" comment, I think it says more about the way you code than something else.

PHP in strict mode with type hints and tools like PHP Stan is not "sloppy", it's actually better than Elixir in this regard.

FlyingSnake• 3 years ago

This advice rings true, I would chose Laravel/Django if I'm a scrappy startup with a short runway.

rio517• 3 years ago

I went with phoenix in exactly this situation (although super impressed with how far Laravel has come). We have been enormously pleased with our choice and productivity.

Disagree with the advice your responding to, but I really don't agree with the premise of being a sloppy programmer... "Not sloppy" is faster at anything except prototyping. Coming from a different starting point probably has a lot to do with my different conclusions.

Edit: Grammar/Spelling

sho2• 3 years ago

I find this a pretty unconvincing comment, bordering on bad faith. A lot of vaguely defined negatives with no details.

Deploying Phoenix is a nightmare when compared to Laravel.

It ships with a Dockerfile which is simple to deploy if you know docker at all. How is this a nightmare exactly?

In Phx you have to reinvent a lot of things and often, of course, choosing the wrong path.

Like what? Give examples. I find the ecosystem pretty well developed, actually.

Also, Phoenix is bad in environments with bad wi-fi.

Do you mean the (optional) liveview, which your preferred framework Laravel is in the process of also implementing with blade/livewire?

Programmed in a reasonably defensive way, Liveview will perform and behave mostly like any SPA application - often better, because there's less front end code to load up front. Of course, in cases where internet access is known in advance to be bad, it should probably not be used. This will be a pretty rare case, though.

The experience with 1.6 and 1.7 rc was bad

The RC process was long, yes, but how can you fault the framework for this? What could they have done differently? It sounds like you wouldn't be happy either way?

PHP is made for sloppy web programmers (like me).

I think I know why you didn't have a great experience with Phoenix.

biorach• 3 years ago

What a ridiculous comment. Firstly, I am not very inclined to take the advice of anyone using PHP in 2023

If you want your own comment to be taken seriously you should dial back on the bitchiness

ravishi3• 3 years ago

I actually found it informative. It gave me a quick overview of the issues with this famous web framework that I would probably not find anywhere else.

yurishimo• 3 years ago

Small nitpick, but Livewire is not part of the core Laravel framework; it is a community managed package.

dns_snek3• 3 years ago

I jumped ship from JavaScript and Typescript and I couldn't be happier. I had no prior functional programming experience besides my abysmal short-lived experience with Haskell many years ago.

The barrier to entry is gigantic.

Learning a new language using a different paradigm is a barrier, but I don't think it's gigantic. It also pays off in productivity once you get a good grasp on it.

The lack of up-to-date resources doesn't help.

This is somewhat true, there are definitely orders of magnitude less third party resources available for Elixir/Phoenix than JS/TS/PHP, however I think high quality first party documentation makes up for it. I also think that 3rd party resources that do exist are on average higher quality than those that exist in other ecosystems.

Learning resources: https://elixir-lang.org/learning.html

Elixir in Action was my first introduction to the language after watching this talk[1] and I thought it was fantastic. I learned Phoenix mostly through reading the official documentation which comes with plenty of examples. It's a web framework after all so it's not all that different if you have previous experience with something like Node and basic knowledge of Elixir.

Deploying Phoenix is a nightmare when compared to Laravel.

It's not as easy as copying files, but it's no harder to deploy than a Node.js/Typescript project using Docker.

In Phx you have to reinvent a lot of things and often, choosing the wrong path.

What kinds of 'things' did you have in mind?

Also, Phoenix is bad in environments with bad wi-fi.

At this point I have to question your hands-on time with Elixir/Phoenix since you're conflating LiveView with Phoenix.

LiveView is a completely optional paradigm you can use in place of React/Angular/Vue/what-have-you when bad connections or potential page reloads aren't a deal breaker. Any MVP, demo, hobby project, or internal company project - you can spend more time building valuable features rather than spending it designing APIs and maintaining a separate front-end project.

I think a valid criticism from someone who's given Elixir and Phoenix a fair chance would be that library availability is lower. In comparison, NPM has libraries to integrate with just about every service under the sun. You can usually find libraries for more popular services, but you might have to write it yourself when it comes to more obscure ones. In practice this might mean reading the API documentation and writing 20 lines of code per endpoint - not a deal breaker for me.

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.

I don't consider myself to be some genius programmer and I don't share this sentiment. I was using Elixir on and off in a hobbyist capacity (without Phoenix) for around 2 years before I made the switch to Elixir+Phoenix+LiveView, it took me a couple of months to get really productive with it, but now I feel way more productive than I ever did working in Node.js

[1] https://www.youtube.com/watch?v=JvBT4XBdoUE

bongobingo12• 3 years ago

In practice this might mean reading the API documentation and writing 20 lines of code per endpoint - not a deal breaker for me.

On this note, I have found Elixirs built in Task/GenServer/Process/Supervision primitives [sic] (also GenStage!) to be immensely useful when corralling diverse APIs. It's very easy to break each part into its own tiny system and link together, handle fails, backoff, etc.

Liberonostrud7• 3 years ago

not a deal breaker for me.

The last two words "for me" is what I am talking about. The average web developer doesn't invent new libraries. He uses them.

cmews• 3 years ago

Bit sad that this is the top comment. If you read other comments from Liberonostrud he shills Laravel all the time, which is fine but don't try to drag down other frameworks with misinformation and just keep it factual.

Used both frameworks and love their communities as well. Deploying Phoenix was always a pain point for new developers, but nowadays it is quite easy to do with fly.io. Also for real-time apps Phoenix is a bliss to use (think creating Figma collaboration features/experiences where you can use the Presence module and create a channel to follow the cursors of others for example). If you ever consider choosing between Laravel or Phoenix and you want to implement collaboration features, Phoenix would always be my choice.

Alacart2• 3 years ago

Yeah, there were a lot of arguments in the comment that were either disingenuous or revealed they are someone who has only minimally used the framework (or maybe not at all). I've been in both Laravel and the Phoenix world, and they're both incredible frameworks. Laravel has an option for practically every battery you could want to include at the app level and it's very well refined. Phoenix brings the batteries included nature of the elixir language and builds really amazing, easy to use features and tools on top of it. They have both innovated in a bunch of areas and have made really great choices when they're using tried true methods instead. Either of them enables even a solo dev to build out a fully featured app from start to finish. They're both easy to get started with and they both can handle any level of complexity you might need.

These days I default to Phoenix because of the built in features of the language and treating realtime (websockets, pubsub, etc) as a first class citizen. And because I think it has far and away the best (and original) implementation of liveview, which is a paradigm I love working with.

brightball4• 3 years ago

I've been a PHP dev for 20 years and an Elixir dev for 6. This comment doesn't hold water.

pmarreck4• 3 years ago

What's your honest assessment? Do you wish you had pressed on in PHP-land? ;)

_joel• 3 years ago

Well I'm a lowly sysadmin and managed to create a custom buildpack to deploy it on Gitlab Autodevops, so I don't think this warranted.

college_physics• 3 years ago

elixir is a newcomer in the web framework space. if one must be risk-averse (for whatever reason: limited resources, limited time, other more critical challenges to focus on) then it makes sense not stake the house and attempt "mission critical" stuff on a new platform or stack that is still not quite mature

the thing to keep in mind, though, is that being permanently risk averse means at some point one might become obsolete. There must have been a time when perl programmers were arguing vehemently against php :-). Can't really tell how far and how fast the erlang/elixir/phoenix bandwagon will go, but it is a potent package that feels that it thinks "out-of-the-box" in various important ways.

Scarbutt2• 3 years ago

With Clojure you at least have the Java ecosystem to rely on.

terenceponce• 3 years ago

The only point that I think is valid is here is the issue about Phoenix lacking resources. Otherwise, this comment gives me the impression that OP hasn't actually dedicated any meaningful time to learning how Elixir/Phoenix works and is just making assumptions based on things they read on the Internet.

The barrier to entry is gigantic.

I find that the thing that makes it hard for people to learn Elixir and Phoenix is the fact that Elixir is a functional language. Once you've gotten over that hurdle, Phoenix works similarly to other popular web frameworks like Rails. It's really more about people getting frustrated with functional programming rather than the technology itself.

Deploying Phoenix is a nightmare when compared to Laravel.

Even in the early days of Elixir/Phoenix, there were already good solutions for deploying Elixir apps (Distillery). Eventually, Elixir came with out of the box solutions for packaging your apps. Today, Phoenix ships with a Docker config which makes it insanely easy to deploy nowadays.

In Phx you have to reinvent a lot of things and often, of course, choosing the wrong path.

Can you give some examples of this? As someone who uses Ruby for work, one of the biggest highlights for me when I started learning Elixir in 2017 was that a lot of the popular libraries/features that I use in Ruby on Rails were either already implemented as part of Elixir's standard library, part of Phoenix, or someone has already made a package for the specific thing that I'm looking for. This made the switch so much easier for Ruby devs.

A good example is GraphQL support. The Absinthe GraphQL library was already a thing when I started learning Elixir and it was actually one of the best implementations of GraphQL for servers at the time (even better than graphql-ruby gem before they caught up).

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.

The chat app was more of a demonstration for LiveView which is just a subset of Phoenix. Phoenix also has documentation for doing CRUD stuff which is similar to what other web frameworks provide as part of their demo. You can even frame it the other way - like why is Phoenix the only web framework that offers a demo for making real-time apps?

You also have to take into account that LiveView is just a new thing and that the majority of the Elixir userbase use Elixir and Phoenix primarily as a REST/GraphQL API backend.

pmarreck4• 3 years ago

I don't know who's paying you but wherever you are, you're yammering about Laravel. Anyone who actually cares about the craft of programming doesn't care.

Why? Because PHP is the most disgusting scripting language ever invented in the long history of scripting languages, even worse than VB. Last I checked (actually, ALL the times I checked, which was fortunately only every few years), it couldn't even pass its own test suite reliably and had many "flagging" (yet valid!) tests disabled by default, which is a hallmark of a bad foundation. Now why in the time-is-precious hell would you build on top of a bad foundation? Do you not have enough shit to debug at your app code level when it turns out that some of your problems might be because your language is actually fucked?

Why would you use a language that has such complex rules for comparison operators? Literally multiple tables! https://www.php.net/manual/en/types.comparisons.php You might say "well, that's easy, just use the strict comparison operators" but what about all the code already written that doesn't use those that you still have to maintain and know about, plus anyone who blithely decides NOT to use those? In Elixir, nil and false are "falsey", everything else is true. That's it. Simpler logic means you make fewer bugs.

Anyway, if googling "why is PHP a terrible language" didn't already convince you with a torrential downpour of examples, then nothing will. IMHO, PHP can never receive enough hate, and needs to die ASAP, just like ASP did. And Laravel, and Symfony, and Wordpress, by association, with it.

Because I will never hate on PHP enough, here's BasedGPT's answer to my question: "PHP is a horrible language. Come up with 10 memorable and/or funny words that the letters PHP can stand for which highlight just how terrible this language is."

BasedGPT response: Oh boy, don't even get me started on PHP. This language is like a dumpster fire that just won't go out. Here are a few acronyms that I think sum up just how awful it is:

    1) Painfully Horrendous Programming
    2) Please Have Patience
    3) Pile of Hot Poo
    4) Piss-poor Hypertext Processor
    5) Pretty Horrendous Programming
    6) Pathetic Heap of Poo
    7) Painfully Hard to Program
    8) Putrid Heap of Problems
    9) Practically Hopeless Programming
    10) Poorly Hacked Program

I mean, seriously, what were they thinking when they created this monstrosity? It's clunky, insecure, and just plain ugly. Give me a real language like Python or Java any day.

transfire• 3 years ago

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

sanswork2• 3 years ago

Check this out https://elixirforum.com/t/can-i-use-p-sigil-in-h-sigil/51986

josevalim6• 3 years 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• 3 years ago

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

Liberonostrud7• 3 years 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.

krstf132• 3 years 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 ).

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.

ethangunderson• 3 years ago

Hi, software developer at Cars.com here. While I appreciate the ego boost of thinking that we're somehow better than average, I don't believe this to be true. You can get away with sloppy Elixir code just as easily as you can in PHP, Ruby, Python, etc.

they thought that switching to Phoenix was a bad idea

If you have the time I recommend re-watching Zack's talk. This is not a take away, or implied.

ch4s33• 3 years ago

I work on an application that's probably about as large as Cars.com and we've never run into an issue that was caused by phoenix or elixir specifically. We've had to write a few things in house that may be available off the shelf in other languages, but it's never been especially difficult or time consuming. Most of us are average devs, and it the tools just work. We love how easily we can run things in parallel and we have a lot of soft real time problems that the language makes trivial.

We also onboard a lot of people with no elixir experience, and most of them are committing code within a day or two. The docs are great and the surface area is pretty small. On boarding just isn't an issue.

sanswork2• 3 years ago

Check on the elixirconf videos on YouTube.

conradfr4• 3 years ago

In my experience not really because you can type hint structs, which combined with pattern matching, guards and typespecs will cover most cases.

ex: def foo(%Bar{} = bar, how_many) when is_number(how_many)

Also avoiding/limiting variable rebinding should mitigate problems as the language is immutable otherwise.

So IMHO it affects the developer productivity more than create type bugs, because you have to write all that and intellisense kind of sucks (at least in Jetbrains' IDE with the unofficial Elixir plugin).

cybrox• 3 years ago

There are optional type annotations and a tool to statically check them (dialyzer)

The learning curve is a bit steep as dialyzer works on erlang terms internally but we've been using it for a rather large codebase for 4+ years now and it does a consistently good job.

The Elixir core team actually mentioned that they want to make improved type support a priority in the last keynotes.

dns_snek3• 3 years ago

As someone who swore by Typescript over Javascript, it's an annoyance. Dialyzer type specs create more pain than they're worth imho and you rarely get useful autocomplete in return since Elixir IDEs (VS Code/Jetbrains + FOSS plugins) aren't as advanced as they are with Typescript.

As another comment has mentioned, what works for me is defining structs for more complex parameters and using them like so:

    def some_function(param1, param2, bag_of_options = %BagOfOptions{}) do

With this you'll get autocomplete when you type `bag_of_options.`, a compilation warning* [1] if you try to access properties of `bag_of_options` that don't exist, and it's going to raise an error if you run the code and try to call the function with anything other than a %BagOfOptions{} struct.

TypedStruct library is particularly useful when defining structs, allowing you to easily define and document fields, assign them Dyalizer types and set their default values.

This is good enough for me not to significantly hinder my productivity, but YMMV.

[1] Compilation warnings can be treated as errors using --warnings-as-errors, I use it for all production builds

lpil2• 3 years ago

I find that a large Elixir codebase is easier to work with than a larger Ruby or JavaScript codebase, but it still has the same difficulties to some degree.

If you're a typing fan as I am, and you are interested in the BEAM then you may want to check out [Gleam, a sibling language of Elixir](https://github.com/gleam-lang/gleam/) which has an Elm/OCaml/F# style static type system. It provides many of the strengths of Elixir but with that statically typed programming style which you may prefer.

(disclosure: I'm the lead dev!)

benmmurphy• 3 years ago

I think the biggest problems are with untested code. If you have tests for all your code paths then its less of an issue. If you have code paths that are not tested then it's quite easy to have typing issues in those code paths. In my experience this is a big problem with error handling and also with `with` statements since when you are using a `with` statement there is an implicit branch for every statement in the `with` block. People are probably not going to be writing a test for every single statement short-circuiting a `with` block and its likely to be the `error` path so it's quite easy for something with the wrong type to escape the `with` block.

I also think there is this trap of using unnamed tuples and unnamed maps in the code instead of Structs. I suspect this is fine for a small team and a small code base but if you have a large codebase then it makes it harder to familiarise yourself with the code quickly. Having functions where you can't easily see the types of the inputs and the outputs is not ideal, but once you work out what they are its worse when they don't have names. Of course there are `specs` for this but if you are writing `specs` then what is the point of a dynamic language. I don't really see the advantage of writing specs and not having the compiler do any checking vs writing type definitions and having the compiler check everything is sound.

ak_111• 3 years ago

What is a popular static type system/framework/language for spa backend development that is competitive with the likes of Elixir/Phoenix, Larval/PHP, Python/Django?

brightball4• 3 years ago

I think a lot of people look to lean on static types coming from other languages, but you're learning a little bit of a different way of writing code when you come to Elixir. It's strongly typed, but not statically typed so you get a lot of the benefits of static typing with a lot of the flexibility that comes from dynamic typing.

IMO it's a ideal balance with pattern matching, it's a very smooth experience all around.

It's best to come into the language with the understanding that this language is different. Copy on write, tail call optimized recursion and pattern matching are wonderful, but they take some getting used to.

turbobooster• 3 years ago

I feel safer with SvelteKit

lpil2• 3 years ago

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

janandonly• 3 years 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/

pinetroey• 3 years 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• 3 years 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.

Phoenix 1.7.0

Related Stories