Hacker News Reader

Comment by sevenzero | Hacker News Reader

Also as a webdev, it writes basic CRUD pretty good. I am tired of having to build forms myself and the LLMs are usually really good at that.

Been building a new app with lots of policies and whatnot and instructing a LLM is just much faster than doing the same repetitive shit over and over myself.

View on HN

If you were tired of writing forms yourself, had you looked at https://jsonforms.io/? Just specify the the data you need, or extract it from the api spec and go. Display the form uniformly every time across your site. No need to burn AI time.

I typically avoid any most abstractions or third party dependencies. Yea it could be neat, but I still need a lot of custom logic here and there. Same reason I avoid stuff like GraphQL.

A little update: upon viewing the page on phone, for me the "comitter" field in the demo is going out of bounds... Really not speaking for their product.

Sounds like you're just fine depending on an extremely imprecise abstraction (natural language) and an extremely opaque third party (anthropic).

I can also just do it myself though lmao its not like I dont look at what it is producing

The recommended tool cant even produce mobile friendly, like why would I ever use it?

I don't know or care about that specific tool, or really what you do at all, I was just reacting to how the principle you stated conflicts with the practice you described. How you reconcile those is up to you.

I think you're missing the point of the commenter. A third party library is a new dependency. Since there's new vulnerabilities almost every week in the npm ecosystem, if you can do something without a third party, it's probably better.

With LLM driven code you can generate code once, and then if anything is shitty about it you can always manually update it yourself without the need of an LLM. It's a dependency of convenience, not an app-dependency.

From the description of the recommended tool it sounded to me like something that you use to deterministically generate code from a spec, which you could then modify if you like. That would be the same kind of dependency as the LLM workflow you describe, except that the abstraction is well-defined in a way that the LLM is not. Whether it's good or not is a different question.

That would be nice if it were the case but from what I can gather from this interesting dependency graph, there's a hard dependency on its renderer and schema.

https://jsonforms.io/img/architecture.svg

You can add your custom renderer but you still need their library for bindings and such.

If that is really a concern you could always have a pre-render step or server side render, whatever the name dujour is.

> I typically avoid any most abstractions or third party dependencies

Right, so depending on an LLM makes perfect sense in that case, thanks for clarifying :)

This might pair well with something like https://data-atlas.net.

I‘ve used it in a previous engagement. Unfortunately it’s not customizable enough, and performance for deep forms is really bad. Also, I‘d definitely use agents to set it up.

Reply on news.ycombinator.com