15 ms·

Ask HN: So, what's up with Phoenix (web framework)?

• neximo64 4y ago
  It's an odd way to judge the success of a project based on number of recent blog posts or whatever. In general Elixir is a bit more quiet that way, but that doesn't go to say its not nice to use.
  • jstummbillig 4y ago
    I questioned neither success nor usability. (Apparent) activity of a project relative to how active the overall space is seems like a decent metric to look at.
    • threatofrain 4y ago
      I would also look at https://trends.google.com/trends/explore?date=today%205-y&geo=US&q=%2Fm%2F0pl075p https://trends.google.com/trends/explore?date=today%205-y&ge...
    • andy_ppp 4y ago
      Ther weirdest thing about Elixir projects like Phoenix is that they don’t rewrite them changing things needlessly every generation, instead something about the language and decisions made causes things to be very stable. You might see this as a lack of activity but they really have worked on great new features with every release. Phoenix is really lovely, I’ve been using Absinthe the GraphQL add on and it’s been awesome and for the first time I’m starting to play with channels and web sockets which are really so well done and so scalable. The only thing I’d really like is types and better introspection support in my editor but pattern matching often can be used to simulate runtime duck typing to a certain extent protecting you even if your program will still compile. Maybe worth trying it out as Elixir and Phoenix are quite simple compared to a lot of magic you’ll see in OOP programming languages.
      • namaria 4y ago
        >something about the language and decisions made causes things to be very stable We should never underestimate the value of building on solid foundations. This may not be as intuitive with software as with, say, buildings. But it's just as true. Start with a language slapped together quickly and you end up with tonnes of unnecessary headaches down the line. Start with one built around the main problem it's trying to solve, with a lot of foresight and early improvements built in, and you eliminate whole classes of problems.
      • signaleleven 4y ago
        LiveView, which of course isn’t exactly Phoenix but is closely related, changed a great deal late last year. These were welcome changes but they were significant.
      • ramchip 4y ago
        Reminds me of this twitter thread from Jose yesterday: > I keep reading the false dichotomy that languages/frameworks either evolve (and therefore break code) or stagnate (and are stable) while there is plenty of evidence in both old (C#, Erlang, etc) and new (Rust, Go, Elixir, etc) that you can evolve without breaking code. [1/4] https://twitter.com/josevalim/status/1560552538004389890 https://twitter.com/josevalim/status/1560552538004389890
        • BuckRogers 4y ago
          Linus Torvalds has a simple demand: don’t break userspace. It’s hard work, but breaking changes should be rare. As a happy C# dev, very rarely is anything broken over here. Some obscure changes were made for the upgrade to 4.8 and .NET 5.0 but there are significant benefits.
    • conradfr 4y ago
      I think LiveView has taken a lot of effort off the main Phoenix project.
• AlchemistCamp 4y ago
  I've been using it for almost 6 years and I've found that the dev experience is fantastic and improving. That's why I stuck with it even after winding down the startup that pushed me to learn Elixir. For 95% of web apps, I'd say Phoenix is the best option these days. It just solves a whole class of problems that send users of RoR and JS frameworks reaching for Redis, Sidekiq, etc. It's also great in terms of debuggability, which I'm now seeing in a project I've taken over that has immense technical debt. As far as community buzz, I'd say it's been a slow, gradual growth. There have been more books, conferences and podcasts than I'd have expected for the size of the community, but it's still a fairly young and niche language. The biggest weakness is lack of 3rd-party support. E.g., Stripe documentation will leave you hanging if you don't use a language they've written a client for: https://stripe.com/docs/payments/checkout/fulfill-orders https://stripe.com/docs/payments/checkout/fulfill-orders
  • Dowwie 4y ago
    What are you doing to handle replication among nodes? There's still a great reason to reach for Redis for caching and messaging despite using Elixir: when the Application crashes, the state is gone. As for Stripe, some client developers have been code-generating their client with mixed success. ExAws, however, is essential.
    • liveoneggs 4y ago
      replication is built in to mnesia and your "app" crashing really shouldn't be taking down the entire OTP on your local machine, so ETS would persist on a single node
      • mplewis 4y ago
        When you’re running in a highly-distributed environment, your instances can go away for reasons other than OTP crashing – say, you’re being rescheduled onto a new node. Am I missing context here?
        • liveoneggs 4y ago
• rapnie 4y ago
  Not an answer to your question, but a lot of Elixir activity takes place on elixirforum.com and there's a Phoenix sub-forum there at well. https://elixirforum.com/c/phoenix-forum/20 https://elixirforum.com/c/phoenix-forum/20
• joshxyz 4y ago
  You have no idea how much Express.js sucks on larger projects. A pain in the ass.
  • domlebo70 4y ago
    How so?
    • jaynetics 4y ago
      Zero predefined structure
    • joshxyz 4y ago
      Lots of reasons: - Code cleanliness: their code almost looks like code golfing. Hard to debug. - Dependencies: everyone has different ways of implementing everything. some are even outdated. some even have stale bots that close legitimate but unattended issues. - Performance: fastify and uWebSockets.js beats express.js on benchmarks. see https://www.fastify.io/benchmarks/ https://www.fastify.io/benchmarks/ and https://github.com/uNetworking/uWebSockets/tree/master/benchmarks https://github.com/uNetworking/uWebSockets/tree/master/bench... - Multi-part parsing: this is built-in with uWebSockets.js. on express your options are multer or busboy. - WebSocket Server support: this is built-in with uWebSockets.js. on express your options are using ws and socket.io. - WebSocket pub/sub: built-in with uWebSockets.js There are better alternatives like the following: - https://www.fastify.io/ https://www.fastify.io/ - https://github.com/uNetworking/uWebSockets.js https://github.com/uNetworking/uWebSockets.js - https://github.com/kartikk221/hyper-express https://github.com/kartikk221/hyper-express
  • stoicjumbotron 4y ago
    Thoughts on Nest.js?
    • joshxyz 4y ago
      Nest.js uses express.js and socket.io underneath. uWebSockets.js beats both on performance benchmarks. In fact it beats everything based on Node's built-in http module, such as fastify, hapi, koa. https://github.com/uNetworking/uWebSockets.js https://github.com/uNetworking/uWebSockets.js
• mstipetic 4y ago
  After using Liveview it’s very hard for me to go back to normal full stack development, the separation between frontend and backend with some rest api seems so arbitrary to me. Especially with doing anything realtime, with your custom websocket protocols, sagas etc. I’ve been consulting with a few startups and it’s crazy to see how much effort is duplicated and coordination needed even in cases where there’s no public api necessary. ATM I’m working on a few side projects and I’m enjoying being able to build all of the functionality necessary alone without reaching for anything outside elixir+postgres. The biggest issue is a pretty steep learning curve and lack of beginner friendly documentation, lots of tinkering and code reading is necessary when starting.
  • cultofmetatron 4y ago
    after 8 years as a nodejs developer, elixir's concurrency and parrallelism toolkit is lightyears ahead. sagas, promises, channels.. Its all a joke compared to what elixir offers. Phoenix gives me a network synced crdta backed data structures, multicluster websocket support with long polling fallback, supervision trees with long lived processes and a descent pubsub system out of the box. we've gone 2 years in production and haven't needed redis or rabbitmq yet. its allowed us to focus on delivering features without drowning in infrastructure.
    • mstipetic 4y ago
      For me the most depressing thing has been - once I've seen the OTP library and everything elixir (well, erlang) provides, I've realized we've figured out most of the things like 30 years ago and have kept reinventing the wheel constantly, just because of not looking back and checking has it been solved already. Erlang's introspection tooling is better than 99% of what the market offers now as an expensive SaaS.
  • AlchemistCamp 4y ago
    Can you elaborate a bit on the "steep learning curve" bit? What took the most time and what do you wish you'd known sooner?
• skrebbel 4y ago
  We use phoenix for a few years or so, and it’s very decent. I disagree strongly with the crowd that says it’s the best thing since sliced bread, it’s, well, just a framework. It has the basics for oldschool mvc and real-time stuff, and for the rest you just write regular elixir code. It has some weird naming quirks and, to my taste, a bit too much macro magic but nothing that can’t be learned in a few days. I don’t mean to downplay the humongous effort that goes into building any framework that doesn’t suck. Phoenix very much doesn’t suck. But it simply got all the basic right and then the true benefits come from it running in elixir/beam, which means you can skip all the job runners, redises, microservices etc. I don’t know where you got the idea from that something is up with it. It’s chugging along great.
  • namaria 4y ago
    >I don’t mean to downplay the humongous effort that goes into building any framework that doesn’t suck. I think you captured something I've been mulling about recently. The perception of software quality should be on an inverted scale, like incident severity where zero is the worst possible outcome. Software can't be better then "works well, has little accidental complexity". But it can be much worse than that. People rave about pieces of software that do their job and get out of the way because they're so rare, and not because they are magical unicorns that cook you breakfast and give you massages. But because they fulfill expectations at a reasonable cost.
  • spapas82 4y ago
    Ah yes! I wrote a very extensive comment about phoenix vs django and forgot one of the biggest drawbacks of phoenix and ecto: the very very heavy macro usage. This is really problematic. When using Django and get an exception you can see the line that threw and (usually) understand the problem. When using phoenix if the error is on some macro related code, you are lost. Also in Django you can easily follow the code to understand what's going on under the hood. This is not very easy in phoenix since macros are involved. Don't get me wrong I understand that macros are used to make the code more ergonomic and avoid repeating stuff. However macros are so complicated and out of my league that I don't even try understanding them. You should not need an IQ of 150 to understand a web framework. That's the reason phoenix w could never be widely adopted. People need a tool not a way to show off their intelligence.
• fareesh 4y ago
  Phoenix is amazing The only reason it isn't dethroning RoR is because it will take some time before the ecosystem of plugs can catch up to the amazing ecosystem of gems
  • bnt 4y ago
    Meanwhile, plenty of gems have gone abandoned.
    • fareesh 4y ago
      That may be true, but not to a degree where it affects the overall landscape of which framework is going to help you get your product/iteration up and running faster
• mkl95 4y ago
  Phoenix / LiveView is a glimpse at what mainstream web development may look like in the future. Nowadays companies burn a lot of money to hire frontend and backend technology specialists, and making them work together productively is not a trivial task. Simplifying your stack can mitigate or solve many problems.
• ylyn 4y ago
  Phoenix is pretty nice, but its (or Elixir's, rather) biggest weakness is the lack of static typing.
  • bongobingo1 4y ago
    AFAIK there was some posts by Jose Valim on twitter about static typing exploration, I think it was spurred on by their work with NX/Numbat (scientific Elixir libs). Twitter wont let me view more than 3 tweets without making an account so I can't find it...
    • krstf13 4y ago
      He talked about it at length at the most recent elixir conf eu : https://youtu.be/Jf5Hsa1KOc8 https://youtu.be/Jf5Hsa1KOc8 .But it might never materialise.
    • aaaaaaaaata 4y ago
      https://nitter.42l.fr/josevalim https://nitter.42l.fr/josevalim
  • yellowapple 4y ago
    Having written a fair bit of Elixir and Erlang code over the years, I don't feel like I miss static types much when I can readily pattern match on tagged tuples.
    • sethammons 4y ago
      Having written Elixir code for about a year and coming from Go, I miss static types dearly and specs are not enough. I have to dive into the code to know what I'm working with locally. My largest frustration is all the unhandled errors and exceptions that will not have the required context when they finally crash some process. It is apparently uniodiomatic to capture details in structured logs.
    • vasergen 4y ago
      What is your experience with refactoring, especially a big project? This is where static typing helps a lot ihmo. Especially if you are in a startup like environment where things tend to change quickly.
• barrell 4y ago
  I played with Elixir and Phoenix for about two years. I absolutely loved it. To be honest, Elixir wasn't my favorite, but I felt like Phoenix was everything Ruby on Rails ever set out to be. I did find the documentation a little sparse at times, especially when dealing with heavily nested tables (or even just many_to_many relationships were cumbersome to work with). Things like Plug, hex, pattern matching and so much more have stuck with me and I still miss them almost daily in my current stack.
• conradfr 4y ago
  Channels are great, LiveView is good, Plugs are elegant, although one thing I don't quite like are Contexts. Actually a lot of its strength come from using Elixir & the Beam. For everything else I still feel it's inferior to my other framework of choice Symfony (well ok ... maybe not regarding Ecto vs Doctrine, but "transparent" caching would have been nice).
  • sph 4y ago
    > I don't quite like are Contexts A while back I wrote a small guide on how to design your contexts and its queries for flexibility. Not sure if this will actually answer some on your issues with them. https://elixirforum.com/t/a-design-pattern-for-more-flexible-context-apis/29238 https://elixirforum.com/t/a-design-pattern-for-more-flexible...
    • conradfr 4y ago
      Yes it's not bad! I guess I dislike the code that the context generator produces. A bit like the auth generator that forces you to commit code you didn't write and that is basically a mess to upgrade, and frankly not that great to modify to suit your needs.
      • sph 4y ago
        I really dislike how the auth system is implemented, that it is only accessible with a generator. I had a crappy auth system I wanted to migrate to it, I had to run the generator and try to update my code with the generated logic. Ugh, not fun. But regarding contexts, they're just modules. Nothing mandates them, it's just a best practice to collect database functions in their own module, whatever the language. I've never used the context generator.
  • deleted 4y ago
    [deleted]
• chrismccord 4y ago
  Creator of Phoenix here. I was delightfully surprised to see Phoenix as most loved on the survey since I forgot SO survey was a thing this year. So we can rule out some coordinated voting effort. Truthfully, while we’re still a smaller community, the folks that find us tend to love us and stick around.
  • cultofmetatron 4y ago
    On year 3 of a startup I cofounded in 2019. A lot of our success dealing with scaling and reliability for our users come directly from how well designed phoenix is. Channels and OTP power some of our killer features and I wouldn't envy someone trying to replicate what we have with javascript or go. Some people say ecto is limited. I love that it lets sql be sql. It lets me think of the solution in sql and write that sql almost directly in elixir with better ergonomics (being able to make a subquery a separate variable that I join into is a HUGE improvement over raw sql). Those uses of fragment can easily just be turned into macros that integrate cleanly into ecto when I use them enough. Thanks for one of the best developer experiences I ever worked with. when I have a side project, I'll be trying fly.io and I've already recommended it to other founders. We be using it if it was at its current state in 2020.
  • brightball 4y ago
    Thanks Chris. Phoenix revitalized my interest in programming at a time when I was so frustrated by the state of things that I was ready to change careers.
• yellowapple 4y ago
  A lot of what's great about Phoenix is simply that it builds on top of Elixir, which is already great and which itself builds on top of Erlang/OTP, which is, too, already great; it's the "standing on the shoulders of giants" concept. The overlap between Phoenix devs and Elixir devs helps, too. Phoenix ain't quite my cup of tea for the same reason Rails ain't my cup of tea: it's big, and it does little to hide that bigness. It's why, when I was doing web development on Elixir, I ended up gravitating to alternative frameworks (like Sugar - which, as a disclaimer, I'm a very inactive maintainer of), for the same reasons I tended to prefer Sinatra or Padrino over Rails. For most people, though, "bigness" ain't really a problem - and Phoenix does a really good job of being "Rails but actually good". At the end of the day, it's a solid choice that probably won't bite you in the ass, and that's what matters.
  • chrismccord 4y ago
    Phoenix is actually quite small if you look at the source and patterns. It would be interesting to compare to other frameworks. We get a lot for free from the platform, so even if you include Phoenix pubsub the feature set for size of the framework is going to be unmatched because of the process model and distributed runtime. Here’s an entire Phoenix app in 50 LOC https://gist.github.com/Gazler/b4e92e9ab7527c7e326f19856f8a974a https://gist.github.com/Gazler/b4e92e9ab7527c7e326f19856f8a9...
    • yellowapple 4y ago
      That's true. By the same virtue, though, Phoenix is big compared to most other Elixir web frameworks - which also get a lot for free from the platform (and even more for free from Plug). Of course you can ignore the vast majority of what Phoenix offers and churn out a 50-SLOC minimal example like that, but then why pull in an extra dependency when you could accomplish much of the same while just using Plug?
  • brightball 4y ago
    One of the things I like most about Phoenix is actually the size. Rails significantly slows down Ruby, while adding a lot of value. Phoenix has a negligible effect on Elixir performance, while adding a lot of value.
• mfsch 4y ago
  Perhaps worth mentioning that the Phoenix creator Chris McCord has written a number of posts on the Fly.io blog since he joined them a year ago (exactly a year today?): https://fly.io/blog/how-we-got-to-liveview/ https://fly.io/blog/how-we-got-to-liveview/ https://fly.io/blog/how-safari-ruined-my-tuesday/ https://fly.io/blog/how-safari-ruined-my-tuesday/ https://fly.io/blog/livebeats/ https://fly.io/blog/livebeats/ https://fly.io/blog/liveview-its-alive/ https://fly.io/blog/liveview-its-alive/ I guess that’s part of the reason why the Phoenix blog is less active?
• dinedal 4y ago
  Having used Pheonix for one of my small failed startups in the past (failed because of the business, not because of the tech) - I loved every second of it. It was super easy to use and extremely quick to be productive. Ecto is a fantastic ORM, the OTP system is great to build on, and LiveView is magic. As a solo dev, it is a true isomorphic web dev experience with a nice clean language and structure to build in. Even tests work. I just wish I could get a job in it.
• spapas82 4y ago
  I'm using django for more than 10 years, phoenix for like 4. I consider myself experienced in both frameworks. I wanted to write some blog post about my experience with them, but never found the time. In any case, Phoenix is a fine (niche) framework but can't really be compared to a masterpiece like Django: * Phoenix, probably because of its influences from the ruby world is using some concept called "generators". Using the generator it will generate (sometimes a lot) source code files that will implement some functionality. For example, let's suppose you create a new schema (similar to the django model concept). You can use the generator so it will automagically create code for the schema file, its migratinons, some crud forms and even tests. This works fine until you need add another field to your schema, or you need to rename a field or just do a small mistake! Then you'll need to do some very error-prone and boring work. Compare this to the way that Django uses the Model to generate everything from that using class inheritance and composition, without the need to write any code. Also notice that the phoenix generators can't understand relations and you need to edit the schema and migration files by hand to properly add references. * No auto-migraton support. That's that. If you add a field to a schema you need to edit the migrtion file yourself. Django automagically understands the changes and will generate the migration file. * This generator thing unfortunately has influenced various other stuff from phoenix, like authentication (you use generators to create some kind of authentication code which then you need to edit). Again, compare this to the elegance of Django using the authentication backends. Also you use generators for presence, channels, whatever... * The "ORM" (which is not really an ORM it's more or less a way to talk to the DB called ecto) is miles behind the Django ORM. It doesn't support any andvanced stuff, you need to do the joins yourself (i.e from(u in User), left_join: (a in Authority), on: a.id = u.authority_id, where: u.is_active == true. Compare that to User.objects.filter(is_active=True).select_related('authority'). * Also the ORM doesn't support most of the advanced stuff and you need to use an escape hatch called "fragment" that allows you to write raw SQL. * Phoenix has no django admin. nuff said. * The phoenix has some funny controller/view/template architecture (which I also think that was influenced from rails) that isn't very intuitive. The views are more or less useless and everything is like router -> controller -> template. Similar to urls -> views -> template in Django. But having the unnecessary views there adds another level of abstraction making everything more complexfor no reason. * Things like template inheritance are not really possible in phoenix. You use a thing called layouts to re-use stuff. The Django template inheritance is much, much more powerful and simple to understand. * Django is much more batteries included: Phoenix has more or less no authentication (beyond the generator generated one I mentioned before), no caching framework (you need to use some kind of extension), no pagination support (!), no permissions and various other things that you'll need to implement yourself or find some obscure library that has 3 years to be updated and doesn't suport the latest phoenix, which gets me to the next point: * Phoenix needs a JS bundler for its javascript code. It used to use webpack and now uses esbuild. Still, they could just provide the proper compiled JS files and let us decide if we wanted to use any node-js stuff (which I avoid like hell). * Re-using code among controllers is possible using plugs but definitely not as straightforward as extending class based views with mixins. * The ecosystem is very very small. Most libraries/extensions are 1 person projects and most of these are from persons that tried phoenix for a project but moved on so they are unmaintained. I remember that there was the "default" pagination library in phoenix (scrivener) and it didn't support the latest phoenix for like 2 years? People had to use a fork instead. * Better support and much easier updates. Because of the huge different in users, when you have any problem with django you're going to easily find answers on line. Also because Django is more mature and much more eyes look at its release candidates, it will be much easier to update to new versions. I've got apps that started from Django 1.6 and now are at 3.2. * The documentation of phoenix is not bad but it can't be compared to the django docs. Yes I know that until now I only told bad things about Phoenix but it's my experience and especially when trying to compare it with something definitely better. However I have used phoenix in a couple of specific projects and these were sucesfull. My opinion in that phoenix is not a general purpose framework but a niche one. When you have some specific requirements then yes phoenix would be a fine solution. These requirements are real-time updates using websockets. It's exactly the niche that Django (and python is general) is not good. Phoenix, because of elixir (and erlang) is great on supporting small processes that can be used to implement quick real-time communication between clients and server so as to implement apps like chat servers, online games, broadcast communication server etc i.e when your http clients open a websocket and send/receive real-time updates to the server. To enhance that even more, phoenix has a technology called Liveview that makes all this stuff even easier because it allows you to do client-side updates from the server side so as to keep JS to a bare minimum; instead of using react in your client side you keep all your app server side. This is a revelation and a much better way to work than using the client side JS framworks. This probably is the reason that Phoenix is loved so much more. Please notice that I didn't compare Elixir/Erlang vs Python. Elixir can be used to create some stuff that can't be done in Python (i.e using processes to schedule or queue stuff etc) but these are not Phoenix/Django related stuff. Sorry for the long comment, I guess I should have written the blog post ...
• benmmurphy 4y ago
  I think part of it might be because it has a very ruby friendly syntax. So you end up with a bunch of ruby refugees trying it and they are shocked at how quick it is and how easy concurrency is compared to ruby so they fall in love. In reality elixir is not really fast it’s just ruby is shockingly slow. But elixir does have a nice concurrency story. There is no denying that.
• enumjorge 4y ago
  In the several years I’ve worked as a dev professionally I’ve seen the same pattern happen over and over again: a new tech/library/framework comes out that develops a very vocal fanbase, it manages to gain widespread adoption/traction, with time the warts come out, eventually some people sour on the technology and we get an uptick on “Why our team moved away from X”, some more informed than others. I’ve seen it happen in various degrees to React, Docker, Microservices, Kubernetes, Rust and I’m sure I’m forgetting others. Certain problems in software are so complex, that there’s no one size fits all solution. The problem with the early fanbase is that it tends to be a self-selecting group in one way or another. When you read someone’s anecdote that library/framework X “was a delight” you don’t always know for example that it was maybe used by a group of 3 devs for a startup pulling $50k in MRR. Will the same apply for you team that is 10x bigger? Maybe. The opposite can be true where you have some project get open sourced by a tech giant which gets adopted by smaller teams with very different needs or resources. My point is, if you hear outsized praise for something it’s likely because it’s early in the hype cycle or it hasn’t seen enough wide adoption. No solution is perfect. It’s better to take a look yourself since no one else will know your or your teams needs and preferences. This is where the buzz can come in handy. It can highlight new technologies worth trying out. You’ll usually learn something new in the process.
  • claytongulick 4y ago
    > I’ve seen it happen in various degrees to React, Docker, Microservices, Kubernetes, Rust and I’m sure I’m forgetting others. MFC, vb3,4,5,6, entity framework (every version), OLE, COM, DCOM, ActiveX (all of which were basically the same thing), as2, as3, PureMVC, Cairngorm, Flex, asp, asp server controls, DAO, asp.net, php (and every php framework), Cold Fusion, CFCs, JSP, servelets, beans, spring, dojo, jQuery, ext, Google's JWC, backbone, moo tools, knockout, meteor, angular, angular (x), react Just off the top of my head of hype trains I've ridden. Now I'm all about simple. Express + web components + postgres is the magic combination of simplicity, time to market, performance and community for me these days.
    • nazka 4y ago
      Why not use NestJS?
• lycos 4y ago
  All I can say is that after 15+ years of web development, when I started using Elixir and Phoenix a few years ago they brought me a joy I had lost in recent years. Is it at times frustrating that the community is smaller, and there is less official support from companies? Sure. But I wouldn't say it has been a real problem for us yet to be honest. LiveView itself is an interesting concept and while we do use it in production daily for almost 2 years, I'm not yet convinced it's really better than having the frontend be React (or whichever you prefer). It has grown quickly and become much more useful than it started out as. Ecto in my opinion is the thing I would miss most were I to switch to something else.
• signaleleven 4y ago
  I'm not as much of a fan of the Elixir/Phoenix/LiveView stack like many here, so I'd like to respectfully share my experience. First off, Phoenix fixes pretty much everything I didn't like about Ruby on Rails and when I need to write an API for a weekend side project that I need to turn out quickly, I'll choose it without question. If you want to use a convention-based framework that includes support for migrations and instant DB mapping, it works well. The documentation is excellent. I personally would not choose it for a large enterprise codebase, or for something with a rich Ux that you can't control the designs for (ie. you have a Ux team that calls all the shots). LiveView is interesting. I have found certain things overly difficult to do that are easy in the js-based frameworks. For instance, a UI that has a list of children that you want to add and remove in memory and then save at the end. Obviously you can do this, and I've done it a lot, but there are quirks with the interaction of changesets, ecto, and your form that make it tricky for newcomers. I think the tight coupling between changesets and the form gets strange as soon as the page gets complicated. Schemaless changesets work well for this, but this is more to add to the learning curve. Understanding the interaction between LiveComponents and function components will be tricky for newcomers as soon as you are past trivial implementations. Knowing where the memory is stored and what a genserver is is super important, but not intuitive. Targeting a specific LiveComponent to receive events if you have one that has another as a child isn't intuitive. Unit testing a LiveComponent and a function component is pretty sweet, but there's a learning curve there and I ran into a few frustrating bugs that didn't help (they were fixed after a few weeks). There's a lot of these examples. The interaction with client-side js has evolved a lot this year, but it's tricky in my opinion. I have personally witnessed experienced, talented and smart Elixir developers struggle with LiveView. The learning curve is real. I know Elixir people love this stuff deeply, but I don't think LiveView will win in the marketplace of ideas, even if Elixir and Phoenix gain traction. People who aren't already bought in to this stack won't be willing to build complex websites this way. I know Chris and Jose are reading this thread, and I have deep respect for their accomplishment and talent, but LiveView isn't going to be for me.
  • josevalim 4y ago
    The pain points that you brought up (forms and live component exchange) are real and they are definitely in our radar. For example, the new function components are meant to reduce the reliance on LiveComponent and ease the learning curve. We don’t have an answer for complex forms yet. I truly think the programming model is solid and is the next step in building server driven interactive and real time applications. But we will definitely stumble here and there as we iron out the finer details. :) thanks for the feedback!
• bontaq 4y ago
  Any time I want to get a side project actually done, I'll use Phoenix + Live View. It's effective and efficient (from both a dev perspective, a server resources perspective, and a client load speed perspective). You don't have to worry about an API or setting up react etc but have enough interactivity to get your idea across. I don't think it's any fanatical following, it looks like a lot of other people are in the same boat as me with it. It's just good and effective.
• thibaut_barrere 4y ago
  I'm one of the 3 maintainers of the French open-data transportation access point (at https://transport.data.gouv.fr/?locale=en https://transport.data.gouv.fr/?locale=en), which runs on top of Elixir & Phoenix. I'm not a big fan of surveys and I'm not sure I've responded to this one actually, but: my current feeling around Phoenix is that it will be my go-to framework for anything web related for the years to come, but also Elixir will be, for larger topics (ML, embedded, data-viz, scripting, etc). There are a number of important points (to my taste) that comes out of my use of Elixir & Phoenix : - the maintenance story has been quite good (maintenance work is one of my main line of work since year 2k, I have used many stacks, including Java, .Net, RubyOnRails etc). Upgrades and refactoring & moving code around has been quite easy overall, once you get the stuff right (using Mox etc). - Phoenix, Ecto & Elixir are a good "generalist web framework" for a lot of use - Compared to some stacks (non-evented Ruby & Python, for instance), having a part of your app work as a proxy for domain-specific uses, is not a problem, and does not even require you to split that part from the main app (example at https://github.com/etalab/transport-site/tree/master/apps/unlock https://github.com/etalab/transport-site/tree/master/apps/un..., where we proxy/cache GTFS-RT protobuf & SIRI XML feeds behind rules, adding rate-limiting & hiding target server authentication schemes) - Similarly, anything real-time is at least initially trivial. For instance, creating this real-time view of moving vehicles (https://transport.data.gouv.fr/explore https://transport.data.gouv.fr/explore) with 70+ GTFS-RT feeds has been quite easy (PR at https://github.com/etalab/transport-site/pull/2224 https://github.com/etalab/transport-site/pull/2224). The server side is like "EventMachine done right", and the live updates are broadcasted to each client via web socket. No extra server (e.g. AnyCable) or anything is needed. From a perf/ops POV, the amount of topics you do not even have to think about is quite important, which is very nice. Overall I can see myself sticking to this stack for the next 15 years or so, without much worries (I've been coding since 1984 as a kid, so I have a good idea to know when to keep a framework around or not :P)
  • nazka 4y ago
    Thank you for all this. Did you have any pain point? Lack of libraries or something so far?
• tluyben2 4y ago
  Phoenix (and similar projects, but this is the best I tried), are what things are supposed to be like. React etc are depressingly overly complex for the programmer imho. I mean I made very large (because it's more popular so more people want it) react/react native applications and I made large-ish phoenix & laravel livewire applications. There is simply no comparison in the experience as far as i'm concerned. Sure there are negatives to the Phoenix approach, but nothing can make up for the productivity you gain.
  • omnimus 4y ago
    Could you elaborate on differences between Liveview and Livewire from your point of view? The Elixir/Phoenix seems to be much more suited to this approach because of websockets. PHP/Laravel have to do everything through http requests and it seems it would be limiting? If the Livewire approach worked well it would be theoretically possible to use it in pretty much any system that speaks http (RoR already also has hotwire). I am mostly curious if i should try Livewire for next smaller project.
• sb8244 4y ago
  Here's an analogy that I've been using lately that talks about why I love elixir. When I wrote apps in other languages in the past, I felt like I was building a big skyscraper. Everything was sorta connected and it was difficult to add new doors into the project. I was sometimes limited to building something I wanted because the runtime just wouldn't allow it. When I'm writing Elixir, it's like I'm building a city. Everything works in concert, but I could build a small building next to a skyscraper next to another building. This is because of the runtime, not the language. It's easy to build self contained "apps" that are deployed with everything else but isolated. It let's me build the app I want rather than forcing me into a very specific way of building. And just to be clear I'm not talking microservice, that would be like building multiple cities connected only by little roads. I'm work shopping this analogy since it's not as clear and concise as I'd like :) PS. I'm pretty active in the community and other private communities and didn't know about the survey. I would have a hard time imagining large scale survey orchestration given that.
  • dfee 4y ago
    The analogy makes sense if you’re implying that it’s a monodeploy of apps - all on the same “plot of land”. I’ve never used the language, so no feedback to the value of the claim, but that metaphor does resonate.
  • klabb3 4y ago
    My experience using channels in Go, was that I replicated state across "actors", similar to microservices (which is one of many problems that microservices have vs a monolith). Worse, this state is not in sync, so you end up worrying a lot about logical race conditions (if you're paranoid like me). I ended up still using channels, but a single message bus with a single threaded dispatch loop. I am curious about if redundant state and state synchronization tends to be an issue in medium-to-large Elixir apps? If not, how does one design the component/actor hierarchy to avoid such issues?
    • sieabah 4y ago
      Well each process has its own state, so if you needed to sync that you'd be storing it in mnesia, ets, or an external DB. Processes can watch and get messages about other processes if something were to succeed/fail.
• ravenstine 4y ago
  I haven't used Phoenix or Elixir since the latter was new, though I'm sure that they're great tools. The fanaticism around them partly comes from disillusionment from frontend development. The pendulum has swung to "server-side was right the whole time!" Disillusionment with Ruby may also be a factor as well. Elixir also makes way more promises around scalability and fault tolerance than any language I'm aware of (yes I know it's using the Erlang VM but no one wants to write Erlang).
• 0x69420 4y ago
  elixir takes the operational characteristics of the beam, which are by historical serendipity very desirable for implementing http servers, sands the rough edges off erlang's tooling, and gives the language a syntactic facelift that is very comfortable and non-threatening for ruby-on-rails-generation webdevs in a similar spirit, phoenix takes cowboy, an http server written in erlang that very competently exploits the above-mentioned operational characteristics, and slots it into a relatively well-thought-out, ergonomic elixir web framework in summary, it appeals to “wow cool shiny clean low boilerplate” etc., but at the same time is built atop solid tech, & so doesn't shit the bed when you scale. similar vibe to why people fall in love clojure (or so i am told on that count)
• eqmvii 4y ago
  Phoenix really is a joy to use, been using it in production for almost half a decade now. Elixir can have a somewhat steep learning curve, especially for junior devs, but the other side of it is a wonderful place to code.
• leephillips 4y ago
  If you want to understand, build something with it. Then you will see.
• hartator 4y ago
  The last time I try to play with it, I got stuck on 2 things that seem basic: - Couldn’t serve a static folder! Like I had a folder of js/img that I wanted to serve as is, didn’t want to transform into anything, it was super difficult to do. - Couldn’t find an easy way to inspect or debug a live pipe. It was a while ago so maybe things have improved a lot. However it kind of left a sour taste in my mouth when asking for help, I was told static folder is not really the scope of the framework and things in the like.
  • unvs 4y ago
    In your generated `my_app_web/endpoint.ex` there is a plug that will serve static contents from your `priv/static` directory: https://github.com/phoenixframework/phoenix/blob/master/installer/templates/phx_web/endpoint.ex#L16-L24 https://github.com/phoenixframework/phoenix/blob/master/inst... This points to a function in `my_app_web.ex` which specifies which paths it will serve: https://github.com/phoenixframework/phoenix/blob/master/installer/templates/phx_single/lib/app_name_web.ex#L20 https://github.com/phoenixframework/phoenix/blob/master/inst... So you can either copy your js and image folders to `priv/static/assets` and they will be available as `localhost:port/assets/js/somefile.js` etc. OR you can add `js` to the list of paths to serve in app_name_web.ex and copy your js files to `priv/static/js` and access them at `localhost:port/js/somefile.js`.
• mattbrewsbytes 4y ago
  I like it but coming with experience in Rails there isn’t the depth of hex packages to choose from and I don’t know if I’d call Ecto an ORM for a couple reasons. Well, there aren’t objects and Ecto gives you a blueprint to write DB code, you still need to write all of the actual code yourself for anything beyond a simple model structure. Unless I’ve misunderstood things a bit. Thats part of the issue is the docs feel obtuse (maybe its me), like very common things you want to do are buried somewhere and use different terminology than I would think. I understand the approach isn’t the same as Rails which is very opinionated about how to do things but I wish their were a set of opinionated guides on how to do things of medium complexity. Like complex forms, views representing normalized data from a half-dozen tables that have relationships.
• thinkpad13 4y ago
  I want to know too did you guys have much library now because back then i don't want to use because the library and example or article about phoenix still scarce like i don't know how to handle the authentication without devise and things such as that sorry my shift in this keyboard is broken so no capitalise or question mark
• losvedir 4y ago
  I was a RoR developer for 5 years and have now worked on Phoenix apps for about 6 years. The survey results have certainly gotta be at least a little selection bias, combined with Rails apps being on average older (and therefore more "legacy"). But on the other hand, for me Elixir and Phoenix really did clean up a lot of the pain points around Rails (performance, magic), while keeping the great things (developer experience, general structure), and adding some brand new stuff (channels). LiveView is really interesting, but still a bit of an experiment, from my perspective. At least, I haven't had a chance to use it "in anger" in production yet, but am generally satisfied with my "Phoenix as a better Rails" apps.
  • jstummbillig 4y ago
    How do you feel about Hotwire in comparison (or someone else)?
• gregors 4y ago
  I chose my current employer because I had the option to choose an Elixir/Phoenix stack. In addition, I managed to get another senior developer to join me and leave his secure quasi-government job because of Elixir as well.
• knoebber 4y ago
  I have been greatly enjoying writing a side project in phoenix/liveview. It's fun, works well, community is welcoming, etc. Previously I was writing side projects with Go APIs and react, and compared to that, this is miles ahead. I love not having to worry about creating a REST endpoint for every single interaction. Also, I really like Ecto. It hits the sweet spot for an ORM of not too much magic and a lot of convenience. Give it try if you haven't already :)
• sergiotapia 4y ago
  Half Life Alyx ruined VR gaming for me. Every other game feels like a tech demo compared to it, and so my Valve Index sits behind me collecting dust. So to has Phoenix ruined any other way of building website. The though of going back to react and all that mess just makes my stomach turn. We're building a new startup with Liveview, all-in and it's been fun. There are some sharp corners but you get so much for free it's completely worth it to me. I don't think I would build a webapp with anything other than liveview for the next decade. It's just too good and too productive.
• bluesnowmonkey 4y ago
  We’ve used Phoenix for 5 years for an important internal project in a large tech company. We don’t do a ton with Phoenix itself, it’s just a simple MVC web app for managing a more complicated Elixir thing. No Liveview or even Ecto, for instance. But it has worked just fine. We push Elixir to its absolute limits, though, and after years of being on call for a production Elixir system, I’m still totally in love with it. Plenty of experience with Ruby, Python, PHP, Java. Elixir is a game changer. If I build basically anything in the future it will be in Elixir. And it will probably need some kind of web interface, so that will definitely be Phoenix.
  • nazka 4y ago
    What do you mean by pushing it to the limit? And do you have any insight of what’s it’s like to be on call with Elixir? From what I saw it has many great tools to debug problem. Also the “it never crashes” is quite appealing.
    • bluesnowmonkey 4y ago
      Pushing it in terms of performance and complexity. We have high QPS and need low latency, a few milliseconds to do a lot of work. Baseline performance of nice idiomatic Elixir is good enough mostly for general business logic. Tools like Recon help you find bottlenecks. You can move state off heap into ETS to reduce GC, or share a public ETS table to eliminate inter-process communication. You can dynamically recompile a module at runtime when configuration changes. You can move really hot loops into NIFs. These are all relatively easy once you know how and really good at eliminating bottlenecks. On call is great. Tail latency (p99.9 and up) is great, much better than Java, due to per-process vs stop-the-world GC. Remote console is a superpower, lets you debug in production. Minor flakiness tends to get handled silently be supervised processes crashing and getting restarted. Elixir stuff just pages us much, much less than other languages.
• pindab0ter 4y ago
  As a Laravel dev, can somebody tell me what Phoenix does that Laravel doesn’t? Or maybe, what it does better and/or worse?
• nazka 4y ago
  Those using it for big projects, is it possible to have some feedback about what is still missing or libraries are there but still need more development. Like does it have the library for Elaticsearch? Everything for auth? Etc… which important library lack documentation? For instance I saw that the one of Stripe is not that good. That’s what stop me from using it. Being in a startup we don’t have the ressources to have developers having to code other things on top of raising a startup from the ground…