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

61–70 of 129 posts

Re: Form to DB

#61

Post by hk__2 »

pantulis wrote: post #59
rmbyrro wrote: post #56

Earlier quoted context omitted.

Congrats on the launch, looks neat! > and b) building my own frontend (probably via React, and then maybe via formik) There's also a new technology called HTML. It comes with a tag, field tags, and even a to submit! Although new, they managed to get all browsers on board to support it. You will not need to import 150kb of JavaScript, though, which is sad. And it's not shiny to speak about in the interview for your ne…

Let me tell you something about this fancy HTML tag you are talking about. It has an "action" attribute that points to a server you need to own and run a code you need to code in order to validate the input and store it in the database. If you are comfortable doing this, which no doubt you are, then you are not the target audience of this tool.

> It has an "action" attribute that points to a server you need to own and run a code you need to code in order to validate the input and store it in the database

Pure-HTML forms work exactly like React forms; React does the lifting but it doesn’t change anything to the fact that the data eventually needs to be sent to a server to be stored in the database.

Re: Form to DB

#62

Post by rajamaka »

rmbyrro wrote: post #56
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…

Congrats on the launch, looks neat! > and b) building my own frontend (probably via React, and then maybe via formik) There's also a new technology called HTML. It comes with a tag, field tags, and even a to submit! Although new, they managed to get all browsers on board to support it. You will not need to import 150kb of JavaScript, though, which is sad. And it's not shiny to speak about in the interview for your ne…

Why do people here commonly imply downloading 150kb of data is an issue in the current year?

Re: Form to DB

#63

Post by hk__2 »

rajamaka wrote: post #62
rmbyrro wrote: post #56

Earlier quoted context omitted.

Congrats on the launch, looks neat! > and b) building my own frontend (probably via React, and then maybe via formik) There's also a new technology called HTML. It comes with a tag, field tags, and even a to submit! Although new, they managed to get all browsers on board to support it. You will not need to import 150kb of JavaScript, though, which is sad. And it's not shiny to speak about in the interview for your ne…

Why do people here commonly imply downloading 150kb of data is an issue in the current year?

Because it is. It can be very frustrating not to be able to fill a form on mobile with a 3G connection just because some random dev decided that downloading 150kb of JS to render a simple form is fine.

I mean it’s a form; we already have all the HTML elements already; why do you need React for? This is why nowadays we end up with Electron apps that take 6GB of RAM to display a chat.

Re: Form to DB

#64

Post by throwaway60320 »

hk__2 wrote: post #63
rajamaka wrote: post #62

Earlier quoted context omitted.

Why do people here commonly imply downloading 150kb of data is an issue in the current year?

Because it is. It can be very frustrating not to be able to fill a form on mobile with a 3G connection just because some random dev decided that downloading 150kb of JS to render a simple form is fine. I mean it’s a form; we already have all the HTML elements already; why do you need React for? This is why nowadays we end up with Electron apps that take 6GB of RAM to display a chat.

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 form is 5 simple text inputs.

Re: Form to DB

#65

Post by rmbyrro »

pantulis wrote: post #59
rmbyrro wrote: post #56

Earlier quoted context omitted.

Congrats on the launch, looks neat! > and b) building my own frontend (probably via React, and then maybe via formik) There's also a new technology called HTML. It comes with a tag, field tags, and even a to submit! Although new, they managed to get all browsers on board to support it. You will not need to import 150kb of JavaScript, though, which is sad. And it's not shiny to speak about in the interview for your ne…

Let me tell you something about this fancy HTML tag you are talking about. It has an "action" attribute that points to a server you need to own and run a code you need to code in order to validate the input and store it in the database. If you are comfortable doing this, which no doubt you are, then you are not the target audience of this tool.

Let me tell you something else.

If you read the comment again, you'll see I'm replying to OP's scenario of setting his own server and frontend.

I'm questioning the "probably using React" part of the frontend because... it's an overly complex solution to an already elegantly solved problem?

Re: Form to DB

#66

Post by rmbyrro »

throwaway60320 wrote: post #64
hk__2 wrote: post #63

Earlier quoted context omitted.

Because it is. It can be very frustrating not to be able to fill a form on mobile with a 3G connection just because some random dev decided that downloading 150kb of JS to render a simple form is fine. I mean it’s a form; we already have all the HTML elements already; why do you need React for? This is why nowadays we end up with Electron apps that take 6GB of RAM to display a chat.

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…

Doing validation in the frontend is a bad idea.

You'll have to do in the server, if you're sane.

I bet Retool Forms does in the server.

You're worried the page will refresh with an empty form, if it fails. It's simple, just collect the data and return the form pre-filled using the value attribute, along with the error message.

If you don't want to refresh the page, you could even use something like htmx, which is a LOT simpler than React, but really not necessary for simple form submission.

Re: Form to DB

#67

Post by rmbyrro »

rajamaka wrote: post #62
rmbyrro wrote: post #56

Earlier quoted context omitted.

Congrats on the launch, looks neat! > and b) building my own frontend (probably via React, and then maybe via formik) There's also a new technology called HTML. It comes with a tag, field tags, and even a to submit! Although new, they managed to get all browsers on board to support it. You will not need to import 150kb of JavaScript, though, which is sad. And it's not shiny to speak about in the interview for your ne…

Why do people here commonly imply downloading 150kb of data is an issue in the current year?

From the user perspective, forcing to download 150kb unnecessarily is a bad professional practice. Not everyone has 5G and an iPhone.

From the dev experience perspective, these 150kb of Javascript and the complexity you'll build upon it will come with bugs, security holes, updates, maintenance. Personally I wouldn't want this for me unnecessarily.

Re: Form to DB

#68

Post by TheFragenTaken »

account-5 wrote: post #36

These types of projects always remind me of MS Access. Access is forms on a database, and really easy to use. It obviously has its drawbacks but nothing has come close to it. I've never understood why MS didn't capitalise on it by extending and improving it.

I'd love a modern non-SaaS MS Access equivalent, that just use files: https://stephango.com/file-over-app

Re: Form to DB

#69

Post by TheFragenTaken »

Don't most orgs already own Google Workspace, or MS365? I fail to see how MS Forms + Excel, or Google Forms + Sheets can't accomplish this (with the addition of common spreadsheet features). It's not to be snarky, but it feels like an easy comparison to make.

Re: Form to DB

#70

Post by Takennickname »

TheFragenTaken wrote: post #69

Don't most orgs already own Google Workspace, or MS365? I fail to see how MS Forms + Excel, or Google Forms + Sheets can't accomplish this (with the addition of common spreadsheet features). It's not to be snarky, but it feels like an easy comparison to make.

Some people care (too much) about design details. Still a market though.
Post reply on HN