9 ms·

Dynamic Forms with LiveView Streams

129 points by unripe_syntax 3y ago

rjh29 3y ago
Phoenix/LiveView must be really good if people are learning not one but two niche languages (Elixir and Erlang) just to use it. I wonder if the framework is particularly tied to Elixir or if it could be done in a more popular language so more people will take it up. edit: and yes I know WhatsApp was/is written in Erlang, just to save you commenting.
- rkangel 3y ago
  > I wonder if the framework is particularly tied to Elixir or if it could be done in a more popular language so more people will take it up. My understanding of the origin of Phoenix is that Chris McCord tried to create something like LiveView in Ruby, but the concurrency system didn't support the vision he had for how it would work. He cast around a bit, discovered Elixir and create Phoenix and then LiveView. The concurrency story in other languages is improving over time, but they're still trying to catch up with what Erlang was doing in the 80s. Building complicated applications on top of the BEAM and OTP is a joy compared to any other system that I've used. You learn a few simple approaches, and many things you've had to think about just go completely away.
- iudqnolq 3y ago
  > learning not one but two niche languages You need to learn Elixir. Learning Erlang isn't going to be particularly helpful. > I wonder if the framework is particularly tied to Elixir or if it could be done in a more popular language so more people will take it up. Blazor (C#) and StimulusReflex (Ruby) are the ones that immediately pop into my head.
- arrowsmith 3y ago
  You don't need to know Erlang to use Phoenix or LiveView.
- deofoo 3y ago
  First, it is really good. Second, you only need to learn Elixir, no need for any Erlang knowledge.
  - yurishimo 3y ago
    This is true, but I would add an asterisk. While not knowing Erlang is not a hard requirement, eventually, you will greatly benefit from being able to read and write some basic Erlang. That said, learning Elixir first will at least get you in the right mindset, and then Erlang becomes an easy lesson in syntax.
- sph 3y ago
  > I wonder if the framework is particularly tied to Elixir or if it could be done in a more popular language so more people will take it up. All programming languages are Turing-complete thus compatible. So you shan't need much more than Brainfuck. But if you consider all the benefits the language and the platform it sits on (the BEAM) provides, no, you cannot do Live View as easily and comfortably than you can do on Elixir. Because its model is strongly tied to lightweight processes, message passing, mailboxes and pattern matching. You can implement Live View in assembly or Python or Rust, but it's not going to be very quite as ergonomic and productive. Also, you don't need to know Erlang to be productive in Elixir, but knowing the Erlang ecosystem (i.e. OTP) is going to pay dividends, since it's very powerful and at your fingertips from the Ruby-like comfort of Elixir.
  - bryanrasmussen 3y ago
    >All programming languages are Turing-complete thus compatible. So you shan't need much more than Brainfuck. XSL-T 1.0 is Turing complete but you can't really write a C compiler in it - despite what some people may have been heard to claim at various XML conferences in 2000 - because what matters in most things is what rights and accesses the language offers you and XSL-T 1.0 does not give you the possibility of loading in non-XML files.
    - sph 3y ago
      Fine, you shan't need more than an assembler for your CPU architecture.
  - clessg 3y ago
    > You can implement Live View in assembly I would love to see this.
- krnsi 3y ago
  Here you go – a list of LiveView workalikes: https://github.com/liveviews/liveviews https://github.com/liveviews/liveviews
  - rapnie 3y ago
    The list is seeking a maintainer. https://github.com/liveviews/liveviews/issues/23 https://github.com/liveviews/liveviews/issues/23
- victorbjorklund 3y ago
  You really don't need to learn Erlang. Would it help to understand some of the deeper stuff in some libraries or the beam itself? Sure, but then you could argue you need to learn Javascript and C to use Node because a lot of low-level stuff in node is C. Will it help to become a better Node dev? Probably doesn't hurt but you def don't need to learn C to work with Node.
- pmarreck 3y ago
  When you learn Elixir, you basically also learn Erlang semantics, with only the syntactic details to work out later. Plus you get a few extra perks, like macros.
- sodapopcan 3y ago
  > I wonder if the framework is particularly tied to Elixir or if it could be done in a more popular language so more people will take it up. As others have pointed out there already are lots (missing at present are LiveWire and there is even a LiveView.js that uses the same JS that Phoenix LiveView uses... it's a very unfortunate name). Having said that, most of these implementations aren't "live" in the same way you get with the Erlang virtual machine where each user has a dedicated process. It's at least possible in Go, but most of these other implementations resort to AJAX and the like.
deofoo 3y ago
After you work with Phoenix/LiveView is soo hard to come back to anything else. I love the fact it's very opinionated and most times there's a right way to do things. LiveView is game changer, same user experience (even better) with 10x better developer experience. No much dual state management and things just work.
- quickthrower2 3y ago
  I keep seeing almost this exact comment from different people when phoenix is mentioned. It is quite a learning curve I might try again one day. What makes this better than say a traditional ruby/rails or django app with maybe some htmx to save doing the JS side of things?
  - fredrikholm 3y ago
    BEAM (ErlangVM). This video explains it better than I can: https://www.youtube.com/watch?v=JvBT4XBdoUE https://www.youtube.com/watch?v=JvBT4XBdoUE
    - yurishimo 3y ago
      I knew which video this was before I clicked on it. It's a brilliant demo of the power of the BEAM and how it can be leveraged for web applications.
  - ch4s3 3y ago
    You get a concurrent request processing spread across all of your cpu/vcpu cores out of the box. The fallback controller pattern for error handling is incredible for boilerplate error handling. Worst case latency is very stable. The query builder/data mapper, Ecto, is IMO far better than ActiveRecor being more explicit and prevents N+1s out of the box. Eex is built on compile time linked lists rather than run time string interpolation like the options in Rails and Django.
    - ativzzz 3y ago
      My opinions on this as a rails dev > You get a concurrent request processing spread across all of your cpu/vcpu cores out of the box That's neat, but this doesn't matter until you reach serious scale, as scaling a rails app horizontally by throwing more server instances works for a long time > The fallback controller pattern for error handling is incredible for boilerplate error handling Sounds just like controller inheritance in rails > Worst case latency is very stable So is rails, worst case latency is generally caused by slow SQL requests or having to render complex documents (which can be offloaded to the background easily) > The query builder/data mapper, Ecto, is IMO far better than ActiveRecor being more explicit and prevents N+1s out of the box I don't have a problem with ActiveRecord, and while N+1s are easy to create, there are a ton of tools to help prevent these in rails. Can be a hinderance for junior devs or devs without rails experience though Once things get complex, you're gonna be writing SQL directly anyway > Eex is built on compile time linked lists Cool but sounds irrelevant for 99.9% of cases, string interpolation isn't what causes rails apps to be slow
ThatMedicIsASpy 3y ago
I sometimes just like to look at code and ignore the rest since it's not something I have experience with. But damn this is some next level ugly mess of code in my eyes.
- marcofiset 3y ago
  You being unfamiliar with a programming language doesn't make it an ugly mess.
- slig 3y ago
  Agreed. Somehow we are back to PHP's level of fuglyness.
- Alifatisk 3y ago
  What are you used to?
melx 3y ago
I read somewhere that it's good to learn new prog language every some time but there's not enough time in one's life (especially after having kid(s)). So I used Elixir (Phoenix/Ecto) on a new project some 18months ago and every project I start now is using that tech stack! The best thing for someone like me (back-end dev) is no need to write JavaScript, care about zillions of build systems, having the Node/npm drama yet I can create nice and "progressive" web apps. In fact one of the projects I'm building is a powerful online forms builder.
pmarreck 3y ago
The use of template code in a view model- Is there a way to push that out into its own template? Is there a reason why things are done this way?
- sodapopcan 3y ago
  It's done this way to collocate related (business) concerns. The views are in their own functions and don't contain any logic and, yes, they can be pushed into separate template files if that's what you prefer. This has been a thing since React came out and its merits have been debated to death already.
  - pmarreck 3y ago
    I noticed this in React and it's also a reason why I didn't like React. Fortunately or unfortunately, I've never had occasion to use React in prod. lol. Can you point me at any of the debates you mentioned so I can catch up? In Rails this would have been a "partial" with some underscored filename
    - sodapopcan 3y ago
      I assume searching for "JSX sucks" would do it. I certainly haven't bookmarked any debates from the past 10 years, lol. Incidentally JSX is the only thing I like about React. I find components are much more flexible and cohesive than partials (Rails was my thing for years and I still have a soft spot for it). But to each their own and I no longer enjoy debating it!
      - pmarreck 3y ago
        that’s cool, I just missed them, I didn’t want to participate in them, I just wanted to catch up
  - madeofpalk 3y ago
    "Seperation of concerns, not technology" is the line often brought up in React circles.
hobo_mark 3y ago
Is this to be understood as the equivalent of HTMX + Jinja, but for Elixir?
- marcofiset 3y ago
  LiveView goes far beyond what htmx offers. Or at least makes it much more fully integrated across the whole stack. htmx is a frontend library first and foremost, that dictates some patterns you may want to implement on the backend. LiveView is a backend-first framework, with excellent support for interactive frontend stuff.
  - deleted 3y ago
    [deleted]
lycos 3y ago
I love working with Elixir and hope to be able to find a new gig where I can continue doing that. That's the hardest part unfortunately still. But more ontopic, has anyone here already used these LiveView Streams in production? Based on this example it feels like I'm having to manage a lot more myself with the only real advantage being less memory usage, right? I'm just wondering where/when it makes sense to play with this instead of, for example, temporary_assigns with phx-update="append". Are there more advantages than the memory usage reduction?
- di4na 3y ago
  I refactored my profiling library to use them. They reduce the amount of stuff to manage. Instead of keeping a whole list of stuff organise, you just pass stuff to the stream and everything just works with good diff.
commitpizza 3y ago
I have tried Liveview and I have looked at alternatives and I have to say that even if I don't use Phoenix or Elixir on daily basis, Liveview is easily the best out there. The developer experience is great and Phoenix is just a great framework. The speed in which one can create stuff is mind blowing which is going to be the biggest pull factor into the language imo. My main issue is that Elixir is great for a lot of hard problems but for the easy, common problems it is lacking a lot in libraries and so on. It also has a high learning curve. Although it is probably just going to get better in time the learning curve will probably not.
- fredrikholm 3y ago
  IME a lot of the learning curve is functional programming, shortly followed by OTP. If you've ever worked with a functional language picking up on the OTP abstractions (eg. GenServer) is a small hill to climb in order to become effective on a day-to-day basis. That said, with every new language comes idioms, tools and libraries that one has to learn, but this is true for all languages.
  - commitpizza 3y ago
    True and honestly, as an experienced developer it wasn't that huge of a step to start coding in Elixir. It's just that I (at least) is still thinking in an object-oriented way even when I'm working in Elixir because that is what I am used to. I think the hardest part is to let go of some of the old practices and embrace functional programming as much as you can. I would like to work with elixir professionally but have yet to find an employer that uses it in production :)
    - yurishimo 3y ago
      Many Elixir companies will hire and train you if you have previous experience. If you're really interested, it's worth reaching out!
      - ch4s3 3y ago
Alifatisk 3y ago
Everytime LiveView or Phoenix pops up here in HN, people always mentions how much they enjoy the framework. It feels to me like it's something I am missing out on? I am Ruby/Rails developer myself and StimulusReflex seem to be the equivalent but idk, is my feeling true?
- sph 3y ago
  No it is not equivalent. My dream stack that I am using for my business is Phoenix, Live View and Stimulus.js with Tailwind. I have built projects on Laravel, Django, RoR, React and a long tail of in house frameworks, and nothing feels as good as this stack for web apps. Ruby on Rails is quite underrated, but the BEAM is a spaceship that fits neatly in the list of unknown unknowns for 99% of software engineers: they do not know what the BEAM can do for them. Its process and mailbox model feels futuristic in its expressiveness and simplicity. It's easier than you think to get used to Elixir's functional language model. For me it was super easy, while with stuff like Haskell or Prolog I felt like I had to rewrite my brain from scratch. To end my proselitism, I am adamant that the first Live View demo by McCord and Valim will have the same staying power if not popularity as DHH's first demo of Ruby on Rails which spawned the modern MVC framework architecture of the past 15 years. The Live View model is in my eyes the next generation of interactive web architecture, the true successor to MVC.
  - pbowyer 3y ago
    > My dream stack that I am using for my business is Phoenix, Live View and Stimulus.js with Tailwind. I am curious, why both LiveView and Stimulus.js? Why and how are you combining the two together?
    - sph 3y ago
      For very small interactions, there is no need for a round trip and state held on the server. Imagine a disappearing burger menu, or a tooltip widget, or a "click here to copy to clipboard" link. For those sprinkles of interactivity, you need JS and Stimulus is ideal for that use case. I just have my Live View process render <input type="text" data-controller="copy-on-click" value="..." /> which is easy to understand and plays great with Live View's model. Don't forget that JS was born for this goal: small snippets of interactive behaviour; it was never meant to be the entire system.
vyrotek 3y ago
Is LiveView like ASP.NET Blazor Server? It seems to look very similar but I didn't see whether LiveView has the "sticky" websocket server requirement like Blazor. With Blazor all of the user's state is in memory on one specific app server. And if a connection is lost the app is completely unresponsive. It's a great dev experience but I've seen comments about scaling and interaction latency concerns. Seems like it'd be great for intranet corp apps. Is anyone running either tech as a public facing service?
- benwilson-512 3y ago
  Hey vryotek, short version: stickiness is not necessary or important. It does use a websocket. To elaborate a bit, while each LiveView client is indeed associated with a long lived process in the LiveView server, the Phoenix framework provides hooks and other lifecycle management tools to minimize the impact of disconnects from eg blue green server deploys. Most interestingly for example with forms, the "automatic form recovery" does a process where when the reconnect happens it delays re-rendering until the client side has had a chance to send the current form state back to the server and allow it to synchronize.
garyrob 3y ago
When I've seen LiveView mentioned in the past, the one major problem seems to be its reliance on sockets, which causes problems in certain environments and also can cause too much latency on slow internet connections. An example of the kind of problems is at [1]. It's not hard to find other such discussions. The other thing I wonder about is cross-platform. If you're using something like React or Flutter there are various solutions. But I haven't run across anything substantial that's oriented towards Phoenix LiveView. [1] https://elixirforum.com/t/live-view-fallback-with-no-websocket/26068/18 https://elixirforum.com/t/live-view-fallback-with-no-websock....
- tomtheelder 3y ago
  The fallback to polling is generally a good solution. I think the sorts of problems that dev ran into are very much the exception, not the rule, given the kind of absurd environment they were working in. Also worth calling out that LiveView was _very_ new when that post was made. The latency issue is a real one. Long polling can also help there, but realistically if a substantial portion of your user base is on poor connections you’re going to be much better off with a traditional server rendered web application than something like LiveView or a SPA. I’m not sure what you mean about cross-platform. LiveView is for building web apps, so there’s only really one platform to speak of: the browser.
  - garyrob 3y ago
    Thanks, that's helpful. > I’m not sure what you mean about cross-platform. LiveView is for building web apps, so there’s only really one platform to speak of: the browser. Similarly, React is for web apps but React Native has emerged such that your knowledge and some code can carry over, and now there's even React Native for Web so that you can write React Native and run it on the web in a way that at least tries to maximize code portability. It sounds like there hasn't been an emergence of equivalent tools with LiveView... but that's fine. As you say, LiveView is for the web and if that's the one thing you're targeting, especially for an internal app so internet connectivity is reliable, it's fantastic and possibly the best solution that exists now. There's certainly nothing wrong with making a great tool to full a particular (major) need!!
dugmartin 3y ago
The new LiveView streams are a good start - they are missing reordering though which is needed for lists but is not a normal property of a stream. I've been working on a personal project which is very list heavy. I started it in pure LiveView using streams but ended up switching to a React SPA hosted in a non-updating LiveView div. Along with missing the reordering (which is needed a lot in the app) the amount of state I needed to hold on the server to wouldn't scale.
- di4na 3y ago
  If you have remarked, you can reorder in this version :)
ihatejs 3y ago
I haven't read the entire article but my biggest complaint is the lack of tutorials to deal with the new way of defining forms and tables using the new function components in Phoenix 1.7. Yes, the official documents do explain how function components (in general) work and are defined but what I really wanted was a superficial guide to use specific components without delving into the internals. I did bite the bullet and read the documentation and looked at the source code but I feel I didn't really need to do it. Just tell me the new tags I could use, what the attributes mean but I don't need to know how the sausage is made.
- mrdoops 3y ago
  Liveview v1.0 is the next step with this release out; 1.0 will be the main target for tutorials, documentation, examples and libraries to build on. Easiest way to get component usage examples ATM is to generate a phx project, and run a mix phx.gen.auth and phx.gen.live command.

129 points by unripe_syntax 3y ago

Phoenix/LiveView must be really good if people are learning not one but two niche languages (Elixir and Erlang) just to use it. I wonder if the framework is particularly tied to Elixir or if it could be done in a more popular language so more people will take it up. edit: and yes I know WhatsApp was/is written in Erlang, just to save you commenting.

rkangel 3y ago
> I wonder if the framework is particularly tied to Elixir or if it could be done in a more popular language so more people will take it up. My understanding of the origin of Phoenix is that Chris McCord tried to create something like LiveView in Ruby, but the concurrency system didn't support the vision he had for how it would work. He cast around a bit, discovered Elixir and create Phoenix and then LiveView. The concurrency story in other languages is improving over time, but they're still trying to catch up with what Erlang was doing in the 80s. Building complicated applications on top of the BEAM and OTP is a joy compared to any other system that I've used. You learn a few simple approaches, and many things you've had to think about just go completely away.
iudqnolq 3y ago
> learning not one but two niche languages You need to learn Elixir. Learning Erlang isn't going to be particularly helpful. > I wonder if the framework is particularly tied to Elixir or if it could be done in a more popular language so more people will take it up. Blazor (C#) and StimulusReflex (Ruby) are the ones that immediately pop into my head.
arrowsmith 3y ago
You don't need to know Erlang to use Phoenix or LiveView.
deofoo 3y ago
First, it is really good. Second, you only need to learn Elixir, no need for any Erlang knowledge.
- yurishimo 3y ago
  This is true, but I would add an asterisk. While not knowing Erlang is not a hard requirement, eventually, you will greatly benefit from being able to read and write some basic Erlang. That said, learning Elixir first will at least get you in the right mindset, and then Erlang becomes an easy lesson in syntax.
sph 3y ago
> I wonder if the framework is particularly tied to Elixir or if it could be done in a more popular language so more people will take it up. All programming languages are Turing-complete thus compatible. So you shan't need much more than Brainfuck. But if you consider all the benefits the language and the platform it sits on (the BEAM) provides, no, you cannot do Live View as easily and comfortably than you can do on Elixir. Because its model is strongly tied to lightweight processes, message passing, mailboxes and pattern matching. You can implement Live View in assembly or Python or Rust, but it's not going to be very quite as ergonomic and productive. Also, you don't need to know Erlang to be productive in Elixir, but knowing the Erlang ecosystem (i.e. OTP) is going to pay dividends, since it's very powerful and at your fingertips from the Ruby-like comfort of Elixir.
- bryanrasmussen 3y ago
  >All programming languages are Turing-complete thus compatible. So you shan't need much more than Brainfuck. XSL-T 1.0 is Turing complete but you can't really write a C compiler in it - despite what some people may have been heard to claim at various XML conferences in 2000 - because what matters in most things is what rights and accesses the language offers you and XSL-T 1.0 does not give you the possibility of loading in non-XML files.
  - sph 3y ago
    Fine, you shan't need more than an assembler for your CPU architecture.
- clessg 3y ago
  > You can implement Live View in assembly I would love to see this.
krnsi 3y ago
Here you go – a list of LiveView workalikes: https://github.com/liveviews/liveviews https://github.com/liveviews/liveviews
- rapnie 3y ago
  The list is seeking a maintainer. https://github.com/liveviews/liveviews/issues/23 https://github.com/liveviews/liveviews/issues/23
victorbjorklund 3y ago
You really don't need to learn Erlang. Would it help to understand some of the deeper stuff in some libraries or the beam itself? Sure, but then you could argue you need to learn Javascript and C to use Node because a lot of low-level stuff in node is C. Will it help to become a better Node dev? Probably doesn't hurt but you def don't need to learn C to work with Node.
pmarreck 3y ago
When you learn Elixir, you basically also learn Erlang semantics, with only the syntactic details to work out later. Plus you get a few extra perks, like macros.
sodapopcan 3y ago
> I wonder if the framework is particularly tied to Elixir or if it could be done in a more popular language so more people will take it up. As others have pointed out there already are lots (missing at present are LiveWire and there is even a LiveView.js that uses the same JS that Phoenix LiveView uses... it's a very unfortunate name). Having said that, most of these implementations aren't "live" in the same way you get with the Erlang virtual machine where each user has a dedicated process. It's at least possible in Go, but most of these other implementations resort to AJAX and the like.

deofoo 3y ago

After you work with Phoenix/LiveView is soo hard to come back to anything else. I love the fact it's very opinionated and most times there's a right way to do things. LiveView is game changer, same user experience (even better) with 10x better developer experience. No much dual state management and things just work.

quickthrower2 3y ago
I keep seeing almost this exact comment from different people when phoenix is mentioned. It is quite a learning curve I might try again one day. What makes this better than say a traditional ruby/rails or django app with maybe some htmx to save doing the JS side of things?
- fredrikholm 3y ago
  BEAM (ErlangVM). This video explains it better than I can: https://www.youtube.com/watch?v=JvBT4XBdoUE https://www.youtube.com/watch?v=JvBT4XBdoUE
  - yurishimo 3y ago
    I knew which video this was before I clicked on it. It's a brilliant demo of the power of the BEAM and how it can be leveraged for web applications.
- ch4s3 3y ago
  You get a concurrent request processing spread across all of your cpu/vcpu cores out of the box. The fallback controller pattern for error handling is incredible for boilerplate error handling. Worst case latency is very stable. The query builder/data mapper, Ecto, is IMO far better than ActiveRecor being more explicit and prevents N+1s out of the box. Eex is built on compile time linked lists rather than run time string interpolation like the options in Rails and Django.
  - ativzzz 3y ago
    My opinions on this as a rails dev > You get a concurrent request processing spread across all of your cpu/vcpu cores out of the box That's neat, but this doesn't matter until you reach serious scale, as scaling a rails app horizontally by throwing more server instances works for a long time > The fallback controller pattern for error handling is incredible for boilerplate error handling Sounds just like controller inheritance in rails > Worst case latency is very stable So is rails, worst case latency is generally caused by slow SQL requests or having to render complex documents (which can be offloaded to the background easily) > The query builder/data mapper, Ecto, is IMO far better than ActiveRecor being more explicit and prevents N+1s out of the box I don't have a problem with ActiveRecord, and while N+1s are easy to create, there are a ton of tools to help prevent these in rails. Can be a hinderance for junior devs or devs without rails experience though Once things get complex, you're gonna be writing SQL directly anyway > Eex is built on compile time linked lists Cool but sounds irrelevant for 99.9% of cases, string interpolation isn't what causes rails apps to be slow

ThatMedicIsASpy 3y ago

I sometimes just like to look at code and ignore the rest since it's not something I have experience with. But damn this is some next level ugly mess of code in my eyes.

marcofiset 3y ago
You being unfamiliar with a programming language doesn't make it an ugly mess.
slig 3y ago
Agreed. Somehow we are back to PHP's level of fuglyness.
Alifatisk 3y ago
What are you used to?

melx 3y ago

I read somewhere that it's good to learn new prog language every some time but there's not enough time in one's life (especially after having kid(s)). So I used Elixir (Phoenix/Ecto) on a new project some 18months ago and every project I start now is using that tech stack! The best thing for someone like me (back-end dev) is no need to write JavaScript, care about zillions of build systems, having the Node/npm drama yet I can create nice and "progressive" web apps. In fact one of the projects I'm building is a powerful online forms builder.

pmarreck 3y ago

The use of template code in a view model- Is there a way to push that out into its own template? Is there a reason why things are done this way?

sodapopcan 3y ago
It's done this way to collocate related (business) concerns. The views are in their own functions and don't contain any logic and, yes, they can be pushed into separate template files if that's what you prefer. This has been a thing since React came out and its merits have been debated to death already.
- pmarreck 3y ago
  I noticed this in React and it's also a reason why I didn't like React. Fortunately or unfortunately, I've never had occasion to use React in prod. lol. Can you point me at any of the debates you mentioned so I can catch up? In Rails this would have been a "partial" with some underscored filename
  - sodapopcan 3y ago
    I assume searching for "JSX sucks" would do it. I certainly haven't bookmarked any debates from the past 10 years, lol. Incidentally JSX is the only thing I like about React. I find components are much more flexible and cohesive than partials (Rails was my thing for years and I still have a soft spot for it). But to each their own and I no longer enjoy debating it!
    - pmarreck 3y ago
      that’s cool, I just missed them, I didn’t want to participate in them, I just wanted to catch up
- madeofpalk 3y ago
  "Seperation of concerns, not technology" is the line often brought up in React circles.

hobo_mark 3y ago

Is this to be understood as the equivalent of HTMX + Jinja, but for Elixir?

marcofiset 3y ago
LiveView goes far beyond what htmx offers. Or at least makes it much more fully integrated across the whole stack. htmx is a frontend library first and foremost, that dictates some patterns you may want to implement on the backend. LiveView is a backend-first framework, with excellent support for interactive frontend stuff.
- deleted 3y ago
  [deleted]

lycos 3y ago

I love working with Elixir and hope to be able to find a new gig where I can continue doing that. That's the hardest part unfortunately still. But more ontopic, has anyone here already used these LiveView Streams in production? Based on this example it feels like I'm having to manage a lot more myself with the only real advantage being less memory usage, right? I'm just wondering where/when it makes sense to play with this instead of, for example, temporary_assigns with phx-update="append". Are there more advantages than the memory usage reduction?

di4na 3y ago
I refactored my profiling library to use them. They reduce the amount of stuff to manage. Instead of keeping a whole list of stuff organise, you just pass stuff to the stream and everything just works with good diff.

commitpizza 3y ago

I have tried Liveview and I have looked at alternatives and I have to say that even if I don't use Phoenix or Elixir on daily basis, Liveview is easily the best out there. The developer experience is great and Phoenix is just a great framework. The speed in which one can create stuff is mind blowing which is going to be the biggest pull factor into the language imo. My main issue is that Elixir is great for a lot of hard problems but for the easy, common problems it is lacking a lot in libraries and so on. It also has a high learning curve. Although it is probably just going to get better in time the learning curve will probably not.

fredrikholm 3y ago
IME a lot of the learning curve is functional programming, shortly followed by OTP. If you've ever worked with a functional language picking up on the OTP abstractions (eg. GenServer) is a small hill to climb in order to become effective on a day-to-day basis. That said, with every new language comes idioms, tools and libraries that one has to learn, but this is true for all languages.
- commitpizza 3y ago
  True and honestly, as an experienced developer it wasn't that huge of a step to start coding in Elixir. It's just that I (at least) is still thinking in an object-oriented way even when I'm working in Elixir because that is what I am used to. I think the hardest part is to let go of some of the old practices and embrace functional programming as much as you can. I would like to work with elixir professionally but have yet to find an employer that uses it in production :)
  - yurishimo 3y ago
    Many Elixir companies will hire and train you if you have previous experience. If you're really interested, it's worth reaching out!
    - ch4s3 3y ago

Alifatisk 3y ago

Everytime LiveView or Phoenix pops up here in HN, people always mentions how much they enjoy the framework. It feels to me like it's something I am missing out on? I am Ruby/Rails developer myself and StimulusReflex seem to be the equivalent but idk, is my feeling true?

sph 3y ago
No it is not equivalent. My dream stack that I am using for my business is Phoenix, Live View and Stimulus.js with Tailwind. I have built projects on Laravel, Django, RoR, React and a long tail of in house frameworks, and nothing feels as good as this stack for web apps. Ruby on Rails is quite underrated, but the BEAM is a spaceship that fits neatly in the list of unknown unknowns for 99% of software engineers: they do not know what the BEAM can do for them. Its process and mailbox model feels futuristic in its expressiveness and simplicity. It's easier than you think to get used to Elixir's functional language model. For me it was super easy, while with stuff like Haskell or Prolog I felt like I had to rewrite my brain from scratch. To end my proselitism, I am adamant that the first Live View demo by McCord and Valim will have the same staying power if not popularity as DHH's first demo of Ruby on Rails which spawned the modern MVC framework architecture of the past 15 years. The Live View model is in my eyes the next generation of interactive web architecture, the true successor to MVC.
- pbowyer 3y ago
  > My dream stack that I am using for my business is Phoenix, Live View and Stimulus.js with Tailwind. I am curious, why both LiveView and Stimulus.js? Why and how are you combining the two together?
  - sph 3y ago
    For very small interactions, there is no need for a round trip and state held on the server. Imagine a disappearing burger menu, or a tooltip widget, or a "click here to copy to clipboard" link. For those sprinkles of interactivity, you need JS and Stimulus is ideal for that use case. I just have my Live View process render <input type="text" data-controller="copy-on-click" value="..." /> which is easy to understand and plays great with Live View's model. Don't forget that JS was born for this goal: small snippets of interactive behaviour; it was never meant to be the entire system.

vyrotek 3y ago

Is LiveView like ASP.NET Blazor Server? It seems to look very similar but I didn't see whether LiveView has the "sticky" websocket server requirement like Blazor. With Blazor all of the user's state is in memory on one specific app server. And if a connection is lost the app is completely unresponsive. It's a great dev experience but I've seen comments about scaling and interaction latency concerns. Seems like it'd be great for intranet corp apps. Is anyone running either tech as a public facing service?

benwilson-512 3y ago
Hey vryotek, short version: stickiness is not necessary or important. It does use a websocket. To elaborate a bit, while each LiveView client is indeed associated with a long lived process in the LiveView server, the Phoenix framework provides hooks and other lifecycle management tools to minimize the impact of disconnects from eg blue green server deploys. Most interestingly for example with forms, the "automatic form recovery" does a process where when the reconnect happens it delays re-rendering until the client side has had a chance to send the current form state back to the server and allow it to synchronize.

garyrob 3y ago

When I've seen LiveView mentioned in the past, the one major problem seems to be its reliance on sockets, which causes problems in certain environments and also can cause too much latency on slow internet connections. An example of the kind of problems is at [1]. It's not hard to find other such discussions. The other thing I wonder about is cross-platform. If you're using something like React or Flutter there are various solutions. But I haven't run across anything substantial that's oriented towards Phoenix LiveView. [1] https://elixirforum.com/t/live-view-fallback-with-no-websocket/26068/18 https://elixirforum.com/t/live-view-fallback-with-no-websock....

tomtheelder 3y ago
The fallback to polling is generally a good solution. I think the sorts of problems that dev ran into are very much the exception, not the rule, given the kind of absurd environment they were working in. Also worth calling out that LiveView was _very_ new when that post was made. The latency issue is a real one. Long polling can also help there, but realistically if a substantial portion of your user base is on poor connections you’re going to be much better off with a traditional server rendered web application than something like LiveView or a SPA. I’m not sure what you mean about cross-platform. LiveView is for building web apps, so there’s only really one platform to speak of: the browser.
- garyrob 3y ago
  Thanks, that's helpful. > I’m not sure what you mean about cross-platform. LiveView is for building web apps, so there’s only really one platform to speak of: the browser. Similarly, React is for web apps but React Native has emerged such that your knowledge and some code can carry over, and now there's even React Native for Web so that you can write React Native and run it on the web in a way that at least tries to maximize code portability. It sounds like there hasn't been an emergence of equivalent tools with LiveView... but that's fine. As you say, LiveView is for the web and if that's the one thing you're targeting, especially for an internal app so internet connectivity is reliable, it's fantastic and possibly the best solution that exists now. There's certainly nothing wrong with making a great tool to full a particular (major) need!!

dugmartin 3y ago

The new LiveView streams are a good start - they are missing reordering though which is needed for lists but is not a normal property of a stream. I've been working on a personal project which is very list heavy. I started it in pure LiveView using streams but ended up switching to a React SPA hosted in a non-updating LiveView div. Along with missing the reordering (which is needed a lot in the app) the amount of state I needed to hold on the server to wouldn't scale.

di4na 3y ago
If you have remarked, you can reorder in this version :)

ihatejs 3y ago

I haven't read the entire article but my biggest complaint is the lack of tutorials to deal with the new way of defining forms and tables using the new function components in Phoenix 1.7. Yes, the official documents do explain how function components (in general) work and are defined but what I really wanted was a superficial guide to use specific components without delving into the internals. I did bite the bullet and read the documentation and looked at the source code but I feel I didn't really need to do it. Just tell me the new tags I could use, what the attributes mean but I don't need to know how the sausage is made.

mrdoops 3y ago
Liveview v1.0 is the next step with this release out; 1.0 will be the main target for tutorials, documentation, examples and libraries to build on. Easiest way to get component usage examples ATM is to generate a phx project, and run a mix phx.gen.auth and phx.gen.live command.