DEV Community

codewander
codewander

Posted on • Edited on

Isomorphic showdown: liveview vs nextjs

Nextjs is an incredibly popular framework for implementing isomorphic web applications, you can fetch data from database, render wherever you want, and transition into a running react app, all without writing plumbing to get your data from the server to the client. It takes care of serializing your data and fetching it when needed as you traverse to a page.

Elixir's Liveview is a cutting edge framework which relies on the Erlang vm/beam extremely lightweight processes to run one server side digital twin for each client, and sends over small DOM change lists to the client over a websocket, along with a library that implements receiving DOM change lists and takes care of applying them to a rendered DOM. Liveview effectively runs everything server side.

They both let you achieve the dream of using one programming language to implement data fetching and rendering, rather than the usual context switch when implementing a backend API in go/python and front end using react.

Liveview let's you truly think in one platform and set of libraries, there is no need to think about which portions will run on the client side or server side, since it's all server side. Nextjs still requires some consideration about whether code is running in a server side context or a client side context, and you may have to reason about which libraries are available where. It's not a frequent issue, but it does come up.

Liveview also scales smoothly and elixir libraries are typically implemented with scalability accounted for. As I understand, scaling node/nextjs can require some effort as you use a mixture of libraries.

At the time of writing, nextjs provides a rich ecosystem of typed libraries via typescript. Liveview does not have static typing, although it may arrive in elixir in 2024, or an imitation of liveview in the statically typed gleam may reach feature parity in 2024. If types are essential, then nextjs is the only option right now.

There are more community tutorials, guides, and best practices established for nextjs, given the enormous user population, but liveview also has a body of quality articles on how to use it.

Nextjs is more polished and has been in production use much longer than liveview. Although elixir and erlang VM has solved scaling and been around much longer than node/nextjs.

Nextjs provides some interesting side features stemming from its use as a static site generator. It supports compile time rendering and complex incremental re-rendering, in addition to server side and client side rendering.

Ecto is an incredible query library and I don't believe there is anything as full featured in the world of node.

There are numerous UI component libraries for react. Liveview has some budding component libraries.

Overall, the two are close. I would select liveview if I had to choose, because I love Ecto, I value the simplicity of only thinking about one platform/server side context, and I like that I can just rely on smooth scaling without any effort. I would miss the static typing of nextjs/typescript and the clean, rich ecosystem around react relative to liveview's clunky template system.

Top comments (2)

Collapse
 
codewander profile image
codewander

With typescript, you can also use isomorphic with an API by implementing a separate trpc backend speaking to a SPA or nextjs front end. This gives you some more freedom to change your front end and backend with being tied to one framework like nextjs.

Collapse
 
codewander profile image
codewander

React has readily available accessible component libraries