I agree. Even though we're all in on React, it's good to see some change for once, and Phoenix just looks better and better overall. Makes me wanna try it "for real"
It’ll be interesting to see how people use it. So many use cases where you could benefit from low overhead real-time updates. I also wonder if anyone can/would figure out a way to run React or Vue style components in Phoenix with this. Theoretically it should be possible. :-)
I have been eagerly waiting for this ever since I saw Chris McCord's demo. Having this become tightly integrated into the Phoenix framework will be game changing.
I think there are a large number of use cases for which this completely obviates the need to build a SPA. That's a huge time savings, and also makes for a faster cycle time as an app gets iterated upon/redesigned. The cost implications are massive.
In many circumstances I think it will also be a better user experience than a SPA -- e.g. this avoids "cold start" performance issues for a user's first page.
Thanks for the hard work Chris, José & team. Elixir & Phoenix are a joy to use while also being incredibly powerful/productive.
Or look at the ElixirConf keynote:
https://youtu.be/Z2DU0qLfPIY?t=2503 (the video starts at 41:43 showcasing a cool demo where you would expect the latency to be a bottleneck, yet it's not)
Been looking forward it for quite a while. For those guys who don't like SPA and JavaScript, this could be a great way of bring back rails MVC development experience while keeping some pros of SPA.
I cant help comparing it to ancient stateful Java web apps which were a pain to use. What is different this time so that it can outdo the hard-won victory of stateless servers over stateful servers?
The apps I know were:
1. Freezes and needing a refresh/logout after the server-side "actor" or connection fails.
2. Refresh won't actually work, you need to login again.
3. Neither does back/forward, hence the big warnings not to hit back button, for example in a paginated list. Hitting back makes it freeze.
4. Extreme latency.
5. No shareable urls or hyperlinks possible, two tabs in same browser will sync with each other.
12 comments
[ 4.4 ms ] story [ 37.5 ms ] threadI think there are a large number of use cases for which this completely obviates the need to build a SPA. That's a huge time savings, and also makes for a faster cycle time as an app gets iterated upon/redesigned. The cost implications are massive.
In many circumstances I think it will also be a better user experience than a SPA -- e.g. this avoids "cold start" performance issues for a user's first page.
Thanks for the hard work Chris, José & team. Elixir & Phoenix are a joy to use while also being incredibly powerful/productive.
Or look at the ElixirConf keynote: https://youtu.be/Z2DU0qLfPIY?t=2503 (the video starts at 41:43 showcasing a cool demo where you would expect the latency to be a bottleneck, yet it's not)
The apps I know were:
1. Freezes and needing a refresh/logout after the server-side "actor" or connection fails.
2. Refresh won't actually work, you need to login again.
3. Neither does back/forward, hence the big warnings not to hit back button, for example in a paginated list. Hitting back makes it freeze.
4. Extreme latency.
5. No shareable urls or hyperlinks possible, two tabs in same browser will sync with each other.