5 ms·

The main issue with Phoenix on the front-end is all the great component libraries target React. Developing accessible, battle-tested components (even a simple d

The main issue with Phoenix on the front-end is all the great component libraries target React. Developing accessible, battle-tested components (even a simple dropdown is much more involved than you think) is extremely hard and can drain a lot of development time. I've seen a few blogs about using React alongside LiveView--even sharing state--but I think we need something official.

impulser_ 3y ago
It actually not that hard at all with LiveView. LiveView gives you a bunch of helper functions to make it easy to build components with JS https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.html https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.htm... It might be hard if you never used JS before but it not as hard as you think once you build a component. Also Phoenix comes with common components like modals.
- sb8244 3y ago
  I did heavy LiveView development for a while. The library problem definitely exists. It's very rare to find what you want already implemented, so you have to rebuild it yourself. It takes a lot of time. What I ended up doing was loading react components using LiveView hooks and syncing state using pushed events. Saved me a ton of time because libraries were all there, and worked seamlessly alongside my LiveView app.
  - impulser_ 3y ago
    There are component libaries for LiveView. https://github.com/petalframework/petal_components https://github.com/petalframework/petal_components https://github.com/coingaming/moon https://github.com/coingaming/moon I personally wouldn't use React for components in LiveView, you are just adding more complexity to your application for no reason. It really not that hard to build components using JS and LiveView. In the end you get less complex components than what you would get with react.
    - ahallock 3y ago
      Thanks. I took a cursory look and they just don't seem as high quality as something like shadcn/ui (built on Radix UI) or Tailwind's upcoming Catalyst. For example, on Moon, the dropdown arrow support seems broken and it doesn't switch positions based on the viewport. It's these little details that matter, especially for accessibility.
    - sb8244 3y ago
      What about wysiwyg editors? Something equivalent to react-grid-layout? Date pickers? I want to build a startup, not rebuild complex components for the sake of purity. Simple components are taken care of, but I think that's not where the discussion is very relevant. I'm sorry to disagree here, but I think it's disingenuous to act like the problem is solved when there's really quite a large gap. (Btw, of course I built my components with pure LiveView when it made sense.)
      - sodapopcan 3y ago
        I always find good vanilla JS for everything I've needed (though my needs haven't been too special). Depending on what you're building you could also say: "I want to spend time building my business, not writing an API for myself just so I can communicate with my own backend." Which is not even to mention how much simpler concurrency features are. But again, it depends on the application.
        sb8244 3y ago
        True, I used a vanilla wysiwyg editor integrated via hooks. To be clear, I heartily endorse LiveView. Not using it now due to pretty heavy chrome extension needs, but it was solid. It's just rough in the "just works JS integrations" department. I'd argue you have to be really good at JS to handle any heavier library integrations.
        sodapopcan 3y ago
        > I'd argue you have to be really good at JS to handle any heavier library integrations. You aren't wrong there! LiveView was initially developed to make a certain class of web-app without needing JS. Of course, people went and pushed it further and I see it as a "only write the JS that is necessary" type of framework. I'm very fullstack-minded so this doesn't bother me in the least. I love writing JS for DOM manipulations and whatnot, I just don't want to write any business or server-side logic with it, so LiveView is a great fit for me. But even as an advocate, if your application needs to be very JS-heavy, I wouldn't necessarily recommend it. No frameworks are one-size-fits all, but of course most people want to work that way.
- ahallock 3y ago
  With all due respect, if you want to build accessible components, you cannot rely on JS commands alone. I've been down this road and ended up writing JS commands combined with JS Hooks for just about every component to get what I actually wanted.

impulser_ 3y ago

It actually not that hard at all with LiveView. LiveView gives you a bunch of helper functions to make it easy to build components with JS https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.html https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.htm... It might be hard if you never used JS before but it not as hard as you think once you build a component. Also Phoenix comes with common components like modals.

sb8244 3y ago
I did heavy LiveView development for a while. The library problem definitely exists. It's very rare to find what you want already implemented, so you have to rebuild it yourself. It takes a lot of time. What I ended up doing was loading react components using LiveView hooks and syncing state using pushed events. Saved me a ton of time because libraries were all there, and worked seamlessly alongside my LiveView app.
- impulser_ 3y ago
  There are component libaries for LiveView. https://github.com/petalframework/petal_components https://github.com/petalframework/petal_components https://github.com/coingaming/moon https://github.com/coingaming/moon I personally wouldn't use React for components in LiveView, you are just adding more complexity to your application for no reason. It really not that hard to build components using JS and LiveView. In the end you get less complex components than what you would get with react.
  - ahallock 3y ago
    Thanks. I took a cursory look and they just don't seem as high quality as something like shadcn/ui (built on Radix UI) or Tailwind's upcoming Catalyst. For example, on Moon, the dropdown arrow support seems broken and it doesn't switch positions based on the viewport. It's these little details that matter, especially for accessibility.
  - sb8244 3y ago
    What about wysiwyg editors? Something equivalent to react-grid-layout? Date pickers? I want to build a startup, not rebuild complex components for the sake of purity. Simple components are taken care of, but I think that's not where the discussion is very relevant. I'm sorry to disagree here, but I think it's disingenuous to act like the problem is solved when there's really quite a large gap. (Btw, of course I built my components with pure LiveView when it made sense.)
    - sodapopcan 3y ago
      I always find good vanilla JS for everything I've needed (though my needs haven't been too special). Depending on what you're building you could also say: "I want to spend time building my business, not writing an API for myself just so I can communicate with my own backend." Which is not even to mention how much simpler concurrency features are. But again, it depends on the application.
      - sb8244 3y ago
        True, I used a vanilla wysiwyg editor integrated via hooks. To be clear, I heartily endorse LiveView. Not using it now due to pretty heavy chrome extension needs, but it was solid. It's just rough in the "just works JS integrations" department. I'd argue you have to be really good at JS to handle any heavier library integrations.
        sodapopcan 3y ago
        > I'd argue you have to be really good at JS to handle any heavier library integrations. You aren't wrong there! LiveView was initially developed to make a certain class of web-app without needing JS. Of course, people went and pushed it further and I see it as a "only write the JS that is necessary" type of framework. I'm very fullstack-minded so this doesn't bother me in the least. I love writing JS for DOM manipulations and whatnot, I just don't want to write any business or server-side logic with it, so LiveView is a great fit for me. But even as an advocate, if your application needs to be very JS-heavy, I wouldn't necessarily recommend it. No frameworks are one-size-fits all, but of course most people want to work that way.
ahallock 3y ago
With all due respect, if you want to build accessible components, you cannot rely on JS commands alone. I've been down this road and ended up writing JS commands combined with JS Hooks for just about every component to get what I actually wanted.