Ask HN: How to pick tech with longevity?

Your 2001 .Net web app will probably still run and you can probably find devs to work on it as is or upgrade it.

I've also built stuff on actionscript 3/flash right at the tail end of the flash era, it sucks to have the floor fall from under you like that but what can you do.

who knows, maybe in 10 years the web itself will be dead and all we'll have left are walled gardens (shudder). It's probably best to learn to embrace the change.

PHP is a good pick to avoid that, but you need to make sure not to fall behind on too many major versions (note in PHP a major version is 7.1 or 7.2, it is not semver). Make sure that you are at least only 2 versions behind.

Upgrading one major version for PHP is not that much work because PHP values backward combability, but upgrading many versions in one go can become complicated. I upgraded an old system from PHP 5.2 to PHP 7.4, doable but time consuming. There are tools that can help you with this.

Other things to avoid with PHP is not using any odd or uncommon extension, try to always solve your problem with pure PHP and only use common extensions that are well maintained.

Don't rely on weird php ini settings (like unserialize_max_depth or max_input_vars) or hacks that exploits undefined behavior in either PHP or in the browser. Follow standards.

Try to do much as possible with server side rendering to avoid being dependent on a fancy JavaScript framework. If you need dynamic rendering of components on a page, send pre-rendered HTML fragments with ajax to the browser and use something like jQuery or htmx to swap in the new and out the old. This way you can have all UI components as backend templates, thus keeping it nice & simple. No need to send JSON from the server and then have fancy JS framework converting it to HTML.

Upgrading old PHP frameworks is a mess. I have learned that the hard way and even modern frameworks can be messy between major versions or if there are too many major versions (like Laravel). That is why I don't use large frameworks at all. Pick a small one (like Slim) or do it yourself (what I do). I focus more on using good & stable libraries when needed. Make sure to decouple your code from the framework, the majority of the project code should be outside of the framework or at least not be dependent on specific framework features, extract what you need from the framework first, then pass it on to your decoupled code.

Don't use an ORM, write SQL, that is more future proof.

Composer dependencies, that is also important to upgrade often.

You have to maintain source code, even if the project is considered feature complete. Plan a day or half a day a year to upgrade dependencies and fix any bugs.

Use an error reporting server software like Sentry to catch all bugs in your project and make sure to fix them a soon as possible. Always use E_ALL and don't ignore notices or deprecated warnings, in the future they can become bugs.

Use strict typing and type hints for functions, will catch any changes between upgrades that you missed, will throw TypeError and if you have your Sentry (or similar) configured correctly you can get an bug report immediately so you can fix it. IMHO it is better to fail fast than having hidden bugs. Make sure to have a fast deployment step so can push out bug fixes fast, ideally push to some branch in git and it auto-deploys.

Use tried and mature technology like the LAMP stack. Avoid newer technologies like NoSQL, message busses and other hyped technologies. Most problems can be solved efficiently with PHP, SQL and cron.

Minimize number of external dependencies, don't rely on specific operating system features, like bash, or make assumptions where you are running your application, like specific server addresses.

Don't have complicated build or setup steps for you project, like a huge Makefile or something, that also has a tendency to break down over time. Instead write your code to almost be zero configuration. It should be possible to do a git pull add db login to a simple config file then done. If you still need some setup code, do it in PHP, that way you also avoid duplicating project settings and avoid an extra dependency.

Don't have complicated .htaccess files with complex routing and what not, that will lock you into apache forever and the risk of having double routing, both in .htacces and php.

Always run MySQL with the strictest mode set, so you can't write bogus data to it (like non existing dates and zero dates). Makes it easier to upgrade MySQL versions.

Follow the KISS principle. Don't write overcomplicated abstractions that over time will become a nightmare to maintain.