Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I build software quickly

evanhahn.com

Post reply on HN
Print view View original

211–215 of 215 posts

Re: How I build software quickly

#211

Post by pdhborges »

creshal wrote: post #193
pdhborges wrote: post #62

Earlier quoted context omitted.

What do you save by going with sqlite vs how much pain are you going to endure in the future?

I save having to deal with a full-blown DBMS daemon accessed through a network boundary unless I need this, and I have approximately zero pain, because I read the documentation and set up my database schemas to work on both solutions (and use WALs so sqlite is rock stable). I also know how to open a file on the command line if I need raw database access for some reason (very rare with django anyway, django's console…

It's not FUD. For all the trouble you claim to have with Postgres I experienced 0 of it in the last 4 years. The only thing extra for a simple setup is a couple of lines in your docker compose files which is completely amortised because you already have a multi process architecture with Python anyway (proxy + webserver + web server works). The upfront cost is so small that for me the expected total cost will rarely make sense even if you assume that your application has 1% of chance of scaling beyond what you can do with sqlite.

Re: How I build software quickly

#213

Post by kukkeliskuu »

pdimitar wrote: post #210
kukkeliskuu wrote: post #209

Earlier quoted context omitted.

That is on my list of things to learn. It is not high priority, though, because I don't think Phoenix LiveView is extremely boring technology at the moment. The user base is not large enough.

A lot of stuff is quite commoditized already, and I never found the size of a user base a convincing metric to judge by (not to mention the chicken-and-egg problem that you just demonstrated). People are doing genuinely hugely impressive production-grade work there, and I am currently looking at a SigNoz dashboard while >200 users are frantically clicking on dozens of places in our UI (contains many reactive bits); o…

The context of the discussion is how to create apps extremely fast. If I would optimize for something else, it would be a different story.

Re: How I build software quickly

#214

Post by pdimitar »

kukkeliskuu wrote: post #213
pdimitar wrote: post #210

Earlier quoted context omitted.

A lot of stuff is quite commoditized already, and I never found the size of a user base a convincing metric to judge by (not to mention the chicken-and-egg problem that you just demonstrated). People are doing genuinely hugely impressive production-grade work there, and I am currently looking at a SigNoz dashboard while >200 users are frantically clicking on dozens of places in our UI (contains many reactive bits); o…

The context of the discussion is how to create apps extremely fast. If I would optimize for something else, it would be a different story.

Oh well, if you find that way then many people -- myself included -- would be very interested in your blog post. Bootstrapping remains a tricky territory, not because it can't be done very quickly but because it leaves a lot of tech debt behind that has to be paid off, inevitably, at one point.

Re: How I build software quickly

#215

Post by lmm »

kukkeliskuu wrote: post #208
lmm wrote: post #202

Earlier quoted context omitted.

> Backend is needed in any case Well, sort of. Much as I hate the idea, maybe Next.js for everything is the way to go, bashing out a CRUD app there is very quick. > create partial forms and return HTML fragments, instead of full pages I loved that approach with Wicket and made systems that way for many years, but it just isn't good enough these days, at least for a website that's going to be used in more than one loc…

I assume you are talking about geographical distribution of the user base. I don't have experience implementing apps that require heavy geographical distribution, but why does REST/JSON work better for this? I don't have experience with Wicket, but with HTMX, I have tried to make components very small. For example one switch button is one component. Loading that is very fast in my experience, as compared to reloading…

> I assume you are talking about geographical distribution of the user base. I don't have experience implementing apps that require heavy geographical distribution, but why does REST/JSON work better for this?

Once you see the smoothness of fully local UI transitions compared to doing a WAN roundtrip, you can't go back, even if it's objectively not a huge difference. Things like switching between tabs, or hierarchical dropdowns where the choices in the second dropdown depend on what was chosen in the first dropdown, doing a network roundtrip to load an HTML fragment is maybe OK over a LAN but it's a nonstarter over the internet.

So your state management needs to be at least partially local to the frontend. And in my experience the only approaches available for that are a) React or b) ad-hoc hacks; some frameworks build the ad-hoc hacks into their builtin components so you get smooth local UI transitions as long as you're sticking to the happy path, but that ends up not being enough.

Post reply on HN