Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React to LiveView for Performance [audio]

podcast.thinkingelixir.com

Post reply on HN
Print view View original

11–20 of 48 posts

Re: React to LiveView for Performance [audio]

#11

Post by eclark »

lefrenchy wrote: post #2

I’ve been wanting to use LiveView so bad, it’s just incredibly hard to justify to a team when React is working just fine :(

LiveView and Elixir combine to in my opinion to make the only platform that's enjoyable for front end and backend developers.

Front-end developers love the LiveView model with functional components, no state, and light node.js dependency.

Backend developers get a process/actor + OTP supervision tree that's second to none. Horizontally scalable, functional, and pretty simple at its core.

Fullstack developers get to transition seamlessly.

I've really enjoyed using it while building.

Re: React to LiveView for Performance [audio]

#13

Post by deliriumchn »

nesarkvechnep wrote: post #5
lefrenchy wrote: post #2

I’ve been wanting to use LiveView so bad, it’s just incredibly hard to justify to a team when React is working just fine :(

It is hard to justify, especially when front-end devs are monoglots. I bet your backend is Node + Mongo.

not just this, but also no one knows elixir. Its a very niche language for very niche set of tasks, rewriting existing apps form react to elixir just to use liveview is a pointless overkill

Re: React to LiveView for Performance [audio]

#14

Post by artellectual »

egeozcan wrote: post #12

Would it make sense to task elixir and liveview to work only as a BFF with a separate backend? Does it not being typed affect productivity? If anyone with experience can chime in, that'd be very appreciated!

I recently converted an entire React / TypeScript frontend to LiveView (will open-source the project soon). I've gone much faster with LiveView. Something which use to take me 4-5 weeks to build with React / TypeScript now takes 4-5 days.

The main reason for that is, the LiveView test framework is super simple to work with. I didn't write any tests when I was doing React / TypeScript just because it seemed so cumbersome to setup. Having a test suite that works out of the box made me write more tests for my front-end.

Not having to build API endpoints for my react components is also a huge accelerator in productivity.

In the end I ended up writing less code, with more polished / well tested front-end.

You can watch the video of what I built with LiveView here https://instellar.app

Re: React to LiveView for Performance [audio]

#16

Post by deliriumchn »

jamil7 wrote: post #15

Whenever I see examples of LiveView being used it all works seamlessly but the UI always looks very simple, like basic forms, links and buttons. How does one build more custom/complex UI controls with it?

thats pretty much what happens when backend developers write UI, they mostly care about some ephemeral performance (hoping that their ui will get 1k RPS or something) while performance of existing tools (vue/react/svelte/remix/solid) is already absolutely enough even for heavy cases like high interval trading

Re: React to LiveView for Performance [audio]

#17

Post by peoplefromibiza »

jamil7 wrote: post #15

Whenever I see examples of LiveView being used it all works seamlessly but the UI always looks very simple, like basic forms, links and buttons. How does one build more custom/complex UI controls with it?

the same way you do it with every other technology

you write components for it

https://petal.build/

Re: React to LiveView for Performance [audio]

#18

Post by jamil7 »

peoplefromibiza wrote: post #17
jamil7 wrote: post #15

Whenever I see examples of LiveView being used it all works seamlessly but the UI always looks very simple, like basic forms, links and buttons. How does one build more custom/complex UI controls with it?

the same way you do it with every other technology you write components for it https://petal.build/

OK, so by mixing it with a JS library (Alpine.js) by the looks of the source code.

Re: React to LiveView for Performance [audio]

#19

Post by bongobingo1 »

eclark wrote: post #11
lefrenchy wrote: post #2

I’ve been wanting to use LiveView so bad, it’s just incredibly hard to justify to a team when React is working just fine :(

LiveView and Elixir combine to in my opinion to make the only platform that's enjoyable for front end and backend developers. Front-end developers love the LiveView model with functional components, no state, and light node.js dependency. Backend developers get a process/actor + OTP supervision tree that's second to none. Horizontally scalable, functional, and pretty simple at its core. Fullstack developers get to tr…

> light node.js dependency

Pedantic but just for drive-by readers, there isn't really any nodejs dependency. You can use it to manage JS dependencies, or you can forgo it for "vendoring" with esbuild (or bun, etc).

Liveview itself has a small JS component that is mostly transparent (socket.connect() basically). You can of course add more JS too it.

Re: React to LiveView for Performance [audio]

#20

Post by peoplefromibiza »

jamil7 wrote: post #18
peoplefromibiza wrote: post #17

Earlier quoted context omitted.

the same way you do it with every other technology you write components for it https://petal.build/

OK, so by mixing it with a JS library (Alpine.js) by the looks of the source code.

Frontend components are frontend, so until JavaScript is the only viable option, the answer is yes.

LiveView is a channel to pass data back and forth between backend and frontend in a very performant and size-effective way, that hides all the complexity involved, making it astonishingly simple to get started.

The presentation layer it's up to the developers.

Wanna react to a change?

setup a `phx-*` event

Wanna handle some custom event?

Setup a hook [1] [2]

[1] https://hexdocs.pm/phoenix_live_view/js-interop.html

[2] example of reacting to Monaco editor events: https://github.com/BeaconCMS/live_monaco_editor#fetching-the...

Post reply on HN