[nicoburns]

> If nothing stable, decades old, and well documented can solve the problem then reach for hot new-ness

I think it's a little more nuanced than that. Usually the older technology is more stable and better documented. But not always. Sometimes the new hotness is the new hotness precisely because it's better in these kind of categories.

[tl]

It's 100% true, but only in broad strokes. My personal ladder is

- paper

- text files / spreadsheets

- desktop apps / local db

- SSR web apps / single database

- SPA or mobile app / cloud storage

The only thing that challenges that is the reality that around a decade ago smartphones with tiny screens and no filesystem access eclipsed desktop computer, and we're still reeling over how much more expensive that makes development.

[rablackburn]

Are SSR/SPA solutions really that much more expensive than local apps to develop?

The start of my ladder looks much the same as yours except I jump from local files straight to single database SSR/SPA. Maybe slightly more complicated than a local app because you need auth, but when prototyping something I just use basic auth to start.

Chuck it up on a $5 DO box and you instantly get:

- Multidevice access, desktop and mobile (write mobile-first css and the tiny screens aren’t a problem)

- a UI that’s trivial to hack on (HTML and css are easy)

- likewise, a technical base that’s easy to extend. Drop in react, build out the api side and use it as a source for other projects, etc

All this assuming you have reasonably reliable network access, and even then you can build it as a clever PWA falling back to local storage if you need to (I think, prototyping that is still on my todo list)

Heck, save yourself $5/month and stick it on a raspberry pi at home.

It’s truly a golden sweet-spot for personal software tools. The only external dependency that irks me is needing a domain name.

[tonyedgecombe]

HTML and css are easy

All of the constituent parts are easy. It's when you tie it all together that it starts to get complex. There is no doubt there are many more moving parts in a modern web app compared to desktop. I did a few VB projects and I needed know two things, VB6 and a database.

Of course we can't go back, enterprises are rightly presenting their systems directly to the customer, you can't do that with a desktop app. None the less it does feel more complex than it needs to be.

[nicoburns]

> I did a few VB projects and I needed know two things, VB6 and a database.

Desktop apps are relatively simple if you only need to target one platform. Both windows and macOS have good options accessible from managed languages. But if you want to do cross platform then the complexity rockets.

[polskibus]

Yes they are more expensive to develop. With a winforms or wpf gui you can iterate much faster than with a web one while supporting rich interactions, thinner tech stack, faster feedback loop.

[fuzzfactor]

I see no legitimate way to call a phone with no filesystem access _smart_.

[bgroat]

You and Retric are right. I'm imagining a checklist of: - Stable - Well Documented - Age

In descending order of importance.

When choosing between any technology choose the one that is most stable.

If multiple options are on a stable release, choose the one that is best documented.

If multiple stable releases have excellent documentation, choose whichever is oldest.

I don't think this framework is always (or even often) right. But it works for me

[makapuf]

My checklist would be (I'm eager to know other people correct me) suitable (does it some my needs) , stable, available (including documentation, live q&a resources like stackoverflow, blog posts explaining how- not new ones but existing and up to date regarding the version available), and simple.

[josephg]

I try to adapt my checklist to the problem at hand. Sometimes I'm making something as a hobby project, or to solve a problem right now. Sometimes I want to write code that will outlive me, and sometimes I'll just throw some code at the wall and call it done.

Each situation necessarily results in different priorities and tools. I wouldn't TDD a gamejam project, and I wouldn't start a multi-year project in zig - at least, not yet.

For infrastructure projects I want well written deps which are simple, easy to use and have good documentation. When I'm evaluating something I often read bits of its source code (eg to figure out how to do something not listed in the examples). You get a sense of where to put things that way - actix (the actor library, not the web library) is very carefully designed, but seems to go a bit overboard inventing new concepts (+ associated traits). Tide feels pragmatic - its a bit sloppy with allocations, but it doesn't seem to really care. It wants to be fast enough and good enough while being simple to use.

For hobby projects I like to follow my nose and pick whatever seems shiny. Over the last few years I've learned svelte, typescript, snowpack, rust (and some rust libraries), zig, wasm and other stuff. I like to make some risky bets and then just play the hand out and see what happens. And I use that as fuel for when I make longer term projects. I'm making a little database at the moment and I'm using rust - which is much slower for me to write (compared to nodejs) but it matches the values of the project I'm working on to a tee.