Form to DB(formtodb.com)
formtodb.com
Form to DB
https://www.formtodb.com/
126 comments
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 <form> tag, <input> field tags, and even a <button> 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 next job.
I guess the pros dont overweight these cons... Yes, "probably via React" is the way!
> 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 <form> tag, <input> field tags, and even a <button> 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 next job.
I guess the pros dont overweight these cons... Yes, "probably via React" is the way!
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. 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.
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.
> Pure-HTML forms work exactly like React forms
This should probably read "React forms work exactly like pur-HTML forms" seeing as HTML came first and react ultimately spits out either an HTML form or a form request.
The original point still remains though, reaching for react just for forms is really heavy handed. It works fine if everything on the site is react already, though that's an assumption that I wouldn't make and that I hope will die soon enough if devs finally start moving away from massive react apps.
This should probably read "React forms work exactly like pur-HTML forms" seeing as HTML came first and react ultimately spits out either an HTML form or a form request.
The original point still remains though, reaching for react just for forms is really heavy handed. It works fine if everything on the site is react already, though that's an assumption that I wouldn't make and that I hope will die soon enough if devs finally start moving away from massive react apps.
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?
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?
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.
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.
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.
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.
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.
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.
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.
Of course you have to validate on the server. That's a given, always.
But you want to provide better UX to the user.
Htmx is not simpler than React. I can't deploy that without a server that knows everything about the frontend. React allows me to decouple. Templates are hell. I lived in it for many years, never again.
But you want to provide better UX to the user.
Htmx is not simpler than React. I can't deploy that without a server that knows everything about the frontend. React allows me to decouple. Templates are hell. I lived in it for many years, never again.
Detractors of the "html over the wire" movement are always talking about it as if the people working on this stuff didn't live through the jQuery days and are blindly repeating them.
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?
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?
So did I and you’re side-stepping my initial comment by responding to my response that people can use jQuery if they want. I no longer use it myself nor, btw, did I say anything about its size.
sometimes it is:
https://htmx.org/essays/a-real-world-react-to-htmx-port/
https://htmx.org/essays/a-real-world-react-to-htmx-port/
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/
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?
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?
well, an extended answer is offered in the essays linked above, but, to take some numbers from https://htmx.org/essays/a-real-world-react-to-htmx-port/, here's why:
- no reduction in app ux
- code base reduced by 67% (21,500 LOC to 7200 LOC)
- total JS dependencies reduced by by 96% (255 to 9)
- web build time reduced by 88% (40 seconds to 5)
- Time-to-interactive reduced by 50-60%
- htmx allowed them to display much larger data sets
- memory usage reduced by 46% (75MB to 45MB)
the essays above also discuss why to split your apis (disentangle web app churn from your general purpose data API) and how to avoid duplicating logic (the mvc essay)
i take pains to reiterate in the essays and book that htmx isn't right for every application, but it is a good architectural choice for some, and many more than most web developers who are used to reactive-style programming would think
there are not thousands of pre-made components for htmx because there are no components for htmx: there are rather components for HTML. those components should integrate with htmx in the HTML-standard manner: events & form participation
- no reduction in app ux
- code base reduced by 67% (21,500 LOC to 7200 LOC)
- total JS dependencies reduced by by 96% (255 to 9)
- web build time reduced by 88% (40 seconds to 5)
- Time-to-interactive reduced by 50-60%
- htmx allowed them to display much larger data sets
- memory usage reduced by 46% (75MB to 45MB)
the essays above also discuss why to split your apis (disentangle web app churn from your general purpose data API) and how to avoid duplicating logic (the mvc essay)
i take pains to reiterate in the essays and book that htmx isn't right for every application, but it is a good architectural choice for some, and many more than most web developers who are used to reactive-style programming would think
there are not thousands of pre-made components for htmx because there are no components for htmx: there are rather components for HTML. those components should integrate with htmx in the HTML-standard manner: events & form participation
> Don't act like every form is 5 simple text inputs.
Well to be honest 99% of forms are 5 simple text inputs with a select. What was the last time you had to implement a "choose up to 5 locations in the radius of 10km", really?
> What about form fields like "pick a point on a map"?
Same thing: of course there are rich forms for which you need JS, but they are the exception, not the rule.
Well to be honest 99% of forms are 5 simple text inputs with a select. What was the last time you had to implement a "choose up to 5 locations in the radius of 10km", really?
> What about form fields like "pick a point on a map"?
Same thing: of course there are rich forms for which you need JS, but they are the exception, not the rule.
React isn't required for client-side validation or non-spec form inputs.
Doing form validation in event handlers for DOM events works very well, and a simple script tag or custom element is all that's needed to build a multi-value select.
Doing form validation in event handlers for DOM events works very well, and a simple script tag or custom element is all that's needed to build a multi-value select.
It's not simple. I made multi-page forms with dozens fields where your suggestion would lead to intangible mess of spaghetti code - I know because I worked with the web way before React. Even with the best coding standards and a team of seniors it's just too hard to maintain - and seniors usually don't write forms.
I really don't want to go back to the jQuery days. You do you, but don't say it's easier - it really isn't.
BTW you can just use Preact if you're worried about the bundle size. I do that, it's perfect and just a little performance impact, usually not visible in small apps.
I really don't want to go back to the jQuery days. You do you, but don't say it's easier - it really isn't.
BTW you can just use Preact if you're worried about the bundle size. I do that, it's perfect and just a little performance impact, usually not visible in small apps.
Oh that's interesting, multi-page forms are actually my least favorite form use case for react.
I reach for a state machine whenever possible to manage the complex flow of the multi-page or multi-step form, even if react is still used for custom inputs.
I reach for a state machine whenever possible to manage the complex flow of the multi-page or multi-step form, even if react is still used for custom inputs.
Check out XState, it's really great!
But it's not that necessary in my case, my forms are usually not complex statecharts, just a lot of individual and largely decoupled complex form controls - multiselects with rules, map pins, tag inputs with autosuggest, data grids etc.
But it's not that necessary in my case, my forms are usually not complex statecharts, just a lot of individual and largely decoupled complex form controls - multiselects with rules, map pins, tag inputs with autosuggest, data grids etc.
> 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
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.
Sure, and React is the best way to show a message in response to an input in a web form, right?
Let me tell you some news, they just launched an integration of this new HTML <form> thing with javascript, so you can have JS listening to inputs and displaying information anywhere on the page. Cool, isn't it?
Ah, but the sad part, again, is you don't get to download an unnecessary library for that. It comes baked and activated into all browsers by default. It doesn't make your resume shine, either...
Let me tell you some news, they just launched an integration of this new HTML <form> thing with javascript, so you can have JS listening to inputs and displaying information anywhere on the page. Cool, isn't it?
Ah, but the sad part, again, is you don't get to download an unnecessary library for that. It comes baked and activated into all browsers by default. It doesn't make your resume shine, either...
(P)React is the best way to do it in a maintainable, easy-to-reuse, easy-to-understand, extendable fashion, indeed. Show me something better and I'll jump on it.
I don't care about resumes, I own my consultancy. I care about quickly solving business problems for my clients, not making new problems in the process, and reusing the solutions. I am not paid hourly, I don't make money from fixing spaghetti code broken by adding a stateful form control elsewhere.
I don't care about resumes, I own my consultancy. I care about quickly solving business problems for my clients, not making new problems in the process, and reusing the solutions. I am not paid hourly, I don't make money from fixing spaghetti code broken by adding a stateful form control elsewhere.
Just saying: You can do input validation without JS using the pattern attribute.
If people typically get 10s of errors on a single form, it might well be better to split it up into several sub forms.
So, you didn’t feel comfortable relying on “another SaaS” app, and then go on to suggest Retool Workflows, which is itself part of another paid SaaS app? All those “shoddy” alternatives also have free tiers.
Not sure that is fair? The difference seems to be the data is squarely in your own DB. You can use their SaaS for validation. You might pay for something (surprise?).
So exactly like Budibase, but closed-source?
It would be pulling in another SaaS, what isn't fair?
It actually sounds like an interesting service in my opinion, but it is another SaaS that is giving me an API for a form handler that I could otherwise host myself.
Personally I wouldn't see the use case of using your own DB as helpful, if you already have your own database the odds that you aren't hosting APIs as well seems low.
It actually sounds like an interesting service in my opinion, but it is another SaaS that is giving me an API for a form handler that I could otherwise host myself.
Personally I wouldn't see the use case of using your own DB as helpful, if you already have your own database the odds that you aren't hosting APIs as well seems low.
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.
When you say on the website that Amazon uses this product, is Amazon a paying customer or is it simply an engineer (or a few I suppose) are using it?
I’m curious how to interpret the “trusted by” statement here
I’m curious how to interpret the “trusted by” statement here
Amazon pays us more than $1M annually. See also: https://news.ycombinator.com/item?id=37426191
> There was no “one click” form-on-top-of-my-database tool available.
Does this count: https://airforms.com/
Does this count: https://airforms.com/
Interesting. 'Automatic database diagrams'. How does that work in a db without primary/foreign keys?
In that case you would want to use another tool that is more manual than automatic.
> There was no “one click” form-on-top-of-my-database tool available
When did you start building it? Budibase does exactly this since 2020.
When did you start building it? Budibase does exactly this since 2020.
There is no download link, so how can this be self-hosted?
+1, and the "self-hosted" page on their documentation is… empty.
https://docs.retool.com/education/labs/self-hosted
Edit: the right page seems to be https://docs.retool.com/self-hosted but it’s about Retool in general; I doubt you need 8 vCPUs and 16GB of RAM to host forms [1].
[1]: https://docs.retool.com/self-hosted/quickstarts/docker#vm-co...
https://docs.retool.com/education/labs/self-hosted
Edit: the right page seems to be https://docs.retool.com/self-hosted but it’s about Retool in general; I doubt you need 8 vCPUs and 16GB of RAM to host forms [1].
[1]: https://docs.retool.com/self-hosted/quickstarts/docker#vm-co...
You can self-host here: https://retool.com/self-hosted. Most people deploy it as a docker container on an EC2 instance but there’s various options
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.
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
https://www.getgrist.com
I love Grist, and relevant to this discussion, it now has forms: https://www.getgrist.com/forms/
Grist is open source, Python scriptable and each project is stored in a SQLite database.
Grist is open source, Python scriptable and each project is stored in a SQLite database.
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.
I'd love a modern non-SaaS MS Access equivalent, that just use files: https://stephango.com/file-over-app
I never saw an Access database that didn't become a regretful mess after a couple of years - the person that made it left, no-one knew how to update it. Fancy validation built into the form that just got in the way when requirements changed.
Thus I came to the conclusion that any Access database is probably better off being a spreadsheet, even with all the chaos that not having forms as a front end and not having relational structure entails. At least people can understand other peoples spreadsheets (up to a point)
Thus I came to the conclusion that any Access database is probably better off being a spreadsheet, even with all the chaos that not having forms as a front end and not having relational structure entails. At least people can understand other peoples spreadsheets (up to a point)
Most Access-based apps turn to shit because they're made by non-developers. The tool itself isn't to blame. I've seen Access used to great success when coupled with scripting to dump schema and code to text files for version control and code review.
Right, but if you're a developer you might as well use something more developery. Like the selling point of Access was supposed to be that non-coders could use it to knock together a database.
In the late 90s I built some quite big things in Access and promptly regretted it. I guess Access got used for those projects because the organisation already 'owned' it as part of the Office bundle whereas Visual Studio 6 was seen as 'expensive' (I think it was about £500 per developer or something).
But these days that problem would not occur. The days of development tools needing comparatively expensive licences are over.
In the late 90s I built some quite big things in Access and promptly regretted it. I guess Access got used for those projects because the organisation already 'owned' it as part of the Office bundle whereas Visual Studio 6 was seen as 'expensive' (I think it was about £500 per developer or something).
But these days that problem would not occur. The days of development tools needing comparatively expensive licences are over.
> I guess Access got used for those projects because the organisation already 'owned' it...
> The days of development tools needing comparatively expensive licences are over.
That's exactly the motivation I saw for Access being used in the past. I agree, those days are over and that justification for using Access is moot.
> The days of development tools needing comparatively expensive licences are over.
That's exactly the motivation I saw for Access being used in the past. I agree, those days are over and that justification for using Access is moot.
I'm unfortunately forced to use access at work. I never wanted to learn what is, unless MS do something, a dead technology, I fully agree that most access databases are a shit show but only because nondevelopers (as mentioned but others). However, kept simple, on point and used within it's limitations, it's a very flexible system.
I don't know, it's something I've wanted many times.
Recently I discovered https://directus.io/ which comes pretty close and it's open source.
Recently I discovered https://directus.io/ which comes pretty close and it's open source.
As a side note I found retool to be the most prohibitively expensive out of 6-7 solutions I was researching for “low code admin app builder” ecosystem.
Hm, sorry you found us to be expensive. Two notes:
* Forms (ie the product here) is free.
* We’ve always aimed to build a sustainable business where we charge reasonable prices and can guarantee we’ll stay in business ourselves. It’s true there are other products that are cheaper, but every single one of those companies is unprofitable and many will probably be dead in a few years. See, for example, Airplane, Interval, or Dynaboard. Dynaboard just got acquired today (their founder is apparently “thrilled” about it: https://dynaboard.com/blog/figma-acquires-dynaboard) and they’re shutting down on April 30th. If you’re a paying customer you’ll need to rebuild all your apps by then. Ouch! (I’d rather pay more and not have worry about core pieces of my business getting shut down with three months’ notice.)
* Forms (ie the product here) is free.
* We’ve always aimed to build a sustainable business where we charge reasonable prices and can guarantee we’ll stay in business ourselves. It’s true there are other products that are cheaper, but every single one of those companies is unprofitable and many will probably be dead in a few years. See, for example, Airplane, Interval, or Dynaboard. Dynaboard just got acquired today (their founder is apparently “thrilled” about it: https://dynaboard.com/blog/figma-acquires-dynaboard) and they’re shutting down on April 30th. If you’re a paying customer you’ll need to rebuild all your apps by then. Ouch! (I’d rather pay more and not have worry about core pieces of my business getting shut down with three months’ notice.)
As a counterpoint--from another potential user who looked at Retool first but landed on a competitor's product because Retool was too expensive--another way for me to avoid that outcome is to choose a tool that's open source and self-hosted. That's precisely what we did. If/when the company goes out of business, we can keep using it; this already happened to us with RethinkDB and we continue to run that in its community-maintained form. I'll likely want to find a new platform for new development but I won't have to rewrite my existing apps by a deadline.
You're right that it's a big concern, but it's a pretty tough sell to solve this problem by just charging so much that it's clear you could not possibly go out of business. I had to go pretty far down the list of your top competitors to find a good one that was open source, but I did find it.
All that said, Retool's pricing at that time was MUCH worse than it is today. This is what Retool was offering us at the time: https://web.archive.org/web/20230315060042/https://retool.co... -- no distinction between developers and end users! No access controls until the $50/user/month level! That was totally out of the question. The current pricing looks a bit more reasonable, but it's too late; we already committed to the competitor offering an open source solution.
You're right that it's a big concern, but it's a pretty tough sell to solve this problem by just charging so much that it's clear you could not possibly go out of business. I had to go pretty far down the list of your top competitors to find a good one that was open source, but I did find it.
All that said, Retool's pricing at that time was MUCH worse than it is today. This is what Retool was offering us at the time: https://web.archive.org/web/20230315060042/https://retool.co... -- no distinction between developers and end users! No access controls until the $50/user/month level! That was totally out of the question. The current pricing looks a bit more reasonable, but it's too late; we already committed to the competitor offering an open source solution.
Thank you for your feedback (seriously!). I myself talked a few users that shared your point of view last year and that's why we ended up changing our pricing.
I do think there is more work for us to do — I do think especially as we get more enterprise customers (currently 4 of the Fortune 10 are customers; we're aiming to get to all 10 soon!), we'll be able to make it cheaper and cheaper for indie developers (maybe one day even totally free for up to, say, 100 users, or perhaps to introduce a plan that you can build public apps with unlimited users for free).
We have considered open-coring Retool. I think there are many pros to that (as you note). But my main fear is that it would be difficult to build a business around it, since we'd be stuck selling either hosting or support (neither of which is particularly high margin; cf. Elastic). Or we'd be forced to limit the open-source version to not have important features (e.g. SSO)... and it feels like we wouldn't be true to the open-source philosophy if so.
Thank you for considering Retool!
I do think there is more work for us to do — I do think especially as we get more enterprise customers (currently 4 of the Fortune 10 are customers; we're aiming to get to all 10 soon!), we'll be able to make it cheaper and cheaper for indie developers (maybe one day even totally free for up to, say, 100 users, or perhaps to introduce a plan that you can build public apps with unlimited users for free).
We have considered open-coring Retool. I think there are many pros to that (as you note). But my main fear is that it would be difficult to build a business around it, since we'd be stuck selling either hosting or support (neither of which is particularly high margin; cf. Elastic). Or we'd be forced to limit the open-source version to not have important features (e.g. SSO)... and it feels like we wouldn't be true to the open-source philosophy if so.
Thank you for considering Retool!
As someone who also tried and really liked Retool but also found it too expensive I can add my reasoning.
I help companies with digital transformation, what it usually entails is deploying solutions to small teams and then growing them as we get buy in from the business. The initial users are high frequency users of the tools, and later users might be infrequent users.
The problem I found with Retool was that as I scaled to the infrequent users the cost per user remained static, so I would be punished for my tool becoming more popular.
I help companies with digital transformation, what it usually entails is deploying solutions to small teams and then growing them as we get buy in from the business. The initial users are high frequency users of the tools, and later users might be infrequent users.
The problem I found with Retool was that as I scaled to the infrequent users the cost per user remained static, so I would be punished for my tool becoming more popular.
Dynaboard shutting down does not relate to pricing for end-users.
From a Low Code product perspective, we were still able to build a beautiful and functional product. Our product unit/engineer ratio is much higher than our competition (see, for example, Retool), which allows us to provide the best value for our users. Regarding the transition, I don't see any indication from the note you posted that users will have to rebuild all their apps. Rather, the founder is saying he will provide more information and possible steps. Who knows – maybe it would be integrated into Figma? And Figma would gain great runtime and IDE capacities?
From a Low Code product perspective, we were still able to build a beautiful and functional product. Our product unit/engineer ratio is much higher than our competition (see, for example, Retool), which allows us to provide the best value for our users. Regarding the transition, I don't see any indication from the note you posted that users will have to rebuild all their apps. Rather, the founder is saying he will provide more information and possible steps. Who knows – maybe it would be integrated into Figma? And Figma would gain great runtime and IDE capacities?
Sorry I didn't link to a Dynaboard email. Here's what an (unhappy) customer of theirs sent me: https://imgur.com/a/qTGpgbQ. They were unhappy because they're a) losing all their data, and b) losing all their applications.
mehal and I are former Dynaboard engineers, so we are well aware of the situation. No one is more upset about the removal of Dynaboard than the team, but it doesn't justify poor pricing practices from competitors
Just wanted to echo I love your product but the pricing is too prohibitive. My use-case is wanting to offer a dashboard to my own clients. But the business pricing was $50/mo per user and also gave each user editor privileges.
I want to create customer accounts, apply settings (e.g. I delimit the data their account can access, basically adding WHERE clauses on a per-account basis), and they can access white-label read-only dashboards with their own user/pass.
Retool seemed 100% insistent on being an internal-only tool with a high cost per user.
I want to create customer accounts, apply settings (e.g. I delimit the data their account can access, basically adding WHERE clauses on a per-account basis), and they can access white-label read-only dashboards with their own user/pass.
Retool seemed 100% insistent on being an internal-only tool with a high cost per user.
Hi! Last year, Retool introduced differentiated pricing for end users (viewers) and standard users (editors) to make these kinds of use cases much more palatable[0]. We also rolled out support for building customer-facing apps through letting you whitelabel and ship apps to people outside your organization [1].
Would be more than happy to talk through your use case; feel free to reach out at antony[at]retool[dot]com.
[0] https://retool.com/pricing [1] https://retool.com/products/portals
Would be more than happy to talk through your use case; feel free to reach out at antony[at]retool[dot]com.
[0] https://retool.com/pricing [1] https://retool.com/products/portals
Pricing is always tricky. One pricing never fits all use case. So we have worked hard to offer pricing options like usage based pricing/ dev based pricing in addition to user based pricing.
Was curious to apply your use case and see if our pricing model maximises ROI.
Disclaimer: I am co-founder at a retool alternative platform for building internal tools and enterprise apps.
Was curious to apply your use case and see if our pricing model maximises ROI.
Disclaimer: I am co-founder at a retool alternative platform for building internal tools and enterprise apps.
Hey David! I love the sustainable work you are doing for developer tools.
We were emailing back in 2021 about one of the many products you and your team have built for developers. Exciting conversation, for sure!
If anyone is interested in reading about my experience with ReTool's approach to developer tools, I have a link: https://marak.com/blog/2021-04-25-monetizing-open-source-is-...
We were emailing back in 2021 about one of the many products you and your team have built for developers. Exciting conversation, for sure!
If anyone is interested in reading about my experience with ReTool's approach to developer tools, I have a link: https://marak.com/blog/2021-04-25-monetizing-open-source-is-...
Hi Marak! Let me know if you think this response is fair: https://news.ycombinator.com/item?id=27252331. I'd summarize it as "we used a MIT library to generate some data, and unbeknownst to us, this MIT library linked to proprietary data. We then immediately removed such data once we found out."
If you don't think that's a fair reaction, would love to hear your perspective and buy you a coffee next time I'm in NYC. I'll send you an email now. :)
If you don't think that's a fair reaction, would love to hear your perspective and buy you a coffee next time I'm in NYC. I'll send you an email now. :)
It's a fair reaction, and I appreciate your offer of coffee.
Keep up the excellent work, creating value with your ReTool company. I am confident you will find continued success with your sustainable approach.
Keep up the excellent work, creating value with your ReTool company. I am confident you will find continued success with your sustainable approach.
Curious - what was your use case for low code tool? Just build a single admin tool for a few users or something more elaborate.
FWIW I run growth for a low code platform company and we are one of the retool alternatives. One of the things I am trying to get right is getting the value proposition right for different scenarios like say building a customer portal (unlimited external users) to admin tools (few internal users). So far we have been able to do good on this front by helping customers with usage based pricing or even developer based pricing. But yet curious to hear your use case and see if there is something I am missing.
FWIW I run growth for a low code platform company and we are one of the retool alternatives. One of the things I am trying to get right is getting the value proposition right for different scenarios like say building a customer portal (unlimited external users) to admin tools (few internal users). So far we have been able to do good on this front by helping customers with usage based pricing or even developer based pricing. But yet curious to hear your use case and see if there is something I am missing.
It’s a progression. It starts out as an admin dashboard for a team of 5, then it grows to an internal platform for 15 devs plus “ops” people etc. Thus there’s micro segments inside this market based on stage
Interesting. Would love to chat if you got 15 and see if app based pricing works better or pure usage. Email is in profile.
This does a better job: https://visualdb.com/
I build a better one https://teable.io/ and plan to open source it next week
teable looks very interesting, I hope you do follow through on open sourcing it.
There's also https://www.airsequel.com/
And
https://airforms.com/
And
https://airforms.com/
https://airforms.com/ and https://visualdb.com/ appear to be the same thing?
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 :-)
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 :-)
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?
Where were all these alternatives when I was looking for a WYSIWYG form builder?
I am a little confused by Retool. Every page on retool.com has a different look and feel, different font styles and colour schemes. It feels extremely disjointed and almost like hacked together by completely different people who then merged html pages into a single web app. Then Form to DB has even its own domain and is marketed as a complete standalone product here but I can't find a way to only sign up to it or find pricing for it. How is From to DB related to Retool?
Crazy prices. I'm always wondering for what kind of companies things like Retool are. Internally, when we want to whip up a crud app, we use Nextjs with T3 stack and you are up and running in two-three hours.
How new is this Retool product? The idea that OpenAI, Amazon, NBC, Mercedes, and Doordash all use it seems dubious.
See comment by the CEO:
https://news.ycombinator.com/item?id=39476663
Retool is very widely adopted by major companies.
Retool is very widely adopted by major companies.
Sure, but that feels like validation for Retool rather than Form to DB.
I may very well be nitpicking unfairly here, those marketing "trusted by" blocks on brand new products just always rub me the wrong way.
I may very well be nitpicking unfairly here, those marketing "trusted by" blocks on brand new products just always rub me the wrong way.
Retool is popular for building internal dashboards on top of you data. It has been there for many years
Retool has sure, but I'd expect the Form to DB homepage to be validating this product rather than the team behind it.
I said this in a sibling comment too, I may just be unfairly nitpicking here but these "trusted by" marketing blocks just rub me the wrong way when the product is brand new.
I said this in a sibling comment too, I may just be unfairly nitpicking here but these "trusted by" marketing blocks just rub me the wrong way when the product is brand new.
Would be nice if there was some kind of demo or docs. Like this is basic landing page stuff at this point.
Here are the docs: https://docs.retool.com/apps/forms. Just added a link to them from the landing page. Agree we should also add a quick demo to the landing page
And pricing! When this kind of service doesn't make its pricing clear it immediately puts me off.
Retool Forms is completely free. No arbitrary limits on the number of users, forms or submissions. I'll make this clearer on the landing page.
For building Retool Apps/Workflows, our pricing is here: https://retool.com/pricing
For building Retool Apps/Workflows, our pricing is here: https://retool.com/pricing
Or... An open-source alternative
https://budibase.com/forms
https://budibase.com/forms
I remember Microsoft InfoPath, for which this appears to be a competitor.
I never really understood why InfoPath didn't catch on better.
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.
- 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.
Oh my goodness, what a blast from the past! Didn't you have to define forms using XML and XSLT? If I recall right, you had to host it either in SharePoint or InfoPath forms server.
Don't get me wrong, it was an amazing tool for its day, but had some steep and proprietary onramps that limited adoption. I'm personally not at all surprised that it faded from general consciousness.
Don't get me wrong, it was an amazing tool for its day, but had some steep and proprietary onramps that limited adoption. I'm personally not at all surprised that it faded from general consciousness.
You (usually) built forms using the graphical form editor, and they could be packaged as an executable desktop application that emailed you results back. If you wanted them to be in a browser they had to be on SharePoint, of course, because it's the usual Microsoft lock-in thing.
It was surprisingly good at letting non-computer-people build data gathering applications though.
It was surprisingly good at letting non-computer-people build data gathering applications though.
Did InfoPath have any other workflow/automation/integration things available besides BizTalk (which is the one thing I saw InfoPath with)? Because if not, then it's no surprise that it didn't catch on.
I remember it inserting rows straight into an Access or arbitrary-SQL database, and the integrations running from there. It was a data collection tool.
It’s wild to read “there’s no one click form to database tool” in 2024 when 25+ years ago one was available in Vermeer FrontPage and of course ColdFusion had a database form wizard.
Plenty “SSR” (the only place to render, so it wasn’t called that) tempting engines of the day, if you had an ODBC connection, you could generate form handlers with “one click”.
Of course, this was also before OWASP (started circa 2001)...
Plenty “SSR” (the only place to render, so it wasn’t called that) tempting engines of the day, if you had an ODBC connection, you could generate form handlers with “one click”.
Of course, this was also before OWASP (started circa 2001)...
It's strange this doesn't support plain nosql databases. I'm not sure I see the value in a full blown relational setup for... form submissions.
It’s a miracle, it didn’t get flagged
Form to db is simple task, the hard part is the table.
Agree, the table is the component we’ve spent the most time building: https://retool.com/components/table-new
This links to the legacy table component.
Which should I use for new projects? I assume the new one?
Which should I use for new projects? I assume the new one?
Sorry just updated!
I'm curious what's the generated sql for the table with grouped rows ?
hello! engineer who worked on the new Table component here. the grouping actually happens client side, so there's no generated sql. it's compatible with any data you bring into Retool, and is configured by simply selecting one or more columns in the Table you'd like you group the rows by.
Looks cool but what is the pricing? Get started for free kind of implies that it isn't free after a while or..?
So Oracle forms, but with UX/DX :-)
Don't underestimate how important that is. I can tell an Oracle web app a mile away and I immediately now it is going to be an absolute pain to use: UI components too small/big; standard form controls missing; horrible lag etc
Oracle forms 3 on a terminal was actually a super nice tool: very fast way to edit database data, but you have to know all the keyboard shortcuts. Bit like Vi for database forms.
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.
cool idea, i'm always curious about the customer logo sections.
i assume for amazon, mercedes, etc. it's talking about retool? or are there some employees using formtodb?
i assume for amazon, mercedes, etc. it's talking about retool? or are there some employees using formtodb?
Strange the URL for this isn’t retool.com/formtodb
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!
Okay but what about the reply to that form?
Ladies and gentlemen of the Hacker News jury, I’m just a caveman. I fell on some ice and later got thawed out by some of your scientists. Your world frightens and confuses me! Sometimes the honking horns of your traffic make me want to get out of my BMW.. and runoff into the hills, or wherever.. Sometimes when I get a message on my mobile phone, I wonder: “Did little demons get inside and type it?” I don’t know!My primitive mind can’t grasp these concepts. But there is one thing I do know – when we get a "new" solution that replaces all the former solutions, and uses React or HTML, IT MUST BE MAGIC!
So we decided to build a form builder. It allows you to:
1. Send data directly to your database (Postgres in our case), your data warehouse, or wherever else you want it
2. Write JS almost anywhere on the front-end, including libraries like moment and lodash, for custom validations, conditional logic, and data parsing
3. Run any arbitrary code in form submission (or validation), via our Workflows product
4. Store it in our database (where we give you a connection string), or your own database
5. Self-host it in your own VPC
And it’s free with no arbitrary limits on the number of users, forms or submissions.
I’m hoping to ship a bunch more features like integration to any REST API, more styling options, etc. If you have any feedback please let me know!