5 ms·

I've been moving from Django to Elixir/Phoenix/LiveView and loving it so far. I hated the Angular/React era of the web and mostly moved to doing backend develop

by Mizza 5y ago

I've been moving from Django to Elixir/Phoenix/LiveView and loving it so far. I hated the Angular/React era of the web and mostly moved to doing backend development, but the Live App era has reinvigorated my interest in web development as a whole. I'll miss Python a lot and hope they can come up with something that solves the concurrency issues, but Elixir is really pretty good in its own right.

koyote 5y ago
Having recently looked into Blazor Server (similar to LiveView but in C#), one of the cons Microsoft listed was the scalability (compared to a typical SPA) as each client now needs an active websocket connection to the server, which will require more server resources. Do you have any experience in that? I'd love to know where server resource requirements sit between SPA, this and a typical SSR site like Django.
- yurishimo 5y ago
  The thing that elevates Phoenix in this regard is since it’s built on Elixir (and consequently the BEAM), adding a new “process” to hold the web socket in memory is trivial and basically comes for free out of the box. The Phoenix core team has demonstrated over a million (maybe it was even 5?) simultaneous connections running on one server all being updated at once. Granted, it was a proof of concept, but in the real world, you would load balance well before that in all likelihood. The point is the same though. BEAM languages can easily manage a hundred thousand nodes of state simultaneously without breaking a sweat. For most apps, this is plenty as demonstrated by discord, WhatsApp, and other BEAM focused tech companies.
SoylentOrange 5y ago
Can you explain what you mean by “Live App” era vs React era? Can you point towards resources which might disambiguate the two?
- Mizza 5y ago
  Sure! Basically, the idea is that rather than requests in JavaScript going through an API, each user connection is maintained by a lightweight process on the server (which Elixir can scale easily), and then interactions with the page are pushed as a diff via WebSockets and then magically merged into the DOM. Interactive pages, no JavaScript required. I'm still pretty new to it, but after learning the ropes it's seeming very productive, and most importantly, fun. https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...
  - drbw 5y ago
    So pretty much the Blazor Server approach in the Dot Net world then?
    - shijie 5y ago
      Yes, basically. Fun fact: Blazor and LiveView were developed independently, around the same time as each other! Just two similar implementations in disparate communities.
      - pantulis 5y ago
        Guess that was due to browser-land innovations that made this a possibility.
    - keewee7 5y ago
      Blazor Server and Blazor WebAssembly needs to be marketed separately. Most people have heard about Blazor WebAssembly but are unaware that LiveView-style web development is possible in the .Net world using Blazor Server.
      - SketchySeaBeast 5y ago
        Yes, yes they do. I don't know why you'd name pretty much the exact opposite techs the exact same thing.
deleted 5y ago
[deleted]
simonw 5y ago
There's a thriving ecosystem these days around the ASGI standard for building concurrent web applications in Python - it came out of the Django project originally but Starlette and FastAPI are the most widely used implementations of it.
- Starlevel001 5y ago
  ASGI is a bad solution to the concurrency issues as the ecosystem is heavily centralised around asyncio (which is ``java.lang.Thread`` for async/await, with all the pitfalls included).
  - zbentley 5y ago
    Could you elaborate on what you mean by that? I can think of two interpretations, both wrong: 1. Asyncio is like java.lang.Thread in that it's very low level; which isn't accurate: it's totally acceptable and easy to write async concurrency using asyncio (the python async stdlib) directly. While frameworks like Trio are nice they're nowhere near as necessary when working async as thread/pool managers are in Java. 2. Asyncio is like java.lang.Thread in that it has similar pitfalls to threaded programming in general. This is also untrue: in async programming in general, race conditions are much harder to write, and concurrent modification issues aren't a risk at all in Python async code the way they are in threaded Python or Java.
emodendroket 5y ago
I haven't done frontend work for a few years, but Angular was really a revelation to me when it first came out. For all the headaches, it made it practical to do stuff that was really cool.
deleted 5y ago
[deleted]

by Mizza 5y ago

koyote 5y ago

Having recently looked into Blazor Server (similar to LiveView but in C#), one of the cons Microsoft listed was the scalability (compared to a typical SPA) as each client now needs an active websocket connection to the server, which will require more server resources. Do you have any experience in that? I'd love to know where server resource requirements sit between SPA, this and a typical SSR site like Django.

yurishimo 5y ago
The thing that elevates Phoenix in this regard is since it’s built on Elixir (and consequently the BEAM), adding a new “process” to hold the web socket in memory is trivial and basically comes for free out of the box. The Phoenix core team has demonstrated over a million (maybe it was even 5?) simultaneous connections running on one server all being updated at once. Granted, it was a proof of concept, but in the real world, you would load balance well before that in all likelihood. The point is the same though. BEAM languages can easily manage a hundred thousand nodes of state simultaneously without breaking a sweat. For most apps, this is plenty as demonstrated by discord, WhatsApp, and other BEAM focused tech companies.

SoylentOrange 5y ago

Can you explain what you mean by “Live App” era vs React era? Can you point towards resources which might disambiguate the two?

Mizza 5y ago
Sure! Basically, the idea is that rather than requests in JavaScript going through an API, each user connection is maintained by a lightweight process on the server (which Elixir can scale easily), and then interactions with the page are pushed as a diff via WebSockets and then magically merged into the DOM. Interactive pages, no JavaScript required. I'm still pretty new to it, but after learning the ropes it's seeming very productive, and most importantly, fun. https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...
- drbw 5y ago
  So pretty much the Blazor Server approach in the Dot Net world then?
  - shijie 5y ago
    Yes, basically. Fun fact: Blazor and LiveView were developed independently, around the same time as each other! Just two similar implementations in disparate communities.
    - pantulis 5y ago
      Guess that was due to browser-land innovations that made this a possibility.
  - keewee7 5y ago
    Blazor Server and Blazor WebAssembly needs to be marketed separately. Most people have heard about Blazor WebAssembly but are unaware that LiveView-style web development is possible in the .Net world using Blazor Server.
    - SketchySeaBeast 5y ago
      Yes, yes they do. I don't know why you'd name pretty much the exact opposite techs the exact same thing.

deleted 5y ago

[deleted]

simonw 5y ago

There's a thriving ecosystem these days around the ASGI standard for building concurrent web applications in Python - it came out of the Django project originally but Starlette and FastAPI are the most widely used implementations of it.

Starlevel001 5y ago
ASGI is a bad solution to the concurrency issues as the ecosystem is heavily centralised around asyncio (which is ``java.lang.Thread`` for async/await, with all the pitfalls included).
- zbentley 5y ago
  Could you elaborate on what you mean by that? I can think of two interpretations, both wrong: 1. Asyncio is like java.lang.Thread in that it's very low level; which isn't accurate: it's totally acceptable and easy to write async concurrency using asyncio (the python async stdlib) directly. While frameworks like Trio are nice they're nowhere near as necessary when working async as thread/pool managers are in Java. 2. Asyncio is like java.lang.Thread in that it has similar pitfalls to threaded programming in general. This is also untrue: in async programming in general, race conditions are much harder to write, and concurrent modification issues aren't a risk at all in Python async code the way they are in threaded Python or Java.

emodendroket 5y ago

I haven't done frontend work for a few years, but Angular was really a revelation to me when it first came out. For all the headaches, it made it practical to do stuff that was really cool.

deleted 5y ago

[deleted]