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

121–129 of 129 posts

Re: Form to DB

#121

Post by account-5 »

codeulike wrote: post #74
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 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 rel…

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.

Re: Form to DB

#122

Post by throwaway60320 »

rmbyrro wrote: post #118
throwaway60320 wrote: post #108

Earlier quoted context omitted.

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 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…

(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.

Re: Form to DB

#123

Post by throwaway60320 »

recursivedoubts wrote: post #114
throwaway60320 wrote: post #110

Earlier quoted context omitted.

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?

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 muc…

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.

Re: Form to DB

#124

Post by recursivedoubts »

throwaway60320 wrote: post #123
recursivedoubts wrote: post #114

Earlier quoted context omitted.

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 muc…

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…

¯\_(ツ)_/¯

there's always gonna be a hypothetical objection if you want there to be

maybe read the essays and/or book, maybe try it out on a simple project

or don't, doesn't really matter much

Re: Form to DB

#125

Post by endofreach »

throwaway60320 wrote: post #108
cabalamat wrote: post #96

Earlier quoted context omitted.

> 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.

Just saying: You can do input validation without JS using the pattern attribute.

Re: Form to DB

#127

Post by antonybello »

hipadev23 wrote: post #32
dvdhsu wrote: post #21

Earlier quoted context omitted.

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, Interva…

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 rea…

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

Re: Form to DB

#128

Post by Terretta »

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)...

Re: Form to DB

#129

Post by cabalamat »

throwaway60320 wrote: post #108
cabalamat wrote: post #96

Earlier quoted context omitted.

> 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.

If people typically get 10s of errors on a single form, it might well be better to split it up into several sub forms.
Post reply on HN