ElixirConf 2018 - Keynote - Chris McCord
Why Hacker News recommends it
HN recommends it as the original LiveView announcement and demo, a compelling argument for server-side rendering as an alternative to JavaScript front ends.
What it is
Chris McCord's ElixirConf 2018 keynote introduces Phoenix LiveView, which renders HTML on the server and updates the page over websockets. It includes a demo showing that latency is not the bottleneck one might expect.
Recommended by 6 HN commenters across 4 different months, 2018 to 2019.
What Hacker News said
Strong rec lelf · 2019-03 · on “Ask HN: What happened to server-side rendering?”
Phoenix.LiveView — you can't ignore it, the coolest thing happening right now about server-side rendering. Demo: [this video] Links: [LINK] [LINK] PS please stop calling it isomorphic — this is disgrace for the mathematics.
Recommends neya · 2019-01 · on “Ask HN: Go-to web stack today?”
If you didn't provide constraints (node/react), I would use the following. Please note, this is highly opinionated, so nothing to get offended or upset about. I like to keep my stack simple: A. Simple static sites: - Jekyll B. Medium complexity, CRUD applications: - Phoenix/Elixir - Coffeescript Note: With the latest version of Phoenix, you absolutely don't any JS frontends at all. Watch they keynote presentation for the liveview demo: [this video] C. Complex Web applications: - Phoenix/Elixir - GraphQL/Absinthe - VueJs + Vuex + Coffeescript Developing with Phoenix/Elixir is so much better than any of the node frameworks in the ecosystem - this has consistently been my experience. So, give it a s
Recommends snake117 · 2019-01 · on “Ask HN: Hardware guy needs to learn web application development – what language?”
If you are feeling a bit adventurous and open-minded as you begin this venture, I would highly suggest looking into Elixir and Phoenix, especially since you are asking for "...best bang for the buck". In fact, the 1.8.0 release for Elixir was just announced earlier today here: [LINK] ( [LINK] ) What makes Phoenix great is that, not only is it blazing fast, but the framework serves as more of a web interface to your application as oppose to "taking over" your application, like with other major frameworks. Moreover, you get the full power of Erlang and OTP as well. I will have to say that some things are a little rough still, like deploying your application. This process is not as smooth as wh
Recommends karthikksv · 2019-02 · on “Show HN: Purview – A server-side component framework”
Yes, that was my inspiration! Chris gave a great talk about it at ElixirConf is anyone is interested in watching: [this video] Some differences compared to LiveView: - Type-checking: there are extensive JSX typings ( [LINK] ) that ensure you're attaching event handlers with the correct signatures, specifying supported props, using valid HTML tags and attributes, etc. Static-typing guarantees are one of my big priorities. - I'm not sure if LiveView intends to support nested components like React does. Having the ability to split up complex pages into components that you can nest and reuse (with mostly one-way data flow) is a key part of maintainability. I wanted to maintain a very familiar React i
Recommends sfusato · 2019-03 · on “Phoenix: LiveView”
Check the demos here (look at the snake game regarding latency concerns): [LINK] Or look at the ElixirConf keynote: [this video] (the video starts at 41:43 showcasing a cool demo where you would expect the latency to be a bottleneck, yet it's not)
Recommends jeremy_k · 2019-09 · on “Lumen: An alternative BEAM implementation, designed for WebAssembly”
I can't give a deep comparison since I haven't done anything too deep with LiveView (yet!) but I would encourage you to watch the keynotes on LiveView[1][2] if you're really interested. I have spent the last few years working with React / Redux on a big SPA and I believe the entire thing could easily be supported by LiveView; we don't do anything fancy, its basically just a bunch of CRUD based pages. Another shallow comparison is that LiveView isn't meant to compete with modern progressive SPAs. While it can update the DOM with data from the server and is very good at doing that, it has limitations such as no offline support. Chris (the speaker in the videos) also notes that if your clients
Cites mrdoops · 2018-09 · on “The “Developer Experience” Bait-And-Switch”
Don't even need Ajax anymore. You can render on the fly, and deliver new HTML over websockets. The gap between SPA and classic server-side rendering is getting smaller fast. [this video]
Cites mercer · 2018-10 · on “Evergreen: a React UI Framework built by Segment”
> If I had to guess, I would guess that React will still be around in 5 years, but I'm not sure web components will. I agree, and this is why I use React (or rather Preact) for both apps and interactive elements on the page. The big caveat is that in practice it's really easy to end up with a React project that is much more difficult to maintain compared to a monolithic framework (Ember, Angular, Vue, even), because of all the other crap that might be used to take care of all the stuff React doesn't do. For example, I recently took on a React project that used a whole bunch of other packages for state management, routing, etc., and a number of those packages were no longer supported (or outr