You are right, poor phrasing on my side. Instead of focusing on C appearing twice, I should rather focus on how complex the expansion is, meaning that everytime we have to expand the BDD (which we need to do during subtyping or emptiness for example), we end-up doing a lot of repeated operations. I will push an update, thank you for commenting.
Kudos on the article! My understanding on BDDs is sadly not as strong as I would prefer it to be, so I'm guessing I am not quite caught up on how they are being used here.
I think I was expecting to see the algorithm for merging multiple BDDs that I saw in Knuth's work. Though, in that regard, I would expect a ZDD approach would be a lot easier to start with. That or you would have to make the BDD to merge be a big chain of every variable before the stuff to be merged where true goes to BOTTOM, and false goes to the next variable before new first to merge.
Again, kudos on this. I do look forward to trying to understand it more!
LiveView was still before v1.0, hence the churn, but Phoenix itself did not introduce breaking changes since v1.0, released more than a decade ago. Our skeleton for new applications change, as best practices around web apps are still evolving, but it is completely up to you to migrate. As a reference point, most other web frameworks have gone through several major versions in the same time, changing how new apps are built but also breaking old ones.
The idea that Phoenix is also mostly macros does not hold in practice. Last time this came up, I believe less than 5% of Phoenix' public API turned out to be macros. You get this impression because the initial skeleton it generates has the endpoint and the router, which are macro heavy, but once you start writing the actual application logic, your context, your controllers, and templates are all regular functions.
> The idea that Phoenix is also mostly macros does not hold in practice
no, but the Framework does push you into using them. A good example is the `use MyAppWeb` pattern. That's a macro that nests other macros. the good news is that you can pretty much excise that and everything works fine, and LLMs have no problem even! (i think they slightly prefer it)
a few cognitive pain points with phoenix macros:
plug: (love it dearly) but a bit confusing that it creates a conn variable out of whole cloth. a minor complaint. worth it, otherwise.
phoenix.router: is a plug but isnt quite a plug.
anyways that's it! the rest is ~fabulous. i think to find a framework where you have two minor complaints is a blessing. remember how activerecord automagically pluralized tables for you?
> I believe less than 5% of Phoenix' public API turned out to be macros.
The idea may still be right, but I'm curious if that addresses the majority of the public API that users are greeted with. I have unfortunately not written Elixir in a few years (cries), and I've never fully grokked Phoenix, so perhaps I'm still wrong.
I hear you. I'd love to integrate with whatever model subscription is available but it seems using Max outside of Claude products is against their terms. I suggest reaching out to Anthropic and letting them know you would like to use your Max subscription with other coding agents.
Can you ping me on Tidewave's Discord or send me an email (you can find on github.com/josevalim)? We did test it on https recently and it worked fine, so there is something more going on. I'd be glad to see this ironed out!
As you said, the best would be for you to give it a try and see the benefits in practice (if any). Beyond that, I can add to two points you brought up:
First, Playwright MCP is really not enough. For example, imagine you are building a project management software and you are working on a feature for transferring tasks between projects. Testing this feature requires at least a user who is admin and at least two projects. When it is time for Playwright to test this feature, you need to automate the account creation, then it has to set up two projects, add the task, etc, and it often gets stuck.
When you are using Tidewave, you naturally do this setup as part of your development, which Tidewave has direct access to during tests. So it just interacts with the same page. Furthermore, if you see any bugs or places you could improve, you can't really tell Playwright or regular coding agent to fix them, you have to translate what you want. With Tidewave you just point and click and it works across browsers. I talk more about this in the announcement post: https://tidewave.ai/blog/tidewave-web-phoenix-rails
Other than that, I am really curious about the handoff between Tidewave and the editor that you mentioned. At some point, you will need the editor indeed, but how to best do this transaction? Should you be able to review and do tiny tweaks within Tidewave first? Regardless, moving the agent to the browser for web applications bring enough benefits to justify going one lever higher. :)
Playwright MCP has a mode where it can run as a Chrome Extension, which allows you to use it on your active browser session. Not sure if you can do point and click to communicate but it covers the development setup and login bit.
We are working on React integration, first within Rails and Phoenix, but then also standalone. How are you serving/running your React apps in development?
It is both. There is a Tidewave server (which will play a more meaningful role once we introduce agent coordination) but we also hope the limit will be enough for people to see value in the tool and convert into paying users (so we can continue improving it).
reply