The question is - how does the React component model (or its JSX representation) apply in this particular context - other than appealing to developers who are already familiar with it (for better or worse)?
I understand where you’re coming from but I think there’s a more productive way to approach and enlighten each other here.
Both frontend driven and backend driven applications both have learned a lot from each other over the years. It’s now common to server side render your frontend app, we have very sophisticated compilers in frontend development, and we have things like Typescript which mimic the type of languages you could only use in backend driven applications years ago. On the other side of things, Phoenix Live View is a “perfect” example of something that went “ok this SPA stuff on the frontend is pretty cool, let’s take some of this”.
Prior to Live View releasing, if someone came in a backend forum and said “hey I developed this library for doing SPA inside of rails” it would have been incredibly common for at least a couple of people to say “IMO SPA’s are incredibly complicated & complex, and [insert framework / language here] renders fast enough”. The thing that none of these responses understand is that regardless of the downsides, SPA’s (especially a couple of years ago) were unequivocally better than alternatives in “some aspects”.
wrongspotting: the idea of taking someone’s feedback (or idea, or whatever) and saying what’s wrong with it, vs saying what’s right with it, and understanding the perspective.
Maybe there might have been more work to bring spa type features to broader applications (unpoly, alpine, phoenix live view) if there was a broader recognition that there WAS things that spas were better at, rather than just saying they’re wrong for x, y, z reasons.
Here’s my point: Rather than picking apart the model of React (and even componentization), let’s talk about what it does well. Let’s talk about the types of applications we’ll be creating with Phoenix and Phoenix Live View in 3 years time that may pull more inspiration from the frontend world. Let’s ask React devs for code examples of what things are easy to pull off in React that seem like it wouldn’t work well without the component model, and then show them examples that we think mirror that. It’s not enough to say “you’re trying to do this, reconsider because of these principles”. That doesn’t bridge the gap, and it also ignores the great history of both platforms borrowing from each other.
Lastly: the Elm talk you cited, when it talks about React components not scaling, it’s important to understand what people in the Elm community are referring to when they talk about components. Elm commonly talks about the idea of having local methods, state, and views combined being really bad, which is what is generally meant when this is discussed. The important thing to note, is that while React allows you to this, it doesn’t necessarily “mean” that a react component will “absolutely” have states or local methods. Entire React component libraries have been created without any of this.
In their original post, the tag line for the library is “html component library that uses JSX like syntax”. There’s no mention of local methods or state, and if you look at the examples, they’re strictly using html, so it makes me believe you merely saw “react” and “components” in the title of this post and made an entire response that isn’t really applicable here. React components, when used at a rudimentary level, can mostly resemble partials in Phoenix. The only real change here is the DX of using partials vs the JSX type syntax.
I’d also have to subsequently ask you how you’re handling accessibility in your applications, as my general experience is that people that shun frontend component models don’t end up handing the many concerns of accessibility as thoroughly (and this is generally a frontend concern, and frontend people generally reach for components to encapsulate the needed logic).
