A good front end dev should be able to re-organise elements and styling in either a heex template or inline heex - they don’t need to worry about event handlers, assigns, elixir code etc. Unless you’re happy to take on a lot of non-value adding work integrating their styling into your liveviews / components, you’re going to have to get them comfortable running Phoenix and editing directly in the project.

Communication is also key - define the high level UI “scaffolding” (e.g. hierarchy of controls) together, then you can work on the functionality and they can work on the styling.

FWIW - I really, really dislike fighting CSS. But I’ve been down the path of working with a standalone HTML / CSS developer and integrating their work. Learning Tailwind CSS and implementing directly off Figma designs was less of a pain than integrating their work. Best situation is definitely someone who loves the CSS stuff and can work directly in the Phoenix project.

I also have to say the quality-of-life improvements from the recent Phoenix component approach are amazing for the CSS-challenged, like myself. You’re definitely taking the right approach with learning about LiveView & Components. Tools like a Storybook for LiveView (https://phx-live-storybook-sample.fly.dev/storybook/welcome) may be helpful to build out and visualise the components you need. It’s much better to start out this way rather than trying to extract out big chunks of copy-pasted HTML/CSS later.

Just a note that Tailwind is only the default for the Phoenix generator. As far as I know, there’s no Phoenix-related downside to replacing Tailwind with something else, if there’s something else that you or the front-end dev prefers.

As far as tips, I’d suggest:

1. Set up auto-deployment to a preview environment to make it easy for both of you to see changes.

2. Write a lot of UI tests (which of course are super fast with LiveView because there’s no need to involve a web browser).

3. Use separate identifying attributes in your DOM nodes for different uses. That way, the two of you will be less likely to interfere with each others’ domains (front-end vs back-end). I reserve id and class attributes for CSS (even if you are using Tailwind, you might want to throw in an ID or class here and there), data-* attributes for JavaScript (even if you think you’ll only be using LiveView, you might need to have a little JavaScript eventually), and test-* attributes for tests for find DOM nodes (I mostly use test-role and test-id attributes for my testing).

Just to be clear, that post refers to integrating the feedback styling to all of bootstraps specific form input styles, but this is the only css rule you need to get basic showing/hiding of validations (it’s what we generated in the app.css of Phoenix 1.6 apps for example):

/* LiveView specific classes for your customization */
.phx-no-feedback.invalid-feedback,
.phx-no-feedback .invalid-feedback {
  display: none;
}

Then any container with the invalid-feedback class (or whatever you want to call it) would be hidden until the input is interacted with.