Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Form to DB

formtodb.com

Post reply on HN
Print view View original

101–110 of 129 posts

Re: Form to DB

#101

Post by crazymoka »

cuffe wrote: post #7

Hi all, engineer who worked on forms @ Retool here. Excited to get HN’s feedback on a new product I’ve been working on: Retool Forms. There are a ton of form builders out there (e.g. Typeform, Google Forms, Airtable Forms, etc.) and honestly we weren’t really looking to build another one. But as a developer, I wanted my data in my database, not in another SaaS app (which probably has a shoddy API, like every example…

Why is it free? And for how long will it be free for? I do not want to start to use another Form builder to find out months later I'm locked with a $50/m charge.

Re: Form to DB

#102

Post by zubairq »

I love this. I work on an openource project (in progress still) building forms on top of different databases and can say that Retool really nailed this one. Well done!

Re: Form to DB

#103

Post by raphinou »

interlocutor wrote: post #2

This does a better job: https://visualdb.com/

I'll share my own project: https://www.myowndb.com/, running since 2006. I neglected the project for a couple of years but recently launched the new version. It's open source: https://gitlab.com/myowndb/myowndb

I enjoy the technical side, but I'm struggling to commercialise it so don't hesitate to give me your feedback here or on https://www.myowndb.com/contact.html which is of course powered by a myowndb public form :-)

Re: Form to DB

#104

Post by nathanstitt »

interlocutor wrote: post #2

This does a better job: https://visualdb.com/

heh, I'll throw my formial (https://github.com/nathanstitt/formial) project onto this thread. I probably need to update it a bit but it's been working well in production for 2+ years now.

Where were all these alternatives when I was looking for a WYSIWYG form builder?

Re: Form to DB

#105

Post by trollbridge »

Borealid wrote: post #18

I remember Microsoft InfoPath, for which this appears to be a competitor. I never really understood why InfoPath didn't catch on better.

Back in 2009, I ran a project to convert a bunch of paper forms into InfoPath for online forms. After a few months we gave up on InfoPath:

- We still had to have paper forms for legally required forms in case someone didn’t have a computer, etc. so then we needed a regular printable PDF. InfoPath native forms had issues with printing.

- The InfoPath-PDF integration was not very good and not usable for my production.

- The data on the other end went into bizarre formats and thus needed a job to convert it to the format we needed (and take action).

In the end this solution was deployed, and shockingly is still online and in production in 15 years later:

- A graphic designer (often an intern) took the original paper forms or fillable PDFs and made basic HTML forms with them.

- jQuery used for user friendly form validation.

- These forms were integrated with an SSO to allow e-signing.

- “Print” and “Submit” buttons on the form invoked a Perl script which (1) transformed the HTML form to having the content filled in, (2) ran headless Firefox and print-to-PDF to archive the form for legal purposes, (3) stored the form values in the native database, and (4) fired off a stored procedure based on the form name.

In effect, the same things InfoPath was supposed to do, but it didn’t need a dedicated administrator or complex integrations.

Re: Form to DB

#107

Post by breadwinner »

datadrivenangel wrote: post #94
CGamesPlay wrote: post #39

Earlier quoted context omitted.

Because the single-system paradigm doesn't work any more. However, modern replacements do exist, Airtable is one of the first; it's basically the notion of a "spreadsheet with more structure", and then building forms and such on top of that. I've recently been playing with Grist and like it, although it is rough around the edges. https://www.getgrist.com

Airtable also has a surprisingly small hard row limit. 50k rows is very easy to hit quickly.

If you want Airtable, but with unlimited rows in the DB, that's Visual DB: https://visualdb.com You can use query parameters to specify which subset of records to bring to the frontend.

Re: Form to DB

#108

Post by throwaway60320 »

cabalamat wrote: post #96
throwaway60320 wrote: post #64

Earlier quoted context omitted.

It's really not that simple. What about complex validation rules? Do you really think it's user friendly to require them to send the whole form just to tell them "sorry no" 10 times over until they get it right? What about multi-value selects, potentially with rules? E.g. form field like "choose up to 5 locations in the radius of 10km". What about form fields like "pick a point on a map"? Etc. Don't act like every fo…

> What about complex validation rules? I wpould use my server-side form and database library, Bozen[1] to do this. > [1]: https://github.com/cabalamat/frambozenapp

So the user would have to submit the form and be met with 10s of errors? I'd rather tell them immediately.

Re: Form to DB

#109

Post by throwaway60320 »

sodapopcan wrote: post #98
lupire wrote: post #88

Earlier quoted context omitted.

What's wrong with jQuery? All my homies (favorite websites) are jQuery.

jQuery is still viable in many situations! My comment is directed at people who say you can't sanely build bigger things without React.

Sure, you do you. I spent 10 years working with jQuery and am very thankful to leave that very far behind me.

BTW: jQuery is 85.1 kB minified and 29.7 kB gzipped. Preact (same API/dev experience as React, minimal performance impact) is 11.4 kB minified and 4.5 kB gzipped. Who has the smaller JS bundle now?

Re: Form to DB

#110

Post by throwaway60320 »

recursivedoubts wrote: post #91
throwaway60320 wrote: post #85

Earlier quoted context omitted.

Yeah until a manager comes and says "well great, it works, now let's do a mobile app like that"

https://hypermedia.systems/hyperview-a-mobile-hypermedia/ https://hyperview.org https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/two-approaches-to-decoupling/ https://htmx.org/essays/mvc/

Why though? It's much easier to do a simple API (or use a pre-made one like this one) from the web and the app. And no need to change the backend code on design updates.

I just don't get what you're chasing after. All this seems more complex (to develop, to maintain, to operate, to manage) than what I'm doing with (P)React (Native) and APIs.

And where are the thousands of pre-made components like React has?

Post reply on HN