6 ms·

Agreed. This is actually why I think the killer apps for the BEAM are 2 Elixir based ones. Nerves, which is already being heavily used for embedded systems and

Agreed. This is actually why I think the killer apps for the BEAM are 2 Elixir based ones. Nerves, which is already being heavily used for embedded systems and only getting stronger thanks to the likes of Scenic. And Phoenix LiveView (not released yet), which I personally think pulls the strengths of Phoenix together in a way that can truly disrupt web development. It’s very difficult to do what LiveView is doing on other tech stacks. The combination of those two will likely fuel things long term.

woeye 7y ago
Isn't Blazor in ASP.NET basically what LiveView is in Phoenix? https://docs.microsoft.com/en-us/aspnet/core/blazor/?view=aspnetcore-3.0 https://docs.microsoft.com/en-us/aspnet/core/blazor/?view=as...
- strmpnk 7y ago
  Not quite. Elixir code isn't set to the client as Blazor does with .Net IL. LiveView leverages a small runtime loaded onto the client which uses websockets to load deltas. While it sounds expensive at first, the template engine has been extended to support delta tracking and the process model that Elixir inherits fits well for a heavily interactive system with thousands or millions of users. The end result is that it's a very lightweight client setup and outside of using the template system properly, there are no gotchas with learning which code runs where.
  - PhilippGille 7y ago
    There's two distinct Blazor development models: Client side Blazor uses Mono (running as WebAssembly) to run C# code on the client side, but server side Blazor only updates the DOM via SignalR (like WebSockets), which works like LiveView. I didn't use Blazor yet, but that's what I understand from the documentation.
    - strmpnk 7y ago
      Thanks for the correction and clarification. The early parts of the docs didn’t make this distinction clear so I assumed the WASM half was required.
  - Nelkins 7y ago
    I don't think that's correct. Blazor supports both client-side (what you are describing, sending IL to the client and running it as an app) and server-side (what LiveView is doing). More details here: https://docs.microsoft.com/en-us/aspnet/core/blazor/hosting-models?view=aspnetcore-3.0 https://docs.microsoft.com/en-us/aspnet/core/blazor/hosting-...
1_player 7y ago
> Phoenix LiveView (not released yet), which I personally think pulls the strengths of Phoenix together in a way that can truly disrupt web development. It’s very difficult to do what LiveView is doing on other tech stacks. LiveView still needs more work to be really ergonomic, wouldn't work for all use cases, but I'm personally holding my breath here in excitement to adopt it in my Elixir projects. Still, I find it ironic that the next server side web technology leap, after the famous Rails demo referenced in the article, comes from another Ruby-inspired language.
- brightball 7y ago
  Elixir isn't really Ruby inspired though. The only thing about it that really derives from Ruby is the focus on developer productivity.
  - mtarnovan 7y ago
    The syntax is heavily inspired by Ruby.
    - etxm 7y ago
      What, the words def and do?
      - 0_gravitas 7y ago
        Jose himself has cited ruby for syntax inspiration multiple times, because he himself started in the ruby community
    - sjtgraham 7y ago
      Having written Elixir every day for the last 5 or 6 years, and Ruby for the 10 years before that I don't think it is.
      - brightball 7y ago
        That is what I was getting at. Having people who came from the Ruby world and some very mild surface level bits is all that's there. The issue I have with the statement is that it pulls all of the negative connotations that some people have with Ruby onto Elixir...and Elixir is not at all like Ruby.
porker 7y ago
> And Phoenix LiveView (not released yet), which I personally think pulls the strengths of Phoenix together in a way that can truly disrupt web development. It’s very difficult to do what LiveView is doing on other tech stacks. LiveView cannot avoid latency. When I've experimented it's great for something running on my local network; less good when it's in a datacentre in another country. It's laggy. And unless you replicate to many locations, or can deploy it to edge compute nodes (no idea) then this will always be a problem compared to 'true' client-side development. I want it to work but I don't see how it can beat the laws of physics.
- markkanof 7y ago
  That's a fair point, but it does seem like a solvable problem. There are multiple companies offering gaming services where the game is running on a remote system. I haven't tried any of these services, but from what I hear they are very useable for casual games, but still have some work to do for FPS type games where milliseconds count. That would indicate to me that getting a web UI to work with this type of setup should be very possible with geographically distributed servers.
- rikkus 7y ago
  LiveView was always going to have this limitation. Its design makes it suitable for low latency links - such as local network. It’s not going to fail to ‘work’ because of this. It just has a niche and isn’t a general purpose web framework. I’m looking forward to building some admin tools with it, reducing the complexity required when having to deal with server and client separately.
  - porker 7y ago
    > LiveView was always going to have this limitation. Its design makes it suitable for low latency links - such as local network. [...] I’m looking forward to building some admin tools with it All our tools are now hosted in the cloud - we don't run any servers on the local network. With a 20-30ms RTT perhaps it will feel smooth - or the micro-delays will be noticeable.
- nickjj 7y ago
pault 7y ago
Honest question: if liveView does catch on in a big way, what will the front end developers do? I can't see the huge FED community going back to writing HTML and CSS templates. I wonder if that resistance will hurt adoption.
- thomasfortes 7y ago
  LiveView is great for writing form validations or simple admin stuff. Even though the examples show that you can do 60fps animations, it is not the intended use case, you're not going to write anything that needs small latency or that needs a ton of processing using LiveView, front end developers are fine.
  - imtringued 7y ago
    Even in very simple CRUD projects I have to write a few hundred lines of Javascript to enhance the UI. Stuff like: if you check this box 4 more options appear. Or here is an autocomplete field/dropdown that autofills in 4 other form fields. A lot of basic stuff that cannot be done with raw HTML alone. I can see how something like LiveView would replace the need for mucking around with jQuery when your project doesn't need a big and heavy SPA framework.
    - Qwertystop 7y ago
      Hiding things with unchecked checkboxes, at least, can be done entirely in simple CSS. .optional { display: none; } input:checked ~ .optional { display: inherit; }
    - 1_player 7y ago
      I've recently adopted two libraries for my server-side backend app: 1. unpoly to handle common JS behaviours (such as show this div when this checkbox is selected) 2. Web components to handle more complex pieces of UI while maintaining compatibility with LiveView: rendering a functional jQuery carousel via LiveView/Websockets is much harder than just pushing a <carousel> element through the socket. Admittedly I haven't tested if the DOM diffing library LiveView uses plays nice with web components.
ljm 7y ago
I was going to go as far as saying that elixir itself is the ‘killer app’. It doesn’t make you an Erlang developer but it is also arguable that knowing Rails isn’t necessarily sufficient to fully grok Ruby. You’ll still make some headway though. I’ve interviewed plenty of people who cut their teeth on Rails and fall apart as soon as you present them, say, Sinatra. Or a gem that provides an API client. Once it comes to writing non-Rails code (with all the helpers and the magic), it’s as good as learning a new language that happens to look exactly the same.

woeye 7y ago

Isn't Blazor in ASP.NET basically what LiveView is in Phoenix? https://docs.microsoft.com/en-us/aspnet/core/blazor/?view=aspnetcore-3.0 https://docs.microsoft.com/en-us/aspnet/core/blazor/?view=as...

strmpnk 7y ago
Not quite. Elixir code isn't set to the client as Blazor does with .Net IL. LiveView leverages a small runtime loaded onto the client which uses websockets to load deltas. While it sounds expensive at first, the template engine has been extended to support delta tracking and the process model that Elixir inherits fits well for a heavily interactive system with thousands or millions of users. The end result is that it's a very lightweight client setup and outside of using the template system properly, there are no gotchas with learning which code runs where.
- PhilippGille 7y ago
  There's two distinct Blazor development models: Client side Blazor uses Mono (running as WebAssembly) to run C# code on the client side, but server side Blazor only updates the DOM via SignalR (like WebSockets), which works like LiveView. I didn't use Blazor yet, but that's what I understand from the documentation.
  - strmpnk 7y ago
    Thanks for the correction and clarification. The early parts of the docs didn’t make this distinction clear so I assumed the WASM half was required.
- Nelkins 7y ago
  I don't think that's correct. Blazor supports both client-side (what you are describing, sending IL to the client and running it as an app) and server-side (what LiveView is doing). More details here: https://docs.microsoft.com/en-us/aspnet/core/blazor/hosting-models?view=aspnetcore-3.0 https://docs.microsoft.com/en-us/aspnet/core/blazor/hosting-...

1_player 7y ago

> Phoenix LiveView (not released yet), which I personally think pulls the strengths of Phoenix together in a way that can truly disrupt web development. It’s very difficult to do what LiveView is doing on other tech stacks. LiveView still needs more work to be really ergonomic, wouldn't work for all use cases, but I'm personally holding my breath here in excitement to adopt it in my Elixir projects. Still, I find it ironic that the next server side web technology leap, after the famous Rails demo referenced in the article, comes from another Ruby-inspired language.

brightball 7y ago
Elixir isn't really Ruby inspired though. The only thing about it that really derives from Ruby is the focus on developer productivity.
- mtarnovan 7y ago
  The syntax is heavily inspired by Ruby.
  - etxm 7y ago
    What, the words def and do?
    - 0_gravitas 7y ago
      Jose himself has cited ruby for syntax inspiration multiple times, because he himself started in the ruby community
  - sjtgraham 7y ago
    Having written Elixir every day for the last 5 or 6 years, and Ruby for the 10 years before that I don't think it is.
    - brightball 7y ago
      That is what I was getting at. Having people who came from the Ruby world and some very mild surface level bits is all that's there. The issue I have with the statement is that it pulls all of the negative connotations that some people have with Ruby onto Elixir...and Elixir is not at all like Ruby.

porker 7y ago

> And Phoenix LiveView (not released yet), which I personally think pulls the strengths of Phoenix together in a way that can truly disrupt web development. It’s very difficult to do what LiveView is doing on other tech stacks. LiveView cannot avoid latency. When I've experimented it's great for something running on my local network; less good when it's in a datacentre in another country. It's laggy. And unless you replicate to many locations, or can deploy it to edge compute nodes (no idea) then this will always be a problem compared to 'true' client-side development. I want it to work but I don't see how it can beat the laws of physics.

markkanof 7y ago
That's a fair point, but it does seem like a solvable problem. There are multiple companies offering gaming services where the game is running on a remote system. I haven't tried any of these services, but from what I hear they are very useable for casual games, but still have some work to do for FPS type games where milliseconds count. That would indicate to me that getting a web UI to work with this type of setup should be very possible with geographically distributed servers.
rikkus 7y ago
LiveView was always going to have this limitation. Its design makes it suitable for low latency links - such as local network. It’s not going to fail to ‘work’ because of this. It just has a niche and isn’t a general purpose web framework. I’m looking forward to building some admin tools with it, reducing the complexity required when having to deal with server and client separately.
- porker 7y ago
  > LiveView was always going to have this limitation. Its design makes it suitable for low latency links - such as local network. [...] I’m looking forward to building some admin tools with it All our tools are now hosted in the cloud - we don't run any servers on the local network. With a 20-30ms RTT perhaps it will feel smooth - or the micro-delays will be noticeable.
nickjj 7y ago

pault 7y ago

Honest question: if liveView does catch on in a big way, what will the front end developers do? I can't see the huge FED community going back to writing HTML and CSS templates. I wonder if that resistance will hurt adoption.

thomasfortes 7y ago
LiveView is great for writing form validations or simple admin stuff. Even though the examples show that you can do 60fps animations, it is not the intended use case, you're not going to write anything that needs small latency or that needs a ton of processing using LiveView, front end developers are fine.
- imtringued 7y ago
  Even in very simple CRUD projects I have to write a few hundred lines of Javascript to enhance the UI. Stuff like: if you check this box 4 more options appear. Or here is an autocomplete field/dropdown that autofills in 4 other form fields. A lot of basic stuff that cannot be done with raw HTML alone. I can see how something like LiveView would replace the need for mucking around with jQuery when your project doesn't need a big and heavy SPA framework.
  - Qwertystop 7y ago
    Hiding things with unchecked checkboxes, at least, can be done entirely in simple CSS. .optional { display: none; } input:checked ~ .optional { display: inherit; }
  - 1_player 7y ago
    I've recently adopted two libraries for my server-side backend app: 1. unpoly to handle common JS behaviours (such as show this div when this checkbox is selected) 2. Web components to handle more complex pieces of UI while maintaining compatibility with LiveView: rendering a functional jQuery carousel via LiveView/Websockets is much harder than just pushing a <carousel> element through the socket. Admittedly I haven't tested if the DOM diffing library LiveView uses plays nice with web components.

ljm 7y ago

I was going to go as far as saying that elixir itself is the ‘killer app’. It doesn’t make you an Erlang developer but it is also arguable that knowing Rails isn’t necessarily sufficient to fully grok Ruby. You’ll still make some headway though. I’ve interviewed plenty of people who cut their teeth on Rails and fall apart as soon as you present them, say, Sinatra. Or a gem that provides an API client. Once it comes to writing non-Rails code (with all the helpers and the magic), it’s as good as learning a new language that happens to look exactly the same.