I understood the first part where you integrate and liveview with web components, however you lost me on the second part.
If you ditch liveview in favor of graphql and houdini, how is this different from having to maintain 2 separate applications?
D4no0
adw632
My point is the complexity is about the same using a JS library vs Liveview with the approach I am using.
Design System, Houdini GraphQL on the client, Ash on the backend.
Using Svelte JS with Houdini GraphQL is less friction vs using LiveView because the web component wrappers exist vs having to create my own, but I still have some amount of effort to describe the GraphQL fragments on the client and server, and the counterpoint with LiveView is that I still have to think about routing on the server and mediating between my domain and LiveView, handling events and state.
There is not much separating the two options and it comes down to some other factors:
- Two languages vs one
- Can easily implement PWA with Svelte or React
- LiveView connection handling on the browser is flakey. I have concerns with a jarring LiveView issue “finding the internet” after switching tabs in mobile browsers or open close the device. I’ve seen it on multiple occasions with my own prototypes and on other LiveView sites too. There are persistent GitHub issues that are closed but the issue is not fully resolved.
- Higher availability of front end developers for svelte or react vs Elixir Pheonix developers.
- Given the Carbon design system and web components I don’t need or want a front end developer “with flair and creativity”.
- Avoiding a specific role of front end only developer whilst bootstrapping can allow my team to be more general / backend focused. Anyone with Elixir experience can be reasonably productive with UX guidelines.
- A UX developer will consider usability and UX factors far more than a backend developer who naturally dislikes doing front end work.
- If I separate the front end and backend then it is possible to develop features faster. This entails describing the wireframe/prototype UI using a prototyping tool (eg Storybook and UXPin Merge). Then front end and backend developers can work building out their respective sides, with the backend team focusing first on describing the domain model and GraphQL contract in Ash to get a documented API interface.
So its hard to say right this minute where the chips will land. I have a couple of experiments in progress to help me confirm the most productive way forward as it impacts hiring and planning. I have an each way bet in both approaches but right this moment Svelte+Houdini with Ash+Absinthe is looking to be the better choice than LiveView. It may end up that we just use Plug instead of Pheonix as there isn’t much need of Phoenix once it’s GraphQL and some static assets.
4
woylie
Some of the preceding messages sound a bit negative, so I feel like I want to even out the sentiment. We’re pretty happy and productive with LiveView, even without using any component libraries or CSS frameworks. Handling the whole feature from back-end to front-end helps us to keep the user’s needs and the end goal in mind throughout the development process. We avoid any back-and-forth between front-end and back-end developers, which makes it much easier to quickly experiment with different approaches and optimize the feature with our UX designers. We’re usually able to onboard new developers without or with little Elixir or LiveView experience quickly.
6
shamanime
I also keep reading all over the forums how there’s a huge gap in X, Y and Z with LiveView. I find it hard to reason with it.
With 3 “full stack” developers we’ve built and maintained an app built entirely with LV since v0.1.0. Since then A LOT has happened with the ecosystem (for the greater good) and besides some upgrades being time-consuming, it’s been a great ride.
We own CoreComponents (and a bunch of other component modules) and I don’t see the problem in reading the diff and updating whatever is necessary in our app - it’s not like it requires constant updates as it’s just a headstart for new apps, eventually it’ll be custom enough for the app’s needs. The app went through own-rolled CSS to Bulma and now Tailwind, all went fine.
We have no complaints from clients about the “We’re trying to find the internet” issue (well, we had once for a client that blocked WebSocket connections).
It does have a lot of accessibility features and tweaks. Enough to grant us contacts with schools districts where it’s required (ed-tech field).
If we were to start a new project now, porting most of the components would be easy. So yeah starting a new project won’t give you all the bells and whistles one would want, but also for many apps and POCs you don’t need the full package. By the time you need everything you’d have sorted it out with your team.
There’s tools around that will get you very far beyond the starting skeleton, like PETAL and friends, and if they help throw them some money. Extend where they don’t.
I have past experience with Ember, Elm, React and Vue both with Rails and Phoenix, and I’m very sure we wouldn’t be able to build everything we’ve built with such a small team and keep shipping features while maintaining everything up to date if we were using anything else.
I can’t see the tooling (or the lack of it?) we have right now being a problem or getting in the way of building a successful business/app.
9
sodapopcan
I’ve been following along and trying to refrain from saying anything but I can’t resist at this point. I think has gone semi-off topic into adoption vs “should I use LiveView or Vue?”
As far as adoption goes, I do think the pre-1.0 label is relevant as it is a marker used by the team for when it’s considered truly “ready”. The Elixir ecosystem in general seems to favour a slow and steady path to adoption. This is particularly evident in telling us that we may get types sometime within the next five years but there’s a chance we may not get them at all. This is in the face of not only a strong desire of a good chunk of the current community asking for it as well as many outsiders claiming this is the one blocker for them even trying the language. All that to say that while we are certainly missing a state-of-the-art headless UI lib, there is precedent in why one hasn’t been pumped as quickly as possible by the core team.
The other thing at play here is that LiveView is very much a “full stack” developer’s framework (as touched on by @shamanime). I’m not certain that it’s ever going to try and be anything else? I honestly don’t know. Personally, I have never used a truly headless UI system in my career, though I’ve been sympathetic to @adw632’s desires for one now that I’m working on my first contract since my spaghetti PHP days. But ya, this has been touched on already but with LiveView there is no “web api” layer between your front and backend (hopefully you have some hard boundary, though, like via contexts) so seeing that as a positive is a big factor in choosing LiveView.
I had a bunch of other stuff but quickly:
I build up my components from CoreComponents and feel no pain but I do think it might be a bit of a mistake for two reasons: The main one is that many people don’t seem to understand that it’s meant as a jumping-off point that you can edit all you want or throw away entirely. I don’t have any examples off-hand but it seems to be hard to convince some people of this. Of course, this means you can’t use the generators though that’s another issue, I’d say. Secondly, I don’t think it’s great that it so heavily integrates Tailwind and there is a bit more work involved in remove it than simply --no-tailwind. Now don’t get me wrong, I’m a Greying Beard who’s been enjoying writing CSS since 1998 and the moment I saw 100% ultility classes in action I was like, “I want that! NOW!” There is was no period of “you just need to use it to understand it” for this guy! Seeing was believing! But I respect choice as well as there are times where Tailwind doesn’t fit the bill.
@hubertlepicki I really like your post and it has a lot of good points. The one thing about it is that it’s very much from the perspective of someone who already knows JavaScript. This is somewhat fair since everyone in web development knows JavaScript to some degree, but there is an equally long laundry list of stuff to know in JS land if you want to become proficent that perhaps you take for granted. For instance I wouldn’t claim that the JS event loop is all that much easier to grasp than message passing when learning from scratch. “Async by default” is certainly more complicated. And when it comes errors, no matter how much they’ve improved, JS errors are still horrendous. No matter how many times I spend a few days working solely in JavaScript, as soon as I go back to any other language and get my first error I get this massive wave of excitement when it actually tells me exactly what’s wrong and exactly where. Finally, mentioning that you have access to things like GraphQL—but if your app fits LiveView, GraphQL won’t even be in the equation.
Ok whoops, that wasn’t “quickly” at all! / 
4
hubertlepicki
“Async by default” is certainly more complicated
Oh yes, that’s correct. I really dislike writing “business logic” in JavaScript for that reason. Anything that involves some sort of I/O becomes pain in the bottom, and unreadable at that as well. It’s been designed to handle clicks in the browser and not complicated business logic, and if you have a look at server code for Node.js or Next.js or otherwise JavaScript web servers it’s some scary stuff to see.
I wouldn’t want to rely on JavaScript with all its flaws not to create bugs, security issues by omission by developers mine or otherwise, and it Elixir is just way more stable language and environment to do so.
2
D4no0
From my personal experience, I always found developing with liveview faster, I have been using it for most of the projects I worked at since liveivew 0.1. Even with the lack of a good component system, which for me personally is an annoyance because I hate creating designs like a cavemen in a technology of the past, I found it much more enjoyable and fast in the overall picture.
I think the biggest time killer of frontend applications is having to maintain the communication contract. It does seem that graphql is a popular choice nowadays and more efficient than writing custom http endpoints, however this is still the prominent place where a lot of development time is sunk.
I think that by the time you will adapt your application to be PWA, you would have long implemented the functionality natively. I would classify this as people claiming that writing JS on both frontend and backend requires a unified knowledge set, when in reality you have 2 separate runtimes with different constrains and capabilities.
I don’t think this should be a concern worth thinking over. The same could happen with a front-end, where you will timeout a request and place the application in an unknown state or crash it entirely, at least with liveview you have fault tolerance in this case.
Indeed, however the other reality is that finding a few great elixir developers will allow you to replace an army of JS developers. I never worked in teams with a big number of developers, however I think that small focused teams always outperform big teams in terms of performance and quality.
This is a great reason. Developers that are invested fully into the product, will also start to have insights and make correct abstraction and performance decisions, creating a great product is a team game.
I find this argument strange. Can’t you hire someone specializing in frontend development and have him build those things on server-side? I mean he has access to heex templates (that are not much different from what front-end frameworks use), css and js. Make him build everything as components with a good API and there you have it, he writes minimal elixir and you have your divison of responsibilities.
6
sodapopcan
All your points resonate with me very much. It’s just at the end you threw out a pretty big “can’t you just” 
I think finding a good frontend developer who is willing to have a hole on their resume missing some front-end JS framework would be pretty tough. Not impossible, but pretty tough! I could be wrong (in fact I hope I’m wrong).
I will also say that if you want a PWA web app—ie, you know many of your users will have JS turned off and won’t have a native version—LiveView is certainly not the way. Rails’ Turbo is actually really good for this. Remix does this, I believe, but then as @hubertlepicki mentioned, you now have your business logic in JavaScript.
But ya, the whole reason I’ve taken interest in this thread is that I’ve been feeling the pain of not having a headless UI. I’m eager to bring Doggo into my next personal project. Unfortunately, I don’t have time to incorporate into my current one.
2
adw632
I really think Doggo will be the start of good things for the LiveView ecosystem.
Similar to @sodapopcan, if I hire a front end developer, it would be because they are experienced and efficient in the front end framework I would be using. It’s not my preferred option and as I stated previously a backend developer is far more useful. Liveview is the solution which avoids the front end JS tar pit and is why I have been experimenting with web components and design systems as a way forward.
Believe me when I say I agree whole heartedly, I’ve never wanted to be in JS or TS land. I chose Elixir because the paradigm is very safe and side effect free.
Yeah I already looked at the options and accessibility and keyboard navigation was not where it needed to be.
Yes this is the benefit of the server rendered approach and cutting out the middle layers.
Depending what the experiments are, prototyping tools can also save development resources whilst the designers play what if
I’ve also worked on larger projects and teams where you did need multiple front end teams and a backend team. This was because there were native clients in the mix as well as web so it made sense to expose an API on the server only. Fortunately that’s not my use case currently.
1
D4no0
I guess you are right in the current reality, which is sad, the resume matters more than the actual work that was done and the quality of it.
I agree, at least when starting the risk should be minimized. No matter the final decision, I hope that everything will work out for you, as technology choice is only a small part of what lies ahead when starting something from scratch, nonetheless very crucial.
0