878 karma · joined May 11, 2014
[ my public key: https://keybase.io/james2doyle; my proof: https://keybase.io/james2doyle/sigs/3yx8K6dwFtyhoCBUzraSx5DeL40Y5Zj1_WDpvmmTWak ]
I also bounce around to lots of different models. Some are cheap and dumb, some not. When unfamiliar with a model, the last thing I want it to allow file edits and destructive tool calls. Having a mode explicitly for that is helpful.
I always found that those Mimo models to be really good at tool calling and following instructions
I have been doing this test for about a year now. I run it on different harnesses and apps as well just to give me an idea of what they differences between them might be. Since I have been running it for a while now, I have a good sense of the correlation between this output and how the model will be on the rest of the things I want it to do.
I would say that almost every model (just tested Mercury 2.5 Preview and IBM Granite 4.2-8b) are pretty much the same on this task. Some are more diligent with how many sources they go out and get, but for the most part they are all very close in quality and will follow the instructions very well.
So saying "everything struggles" with that has just simply not been my experience.
I looked into this when I tried HTMX 4 on a project earlier this year. I actually found that https://alpine-ajax.js.org/ was smaller than HTMX while providing all the features I needed. It is one of the sanctioned projects they link to so I felt good using it
HTMX has a whole section on their site dedicated to reasons not to use HTMX: https://four.htmx.org/essays#counterpoints
Alpine Ajax is actually promoted on their site as an alternative option but to stay within the HATEOAS universe: https://four.htmx.org/essays/alternatives#alpine-ajax
I tried building something more than a like-button or simple search. It wasn’t that easy to wrangle once it got more complicated.
We could have paginated the results, but the client didn’t want that either because you are just promoting the results that happen to land on the first page. You also can’t just CTRL-F and find things that way.
Now, those could have been loaded in dynamically. That isn’t a free solution either though. It means adding a new endpoint, with a new partial, another request-response round trip, plus the error handling in case it fails, etc. etc.
I just ended up being more practical to go with a reactive JS form component to reduce the HTML being sent back and forth.
Say you have a clothing store listing page and you filter for only "Shirts". Well, the filter that has "Material" might remove (or disable) the option for "Denim" because that is only for "Pants". So that state needs to be computed some where. My thought was, "Ok, refetch the whole thing with the updated options within the form (disable options that can’t be combined together) + the product results for those filters". But that was just a lot of HTML to ask for after each change.
So decoupling it so that the form never refetched, just the results, made it a lot snappier. But you still have the form state issue where you want to update the options based on selections. So the form became a little Alpine data component and the results stayed as an HTML partial.
The gist of what I was saying was that once I had a more complicated experience, the benefits of just fetching a fresh partial each time started to dwindle. The HTML response grew, I needed a bunch of inline handlers to patch over some state issues, as well as the complexity of the template, just started to be too much. Really it was the Alpine part that I was missing. Simple class toggles, easy way to toggle aria attributes, show/hide for elements, and reactive/computed values, were the things I needed to get the results the client wanted.
If I was building a simple search input + results, I would use HTMX all day. These forum people make it work and that seems like a great use case. But it just didn’t fit with a more sophisticated form that had dynamic options plus a large results display and the burden of a slower query to just get the data.
It was only the right side results of the experience that needed to be refetched when the form changed.
But in HTMX, you are expected to just send the whole dang thing back for every change. Makes sense for a like-button, a dialog, or even a classic form submission.
My refactor cut the HTML response by about 70kb and that made a big difference. The form became fully static and I had a simple Alpine data component that would just sync that state with the URL. Still used a GET on the form and still used the same partial endpoint. Just way less HTML to wait for.
I think dynamically fetching results (ala infinite scroll) would have been more complicated to build. I would have had to add an intersection detection (HTMX 4 has that) to trigger the form/request again, but with an ever increasing chunk offset slice. I also need a way to track that state as well. Considering I had one big HTML response, I don’t think I could have done that efficiently without splitting it anyway. Even if I could "pluck" the results I needed from the HTML response, the penalty of waiting for the response was the factor.
If you have any links to some demos where there is something like that, I would appreciate it.
All that being said, the count of items actually isn't the most relevant part. The most relevant part is the amount of HTML per single result. If you have a sophisticated card component (a title, a description, images, a table of information inside of it or complicated layout) just loading six cards could end up being hundreds of HTML elements.
So even if you lazy loaded elements in chunks, those chunks are still gonna take a while to fetch given the size of the HTML. You also break CTRL-F-ing since those results don’t exist in the DOM until you trigger their fetching code. Same problem as classic pagination.
I would have to completely refactor my entire experience regardless because if I want to lazily load the cards/results gradually, I would have to split up the layout to make it more efficient.
So my approach to shrink the HTML response was to break it up the "live" section to just the right half.
The problem I had was that the entire experience became really slow when I had it all working together as one "response". Sending back all that HTML for an entire form with some large select lists as well as the response of results became noticeable laggy when there was more than a half dozen results.
I ended up switching to Alpine Ajax (https://alpine-ajax.js.org/) and pulled the form out of the response and just used a local x-data on it to track the state. This greatly reduced the HTML I needed to send back to just the list of results. I did make the form a bit more complicated but the experience felt a lot snappier. Both versions just synced the form state from the URL and kept the initial render as full HTML from the server.
I found that Alpine + Alpine Ajax was SMALLER than HTMX 4 even though (in my opinion) it offers a lot more features in a more approachable and intuitive way if you need to do interactivity and don’t want to trigger a request just to toggle some classes or attributes. Of course you can use both together (I started down that road) but you are mixing worlds and making the bundle size bigger at the same time.
I still like HTMX and will probably use it again. I just found that with an interactive experience like a product listing page, where the HTML response was quite large/expensive to fetch, it wasn’t the best choice for that.
This page also has 26 emdashes on it. For a page that isn’t an article, that seems pretty high.
On those measures it is better.
You can use any model you want but it is really tailored to work well with the Deepseek duo
The rollout of Mythos was clearly manufactured to stoke the fears of companies that didn’t have access to it. They also bragged (for Fable) about how they "ran an external bug bounty that produced no universal jailbreaks in over 1,000 hours of testing" only for it be circumvented almost immediately.
So them standing on the high horse and saying it is _so powerful, yet so safe_ only to have that blow up in their face just made it that much easier to make an excuse to do this. Again, not disagreeing, but they made themselves the tall poppy here.