[foepys]

People are downvoting you but are overlooking the fact that it's not always about making things in the newest tech but more often than not about making things work. Most software will only be seen by industry specific users that don't care that the program is React Native and runs on AWS. A simple VBA script is sometimes completely sufficient to input the data into a spreadsheet. Scott Hanselman called devs doing this "Dark Matter Developers" [1].

32bit VB6 programs are still able to run on modern Windows 10 machines, even on x64. The hours that would've been lost on porting everything to the newest macOS can be spent on new features or customer wishes. With the .NET Framework it's even possible to seamlessly use VB and .NET in the same program which combines old and modern technology. It's officially unsupported but it works and even gets bugfixes sometimes.

1: https://www.hanselman.com/blog/dark-matter-developers-the-un...

[bgroat]

I don't want to say "anti-pattern" because that's not what I mean...

But new tech should be the last resort.

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

[Retric]

That’s a little far, old doesn’t mean good. The bleeding edge often gets abandoned, but tech has generally been improving over time. IMO, the sweet spot starts when something was a fad ~5 years ago and is still reasonably popular.

[DaiPlusPlus]

> IMO, the sweet spot starts when something was a fad ~5 years ago and is still reasonably popular.

That would mean it's okay to use Angular today, but dev trends (and Google's support "policy") would advise against that.

[yen223]

A good reason to wait a few years is precisely so that we have a clearer picture of what strengths and deficiencies a piece of tech brings to the table, especially out in the real world.

We have a good picture of how Angular and React works in production now. We cannot say the same for something like Svelte.

[_0w8t]

React is far from being stable. It deprecated a lot older API, added entirely new concept of hooks.

If one wants stability, then PHP has a way better track record.

[scrollaway]

Nonsense. React is extremely stable. It indeed added hooks, deprecating exactly nothing in doing so. React deprecations are very few and far between.

[mattmanser]

The MVC and ORM revolutions are the counter-argument to this.

Rails/Django, then ASP.Net MVC/Laravel/whatever Java was was a massive step forward. If you didn't use it, you were hamstringing yourself. People switched to Rails in droves.

As were using ORMs. You'll still get people quibble about this, but never having to go through the tedium of updating 101+ SQL statements when you add a column in a pain you young'uns will never know...

JQuery was actually another example. Cross browser Ajax statements were annoying, plus just manually adding individual HTML nodes in HTML was laborious.

[pjmlp]

I have not seen people switching to rails in droves over here, it was a fashion wave that came and went.

Apparently they are all now learning Elixir after a short migration wave over to Clojure.

C++, Java and ASP.NET over here for the last 20 years.

[valenterry]

ORMs are not the only way to avoid/solve the problem of having to update many SQL statements. People complain rightfully about them.

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

[smitty1e]

I've never ever tried VBA.Net.

But my private NVBC (NecroVisualBasiCon) repo has some great stylings that I tap into at least once a year.

Nevertheless, when are they going to relase Office with Python bindings included?

[jussij]

One minor correction which is there is no such thing as VBA.Net.

There are basically three VB ecosystems.

Visual Basic which many refer to as VB6 and it represents the last version every released.

VBA which is Visual Basic for Application and lives on to this day as an embedded language for Microsoft products like, Word, Excel, Outlook etc.

VB.Net which is an implementation of the Visual Basic language running on the .Net Framework.

[tonyedgecombe]

There was also VBScript, one of the two active scripting engines shipped with Windows and available from IE and WSH.

[JJMcJ]

Not exactly Python bindings but there is a package called Xlwings that provides a Python<->Excel interface.

Somewhat clunky and slow but it does work.