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.
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
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 I listed above). Surprisingly, the only way to build a form on top of my database was by a) building my own backend (probably via node), and b) building my own frontend (probably via React, and then maybe via formik). There was no “one click” form-on-top-of-my-database tool available.
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!
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.
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.
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.
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.
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.
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.
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.
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?
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.
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?
- 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
Sorry but this sounds like they just didn't know how to write React and didn't take the time to learn it. You can write React and have 2 runtime dependencies in total - react and react-dom. Or you can go for preact and have exactly 1 runtime dependency - preact. Everything you need is there.
Time-to-interactive has never been a problem for me. My code-splitted bundles are so small they're pre-loaded quicker than the server-rendered HTML code. And builds? My apps - even big ones - build in single digit seconds (using swc or esbuild), and small ones like forms we're talking about in less than a second. The only thing that takes long time is TypeScript typechecking, I do that in a separate task in my CI while the build is long done and tests are in progress at the same time.
I'm not saying all this is super easy - obviously it's the product of using React literally since it's first public beta release. But it's also not impossible to do, and setting up a htmx and a server to run it on is IMHO similar complexity.
The biggest mistake people do - they use stuff like create-react-app with a bunch of absolutely unnecessary cruft. And then they follow some tutorials made by a dude who knows React for 2 months. Just read the React docs (except for the create-react-app part) and you're good to go.
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.
> 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.
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.
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.
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.
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.
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...
(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.
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?).
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.
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.
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].
we'd love to make the migration as easy as possible and would definitely be open to building an import tool. In the meantime if you're migrating feel free to email me at jamie at retool.com and I'd be happy to help import
Thanks! Yes agree this is very important. We do show references from Retool Vectors out of the box, so you can see what embeddings were used to generate a response. If it'd be helpful I can walk you through a few internal Q&A bot examples which display references - jamie AT retool DOT com
Today we use a cosine similarity search but we're planning to integrate with more vector databases and allow you to customize the search logic soon. Is there a particular query method you're looking for?
Yes working on adding llama2 and AWS bedrock support right now for open source models. But we also want to let users bring their own models - is there a specific model you're looking for?
Who knows longer-term I'd love to help users fine-tune their own models on llama2/gpt-3.5!
Llama 2 and Bedrock is exactly what we are looking at.
I have been playing around with it for a priority enterprise use-case at my org, and this seems promising. We tried using the Retool vectors, but it really struggles to pick up the right context if we dump data without pre-processing it. For example, adding a URL without stripping header/footers/disclaimers/cross links etc. I think adding some steerability to the context selection process is going to be key.
I also have to admit that while retool is extremely feature rich - the user-experience is clunky and the learning curve is steep.
Thanks for the feedback. We're currently working on customization with the url parser and trimming headers/etc makes a lot of sense. If you're able to share more about your use case (jamie AT retool DOT com), happy to get it tuned on your dataset
Excited to already see some great open source projects in this space (Langchain, Llamaindex, Axilla, etc) many of which we're exploring using for this project.
Just to be clear Retool Vectors is completely free (we're even taking on the LLM costs). We put the embeddings in a free postgres DB (and soon other open source vector DB providers) and give you the connection string so you can take it anywhere
We changed our pricing earlier this year to be a lot more affordable for use cases with high end user counts (https://retool.com/blog/pricing-v2/). Let me know if that works better for you?
If you’re looking for external apps, check out portals (https://retool.com/products/portals) that has custom volume discounts for many, many users
I mean, let's be serious for a second, MS PowerApps, an Enterprise tool every CIO knows by now is potentially cheaper than Retool's unknown Enterprise price: https://powerapps.microsoft.com/en-us/pricing/
There is not much to talk about, I don't see it, maybe Retool is targeting a different ICP. I don't see how a CIO would go for Retool when they can reach for PowerApps which is also potentially cheaper. PowerApps also integrates with the rest of the MS stack.
I am not saying I like it, I prefer Slack over MS Teams too, but Retool is a very hard pitch right now for Enterprise, and I don't see AI driving any points in that discussion.
For building Retool Apps/Workflows, our pricing is here: https://retool.com/pricing