dphuang2

I am curious about the exceptions. Is *anybody* using an agent framework with large production usage? I suspect no, but curious to see if anybody on HN knows otherwise.

Konfig founder here, 100% agree. I wouldn't recommend anybody to actually try to decipher/deploy Konfig for their own use. I will say that one of our customers was able to deploy our docs platform for themselves while they find a way to deal with the blowout of Konfig shutting down.

why, for visual or functional reasons?

UPDATE: I looked it up, I guess its just convention tp use en dash

thanks for linking it directly

I think the transformers can be leveraged in a similar way for robotics. Prior art probably exists in self-driving or humanoids.

javascript fatigue

Interesting read. Contrary to what HN thinks, I think its good that VCs feel a forcing function to differentiate themselves. Like any other market, competition is good.

none taken—I appreciate the criticism!

The original purpose of the article is to highlight opinions from the community—not to be a scientific conclusion on what approach is better.

If somebody is seeking an answer for their own engineering problems, then the necessary due diligence is always required on their part.

Thanks for the kind comment! Glad you enjoy the content style—it takes a lot of time to gather comments.

Hm, definitely interesting to have some inline example/resources, I can see examples augmenting the original opinions.

What an ironic observation since LLMs are itself a probability machine.

Such an experiment has happened and well-documented here: https://htmx.org/essays/a-real-world-react-to-htmx-port/.

But still, experiments only happen in one context so its hard to extrapolate how the results would predict your own situation. This is why I think parsing opinions is a great through-provoking exercise.

idk what to say, its cool to see a bunch of gears tracking time and stare at it while it works ._.

not harsh and not untrue :)

But for context, the original intention of this article is to highlight opinions from the community. I feel that interleaving my own opinions would be untrue to the original intent.

appreciate the comment! I think I understand what you mean and I get the feeling that you are crossing into the land of aristotle haha.

A personal blog probably only needs any library besides a markdown to HTML renderer (for the developer-focused) or framework that has a built-in WYSIWYG editor and CMS.

From memory, i'm not to sure that a lot of problems that startups solve need a "thick-client" architecture. I think the canonical "thick-client" products are google sheets and google docs-esque products. I could be wrong about the actually distribution on this though. I think the author of HTMX phrased is correctly in that it really depends on where you are providing value—the backend or frontend. That would determine the viability of adopting HTMX.

I like the private jet analogy. I think people are naturally comparing HTMX to React, which is the source of misunderstanding in this discussion. But its not entirely wrong to make this comparison because people are also slowly learning that HTMX may potentially be able to implement 90% of the use-cases. Now whether or not HTMX is "simpler" to implement in all of those use-cases is highly dependent on many factors like I called out in the article.

Hopefully by understanding people's opinions, we can all make better engineering decisions though.

I think

Actually, you are right. I must have had a freudian slip when I was thinking about React's conditional rendering pattern (https://react.dev/learn/conditional-rendering). But I realize this is actually declarative. I think what I was trying to convey was that React involves more in-memory state management while HTMX embed that state in the HTML itself, which can be a jarring perspective shift in frontend programming.

I'll fix this sentence so I don't confuse any future readers. Thanks for the catch!

Building the highest quality collection of OpenAPI specifications on the internet: https://github.com/konfig-sdks/openapi-examples

This is awesome, the postman collection format is not version-control friendly. I love what Bruno is doing!

always wanted to work on a system that needs hystrix, I haven't needed such strict uptimes just yet.

Recently installed Atuin and found it to be overall net positive. A couple of habitual keystroke combos had to be reprogrammed from my brain but the persistence of shell history + better searching is pretty awesome.

Also the stats are a neat add-on.

Overall would recommend to almost any developer.

I'd say game studios are also especially risk-averse if you are building tools that are in the critical path for the game. Developers have to really trust you to be open to using your tool, which is probably why Microsoft is able to sell Playfab

We are big fans of https://earthly.dev/! Although we haven't personally used Dagger, Earthly has solved our multi-service integration testing problem with elegance. Simple builds + caching baked in.

going to try this and see if it works out :)

big fan of the Arc browser UX so I am hopeful this is better as well.

Fair points, I added a disclosure for clarity in future reference.

That being said, the Pro REST perspectives do scare me away from GraphQL in production. But seeing some posts about PostGraphile + Persisted Queries is interesting.

Also, research papers would have been nice to address but I am satisfied with the many hours this took to compile. A future follow-up may be necessary.

We use GraphQL internally but I admit I am currently more biased towards REST after battling with GraphQL, building a OpenAPI-based company, and playing with ergonomic REST-based frameworks like FastAPI. I still think the GraphQL DX is still miles ahead of OpenAPI and I really admire the best practices in GraphQL prescribed by Relay. But right now, REST is king for me.

Your observation is sort of the point of this article. Everyone has their opinion but nobody is de facto right.

I always found it hard to explain exactly how an SDK makes the experience of integrating a complicated REST API 10x better and I recently found this library that helps you make code walkthroughs https://codehike.org/ (huge props to Rodrigo the maintainer!).

FYI view the link on desktop for the full effect of the animations.