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

111–120 of 129 posts

Re: Form to DB

#111

Post by codeulike »

EvanAnderson wrote: post #92
codeulike wrote: post #74

Earlier quoted context omitted.

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…

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.

Re: Form to DB

#112

Post by EvanAnderson »

codeulike wrote: post #111
EvanAnderson wrote: post #92

Earlier quoted context omitted.

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…

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

Re: Form to DB

#113

Post by kinj28 »

nextworddev wrote: post #86
kinj28 wrote: post #19

Earlier quoted context omitted.

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

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.

Re: Form to DB

#114

Post by recursivedoubts »

throwaway60320 wrote: post #110
recursivedoubts wrote: post #91

Earlier quoted context omitted.

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?

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

Re: Form to DB

#115

Post by akvadrako »

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

Re: Form to DB

#116

Post by sodapopcan »

throwaway60320 wrote: post #109
sodapopcan wrote: post #98

Earlier quoted context omitted.

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?

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.

Re: Form to DB

#117

Post by swimmadude66 »

dvdhsu wrote: post #43
mehal wrote: post #40

Earlier quoted context omitted.

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

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

Re: Form to DB

#118

Post by rmbyrro »

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.

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 into all browsers by default. It doesn't make your resume shine, either...

Re: Form to DB

#119

Post by breadwinner »

prakashn27 wrote: post #89
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 miss acccess too. Good old days

It is still available.

Re: Form to DB

#120

Post by alexi-c »

revskill wrote: post #46
cuffe wrote: post #30

Earlier quoted context omitted.

Agree, the table is the component we’ve spent the most time building: https://retool.com/components/table-new

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.
Post reply on HN