31–40 of 48 posts
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?
When I was looking into Phoenix all routes, no matter how nested, had to resolve to single controller. That meant that controller for path `/user/settings/privacy` was also responsible for getting data to display users sidebar.
Earlier quoted context omitted.
Yeah, that sounds so strange. I've had thousands if not tens of thousands of components, reacting to objects that contain millions of data points that felt native.
With 6x CPU slowdown (although not enough anymore) or a "normal" computer? React isn't exactly fast, in fact it's pretty slow. Developers just think it's fast because they have $4000 Mac Book Pro's.
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 :(
Earlier quoted context omitted.
With React / TypeScript, even the setup of the test suite as I mentioned is painful, which one do you use? playwright? that one is going to be slow and cumbersome, LiveView's built in test suite does the same thing and is much more lightweight and fast. If not playwright which do you use? Jest? Vitest? this is the problem with JS community, too many choice on things that in the end don't matter to the end user. Also…
But many already have API endpoints because you have to serve native apps too. My question was, does LiveView also help you in a Backend-for-Frontend case?
Earlier quoted context omitted.
But many already have API endpoints because you have to serve native apps too. My question was, does LiveView also help you in a Backend-for-Frontend case?
This is why I'm eagerly waiting for LiveView Native. That will remove the need for front-end APIs entirely.
Earlier quoted context omitted.
Yeah, that sounds so strange. I've had thousands if not tens of thousands of components, reacting to objects that contain millions of data points that felt native.
With 6x CPU slowdown (although not enough anymore) or a "normal" computer? React isn't exactly fast, in fact it's pretty slow. Developers just think it's fast because they have $4000 Mac Book Pro's.
If you are only re-rendering what is required, it's just a webpage at rest.
Is it possible to get on Phoenix nested controllers? Like in remix.run, where for each route segment we get one controller/view. It’s really generalised version of layouts. When I was looking into Phoenix all routes, no matter how nested, had to resolve to single controller. That meant that controller for path `/user/settings/privacy` was also responsible for getting data to display users sidebar.
Earlier quoted context omitted.
With 6x CPU slowdown (although not enough anymore) or a "normal" computer? React isn't exactly fast, in fact it's pretty slow. Developers just think it's fast because they have $4000 Mac Book Pro's.
Commercial grade apps where I do throttle CPU. If you are only re-rendering what is required, it's just a webpage at rest.
As someone who has used React since 2015, and has worked on tons of React apps, with a wide range of team members and skill level, this is easier said than done. First of all, some developers just don't "get" React. The framework has a lot of foot guns, especially around performance. The most productive I've ever seen a team is with Mobx, which does fine-grain updates out of the box if you model your state correctly.
Getting great performance in vanilla React requires constantly thinking about where state lives, lifting, lowering state, composition, and memoization. It's not exactly fun, requires a ton of diligence, and most developers can't architect a simple table that has interactivity that just re-renders a single row instead of the entire table.
It's not the fault of the developers, it's the framework that has poor performance, has a team that doubles down on awful architecture, and doesn't have the empathy of what it's actually like working in React day to day with just normal developers.
Compare this with Solid or Svelte, which have fine-grain interactivity, and you don't have to refactor your components changing where state lives constantly. You can actually describe your UI with components based on where they should live, not how they should update. Contrast that with React, which requires you to describe your UI and state by how it's updated, not where it makes sense.
In a world with advancing AI and great new frontend frameworks, why are we specifying memoization dependencies manually? It's a joke. The model of a component executing top-down every change has to go. The react-forget compiler has been in the works for years at this point. I've moved on, so should you.
I could rant on this for hours, but that's the gist.
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?
I guess it depends what you mean by "complex ui controls". You can add "hooks" that attach to any normal element. Those hooks have access to push/pull data/events down the socket, so you can basically set up listeners on any element to trigger what would be your normal REST calls. In that respect you can hook your into integrating with a liveview process, but obviously it wont receive any DOM difffing etc. If your en…