I am in “love with Phoenix Framework”. After the first bloody steps, I feel me comfortable and see many many advantages in the use of this beautiful framework. Now I think to migrate/realize an another project of mine with Phoenix/Elixir. BUT! I also love w2ui (Home | JavaScript UI - w2ui). It is an also beautiful framework but renders most of the things in Javascript, which means, it uses a different approach. My problem is not, that I do not have no idea how to integrate that framework, but the question is, does it makes sense? I miss a UI framework, which can display widgets (like w2ui). Bootstrap, Tailwind, all these don’t fullfill my needs. What is your opinion? Or does anybody know a good AND OPEN SOURCE UI Framework, which works like w2ui with Widgets and uses the advantages of Phoenix? Or is it worth to (or does it make sense) to migrate some parts of w2ui to Phoenix, so that the server renders my pages?
It does absolutely make sense. I use SvelteJs to display server data that is sent through a Phoenix Channel but you can also use Phoenix to provide a REST API or a GraphQL API.
@Sven, many people do that. (Integrating external JS framework into Phoenix.) As of now, in the idiomatic Phoenix way, there are no component libraries that can compete with w2UI or smelte or for that matter any JS web UI frameworks.
However, petalframework/petal_components: Phoenix Live View Components (github.com) is making a serious attempt to fill that gap in the phoenix world. If the components provided do fill your needs to certain level - I suggest, you start in those lines. Mainly because, one framework less is always one headache less. Further, you can write your code mostly in typical Phoenix way.
You can use w2ui with phoenix - normal phoenix controllers with w2ui and some json services to fetch data for w2ui. If you are comfortable with w2ui and can build rapidly - go with it.
I had supported a team who used OJET with phoenix.
All you have to do is to fit in the phoenix life cycle.
Phoenix framework as I see it has different parts to it:
Ecto: ORM kind of thing for talking to database with help of changesets
phoenix_html: to generate html and forms in templating like EEx, Heex
Sockets & Channels: Realtime communication using websockets.
Phoenix.js : javascript library to connect to phoenix sockets and channels.
Controllers and Views: Phoenix views (some call it dead views). It’s the plain old server side rendering of web pages like Ruby On Rails, JSP, Django, etc.
phoenix_live_view: Phoenix LiveView enables rich, real-time user experiences with server-rendered HTML. It shifts development from javascript to elixir world. You can get away with writing less javascript. It uses websockets from point 3.
Phoenix does not ship a js library like w2ui or jet,etc. It can work with these libraries as long as they fit the phoenix life cycle of Phoenix Views and Phoenix Live Views.
Except for Phoenix Live View, everything will work out of box without any issues (with w2ui). You don’t need Phoenix Live View if you are building SPA kind of pages with w2ui or Jet.
You can use 1-5 based on your requirements with w2ui and build web apps. As I see it - few Phoenix views, json services and w2ui are all you need.
