Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I love these sorts of frameworks! Makes doing forms a lot nicer, especially the live validation.

I feel like the next evolution is automatically generating a whole form from selecting a schema in an OpenAPI spec.

In a lot of specs, the type (string, email, phone, int, etc) is present along with any constraints (min/max length). Depending on the language/OpenAPI generator, it even preserves field order. It could massively speed up a lot of the more generic forms that happen in frontend.



As for me, forms are the single most important aspect of many web apps. Including critical ones for the society (banking, tickets, taxes, etc). Large part of my frustration with the state of web stems from how terrible experience with (creating and using) forms is.

Web is almost 30 years old by now, and the announce of a way to make forms relatively easily, still generates an excitement.

I mean, how many more years webdev community needs to realize that typesetting engine from 80s is not a good option for making modern robust UI apps? Technology for making hyperlinked web-pages is a terrible foundation for apps.


Well, forms aren't easy on any client toolkit (e.g. iOS/Android).

Forms are hard because they are (1) pure user input—often textual—, thus inheriting all fundamental difficulties with user input, and (2) arbitrarily reactive such that changing one value may arbitrarily impact other values, e.g. bidirectionally, and (3) you are at the mercy of the platform supporting the input UX that you want to build and you quickly find yourself off the rails otherwise.

This means that even though forms seem like they should be trivial, it's just as hard to generalize over forms as any other UI concept. Or rather, it's not a solved problem for the same reason UI in general isn't a solved problem.


I'm not saying it's easy. But hey, StackOverflow threads on how to post form with checkbox with "false" value in it are pretty telling.

I've done forms with Qt, QML and Flutter, and it's completely different experience.


Well, every platform has its idiosyncrasies that you have to learn. No less with Qt, QML, and Flutter. You just take them for granted.

Cocoa/UIKit are my wheelhouse and have their own share of entry level StackOverflow questions. Though personally I think they make even less sense than the web toolkit. But if you just go by StackOverflow questions, you'd wonder if it was possible to learn anything.

Just search something like "auto layout" on StackOverflow. Turns out that client dev just isn't that easy no matter which abstraction you want to use.


I watched a video recently on how to make fire. 30,000 years we’ve been doing it, and videos like that are still interesting!


1000% this. The state of native form inputs on the web platform is dismal, truly. Particularly on mobile.


Here's a Clojure strategy optimized for streamlining this exact type of development https://hyperfiddle.notion.site/Reactive-Clojure-You-don-t-n...


I know https://github.com/bytebuilders/vue-openapi-form exists but no first hand experience with it.

There's also a number of them out there that generate a form from json schema. I'm most familiar with https://github.com/formschema/native which we use/extend at https://routegy.com for microapps.


These exist, such as: https://github.com/rjsf-team/react-jsonschema-form

We also built one from scratch and used it in client-facing production applications (Angular + React Native). The biggest hurdle is that JSON schema is great at describing the shape of the form data but not a great job at describing how the form looks. We ended up creating a separate "presentation" schema which handled things like order of the form, rows/columns, widgets to use, and much more.


I've definitely tried to find a graphql form generator that would take a schema and mutation and make a form with validation.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: