4 ms·

Hey Chris! Is there a LiveView future where one can forego javascript frameworks altogether in creating higher-fidelity UIs?

yetanothermonk 5y ago
Have you seen Surface UI? Pretty cool. Collection of LiveView components. https://surface-ui.org/ https://surface-ui.org/
chrismccord 5y ago
That's really the goal, and for a large class of applications we are already there. Higher-fidelity UIs is pretty vague and there is absolutely a limit to where you necessarily need a bunch of code running on the client. Google maps & docs? Millions of lines of JS is inescapable, but dashboards, feeds, chats? LiveView excels here. We don't yet know where the limit is, but if you look at Livebook, we have a collaborative code notebook with presence, realtime updates across users and operational-transform based content updates powered by LiveView, with only ~3k lines of basic JavaScript for the client-side bits like the Monaco editor.
- nickjj 5y ago
  Have you done any comprehensive profiling of Livebook? It would be really interesting to see how it runs on low end or average cloud hosting providers under load. I'd love to see how many thousands of concurrent users could be interactively using and collaborating on a Livebook that's running on something like a $15 / month server. You could show off the memory, CPU usage and the latency of responses with varied amounts of load. IMO that would be a very useful thing to look at and could push folks into using Phoenix more so than they already do because having a bunch of tiny websocket connections open (the old 2 million connection benchmark) isn't really relatable to a typical web application that you mentioned people are building like dashboards, feeds and other things. Livebook is a concrete application with features that might appear in many other web apps. Something like that would be worthy of a demo video at a talk or even your YouTube channel if you were ever fishing around for what people in the community might want to see.
  - mrkurt 5y ago
    We have a multi-region Liveview demo here: https://liveview-counter.fly.dev/ https://liveview-counter.fly.dev/ The total cost to run this is on Fly.io is $38/mo (~$2/mo per region). We've seen as many as 10k concurrent users pushing 30k "clicks" per second. People are fond of writing JavaScript in their browser console to simulate very fast clicks, so it turned into a funny stress test. My browser slowed down, the Elixir processes never did.
    - nickjj 5y ago
      Thanks, I remember seeing that one a few months ago. I hope this doesn't come off too harshly but that demo feels like it's meant to showcase high requests per second, not be a representation of how a real application would perform. It's broadcasting a counter over a websocket connection. It feels very similar to the old 2 million websocket connection demo. In other words I can't use your demo to make a meaningful conclusion on how LV would perform in my app. Also according to dev tools your demo page takes 300ms for me to load it from NY but I get 10-15ms response times on many other sites in the north east region of the US. A 300ms page response is usually what I would get hitting a server in Australia. The initial page load feels very delayed to load, although the counter increment was lightning fast. I like the idea of using Livebook as a test case because it's an actual application, it's something relatable to what you might build instead of something that feels like it was created in a vacuum to promote high numbers. Sort of like how you could benchmark nginx with a hello world response. It's cool to see the high numbers but it doesn't help folks understand how things would work in a real app. Having a breakdown of the average and p95/p99 response times at 100, 500, 1000, 2000, 10000, 25000 and 100000 connections all sending messages at varying rates along with seeing CPU and memory usage on a certain tier of VPS would be amazingly useful. You could take that data and factor in how your app might deal with similar conditions.
      - mrkurt 5y ago
        It's not too harsh at all! The demo is really meant to show liveview interaction latency, we didn't really ever think it would be useful for load. That 300ms load time is actually because it queries Australia when you first load the page. Each region keeps its own counter and it grabs the current value from all of them at load time. It's probably worth optimizing that. :)
subbu 5y ago
I rewrote a large Rails+React+GraphQL with LiveView. LiveView replaced most of React. I still use React for rich text editors and complex browser based UI. LiveView plays well with this. I am happy not using GraphQL at all. It also consolidated all MVC code in one place. Phoenix made a few other things possible: in place chat, live updates (via websockets. No more polling).

yetanothermonk 5y ago

Have you seen Surface UI? Pretty cool. Collection of LiveView components. https://surface-ui.org/ https://surface-ui.org/

chrismccord 5y ago

That's really the goal, and for a large class of applications we are already there. Higher-fidelity UIs is pretty vague and there is absolutely a limit to where you necessarily need a bunch of code running on the client. Google maps & docs? Millions of lines of JS is inescapable, but dashboards, feeds, chats? LiveView excels here. We don't yet know where the limit is, but if you look at Livebook, we have a collaborative code notebook with presence, realtime updates across users and operational-transform based content updates powered by LiveView, with only ~3k lines of basic JavaScript for the client-side bits like the Monaco editor.

nickjj 5y ago
Have you done any comprehensive profiling of Livebook? It would be really interesting to see how it runs on low end or average cloud hosting providers under load. I'd love to see how many thousands of concurrent users could be interactively using and collaborating on a Livebook that's running on something like a $15 / month server. You could show off the memory, CPU usage and the latency of responses with varied amounts of load. IMO that would be a very useful thing to look at and could push folks into using Phoenix more so than they already do because having a bunch of tiny websocket connections open (the old 2 million connection benchmark) isn't really relatable to a typical web application that you mentioned people are building like dashboards, feeds and other things. Livebook is a concrete application with features that might appear in many other web apps. Something like that would be worthy of a demo video at a talk or even your YouTube channel if you were ever fishing around for what people in the community might want to see.
- mrkurt 5y ago
  We have a multi-region Liveview demo here: https://liveview-counter.fly.dev/ https://liveview-counter.fly.dev/ The total cost to run this is on Fly.io is $38/mo (~$2/mo per region). We've seen as many as 10k concurrent users pushing 30k "clicks" per second. People are fond of writing JavaScript in their browser console to simulate very fast clicks, so it turned into a funny stress test. My browser slowed down, the Elixir processes never did.
  - nickjj 5y ago
    Thanks, I remember seeing that one a few months ago. I hope this doesn't come off too harshly but that demo feels like it's meant to showcase high requests per second, not be a representation of how a real application would perform. It's broadcasting a counter over a websocket connection. It feels very similar to the old 2 million websocket connection demo. In other words I can't use your demo to make a meaningful conclusion on how LV would perform in my app. Also according to dev tools your demo page takes 300ms for me to load it from NY but I get 10-15ms response times on many other sites in the north east region of the US. A 300ms page response is usually what I would get hitting a server in Australia. The initial page load feels very delayed to load, although the counter increment was lightning fast. I like the idea of using Livebook as a test case because it's an actual application, it's something relatable to what you might build instead of something that feels like it was created in a vacuum to promote high numbers. Sort of like how you could benchmark nginx with a hello world response. It's cool to see the high numbers but it doesn't help folks understand how things would work in a real app. Having a breakdown of the average and p95/p99 response times at 100, 500, 1000, 2000, 10000, 25000 and 100000 connections all sending messages at varying rates along with seeing CPU and memory usage on a certain tier of VPS would be amazingly useful. You could take that data and factor in how your app might deal with similar conditions.
    - mrkurt 5y ago
      It's not too harsh at all! The demo is really meant to show liveview interaction latency, we didn't really ever think it would be useful for load. That 300ms load time is actually because it queries Australia when you first load the page. Each region keeps its own counter and it grabs the current value from all of them at load time. It's probably worth optimizing that. :)

subbu 5y ago

I rewrote a large Rails+React+GraphQL with LiveView. LiveView replaced most of React. I still use React for rich text editors and complex browser based UI. LiveView plays well with this. I am happy not using GraphQL at all. It also consolidated all MVC code in one place. Phoenix made a few other things possible: in place chat, live updates (via websockets. No more polling).