We're in an interesting time where my framework/stack choice is now much less dictated by existing engineer expertise and more about fundamental capabilities in the framework and stack themselves.
I ended up building an agent orchestrator in Elixir and Phoenix, not because I love working in Elixir/Phoenix (I do, but I just don't write code by hand anymore), but because the BEAM/OTP capabilities genuinely worked more reliably and elegantly to solve our orchestrator challenges.
I see projects like Hologram potentially showing up as the right tool for the job much more often. The barrier to picking up a new tool/framework/stack is so low these days with agentic development, and it comes down to speed, capability, and reliability.
Ironically, I don't think agents are going to suggest anything like Hologram on their own, so it is still down to human engineers to push it into common use. That might be the biggest barrier to adoption: overcoming obscurity so that LLMs suggest it as a solution.
My framework/stack choice on the other hand is now much more dictated by the quantity and depth of existing literature on the internet about that stack.
does that really help? I have had llms fumble pretty simple stuff in html/css and probably that's what there's more information on the internet, while with simple packages/languages with clear cut semantics it seems to be much better, even if off some samples pasted into context.
I would be really excited to see this moving forward - saying as someone who uses Phoenix regularly (and likes it for the most part) and has used react, vuejs, and so on - even at the stage it's at is already a very promising DX with what looks like a very reasonable roadmap and clear intent.
Having elixir apps that can work seamlessly local-first would be amazing and take care of one of the only areas where phoenix can't completely cover out of the box, making things that today take a lot of glue code, and error prone, a matter of a few declarations.
We're in an interesting time where my framework/stack choice is now much less dictated by existing engineer expertise and more about fundamental capabilities in the framework and stack themselves.
I ended up building an agent orchestrator in Elixir and Phoenix, not because I love working in Elixir/Phoenix (I do, but I just don't write code by hand anymore), but because the BEAM/OTP capabilities genuinely worked more reliably and elegantly to solve our orchestrator challenges.
I see projects like Hologram potentially showing up as the right tool for the job much more often. The barrier to picking up a new tool/framework/stack is so low these days with agentic development, and it comes down to speed, capability, and reliability.
Ironically, I don't think agents are going to suggest anything like Hologram on their own, so it is still down to human engineers to push it into common use. That might be the biggest barrier to adoption: overcoming obscurity so that LLMs suggest it as a solution.
My framework/stack choice on the other hand is now much more dictated by the quantity and depth of existing literature on the internet about that stack.
does that really help? I have had llms fumble pretty simple stuff in html/css and probably that's what there's more information on the internet, while with simple packages/languages with clear cut semantics it seems to be much better, even if off some samples pasted into context.
Did you use something like Jido or roll your own out of curiosity?
Hologram is a joy to work with. Local first support will take it to the next level. Bart is cooking.
I would be really excited to see this moving forward - saying as someone who uses Phoenix regularly (and likes it for the most part) and has used react, vuejs, and so on - even at the stage it's at is already a very promising DX with what looks like a very reasonable roadmap and clear intent.
Having elixir apps that can work seamlessly local-first would be amazing and take care of one of the only areas where phoenix can't completely cover out of the box, making things that today take a lot of glue code, and error prone, a matter of a few declarations.
Would be great for reviving LiveView Native. Perhaps Dockyard / Brian Carderella might be interested.