11 ms·

Why I Chose Elixir Phoenix over Rails, Laravel, and Next.js

• deleted 1y ago
  [deleted]
• jherdman 1y ago
  > But I still needed background jobs, real-time updates, and two-way communication that just works. Those things are possible in Rails and Laravel, but they take a bit more effort to set up. I'm pretty sure this isn't true at all with Rails. Out of the box you get Solid Queue (jobs), and Solid Cable (real time messaging).
  • nop_slide 1y ago
    Yeah def odd, I'm a recent rails convert and SolidQueue is dead simple and is setup out of the box. When paired with https://github.com/akodkod/solid-queue-dashboard https://github.com/akodkod/solid-queue-dashboard you get a nice overview.
    • jamiecurle 1y ago
      I think what the blog post is getting is OTP and the mystical/but not mystical GenServer / Supervisor/ distributed pattern. It's baked right in there as a core part of the Erlang VM. I think the post glances over the fact that in rails land solid queue may be right there to use (I've not really used rails in over 10 years). Thing is with Elixir though, yes the tools are right there, but you do have to take time to understand them. I've been on and off with Elixir since 2016 and I'm currently wrapping up on a fairly complex elixir project with zero UI. (connecting Shopify GraphQL to a series of 3rd party fulfilment providers who use SFTP (gross). So yes, GenServer, Supervisor etc are all right there as first class citizens, but whilst they are relatively simple to start using, you can end up with some horrifically structured code that would have been much better written without the distributed stuff. Personally, I prefer Django. Been using it since 2006 and as a person who started off in design but ended up as an engineer, nothing beats Django's template engine (braces for incoming). Django isn't perfect but nothing is. When I have to get something done quick and there's UI work for me to do, I go to Django. When performance or no UI, I go elixir. If someone else is doing the UI, I go phoenix.
      • conradfr 1y ago
        That's also where I'm at. For any project with UI (and auth/auth etc) I went back to Symfony (and Vue). I can't stand Phoenix templating especially layouts and I couldn't convince José of the greatness of template inheritance like with jinja2 in python ;) But I'm happy running worker type things in elixir & Phoenix if I can.
      • pmontra 1y ago
        IMHO Django's templating engine is its worst feature but that only proves how subjective all these matters can be. I'm currently making money both from Django and Rails. I made quite a bit of money from Phoenix years ago. Customers choose their platforms, I can choose customers. About OTP's primitives, they are great but a background job system has more features than those primitives offer. We wrote a fair amount of extra code to get what we needed for our production system. I'm using Sidekiq in Rails in my current Rails project and it's more feature complete than what we built for Phoenix. I'm using Celery with RabbitMQ in my current Django project and we would like to get rid of it. It's too fragile.
  • akarshc 1y ago
    All the things are possible in rails as well. it is a beautiful framework, but it is so much easier to use with phoenix. Do try it out
  • sergiotapia 1y ago
    Take it from someone that uses both systems in production, they are not equivalent. Oban is leagues easier to use and obvious than Solid Queue. Solid Queue has no easy way to rerun a successful job, in Oban you can just update some dumb table columns and done, the Oban supervisor will sniff it out and workworkwork. Solid Queue has a ton of database tables. Oban has `oban_jobs` and `oban_peers`. Oban just runs, simple on the same app. Solid Queue you can do that but it requires reading a lot of obscure blog posts and changing the settings. No sane defaults. Just as a whole the Erlang and Elixir primitives allow oban to be built truly in the most retarded, obvious way and get away with it. It's wonderful to use as a dev. Solid Queue I'm bearing because I get other stuff I need from Rails.
    • sorentwo 1y ago
      > Just as a whole the Erlang and Elixir primitives allow oban to be built truly in the most retarded, obvious way and get away with it. Maybe it is obvious in retrospect…
      • sergiotapia 1y ago
        I did not mean to diminish the implementation, of course it must be incredibly complex. I meant all that complexity is hidden from me, the developer. It's really easy to understand what to do. :D
    • JamesSwift 1y ago
      > Solid Queue I'm bearing because I get other stuff I need from Rails. I mean sidekiq is tried and true
      • sergiotapia 1y ago
        I don't want to pay for a redis instance. On principal! coming from elixir thats an ick haha
  • tvink 1y ago
    Solid cable is quite a bit of setup though,compared to Liveview. The way LiveView manages the rendering for your is leaps ahead of how actual rails SolidCable development feels.
• dismalaf 1y ago
  > It’s way ahead of both Rails Hotwire and Laravel Livewire. LiveView communicates through WebSockets Where's the facepalm emoji? Rails Hotwire uses websockets... The research done here seems to be so basic it literally missed something written on hotwired.dev's landing page, albeit it's mentioned far down enough you have to scroll a teeny tiny bit (half a page on my screen)... Rails also has background jobs and all the other things considering Phoenix is modeled after Rails.
  • Rover222 1y ago
    Yeah I feel like most devs still think of rails as it was about... 8 years ago.
    • jbverschoor 1y ago
      18
    • nasmorn 1y ago
      Yeah it has become much more solid recently
  • dpflan 1y ago
    The author is a self-professed front-end developer according to LinkedIn, which may be influencing experience with backend systems and functionality. I was wondering really why this terse post is sky-rocketing to #1 today, hopefully we get some good discussion from the community.
    • grim_io 1y ago
      Any kind of comparison of popular frameworks activates all the dev nourons in my monkey brain.
  • andersmurphy 1y ago
    Websockets are the wrong choice. SSE is the way to go. That or your own UDP protocol.
• phplovesong 1y ago
  Anything PHP and you going to have bad time once you need concurrency. This time will come sooner or later.
  • CharlesW 1y ago
    Request-level concurrency has always scaled well. As for lightweight concurrency, have you worked with PHP Fibers? https://medium.com/@binumathew1988/leveraging-php-fibers-for-concurrent-web-scraping-a-real-world-example-5fce41baf9c7 https://medium.com/@binumathew1988/leveraging-php-fibers-for...
    • phplovesong 1y ago
      PHP Fibers does not do anything on its own. Its basically just syntax for generators, to be used with various external runtimes. This means in a vanilla PHP setup when i do something like this: $a = new Fiber(function () { sleep(2); // block Fiber::suspend(); return null; }); $b = new Fiber(function () { sleep(2); // block Fiber::suspend(); return null; }); // Start execution $a->start(); $b->start(); // ... later in code wait for both executions to finish $a->resume(); $b->resume(); // Total execution time is not 2 seconds, but 4 I need an additional runtime to support real concurrency. I also need a separate async IO library to handle blocking. This is usually a showstopper for most PHP still out there. And just annoying on so many levels.
  • misiek08 1y ago
    The best, most popular serverless platform? There are stacks much worse than PHP, like JVM for example ;) It (JVM) is getting better lately, for example with virtual threads, but still in same resources you can handle much more traffic via PHP and it can be hosted virtually on every hosting!
    • phplovesong 1y ago
      Not sure why you say JVM is "worse" than PHP. It handles most real world workloads with no problem and is probably one one the most fine tunes VMs out there. It supports concurrency out of the box. That said JVM is only a target, so if Java is not your cup of tea, you are free to pick and choose from any of the various JVM languages, like Clojure, Kotlin, Scala etc.
• magdyks 1y ago
  My biggest problem with Elixir is the lack of support for 3rd-party libraries and the small community. I love the idea of it, but every time I try to ship a real project in LiveView, I'm left feeling like the community is not that mature. Maybe coming from a Go backend React frontend stack, that might be the case, but maybe for quick CRUD apps, it's great.
  • dpflan 1y ago
    Elixir is pretty "nifty", and has Rails feels. I have worked on and seen its performance compared to scaled up Rails application. The BEAM / OTP is a very cool system to program on top of. I think it would be a great underlying system to develop a consciousness for AI systems with its concurrency paradigms and message passing, node connecting, other builtins. I'm not sure if the AI/ML focused Elixir projects like Nx have really taken off, but again, an Elixir based system that accepts numerous connections, passes messages around like exciting synaptic communications between functions... it just seems cool, maybe just on paper...
    • lab14 1y ago
      What do you mean "consciousness for AI systems"?
      • dpflan 1y ago
        When you consider the message passing paradigm, I can envision how that simulates neuro-chemical communication between neurons (now here being functions that do things). So there is a design for communication between functions, then there are memory storage and information retrieval parts of the system, short-term RAM, long-term HD/SSD, databases, cache-systems, where relevant information can be and become manipulated. Long and short running processes, acceptance of fail-fast and that communications can fail and that's just part of software system life (I assume also a similar idea in the human brain, don't you find yourself forgetting something you were just thinking about?). There is then the external part of the system, accepting inputs from the outside.
• andai 1y ago
  Interesting article, but I had to scroll all the way to the bottom to find what you actually built. I consider this important information, because the right tool for the job will depend on what the job actually is! (Although I must say the advantages you listed — a strong compiler, concurrency, reliability — do sound universally good.) It would have been interesting to see the specific problems you had when building specific features, and how the unique advantages of this stack helped you solve them.
• righthand 1y ago
  I am curious how much longer NextJS will last considering it is a lock-in vehicle for Vercel. However as far back as I can recall it’s shift onto the dev stack was less about “is it a good framework” and more about “this framework can help Product org prototype faster”. With the advent of Llms, will Product org even care about the dev speed for prototyping?
  • agos 1y ago
    the sentiment around NextJS is terrible, I have rarely seen something go from "oh this might be cool" to "stop pushing this badly engineering crap on me" so quickly. Yes, it's widely used and that's to be expected given the amount of money spent in promoting it, but it's not loved by any mean and I see this as a fatal flaw that they'll have to reckon with sooner or later. It's so bad that it worsened React's reputation by association - React already had some issues to care about, but they went in Next's direction, and people have noticed
  • Exoristos 1y ago
    There's absolutely no reason to use Vercel. I've always run Next on our own servers, for multiple clients and some very complex projects. Page Router or App Router.
    • righthand 1y ago
      Ironically I choose to deploy our nextjs projects on Vercel because interacting with our inhouse stack means involving an infrastructure person who wants to critique and research how you’re developing your app. With Vercel I can just deploy a project and don’t have to ask Steve what the best set of server tools I need and then work with Steve on the monolith of Kubernetes configs to get it deployed. And while I like Steve, adding him to a project is a huge time sink and cost center all it’s own. Even if I get platform access to self serve, Steve will be there gating me for every little permission I need. I hope you at least let devs deploy on whatever stack instantly with new projects and services with something selfserve-y like (Vercel/Heroku/etc).
      • 1y ago
• jbverschoor 1y ago
  Until you realize you're reimplementing Rails :)
  • ch4s3 1y ago
    Having done both for years, I can say confidently that you can use Phoenix without recreating Rails. The differences are important, and IMO Ecto is a much better approach to interacting with a database than ActiveRecord. I've also never seen a bug in my application due to upgrading Ecto, and I definitely can't say that about ActiveRecord.
• exabrial 1y ago
  The Elixir live view model to me look like one of the only sane programming models for modern web development right now... Otherwise your best choice still remains to be server side rendering.
  • dismalaf 1y ago
    > Otherwise your best choice still remains to be server side rendering. ?? Phoenix Live View IS server side rendering...
    • azundo 1y ago
      I think they more specifically mean server side rendering of react components vs an SPA.
    • exabrial 1y ago
      Yes. I wasn't implying live views are not this, I was trying to say react, vue, angular, svelte, next.js, solid, preact, alpine.js, ember, backbone, lit, mithril, stimulus, knockout, aurelia, polymer, riot, inferno, marko, dojo have a terrible programming model and anything with server side templates is a vast improvement.
      • nathanappere 1y ago
        Don't know how much you have used ember, but I disagree, it's quite sane as a programming model and ember data is still ahead in terms of developper comfort for client apps.
• guywithahat 1y ago
  One benefit i found over rails was just some of the libraries were more modern. I'm not a backend developer, so maybe I'm just not skilled enough to know how to do these things, but I found rails libraries tended to be dated and missing more modern features. Specifically I wanted to run both the API and website on the same server (since it was a small company), and with Rails the gem Devise didn't natively support both and while rodauth claimed to support both I couldn't get the build flag to work. With phoenix it just worked out of the box with the most popular libraries, allowing me to move on without becoming an expert in backend frameworks. I agree with most everything else the author said too, specifically about it being more performant and liveview allowing me to build more dynamic websites easily.
  • dismalaf 1y ago
    > the gem Devise didn't natively support both Sounds like a Devise problem.
    • jrochkind1 1y ago
      Sounds like you're saying it sounds like a Devise problem.
    • deleted 1y ago
      [deleted]
  • gregors 1y ago
    A lot of ruby gems have definitely seemed to suffer from brain drain the last few years. It's worth noting that the creator of Elixir was also an author of Devise.
• Jnr 1y ago
  All good, but did you know that Next.js is a full stack framework? You can have backend and frontend in the same code base. You don't need Laravel if you use Next.
  • pier25 1y ago
    > You don't need Laravel if you use Next But you do need to solve a lot of stuff that Laravel already solves for you.
  • FredPret 1y ago
    BEAM / Erlang / OTP / Elixir feels different: - no JS (well a tiny bit ships with Phoenix but I never have to look at it), no NPM, nothing that breaks every week - the whole system lends itself to executing on multiple cores - GenServers BEAM processes in general are amazing
  • rvitorper 1y ago
    Next.js is still missing lots of backend stuff. Background jobs, cron jobs, queues, etc.
  • akarshc 1y ago
    that’s true, next.js does a great job offering a full stack experience. the difference with phoenix is that it’s built on the beam, which gives you concurrency, fault tolerance, and real-time capabilities out of the box. liveview also lets you build interactive frontends without managing separate api layers or client frameworks, keeping everything unified and fast.
• schultzer 1y ago
  A lot of people tend to flag Elixir for its size and rightfully so, but the community is trying to punch above it’s weight with SOTA libraries. As an old developer once told me: less is more. https://github.com/elixir-dbvisor/sql https://github.com/elixir-dbvisor/sql
  • nasmorn 1y ago
    OTOH JS is too big for my taste. Everything has 10 implementations with no consensus about doing things. So everyone chooses their own horrible menu. Like an American super market. Or you go full chain restaurant with whatever Vercel pushes currently
    • schultzer 1y ago
      Couldn’t agree more, I was taking a diplomatic approach as I was linking to my own work!
• cantor_S_drug 1y ago
  For those who want to experience the strength of Elixir, they should watch all videos of Saša Jurić on Elixir.
  • duckydude20 1y ago
    iirc he wrote elixir in action. also. really good.
    • samjowen 1y ago
      Indeed, it's a masterclass in technical writing. It's the best programming book I have read.
• tr888 1y ago
  Not knocking the choice but: > I still needed background jobs, real-time updates, and two-way communication that just works. Those things are possible in Rails and Laravel, but they take a bit more effort to set up. These all have first class support in Laravel out the box.
  • agos 1y ago
    do real time updates and two way communication work out of the box with a cluster as well?
• xutopia 1y ago
  I love how this article reads more like the individual ignores features and capabilities of other frameworks to then state that the framework he chose is better. Rails has everything he mentions as an advantage of Phoenix. He's also implying that Rails does not use web sockets to communicate with frontend which is not only wrong it should be evidently wrong to anyone who built a Rails app in the last 3 years. That's not to say that Phoenix and LiveView aren't phenomenal tools, they are! However what's keeping me in the Rails world is Hotwire Native. I truly feel like a one man army building mobile and web apps in a quick turnaround time.
  • gregors 1y ago
    The problem is the websocket implementation (last time I tested it) sucked. I'm assuming even now if you're doing non-trivial websockets you need to use the node or golang implementation.
    • aantix 1y ago
      You can swap out the ActionCable backend with different providers. Redis, postgres. I think there's a couple of commercial offerings. solid_cable is a database polling mechanism which can also be swapped in.
  • nomilk 1y ago
    Yup. the rails 7 demo showed websockets back in Dec 2021: https://www.youtube.com/watch?v=mpWFrUwAN88&t=25m46s https://www.youtube.com/watch?v=mpWFrUwAN88&t=25m46s
    • solid_fuel 1y ago
      I don't see anything in this post claiming that Rails doesn't support websockets, where are you getting that?
      • akarshc 1y ago
        Author here: Not sure why everyone’s taking this as anti-rails or anti-laravel. It’s not. I just shared what worked best for my use case. Real-time updates are built into phoenix through channels and liveview, while in rails it’s handled through Action Cable and Turbo Streams. Both work great, but phoenix’s setup felt more integrated for what I was building.
• dimitrisnl 1y ago
  The post is mostly about Phoenix LiveView, while the title makes it about the framework. To be honest one of the reasons I don't like Phoenix is that even if I opt-out of LV in the generators, I still get a lot of LV code.
  • causal 1y ago
    Yup - an important distinction that wasn't obvious to me when I first jumped in. LiveViews are very opinionated and generate a ton of boilerplate. Not always a bad thing, but Elixir is elegant because of how spartan and expressive the code is - LiveView is kind of the opposite IMO.
• mati365 1y ago
  I implemented CKEditor integrations for Rails, Livewire, Phoenix, and React. I think the best developer experience was with Phoenix - at every step I was surprised by how well thought-out the framework is and how easy it is to build integrations for it. I definitely can’t say the same about Rails or, especially, React with the awful Next.js. For anyone curious: https://github.com/Mati365/ckeditor5-phoenix https://github.com/Mati365/ckeditor5-phoenix As for Livewire - it feels like a simplified copy of Phoenix. In my opinion, it’s less advanced and less intuitive. For example, Livewire components don’t support slots, while Phoenix components handle them without any issues. Slots are critical for clean component composition - without them, you end up with messy, repetitive templates and a lot of unnecessary logic in the components themselves. When it comes to Next.js, constant router changes and questionable decisions have become a daily routine. There’s no point integrating with something that gets rewritten every week and can’t be trusted to stay stable.
  • ramon156 1y ago
    I want to give both of these a try, especially if you say react+next.js is awful. You'd think TS-TS would be well thought out
    • tracker1 1y ago
      If you want to mix server with React and TS, then take a look at Astro or HTMX.
    • Exoristos 1y ago
      Don't preemptively give up on React with Next.js because some posters turn their frustration with it into contempt. Many of us use React 19 and Next App Router to great effect, and enjoy it, although there was certainly a learning curve.
      • mati365 1y ago
        It’s not about frustration, unwillingness to learn, or dismissing the tool altogether. My point is about trust. I just can’t imagine a Next.js app being as easily maintainable 10 years down the road as a Rails one. Honestly, I can’t even picture upgrading to a new major version without breaking something, because the pace of changes is just too fast. Sure, it’s great for small, simple projects. But building a business on it and risking breakages or dropped support? Not for me.
• jonathan920 1y ago
  What matter most is having enough code out there for ai model to learn and study it so people can build with it.
  • benzible 1y ago
    Chris McCord directly addresses this in his recent ElixirConf talk. There's a threshold amount of training data needed for LLMs to work well, and Elixir more than clears it. Beyond that threshold, having more data doesn't make a tremendous difference. This means the "frustration gap" for newcomers essentially disappears - people who heard "Elixir is good" can now just ask an LLM to build something and start immediately, easing their way into understanding functional programming paradigms in order to be productive. I use Claude Code daily for Elixir development and it understands the language perfectly. The real strategic advantage is that while other ecosystems scramble to solve agent orchestration problems, Elixir/OTP already solved them decades ago. Lots more here: https://www.youtube.com/watch?v=6fj2u6Vm42E&t=1321s https://www.youtube.com/watch?v=6fj2u6Vm42E&t=1321s
• rkangel 1y ago
  Oban is great, but for most cases you don't need it. In languages with a less good concurrency model we are used to needing some form of library or system to manage "background jobs", but in Elixir you can just spin up some GenServers under a supervisor to do work. Start there and only use Oban if there's some form of consistency/resumability guarantee that you need.
  • itbeho 1y ago
    I haven't found Oban difficult to work with and it has the added benefit of ensuring your jobs are run only once. There is also the cron functionality that I find really useful for scheduling.
  • cultofmetatron 1y ago
    > Oban is great, but for most cases you don't need it. 7 years in on an elixir startup that has well over a thousand active paid accounts using our system every day to run critical businesses. I have to politely disagree. USE OBAN from day one for any kind of background jobs. do not trust genservers. they lose their state if a pod goes. There's no retry logic built in. > Start there and only use Oban if there's some form of consistency/resumability guarantee that you need. oban is easy enough to integrate. it takes like 10 min of your time and you get a LOT out of the box. use genservers if you're running ephemeral servers but if you are creating background tasks, absolutely use oban for anything you plan to put on production. Oban is such an easy value proposition to justify. consider it as important to learn as core phoenix
    • conradfr 1y ago
      Oban is good but they should have a more reasonable tiers for their paid offering, the Pro plan is quite steep and is a bit all or nothing.
      • cultofmetatron 1y ago
        we operated for 4 years before we switched to pro. you get quite a bit out of the free version. we only switched because we wanted the rate limiting features of pro. plus $100 month is cheap if you're dealing with the problems that pro solves for you
• alberth 1y ago
  After Elixir announcing being "feature complete" a few years ago, and then Phoenix going down the LiveView path for quite sometime ... I feel like the Phoenix/Elixir stack became less exciting to me. Hope to be wrong though. Erlang based systems are really interesting and under appreciated.
  • recroad 1y ago
    Can you explain more? What became less exciting and why exactly?
    • alberth 1y ago
      It just felt like momentum slowed and/or there was less PR about Elixir/Phoenix. But I could be completely wrong (or have the wrong perception). Note: not at all suggesting hardwork/progress isn't being made.
      • dsiegel2275 1y ago
        I've been developing full-time in Elixir / Phoenix for the last 6 years. I can assure you, momentum in the ecosystem has not slowed at all since the language was declared to be "feature complete".
      • bluehatbrit 1y ago
        The pace of new things coming to the ecosystem hasn't slowed at all, but it's happening beyond the language itself now. Just look at projects like Nx, LiveBook, Explorer, Flame, and Nerves. All are making big steps forward and releasing new and interesting things. As someone who uses the stack daily this is really wonderful. In the elixir world you just don't really have the problem where two tools don't work well together because they're built around very different versions of the language and runtime. I can pick up any elixir based tool and knowledge I can slot it into my tool chain or project and it'll just work. To me this is even more exciting because it suggests a stable foundation, and makes it easy to adopt new developments. But I appreciate those projects aren't discussed as much on HN.
      • 1y ago
• mbesto 1y ago
  Great. Now tell me how you plan to scale a dev team who all know Elixir?
  • akarshc 1y ago
    I guess hiring a developer who knows rails or even laravel can easily pick up with phoenix.
  • sph 1y ago
    If the only metric you care about is "scaling a dev team", use JavaScript. You're welcome.
    • nasmorn 1y ago
      I am not even sure that is true. Only if your main criteria is available resumes where the programming language is listed at all. JS has probably upper 90% there
    • mbesto 1y ago
      Did I say it was?
  • agos 1y ago
    by hiring people without the expectation to be already proficient in it, as long as they are willing and capable of learning it in a reasonable time
    • mbesto 1y ago
      Hiring is hard enough and you want to add this additional complexity? Okay.
      • agos 1y ago
        I would argue that hiring people expecting them to be fully proficient in all your stack is a much worse complexity to add
    • 1y ago
• gregors 1y ago
  As someone who did Rails professionally for a very long time, Phoenix/Elixir is now my default stack. Possibly the one thing that Rails still does better is generating quick throw away CRUD apps with their generators. Rails is still pretty much flawless in that regard. That beings said, when things mature and complexity grows Phoenix/Elixir is definitely the better all around tool.
  • nasmorn 1y ago
    I think LLM have really closed that gap. Quick throwaway stuff can be generated in a couple of minutes. But phoenix gives me back all the control in cases I care.
    • giraffe_lady 1y ago
      Yep I'm a moderate-to-strong LLM hater and this is one of like two things I use them for. Definitely a ground-leveler re: rails too it really had by far the best generators I had come across.
  • x0x0 1y ago
    why / what do you find works better?
    • tvink 1y ago
      You can scaffold a crud resource we with a single CLI command, as far as I know we don't have that in phx?
      • moritz 1y ago
        mix phx.gen.html Accounts User users name:string email:string
• ninetyninenine 1y ago
  I can see why elixir over rails but do you guys know about type checking?
• dmitrijbelikov 1y ago
  Laravel - https://laravel.com/docs/12.x/queues https://laravel.com/docs/12.x/queues
• brap 1y ago
  Doesn’t the LV approach suffer from latency issues? If I understand correctly all state is managed by the server, which means even the most trivial UI interaction needs a roundtrip. Not to mention the cost of managing the state and connection of every client. So how does that work in practice?
  • akarshc 1y ago
    latency is minimal because liveview sends only dom diffs, not full page updates. most interactions feel instant. each connection runs as a lightweight beam process, so managing per-user state scales efficiently. for very high-frequency ui updates, some client-side js may still be needed, but for forms, lists, modals, and live updates, liveview is smooth and responsive.
    • asa400 1y ago
      The size of the diff and the latency of the underlying transport layer are independent. If your user in NY clicks a button that has to go to your server in SF, you pay for that ping both NY->SF and SF—>NY for the reply. Same goes for whether they’re on some flakey mobile connection in a car or on a train. It’s also super easy to accidentally send a ton of data down the wire on component mount. I worked on a massive LiveView app at a company you’ve heard of and these kinds of issues were a problem the whole time. You also give up the standard stateless HTTP request/response model when you go with LiveView. This is not necessarily bad, but people should be aware that they’re turning their stateless web tier into a stateful web tier. It’s an entirely different model (and in my opinion, more challenging). LiveView is cool technology but I don’t want people to overlook the fact that it has some sharp edges you have to be aware of when building large products.
  • lawn 1y ago
    In practice it's mostly fine actually. But yes, for interactive elements it's not optimal. They have some JS helpers for simple things but you may need to drop down to JavaScript hooks yourself if you want do better. I've been playing around with Hologram, which transpiles Elixir to JavaScript. It's very early days but it has the potential to be a much better solution than LiveView. https://hologram.page/ https://hologram.page/
• mcdow 1y ago
  I really want to choose Phoenix, but I can't get over the fact that LiveView is front-and-center. The whole web-socket model just seems so brittle to me.
  • lawn 1y ago
    Although I agree that LiveView sucks up too much air in the ecosystem, you can just ignore that and develop web apps the standard ways of you want.
    • mcdow 1y ago
      Oh ok. Is it still worth learning without LiveView? E.g. in my case I’m much more proficient in Python. Is it worth the jump, over something like Django?
      • laszlokorte 1y ago
        Yes because Elixir is such a nice language. In every language there are sharp edges or dirty corners that are just annoying once you hit them. JavaScript and Php are full of inconsistencies, Ruby and Python are nice and the surface but once you dive into meta programming, OOP and mutability complex code bases are just impossible to trust/reason about their correctness. Rust, C++, C#, F#, Java... I could go on. In my opinion Elixir just hits the sweet spot of good design. After multiple years using it there comes nothing to my mind that I find ugly or annoying. Sure there are other languages that are quiet nice on paper but often they lack the ecosystem to let you just build production ready stuff. The Elixir ecosystem is also not that large, but large enough for quickly building a web app or composing useful automation pipelines.
      • out_of_protocol 1y ago
        Definitely, Phoenix is way more streamlined than Django/Rails. Even if you jump to other language/framework, it'll teach a lot how to built stuff due to good defaults and project structure. Also simpler too. I remember spending hours trying to figure out how to use specific method and where is it coming from in Rails. In Elixir/Phoenix there's very few "import"s in use (single file you can inspect and modify), non hidden state. You see Foo.bar("some argument") and you know you don't need anything else to understand what it does. Rails is very magical in this sense, Django as well, a bit
• dev_l1x_be 1y ago
  These "why I chose articles" can be summed up adding: because I like it more and I cherry picked some facts for justification.
  • adamors 1y ago
    Exactly, this is all blogspam at this point. Ignores all the features available in Rails so he can pick Elixir/Phoenix the “winner”.
    • akarshc 1y ago
      that’s fair, though the intention wasn’t to dismiss rails or crown a winner. it was more about sharing a personal experience with elixir and phoenix for a specific use case, not a comparison to discredit other frameworks. i haven’t discredited rails, but features like fault tolerance and the beam make phoenix especially robust. i also mentioned that rails is a beautiful framework, i just chose what felt best for my project.
      • adamors 1y ago
        > Rails Hotwire really caught my attention, especially because of how fast you can build an MVP with Rails. But I still needed background jobs, real-time updates, and two-way communication that just works. Those things are possible in Rails and Laravel, but they take a bit more effort to set up. All of this is built into Rails tho. That’s why I didn’t like this article, feel free to pick whatever you want and explain the benefits, but if you do comparisions at least try to come accross as well informed. But it sounds like you haven’t started a Rails project in years
        • akarshc 1y ago
          That’s fair, Rails + Hotwire is excellent for building fast MVPs. What really set Phoenix apart for me was the built-in real-time layer (via channels), the BEAM’s fault tolerance and concurrency, and how effortlessly it scales with background jobs, PubSub, and LiveView without needing extra services. Rails can absolutely do all that, but Phoenix gives you those capabilities natively with far less setup and overhead. I appreciate your feedback, I’ll definitely try to add more details in the next one. Also, I’m not implying Phoenix is better than Rails or Laravel.
• fareesh 1y ago
  liveview feels a bit too magical client disconnects, state desyncs, then reconnects, then liveview figures out via crdt and other things how to accurately diff the state feels like i have to trust it too much - i'd have a lot more confidence if people were vocal about how they are running it at scale, battle-tested etc. etc. shopify is straight up yolo running rails edge, which is a crazy endorsement
  • dizhn 1y ago
    I watched a few demos and it is clearly magic and I was very impressed. Though I can't picture how a more standard run off the mill web app would be built with it.
    • auraham 1y ago
      Demos on youtube?
      • dizhn 1y ago
        Yes.
  • deleted 1y ago
    [deleted]
• nowaymo6237 1y ago
  As much as I love node and typescript i am forever bummed it never achieved a railsy or Laravellian framework
  • purplerabbit 1y ago
    Have you checked out t3 stack? Curious which pieces are missing from that that you'd deem critical
    • nowaymo6237 1y ago
      Yes, it’s good, but not nearly as batteries included as it needs to be. Also all the dependencies move separately from each other in development
  • Exoristos 1y ago
    I used to feel the same way, but at a certain level of Node.js experience I came to prefer the backend JavaScript idiom. It's much lighter and more pragmatic, and gives the knowledgeable engineer a lot of flexibility. So stick with it.
  • akarshc 1y ago
    True, the closest thing i like in the node.js backend world is nestjs. It’s a solid framework for building apis, but as an mvp framework, it’s not quite on the same level as laravel, rails, or phoenix.
    • nowaymo6237 1y ago
      Nestjs is popular so there must be something to it. The problem is the complexity. Once you get a certain amount of complexity and meta programming in js you get significant slowdowns. Abstractions are expensive. Also the decorators and DI are weird
      • akarshc 1y ago
        That’s true. As the app grows, having many pages can become difficult to manage, especially with JS backends.
• mountainriver 1y ago
  In the era of vibe coding just use the fastest servers. I wrote my last api in Rust and it wasn't any harder than anything else, it's wicked fast and stable. After doing that, it seems a lot of the higher level languages will go away soonish
  • ahnick 1y ago
    curious what your process was for hardening your API for security? or is that still a pending step?
    • causal 1y ago
      TBH probably easier to vibe-code securely in statically typed languages like Rust vs. something like Elixir. Probably my biggest Elixir complaint tbh.
    • mountainriver 1y ago
      Rust is pretty darn safe as is, I check everything pretty thoroughly in the code reviews. I haven't seen it try sql injection of anything, authn/z was good
  • hu3 1y ago
    I'd rather fix AI slop in simpler languages, thank you very much. And by the time performance is a startup's concern in majority of cases, they would have to rewrite most of the code anyway, including critical parts, so why not start with a language that's easier to find developers?
    • mountainriver 1y ago
      Not for us, this is just a common phrase that I don't think is true anymore. We hit scaling issues with just a couple customers. The overhead of rewriting our servers in rust was actually really low, I found the speed differences in creating the Rust server negligible, so now I just write in Rust.
• habibur 1y ago
  Last I checked, Erlang strings were represented internally as a linked list of integers, one int for every character. That worked, but I felt like not every efficient, as web is very text heavy. Has that changed in the later versions?
  • zerr 1y ago
    In Elixir it's bytestring.
  • finder83 1y ago
    I believe that's still true of Erlang, but Elixir has UTF-8 encoded strings. In practice the only time you need to use Erlang strings from Elixir is if you're using an Erlang API.
  • waynesonfire 1y ago
    Both Erlang and Elixir support two types of text representations. The first is a linked list of Unicode codepoints (also called a character list or a charlist for short). In Erlang, this is written using double quotes. For example, "abc" in Erlang is actually the list [97, 98, 99]. In Elixir, the same representation uses single quotes: 'abc' is a list of integers. The second is a UTF-8 encoded binary. In Erlang, this is written using the <<"abc">> syntax. In Elixir, double quotes represent UTF-8 binaries, so "abc" is a binary. So: Erlang "abc" = list, <<"abc">> = binary Elixir 'abc' = list, "abc" = binary For efficiently handling textual data, Phoenix extensively utilizes iolists (https://hexdocs.pm/elixir/1.15.8/IO.html#module-io-data https://hexdocs.pm/elixir/1.15.8/IO.html#module-io-data) to eliminate copying. It's used in performance critical areas such as generating http responses and template rendering. In general, on the Erlang VM, iolists are a first-class, widely used data structure for efficient I/O.
• zerr 1y ago
  Why not Crystal and one of its web frameworks?
  • etaweb 1y ago
    I worked with Elixir/Phoenix for over 3 years, and I recently started to learn Crystal, mostly to create CLI apps or other programs where I want to create a simple executable binary. I wanted a more expressive language than Go, and easier than Rust. Out of curiosity, I took a quick look at some of the web frameworks available, they are interesting. Lucky's Components looks pretty good, but I still prefer Phoenix's Components because the syntax make it very close to raw HTML. Compilation is not incremental and is single threaded which means I have to wait at least 5 seconds every time I make a change (this was on a minimal project). It's not that bad, but compared to Elixir/Phoenix where it's almost instantaneous, it makes a difference. Still, Crystal is an awesome language, and if for one reason Elixir was not a choice for a web project, I would definitely consider a Crystal framework.
• cweagans 1y ago
  The product that OP is building is a todo list. Rails or Laravel would have both worked just fine. Elixir/Phoenix are neat technologies, but I get the sense that this decision was primarily "because I want to" rather than any particular selection methodology (which is fine - you do you, OP).
  • akarshc 1y ago
    It’s not just a simple todo list. The product includes advanced features like goal tracking, minimal project management, a streak system, daily task resets with a 3-task limit, and AI-powered task creation that can break tasks into subtasks. Users also get individual profiles to share streak progress and build habits. On top of that, we’re working on additional features like adding team members to projects and real-time collaboration. While it’s certainly possible to build these in Laravel, implementing them is not as seamless or straightforward as it is in Phoenix.
• hoppp 1y ago
  +1 to Elixir. The entire erlang ecosystem is great and Elixir allows devs who don't have time to learn Erlang to leverage it. One of the best languages for startups who want to design scalable software from the start
• uka 1y ago
  > First things first, why do we code? To solve problems in the most optimal way possible. I admire the enthusiasm. As a person who codes just to solve problems in a good enough way - I assume I should stick to Rails.
  • akarshc 1y ago
    Rails is awesome!
  • kolme 1y ago
    I had to laugh out loud when I read that sentence. Really? I write code to pay my bills and sometimes just for fun. Trying to do everything "the most optimal way possible" is going to get in the way of actually getting stuff done. "Why do we code? To prematurely optimize all the things".
• huqedato 1y ago
  The tragic part that all my 'corporate' customers don't even want to hear about Elixir. For them only JS, Python, C# and Java exist in this world. Any other stack is either "unacceptable", "unsustainable", "exceedingly expensive" or "unmanageable". In 7 years of using Elixir I couldn't impose it in any corporate project, used it only for hobby/personal/indie stuff.
  • bitbasher 1y ago
    Sounds like you need to sell it better ;p
  • dasil003 1y ago
    In the corporate world ecosystem and fungibility of programmers are the top priority. The only way Elixir will get traction there is by Elixir companies literally growing to Fortune 500 size and showing the language/ecosystem is viable at that scale. Even then I doubt the advantages of Elixir will move the needle for that type of company because once you scale up the challenge is 99% people, teams, and communication; the elegance and efficiency of the code and ops don't matter much in those types of environments.
    • deleted 1y ago
      [deleted]
  • djcoin 1y ago
    I'm always curious about C# because it seems to be fast, feature-full, not too much bloated, etc. I'm an elixir dev/fan, but what's wrong with C#? How would Elixir shine compared to it?
    • PKop 1y ago
      C# is great. You might like Blazor if you enjoy LiveView. I prefer .NET / C# static type system
      • misiek08 1y ago
• badosu 1y ago
  Working with Phoenix, and even more so Elixir and OTP, has been a great joy at a similar to almost the same level I had when transitioning from DotNet to Ruby in 2010 for my experience. There are still some rough edges, and the job market might be more challenging, but overall I feel anything Elixir related at the moment provides for a high quality filter - both in terms of job opportunities and teams as well as the general product development experience.
  • causal 1y ago
    I have been pretty happy with Elixir - the syntax takes getting used to, but I'm usually impressed by its elegance. Phoenix I'm mixed on - it has a few things that "just work" and I'm happy about, but being an opinionated framework I find myself bumping into those opinions the more I want to do things my own way. Usually there's an escape hatch, but being new to both Elixir and Phoenix it's not always obvious to me how to do things when the happy path fails.
• benterix 1y ago
  It's a pity the author didn't decide to offer a trial without attaching a credit card. I get it, we had these discussions here many times. But as a person that could potentially subscribe, I'm baffled at the choice. You could argue that I'm not really willing to subscribe if I'm not willing to provide my CC details yet. But it doesn't work this way. Before I subscribe to a new service, I really like to know it well, to have a kind of emotional relationship to understand what it is giving/saving me. "Give me you CC or get off" makes me not even want to try.
  • cpursley 1y ago
    Not everyone has VC funding where profit does not matter.
    • shkkmo 1y ago
      This isn't a debate about whether to offer a trial period or how of one to offer. This is a debate about forcing people to give you payment info for a free trial. Requiring a credit card for a free trial is a technique to trick people into paying for a subscription when they normally wouldn't have chosen do do so after the trial period. Not taking VC funding doesn't make this kind of dark pattern any less scummy. Fundementally you are trading some voluntary customers (people who don't like these tactics) or involuntary customers (distracted, busy or lazy people who forget to cancel.) When I see a company that does this, it tells me that they care about extracting value from the market than providing value to customers.
      • akarshc 1y ago
        I completely agree. Requiring credit card info for a free trial often feels like a dark pattern designed to trap users into paying. I’m taking a different approach with my product by offering a 3-day free trial that doesn’t require a card, and a 14-day free trial for serious users. I want users to try it without any pressure or tricks and make a decision based on the value they experience, not because they forgot to cancel.
      • cpursley 1y ago
• bluerooibos 1y ago
  I'm taking one look at Elixir and I'm not sure how it's supposed to be an improvement from Ruby? The readability and syntax seems to be a step backwards, so I'll stick with Ruby/Rails, thanks!
• longnighthn 1y ago
  This artile seems like AI generated, with vague content and , at least `Oban` is not phoenix build in: its a 3rd package.
  • akarshc 1y ago
    Thanks for your feedback! Yes, Oban is a third-party package, but it’s built for Phoenix, which is what I meant in the article. Also, the article is not AI-generated. I’ve mentioned the app I built with Phoenix at the bottom to give context from real experience.
    • longnighthn 1y ago
      All right now I know you are not a bot :) your article and your showcase site looks `too AI`
      • akarshc 1y ago
        Yeah, like all other sites or just mine? Everything you are seeing is an AI? (from your perspective). What makes you less of an AI then?
        • longnighthn 1y ago
          Recently people found that a lot of website genereated by ai has purple theme color[1], so when first glance on your site, I think it is a vibe code product immediatlly : ) https://www.reddit.com/r/webdev/comments/1nx0y4q/ai_has_a_purple_problem/ https://www.reddit.com/r/webdev/comments/1nx0y4q/ai_has_a_pu...
          • akarshc 1y ago
            True, I just liked the gradient for branding, and I love how it looks. From your perspective, you’re right though. At least I can assure you there’s no AI-generated code on the landing page. I’ll keep working to improve it as much as possible. Thanks mate :)
• throw-10-13 1y ago
  Author should read the rails docs again, seems like they missed a lot.
  • akarshc 1y ago
    true, there’s always more to learn. i just shared what worked best for my use case with liveview. rails is also a great framework and i enjoy using it, but liveview’s built-in real-time updates and state management fit my project needs better.
• ryanrasti 1y ago
  I share the OP's enthusiasm for Elixir, but as the CTO of a startup that ran it for three years in production, our experience was a mixed bag as the codebase grew. The core promises of the BEAM (concurrency, fault tolerance) absolutely held up. Libraries like Ecto and Oban are world-class, remote `iex` is a lifesaver in prod, and the talent pool is exceptional. However, developer experience (DX) was our biggest bottleneck. At our scale of 300k lines of code, the pain points were sharp: * Compile times: A one-line change could easily take >10 seconds to compile in dev, constantly shattering flow. * Tooling: ElixirLS was a coin flip. Unreliable autocomplete in a large codebase meant constantly grepping for function names and schema fields. * LiveView: It wasn't a fit for our complex UI, which required a lot of client-side interactivity, forcing us to build a React frontend. This introduced the exact split-stack complexity (GraphQL overhead, context switching) LiveView promises to fix I wrote a full retrospective for anyone considering the stack for a long-term project: https://ryanrasti.com/blog/elixir-three-years-production/ https://ryanrasti.com/blog/elixir-three-years-production/
  • Alifatisk 1y ago
    > Compile times: A one-line change could easily take >10 seconds to compile in dev, constantly shattering flow. Has anyone else experienced this? I've mostly read comments on how good Elixir is and if you are a Rails user you will only benefit more from Elixir. This is a bit surprising
    • arrowsmith 1y ago
      Not remotely. Maybe I'm just not working on big enough projects, but I've never experienced any frustration at all with Elixir compile times.
    • Kreoss 1y ago
      Nope. I also worked on a Startup with a Full Phoenix LiveView Experience. Codebase was around 300k-400k lines of code and compilation was blazing fast. I would say they have a lot of circular dependencies if they are experiencing that.
    • fridder 1y ago
• PhysicalDevice 1y ago
  The functioning of the app reminds me of Rails. I really think Rails is awesome but sadly despite the fragmentation JS ecosystem is still superior. SPA style with client side routing is just extremely fast and creates pleasant to use apps. For example, https://blueapex.pro https://blueapex.pro i built this with client side routing. And with TS types end to end client and backend I think Node.js coupled with React are effectively the best way to build modern web apps.
• ccanassa 1y ago
  The only thing that kept me from choosing Elixir was the lack of a type checker. Has that changed?
  • sieep 1y ago
    big update yesterday to the language enhanced type checking https://elixir-lang.org/blog/2025/10/16/elixir-v1-19-0-released/ https://elixir-lang.org/blog/2025/10/16/elixir-v1-19-0-relea...
• auraham 1y ago
  Another advantage of using Elixir/Erlang/Phoenix is high availability. If one client/incomming requests is taking a lot of time to complete, other users are not affected. We can even inspect the system in real time via iex. Please search for "The soul of Elixir" in YouTube, Sasa Juric explains this. Highly recommended.