6 ms·

It doesn’t just work in my experience. Once its working it is fine, better than fine in fact. But I am going through a process of upgrading a Phoenix LiveView h

• ipnon 4y ago
  I agree with your assessment. You have to know what you’re signing up for. Remaining in the JavaScript ecosystem still maintains many tangible benefits.
• throwawaymaths 4y ago
  Yeah you got bitten by the 0.15-0.16 transition in live view. My condolences. Documentation across the elixir ecosystem is pretty good, I find. I am way more comfortable in elixir ecosystem docs over python ecosystem docs.
  • AlchemistCamp 4y ago
    The transitions from about half of the versions between 0.3 and 0.10 were worse for me. From 0.10 to 0.15 were smooth. 0.16 was tied to phx 1.6, which made it worse again, but I didn’t find it that bad. 0.16 to 0.18 has been mostly okay again, but I’ve seen bugs introduced into an app just by adding IDs to HTML elements with a phx-hook on them. This is a problem since heex templates enforce that each hook does have an ID. It’s also strange that a totally new ID never used elsewhere in the app would break existing JS interop, but it does and it’s what I’ll be working on this week so we can continue upgrading… Not sure what it’s going to be like upgrading to Phoenix 1.7, but I think it’s going to be a major undertaking and unfortunately most my Phoenix-related screencasts will become obsolete. Elixir itself and Ecto have been really stable, though.
    • josevalim 4y ago
      Right, Phoenix LiveView has been pre 1.0. We try to keep things deprecated for a while but we need to balance getting to 1.0 and supporting existing code. Now that it is getting closer, we can make it as a default in new Phoenix apps. :) phx-hook always required IDs. They would misbehave (and warn) if you forgot the IDs, so could it be that you were relying on broken behavior? In any case the IDs can be enforced now, so it should be consistent, please file bugs if it does not work. Upgrade to Phoenix v1.7 should be painless, because it only really changed generated code. Screencasts that use generators will be out of date though. In other words, best practices evolved (as they should) but code still works.
      • AlchemistCamp 4y ago
        I don’t see reliance on broken behavior around the hook, but it’s absolutely possible. It’s a large app with a lot of technical debt and was on Elixir 1.9, OTP 22, LiveView 0.4 and Webpack 4.x when I joined on this summer. The existing team had encountered a lot of pain dealing with LiveView and made heavy use of jQuery as an escape hatch. They were seriously considering a rewrite in another language not long before I joined. It’s been a long, painful slog upgrading, but the app is now working with current Elixir and Erlang versions and runs on my M1 Mac now at least. LV 0.16.4 runs on prod and 0.17.5 is working on an upgrade branch (as long certain phx-hooks don’t have an ID). I’ll get to the bottom of the various issues and get the heex migration finished. Ultimately, I’ll remove the currently hooks and related JS entirely and replace the modals that rely on them with pure LV versions. Just reporting the dev experience. IMO Phoenix upgrades were pretty trivial since I started around 1.2, until LiveView. Now, due to the increasing LV integration, it feels like Phoenix itself is no longer 1.0.
        • josevalim 4y ago
          Great job on the upgrades! FWIW, if an element does not have an ID, then it is hard for morphdom to track when it moves around on the page. This will lead the hook to consider it is has been destroyed and mounted instead of updated. About Phoenix, the generated apps definitely evolved a lot, but updating your Phoenix dependency should just work. If it doesn’t, please file a bug report!
  • Existenceblinks 4y ago
    I guess that's heex. I don't like JSX style but the it's not as crazy as javascript. It's okay. With first-class function, passing a thunk that returns template (not in plain string) around is also extensible. But slot is also okay to me. The trade-off of compile time construct is it's harder to do thing in dynamic way.
• conradfr 4y ago
  I don't think you should be downvoted, you gave it a fair shot and concluded it was not for you.
  • timc3 4y ago
    Well I am on the fence at the moment. Perhaps I should be downvoted for being indecisive!
• weatherlite 4y ago
  What's "magical" about Rails...I really dislike that criticism because it's an inaccurate cliche. Rails has great documentation and common sense (for the most part) conventions. Try doing something in Spring and tell me your experience ... it can easily be described as "magic" unless you read a massive amount of Spring documentation.
  • timc3 4y ago
    I admit it's a long time since I used Rails and Ruby, and it was around the same time I was learning Python and Django back when Rails was the hot thing - but Django seemed to be more straight forward and less of "So why is this working". If you read the PEP20 Zen of Python that resonates much more soundly with me particularly "Explicit is better than implicit." This drives me nuts for example: https://guides.rubyonrails.org/layouts_and_rendering.html#rendering-by-default-convention-over-configuration-in-action https://guides.rubyonrails.org/layouts_and_rendering.html#re... - ok it's automatically parsing and rendering that template, based on that route and controller and it's less code but less explicit. And it assumes that we have written all the filenames correctly.
    • amval 4y ago
      Which it's a pretty fair assumption: you would create all of those files through generators, eliminating the need for writing boilerplate. And make the name explicit if, for any reason, your template is located somewhere else. I am not a huge Rails fan, but in this particular case I see zero issues with how Rails does things.
• Existenceblinks 4y ago
  Elixir docs is top-notch, well-organized. Typescript docs is a mess category-wise. Believe it or not Typescript code is going to be buggy than dynamic typed elixir code because it has better defensive mechanism (pattern match + guard + immutability). The only thing I agree is macro, it's designed for human DX .. good though is hard to do interop (programmable).
• h0l0cube 4y ago
  > Phoenix also feels a little bit magical in the way Rails is I've felt this about every backend web framework I've encountered, Django included. There's a tension between reducing boiler-plate, and not having directory structures/symbol names/etc. have some implicit order to them. If you want explicitness, don't use a framework and maybe use something like Flask/Werkzeug > I miss types Most frameworks have typespecs defined which are enforced by dialyzer, using a much richer type system than most. e.g. Without creating some explicit enum you can make a function signature like: @spec some_function() :: {:error, :bad_args | :out_of_bounds } | {:ok, SomeStruct.t} And then you can a caller can just pattern match on that with a 'case' statement, and dialyzer will complain if all paths aren't handled. > I miss C# and Typescripts documentation hexdocs.pm is pretty amazing. Elixir as a language encourages documentation and has iterated heavily on its documentation tooling. I love that I can just fire up an iex console and go `h Module.some_command` and I'll get great docs back. And then `@doctests` that both work as inline unit tests as well as low-cost documentation for the library author. I think the incentives to make good documentation are there, and that has inspired the community to document well. And then there's elixirforum.com if I get stuck. In constrast, many times a Django extension has left me wanting in its description about intended behaviours.
  • timc3 4y ago
    Oh my god, why didn't I know about "h Module.some_command`. Thanks, that is going to be really helpful! Will be reading the IEx documentation more closely.
    • h0l0cube 4y ago
      > Thanks, that is going to be really helpful! That makes me really happy :) And if you prefer docs in web-form, just look up any module in hexdocs.pm . Also can't overstate how helpful elixirforums.com is - a lot of smart + helpful people on there.
    • andyjones11 4y ago
      There was a really great talk at ElixirConf 2022 with this tip + loads more. [1] Definitely check it out! [1] https://www.youtube.com/watch?v=BotVs6TXR-c https://www.youtube.com/watch?v=BotVs6TXR-c
• josevalim 4y ago
  I am sorry that this has been your experience. I am obviously biased but I would stick around. :) I assume you started with LiveView early on, which means the documentation was sprouting and best practices still evolving. Nowadays it is still pre-1.0 but much closer to its vision, so you should find better docs on the current practices. We now support components too, which declare each attribute, alongside their docs and types. So assuming you go through the update, I am hoping you will have a good time once it is done. And don’t hesitate to reach out in ElixirForum.com if you have questions. Regarding types, we are researching types for Elixir: https://elixir-lang.org/blog/2022/10/05/my-future-with-elixir-set-theoretic-types/ https://elixir-lang.org/blog/2022/10/05/my-future-with-elixi... - this is still years ahead, but I thought I would mention in context.
  • timc3 4y ago
    Thanks for the reply. I go through great days with Elixir/Phoenix and bad days, yesterday happened to be a bad day. I really like the promise of Phoenix, it really is one of the most forward thinking projects I have come across - hence continuing using it, though I don't have all the time in the world to invest in it so just jumping in and out can be painful. Want this project to work though, I have tried commercial products, IOS apps, and nothing matches upto my vision or indeed my old working prototype.
  • yurishimo 4y ago
    The docs (or lack there of) were the reason I stopped playing with Phoenix and Liveview. As an Elixir n00b, source diving to figure out how things work isn't an option for me right now. I'm sure you've been linked these a thousand times, but the docs for Laravel are imo, the gold standard for developer documentation. I love the idea of Hex being a built in solution for documentation, but a hodgepodge short guides supplemented by the Hex docs isn't enough. I also realize you're not Chris, but I figured it was worth mentioning. I do really like Elixir and hope I can come back to it when these ideas mature a little more!
    • rkangel 4y ago
      I'm incredibly surprised by this. I personally use the Phoenix documentation as the gold standard for good developer documentation! There is an excellent, clear and practical set of guides that take you through the increasing complexity of a Phoenix app. I find them very clear, and surprisingly complete. They start here: https://hexdocs.pm/phoenix/up_and_running.html https://hexdocs.pm/phoenix/up_and_running.html The 'reference level' documentation is also excellent. I picked this example randomly, but it has an extensive guide at the top and then good description of each of the functions: https://hexdocs.pm/phoenix/Phoenix.Channel.html https://hexdocs.pm/phoenix/Phoenix.Channel.html
• mattbrewsbytes 4y ago
  Your assessment is similar to mine, set aside any cool features of the language, maintaining an Elixir app is the problem. The constant API shift with each LiveView release, not enough people maintaining hex packages, not a large amount of hex packages available forcing some things to be built, etc. Adoption in our organization was halted because of the messiness of upgrade path in Elixir as a whole. Projects that were built on earlier versions suffer the most pain where developers will spend like a week sorting through code changes needed to update. There are some neat aspects of Elixir but the maintenance trade-offs aren't worth it in management's eyes.
  • deleted 4y ago
    [deleted]
• OkayPhysicist 4y ago
  LiveView's growing pains were definitely pretty bad (the early days of it had some pretty obnoxious breaking changes), and I can see while still disagreeing about the magic comment, but what's wrong with Elixir's docs? They are, hands-down, the best language docs I've ever interacted with, and that very much includes C#, so I'm a little baffled as to where that complaint comes from.