I recently converted an entire React / TypeScript frontend to LiveView (will open-source the project soon). I've gone much faster with LiveView. Something which use to take me 4-5 weeks to build with React / TypeScript now takes 4-5 days.
The main reason for that is, the LiveView test framework is super simple to work with. I didn't write any tests when I was doing React / TypeScript just because it seemed so cumbersome to setup. Having a test suite that works out of the box made me write more tests for my front-end.
Not having to build API endpoints for my react components is also a huge accelerator in productivity.
In the end I ended up writing less code, with more polished / well tested front-end.
With React / TypeScript, even the setup of the test suite as I mentioned is painful, which one do you use? playwright? that one is going to be slow and cumbersome, LiveView's built in test suite does the same thing and is much more lightweight and fast. If not playwright which do you use? Jest? Vitest? this is the problem with JS community, too many choice on things that in the end don't matter to the end user.
Also the fact that you have to setup API endpoints for your data, with liveview, you have direct access to the data. You can load any state with a function call instead of having to develop a separate endpoint for your frontend, handle hydration etc... You need real-time updates? It's done out of the box, you don't have to think about it. With react, that stuff is just ALOT to do.
I ended up removing a lot of controllers from my codebase that was there just to service the react front-end. Having those controllers do not service as the "API" of the app. Specs for front-end apis and core APIs are usually quite different based on my experience.
The easiest way I can explain it is LiveView is the least friction between thought and output. React / TypeScript just gets in the way because of all the choice and abstractions you have to build for it.
Don't get me wrong, React still has it's place, there are things I would still use react for, like if I need to render something visually rich, like a flow diagram (reactflow.dev), or video component, or make something like Figma, or a calendar / gantt chart, but for most front-end UIs (95%) you just don't need React.
He did kinda answer your question with: "I ended up removing a lot of controllers from my codebase that was there just to service the react front-end. Having those controllers do not service as the "API" of the app. Specs for front-end apis and core APIs are usually quite different based on my experience"
Oh that's interesting. It won't need to remove the need for APIs (there are scripts and other clients, like embedded, that LiveView will likely not support) but cool.
Thx for your feedback. Most of the workload still happens inside a job queue however for this case we deem that it’s not necessary. Fortunately it’s working well for us, the task async part is also adaptable if the problem becomes more complex than what it needs to be then we can handle those cases accordingly. However we still believe throwing everything in a job queue isn’t always optimal either.
For error handling when the task fails it sends a message to the genserver we can also use that opportunity to handle retry, or do a strategy change where after first failure we throw it into a job queue.
This way we optimize for user experience and at the same time have a robust strategy for handling failure. I guess that can be another blog post on its own.
Thx! For networking, it's all handled by LXD, it supports fan networking out of the box. All PAKman does is build the package.
Once it's delivered the entire runtime / lifecycle / upgrading / bootstrapping is managed by LXD/LXC containers.
It's definitely possible to open up PAKman's support for other build environments. I mean at the end of the day it's just an alpine linux package. As long as you can use alpine's package manager it should work.
https://instellar.app can also serve as a repository for your package. This was an option we considered to enable earlier, but figured people might just want a fully integrated solution.
Absolutely, Zack. The work you've done with PAKman is seriously impressive. The efficiency you've managed to achieve with Alpine packages and LXD seems to be a real game-changer.
I'm really curious about the team behind this. Is this a solo endeavor, or do you have a team backing you up? Handling everything from building the system to managing the lifecycle with LXD - that's a lot of ground to cover.
If this is a solo project, it's nothing short of astonishing. The innovation, the effectiveness, and the potential of PAKman - it all points to an immense amount of work and dedication. Hats off to you!
The idea of instellar.app serving as a package repository is very interesting as well. It makes perfect sense that you'd initially want to provide a fully integrated solution. It fits right in with the efficient, streamlined approach you've taken with PAKman.
Either way, I'm definitely looking forward to seeing what comes next from your work. Keep it up!
In this post I show you how our product instellar.app handles multi cloud deployments. Instellar also makes it easy for you to manage multiple installations of your apps.
Installations basically turn your single tenant app into a multi-tenant app without having to manually code your app to support multi-tenancy.
We also give you a sneak preview of some of the work going into making Rails and Python based Apps compatible with Instellar.app!
I have been working on https://instellar.app to solve this very problem. It allows you to use s3 compatible storage and your compute / database provider. So you can use hetzner or digitalocean or AWS or google cloud, anything you want. For your database you can use digitalocean’s managed / Aiven.io / RDS / Google cloud SQL. This tool brings it all together and enable you simply focus on shipping code.
It does load balancing / automatic ssl issuing out of the box. It will also allow you to scale horizontally. I’m working towards making it public soon.
DigitalOcean has been a good companion to Linode. It seems like many of the offerings are either on par or better, though some prices are a little higher.
May I ask what backend platform / language are you using? I ask this because I've been developing something which is due to be released within Q1 of this year, and would like to understand my target market.
Currently my solution works for Elixir / Phoenix and static pages. But I'm working on expanding to ruby / rails and nodeJS based frameworks.
I'm guessing Apple is not going for quantity but quality. Like everything else they do. Once they figure out what gets them high quality then they figure out how to do it at scale.
I see this in all of the things they do.
The one thing you see from Apple is though. Once they choose to do something they don't give up easily. Case in point Apple Maps. When they launched it they met with a lot of criticism. Now they're going back to the drawing board and re-doing the entire thing.
They really don't give up. I admire that about them.
p.s.
If someone hasn't watched Foundation on Apple TV+, I highly recommend it.
Yes perseverance and quality, signs of great character.
Also they don't easily bend to the dark side with success - unlike most other tech companies that first win the user's trust to betray them later by focusing on profits at all costs.
Its interesting how different tastes people can have. I, for one, couldnt stand Foundation for more than three episodes. Severance, on the other hand, is like a one, series-long, good Black Mirror episode.
