Ask HN: I just want to have fun programming again

[jb1991]

I've written in many very different languages in a professional full-time capacity in my many-year career. Now I'm interested in building something new and I have a clear idea in mind with some code already in C++ to proof-of-concept it for myself, but I'm struggling to find a direction forward that would be... fun. I don't mind challenging work, but I like an environment that feels sane and logical and where I am not facing loads of incidental complexity along the way. I'm also attracted to implementing my app cross-platform.

I just want to have some fun writing something without headaches, and that is seemingly less and less easy to achieve today. I'm not a fan of the complexity of either JavaScript or C++, and while I very much like Swift and working in the UIKit world, it's not so portable to platforms that many use.

I feel like there aren't really any good options in software development any more. It's always one big compromise with lots of possible decision fatigue. Every direction has drawbacks.

If I could write an app in a good static-compiled language that did not require extraneous expertise in CSS but that shipped on a web page and looked good using tools only in that language, with good interop with an HTML Canvas, that would be one possibility, but it is again a compromise -- no easy multithreading, dealing with all the front-end baggage to bundle or deploy such an app, etc.

Any recommendations? I'm not afraid of learning an entirely new language too.

[eddieroger]

This thread has a lot of language suggestions, but I think you need a fun problem to solve. Pick a toy app and work on it. Learn embedded programming with an Arduino. Write an iPhone app to track when you feed the dog. Make a karaoke app for Android. If you pick a project you'll enjoy, the language won't matter. Use whatever is best for the platform. The fun doesn't come with the language, it comes with seeing your project come to life, or others' reaction to the cool thing you made. Every language sucks and every language is the best depending on who you ask. Don't focus so deeply on that part. Solve cool and fun problems.

I've had a long time dream of getting a broken jukebox and gutting it for a Raspberry Pi, but keeping the external interface in tact. I know next to nothing about hardware engineering, and can't write more than ten lines of Python without needing to Google something, but I finally got a broken juke in need of fixing, a multimeter, and a hard drive full of music ready to go. The fun isn't the Python or learning GPIO, it's that eventually I will have a cool retro jukebox with hardware and software I wrote in my basement.

[scubbo]

Big +1 on this. If you're OK with a broader definition of "programming" and have a bit of money to throw around, I've found tinkering with https://www.home-assistant.io/ to be very satisfying. I got more sense of accomplishment from scripting "text me when I leave the house if I forgot to set the alarm, and turn on the front porch lights when I arrive back if it's after sunset" than I did from months of corporate work, even though the actual _difficulty_ was much lower. I can _see_ the results of my work, and benefit from them most days!

[beamgirl]

I've found that sometimes the hardest issue is getting mentally unblocked enough to find a problem that seems approachable. One of the best ways I've found to prompt you is to start browsing libraries till you find some that imply a goal you might enjoy. My last fun personal project was making a command line AppleTV remote with a lib for doing such. I'd been so burnt out till I saw a random link to the lib, and it just sucked me in.

[codazoda]

I did a similar fun project. I created my own slot machine. I made a small shelf like cabinet out of wood, set a TV on it in portrait mode leaning against the wall, added a few lighted push buttons, and dropped a Raspberry Pi inside. I never finished the software side, but I was pretty proud of the looks of the machine.

[jasode]

>, but I think you need a fun problem to solve. Pick a toy app and work on it.

I think you've read the op's question too fast and not fully empathized with his situation. He already found a problem when he wrote, "I have a clear idea in mind with some code already in C++ to proof-of-concept it for myself, ..."

The bulk of op's words surrounding that goal is asking about the process of coding being fun. But then we get several (well-meaning) advice to just focus on the end goal being fun rather than the coding process being fun. Yes, that's a valid perspective -- but a lot of people also require the process itself to be fun too.

E.g. Let's say a programmer wants to code a custom music library manager:

- John wants to use Lisp because having a REPL for quick iteration and feedback loop is "more fun".

- Jane would rather use Python because having a bunch of 3rd-party libraries for lots of tasks is "more fun" than coding a lot of boring low-level tasks from scratch.

Advising people to have a sort of zen enlightenment of only caring about the final product and being totally detached from the process is unrealistic for many programmers. It's a perspective that may work for you but for many others, the particular tools do matter in terms of joy.

In the op's case, he wished that there was a tool that was cross-platform, with easy multi-threading, no incidental complexity, etc. (To answer op's question, there isn't such a tool that meets all requirements.)

We often see variations of the lament: "I wish programmers would quit focusing on particular programming languages. They're all Turing Complete. Just pick one and get on with it."

That's true if the product is corporate project. In that case, the employee needs to suck it up and just use whatever (not-so-fun) programming tool to get the job done. But personal projects like the op's question can try to look for alternative coding environments that are more fun to use.

An analogy in woodworking was illustrated by 2 different shows on PBS:

- Norm Abrams (The New Yankee Workshop) used power tools to build his projects.

- Roy Underhill (The Woodwright's Shop) used hand tools to build his projects.

Roy Underhill likes hand tools because power tools are noisy. On the other hand, Norm Abrams uses power tools as they're fast. Neither are wrong. Both can craft a chair but the tools still matter.

A lot of woodworkers can't just detach themselves from the usage of tools and only focus on the final product. The choice and use of particular tools is a core part of the joy.

[bbarn]

Sounds like a super fun project. Did you find one with the moving pages for album pictures or with the pink yellow and blue "ticket" like song listings, or? Those are so awesome, I can think of all kinds of fun ideas to retro-mod either.

[flohofwoe]

I found fun again in two easy steps:

(1) Unlearn the "large team workflow mindset" and embrace the "single developer mindset" again. You don't need a plan, a Kanban board or a bug database, just an idea in your head. Get rid of "big languages" which are good for team work, but just a hinderance when working alone. In my case this meant: dropping C++ and embracing C (today that would be: Zig). Focus on getting shit done like when you started out with programming instead of agonising over design decisions. It's better to throw away something that doesn't work than wasting too much time upfront with planning (and then it still won't work). At least you still learned something valuable. Try to do the 'planning' part passively in the back of your head out in nature while taking a walk or some other outdoor activity.

(2) Pick a challenging problem where you have no idea yet how it works, but which you would like to know. In my case this was "home computer emulators".

...well 3 steps, step 3 would be: don't set yourself any deadlines for this sort of "fun stuff".

[shortcake27]

> Unlearn the "large team workflow mindset" and embrace the "single developer mindset" again

This worked for me. A few months ago I quit a really great job partly because I was struggling with motivation. Fast forward to today and I’ve got a couple freelance projects on the go which aren’t even that interesting, yet sometimes I can’t stop working on them.

I think the large team workflow took far more of a toll on me than I realised at the time. A single line of CSS might start with a discussion in Slack, followed by a ticket, which then gets brought into a sprint some unknown time in the future. Make the change and wait days for the PR to get approved, PR might have a discussion so you need to find the original discussion in Slack, someone might suggest multiple different ways you could have made the change even though it makes no difference. Someone else might suggest that because you’ve touched this line of code you should refactor the entire file, to avoid conflict you just make all the changes even though you disagree, put it up for review again, someone else says they liked the first way you solved before any changes but whatever, tag it in a release go through QA, QA and BAs interrogate you on why you refactored more than the ticket, QA picks up issues that have nothing to do with your change so you have to figure out how long those issues have existed for, finally 4 weeks later your change is in prod and you can move onto the next task.

Working by myself has been incredible. I don’t miss having to justify every technical decision to a team that can’t ever seem to agree on anything. I’m able to react and ship so much faster and the product is more stable and of a higher quality (subjective) than anything I worked on within a team. I’m not sure what this means for my future prospects, but also not too worried at the moment.

[0xdeadbeefbabe]

> (1) Unlearn the "large team workflow mindset"

That's how Darth started.

[agumonkey]

I did microagile extreme few years ago, trying to make a tiny feature with a minimal amount of impact and a tiny bit of parametricity for obvious options. Was a fun constraint to find fun.

[HarHarVeryFunny]

You seem to have two very conflicting wishes here:

1) To have fun 2) To write a cross-platform web-base app with good HTML canvas inter-op ...

If you really want to deliver this cross-platform app, then it seems that's going to be more work than fun, although no doubt good tool/framework choice can help minimize the headaches.

For a fun project it seems better to avoid all of the things that you already know are going to make it not fun!

My current fun project is writing a compiler to run on an old 8-bit system (initially targeting en emulator) ... 99% useless, but fun, and I get to choose whether to implement the bits that are stupidity on behalf of the language spec, or extend the language to make it better, etc, etc - no practical considerations forcing requirements on me, since it is purely for fun.

[heisenbit]

Exactly, there are plenty of frameworks which make this possible but even with the best you are hitting plenty of potholes adding incidental complexity on the way to a polished end product.

Limit ambitions and focus on getting velocity into roughly the right direction. Have fun and worry not about having fun.

[yoz-y]

I agree, solving multi-platform issues is never fun. Most of it is just either a chore, or getting locked into a very constraining framework.

[latexr]

> while I very much like Swift and working in the UIKit world, it's not so portable to platforms that many use.

Your title says you just want to have fun programming but your post is full of other requirements. You need to decide if having fun really is what you’re after—in which case it seems you’ve found your answer—or if it’s secondary to some other metric such as customer reach.

There is always a compromise. No solution is all good things at once, including easy, performant, and cross-platform. If that existed we’d all be on it. You’re clamouring for a past which I’m doubtful truly existed.

[chubot]

Yeah exactly, even though I'm more of a Linux user than an Apple user, one thing I do admire is that there a lot of apps with UI polish because they JUST build for one platform.

They just focus on making it exist, without premature generality.

[phoehne]

This will probably get lost in the noise. But I think what sucks the fun out of side projects is where your agency is taken away by the ‘right way’ to do things. That’s what makes embedded and a lot of Raspberry Pi projects so fun. There isn’t a large collective telling you to use X build tool plus Y framework, and if you don’t, it’s because you’re doing a bad job and don’t care. And if you ask a question like ‘how do I…’, the response is Y takes care of that for you, you should really use Y.

Pick up an Arduino and there’s no one right answer. It’s still very hobby oriented, so a lot of people do fun an wacky things. The learning curve is fairly short. What I call the ‘book count,’ or how many books you need to read to be productive, is pretty low. On the other end of embedded, it gets very formal, very quick, but that’s for professional embedded developers.

Or, pick a ‘dead’ language. Go to some vendor like thrift books, or hunt used book stores, for books on that language. You might find some for $5. There’s no pressure, and you have full agency to make the greatest or the worst decisions you want. And a lot of the communities around these ‘dead’ languages are a lot of fun.

[robinsonb5]

Agreed - there's a lot to like about embedded programming - it's the antidote to bloat, and encourages a "bonzai" philosophy towards programming. It also means you can have total control and understanding of every byte of the firmware, which - for me at least - is much more conducive to fun than sellotaping together chunks of opaque bloatware.

> Or, pick a ‘dead’ language.

Or a dead platform! Loads of retro platforms still have active and creative communities, and finding new ways to make an old computer do cool things is a lot of fun.

That's where I find my fun, anyway - nothing about what OP want to achieve sounds compatible with fun to me - but that's probably just me showing my age!

[andreygrehov]

Some recommendations for fun (web) programming:

- Forget about the JavaScript ecosystem, don't even touch it, it's a monster

- Use htmx on the front-end (https://htmx.org/)

- Use plain-old CSS with minimum dependencies (sanitize.css)

- Use lightweight CSS framework if you need one (bulma or purecss)

- Use Go on the backend (all other modern languages are bloated)

- Use AWS Lambda

- Use DynamoDB if you don't need data processing

- Use Postgres if you hate or don't want to learn DynamoDB

- Compile SQL to type-safe code (https://sqlc.dev/)

[AlwaysRock]

Meh. I enjoy doing full stack javascript work over all other stack including Go. To each their own I guess.

[MrDresden]

Left my job late last year with the intention of striking out on my own.

Instead I realized quickly that what drove me to quit had been the fact that the joy of coding had left me. And so for the last two months I have been working towards regaining it.

And at this point I realize I have gained it back.

The only projects I have been working on are small libraries and apps whose ideas had written down over the years but never touched.

The longest project has been 3 weeks. Others, like the library I worked on today, have only taken a couple of days. Also done some open source contributions here and there.

I would now recommend it to anyone, given if their financial situation allows for it, to step off the hamster wheel on occasion and work on the things that really motivate them.

When I re-enter the job market, it will be with renewed vigor and plenty of new know-how.

[HeyLaughingBoy]

> Left my job late last year with the intention of striking out on my own.

I read a quote from Amy Hoy (/u/ahoyhere) last week that summed it up pretty well, "most people who think they want to start their own business really just want a better job."

[hawski]

I think of doing something like this, but I'm afraid my problem is that I'm self-directed and my motivation comes from within. Working for someone makes it again a job and making me fix problems someone else have created within limits they envision.

Is it different for you?

[mattgreenrocks]

If you want to have fun, dig into some subfield of computer science, like databases, ray tracing, etc. Something that has been studied rigorously. There, knowledge actually compounds and builds on itself, rather than being thrown out every two years for no gain. Build something small and see if the subject gels with you. If it does, go deeper. If it doesn't, try another one and see if it works. Once you find something you like, you can start self-studying more with books and harder projects.

"But it's hard!" That's the point: surmounting the challenge is where the fun comes from. And then you have skills that 90% of devs don't even attempt because they believed it was "hard."

[didgetmaster]

The OP is a bit ambiguous about where they want the project to go. If the whole point is to just have 'fun' while learning something new, then there are many different directions you can go with no accountability except to yourself. Pick any area of personal interest and start prototyping. It can be really fun to create something that does something nothing else does or does some common thing much faster or better than other solutions. Even if no one else uses it, it can be rewarding in its own right (i.e. a hobby).

If, on the other hand, you want to actually build something that you hope other people will try, adopt, give feedback, and (heaven forbid) actually pay you something for your trouble...then that is hard. You have to worry about things like what operating system or browser it runs on. If you want the project to also be rewarding to many other people, then all the business processes come into play (finding market fit, raising capital, evangelizing it, etc.) which can often be not fun to a technical person.

I know from experience with my own project. Shameless plug: https://didgets.com/

[adql]

> There, knowledge actually compounds and builds on itself, rather than being thrown out every two years for no gain.

That's most of fields. Webshit development is very much exception here, although one with a lot of market share.

[okaleniuk]

Pure JavaScript is fun and simple. If you want a hobby project, ditch all the frameworks, and go vanilla.

I started https://wordsandbuttons.online/ looking for something fun and meaningful to do. I wanted to practice interactive writing and wanted to involve the bare minimum of technology to go forward. So I use rudimentary HTML for layout, JavaScript for interactive illustrations and UI elements, and Python for massive code changes. I have a bit of CSS, but I don't use "cascading" feature of it so whenever I want to change a style overall, I write a Python script for that. On the plus side, every page is entirely self-contained, and my CSS is outrageously simple.

There are no dependencies not external no internal, so the workflow is entirely stress free. Well, rather stress isolated. If I break anything, I know that the breaking change is exactly in the thing I am currently working on and not anywhere else.

If you don't care about productivity and want to enjoy programming with as little tools and dependencies as possible, vanilla JavaScript is the way to go.

[magic_hamster]

May I recommend making a simple game? Developing small games is a lot of fun, and you have complete control over the complexity you'd like to delve into, as well as the scope.

I've been making games with varying degrees of seriousness. I even released a full solo game last year, which was a wild ride. I'm lucky enough to have a job I'm satisfied with, but even so, creating games has never failed to introduce super interesting challenges, it's just a great creative outlet for code and art alike.

I think Godot (Python-like with C# support) is in a very interesting place right now, and it's easy to get into and start making some prototypes. If you want something more involved, try Monogame (C#). There are always Unreal (C++) and Unity (which IMO is getting harder and harder to recommend due to their business model and decisions as of late).

Plus, game developers have some of the best online communities on virtually any platform you can think of. You can always find someone to consult or even join a project, from modding to rev-share game development.

[fierro]

what games have you developed? Can I play one?

[codeptualize]

For UI I do think JS is your best option atm. You don't have to write JS to generate JS, you can use Typescript or go more exotic to things like Rescript.

In terms of CSS; you'll need some form of styling in whatever language, there are plenty of abstractions on top of CSS if you want [something not css].

I would suggest having a look at Next.js if a web app would work, React Native (use Expo) if you want mobile, or Tauri if you want to focus on desktop (Electron, but in Rust, more performant, smaller size, more secure).

Another thing worth checking out is Flutter. I'm personally not a huge fan for irrelevant reasons but it is cross platform, and it's compiled not-JS (Dart).

I also want to say FE has come a long way, the web platform is much more stable, there are great frameworks and libraries, the tooling is amazing, and above all it's really fun and productive. Give it a shot, you might enjoy it. (Do use TS, or Rescript, or something, JS is better with types).

[codeptualize]

Another option I forgot as it's so far away from my world; .NET, they have Xamarin and I think they just released .NET MAUI. That would be C# or F#.

It's not my jam, but it's def cross platform and used quite a bit afaik.

[65]

For front end, there are a ton of UI libraries and CSS frameworks out there that can minimize the amount of styling OP would need to do. I am a big fan of Tailwind, but that might be too much. Maybe some Bootstrap/Material UI React components would do the job.

[Falkon1313]

I deal with web stuff all day every day at work, so that's definitely not what I would choose for a fun hobby project. It's not your best option if that's what you're trying to get away from.

Someone else mentioned .NET. There's also Delphi and Lazarus. Both are cross-platform and have full-fledged UI systems, without any of the web ecosystem nonsense. It's a totally different experience than web development.

[eckza]

https://elm-lang.org

https://elmlang.slack.com

Static FP lang targeting the web as a runtime environment. Wonderful people. The nicest compiler in the game. Tight dev loop. Good tooling.

No JavaScript knowledge required. Join us.

[mayoff]

Programming in Elm with mdgriffith's elm-ui package is the only way I've ever been able to tolerate developing a ‘modern’ web app.

[declnz]

This

Elm brought back joy and longevity for side projects to front-end for me (that had been ground down by the JS ecosystem sadly)

[tasuki]

₊1 for Elm. Easy, fun, reliable.

And the Elm Slack is the most helpful Slack I've ever seen.

[atomicbeanie]

I had similar feelings, and I get the same feelings looking at today's front end development which looks increasingly like embedded C++ development. I had always tinkered with Lisp but expected it to be forever marginalized given how good Common Lisp was, and how poorly it had been adopted by industry. But Clojure changed that for me. The fun seems to come from agency, the ability to affect outcomes with reasonable amounts of time and energy expended. Agency is the ability to change one's circumstances, and modern tool chain's vast incidental complexity takes such agency away. But restore agency, and fun will follow, I suspect.

Now I don't mean to imply there are not good uses for tool chains like C++'s etc. Only I will say that the disconnection from the end result caused by the long write-debug-ship cycle leads to a certain programmer malaise. The same is true for things like coding chips with Verilog. The production chain is so long with respect to the creative endeavor itself that motivation and satisfaction is hard to get.

So, for me, doing SaaS software, which ships "all the time" with Clojure, has restored my ability to 1) read the std library and most others easily to understand them, 2) Create control, preprocessing and IO primitives myself for special purposes which easily rival standard ones, 3) use interop to access large libraries written in another long lived language (Java), 4) build and use tools that simply introspect the code, producing my own tool additions and automations without AST's, and elaborate tooling, after all, code is just data.

Obviously YMMV. One blog post documented someone who changed from C++ to Clojure and did not find satisfaction. But he was attempting to do something, embedded I believe, that is not well suited to a JVM. So changing to Clojure does involve changing to an area that favors one of the two big Clojure host language machines, JVM or Javascript based environments.

[christophilus]

Clojure is my favorite language that I've never used in production. It truly is a joy to use. I just get nervous when thinking about building a real application in it because of: lack of static typing and my temptation to be clever when writing it (this is inversely correlated with long-term maintenance).

But I'd agree that if you want to find joy in programming again, Clojure might do that for you. It's a lot of fun.

[terhechte]

I'm very happy with Dioxus, a Rust UI framework. It might tick most of your boxes, except that it is still quite unfinished. On the positive side, the source code is easy enough so you can create PR's for missing features or bugs that you run into. Here's what's interesting

- You write everything in Rust. Dioxus runs by patching the output from your Rust code onto a VirtualDom in a Webview. So your code runs native, the WebView is just one big canvas that you use to display your UI. It's using WebKit/Tauri not Chromium, so apps are much smaller.

- It is super cross platform (macOS, Windows, Linux, Terminal, Wasm & (very unfinished) iOS/Android)

- You still need to understand some CSS but you could also use an existing framework like tailwind.

- BUT: The way Dioxus is structured, you don't have to Render to a WebView. You can plug in a custom renderer which gets told which elements should be placed in the UI with which parameters. That makes it easy to write a native AppKit or GTK renderer which just places widgets and uses a Flexbox system to figure out the sizing.

Most importantly, working with it is kinda fun. It also supports hot code reloading and so on.

https://dioxuslabs.com

[dimitar]

I'm going to suggest Clojure. It is a very opinionated language made a person who was about to quit professional programming because of an explosion of complexity (both accidental and incidental).

Check out the talks by Rich Hickey to see if you have the same sentiment or perhaps this paper: https://download.clojure.org/papers/clojure-hopl-iv-final.pd...

The community of the language largely follows this philosophy, the ecosystem is very stable and there is little churn. The most common implementation is on the JVM making the language very portable.

The headaches historically were with getting your environment setup, but there are amazing tutorials and good tooling or VSCode, IDEA, Emacs and vim.

[jimbo9991]

I would like to throw in Erlang and or Elixir with this. Not as stable as Clojure in the case of Elixir of course (or even just the BEAM environment tbh, certainly not as popular as JVM), but it's possible OP has already done the traditional functional programming thing.

This is absolutely not a criticism of Clojure or your recommendation. I'm a huge fan of Clojure, but I don't know where OP is coming from/if they've done a LISP before.

I don't know why but whenever I get depressed of bureaucracy at work I turn to functional programming in my spare time.

[gorjusborg]

I love Clojure, and listening to Rich Hickey talk is often enlightening.

I don't know that learning clojure was a good investment from a practical standpoint, but I took a deep dive into lisp-like languages and don't regret it.

[TacticalCoder]

And as a bonus, once you know Clojure (on the JVM) you basically get ClojureScript, on top of JavaScript, for free, which is amazing.

[cmrdporcupine]

It's not "fun", but it's perhaps best to start with the problem you're trying to solve rather than the tools you want to use.

As for "fun" for UI, I found doing UI in Dear ImGui strangely liberating. It sounds like a web front end is part of your requirements, maybe, but if not, try one of the "immediate mode" UI toolkits like that. They have their limitations, for sure, but they come with a lot less "normative lifestyle assumptions" and it's strangely enjoyable to toss a UI together in them.

Also I started having a lot more "fun" once I start doing my hobby projects in Rust rather than C++... once I got past the initial learning curve... I say this not so much for the language side of things -- which can be a little straightjackety -- but for the fact that I was no longer fighting all the sharp corners in the C++ ecosystem (CMake, different 3rd party lib packaging styles, dubious 3rd party library programming styles/standards, etc.). Rust+Cargo simplifies a lot. And the third party crates are generally of pretty good quality and consistency.

Or learn another language, like Zig. That looks fun, too.

[jb1991]

My main problem with Dear ImGui is that it just looks pretty terrible on a high DPI screen like most macs' Retina screens. The scrolling behavior feels clunky too compared to how scrolling works in every other app or browser on mac. If those two things were fixed without my having to figure out workarounds myself, I'd probably use it.

[elcritch]

Nim is a fun language to program and also meets some of your requirements. It can compile to JS and has some libraries to interop with html. Admittedly it’s a bit limited on those packages but they exist.

HTML template: https://github.com/juancarlospaco/nim-html-dsl

SDL on emscripten: https://jipok.github.io/Nim-SDL2-and-Emscripten/

[arbuge]

It is awesome to see all the comments in this thread recommending some form of embedded programming as a side project. I strongly recommend it too.

Here's my own fun embedded programming project... it's been 5 years now, so I should really do something like this again:

https://foundrytechnologies.com/relay.php

It didn't too well commercially, perhaps because the 3d-printed case I designed for it in looked a bit cheap. But the embedded coding was very fun, as well as putting all the pieces together (embedded coding, website & web app, PCB design, CAD and 3d-printing were all involved).

I did sell a few units, and shipped them worldwide. I still see them checking in with the server for updates every 5 minutes from around the world, and there's about half a dozen working around my house today, including one outside by the front door bell. That one's been exposed to the Texas elements for 5 years now and hasn't missed a beat, except that it needed a new case last year to keep it looking fresh.

[jjk166]

Might I recommend instead of looking for a way to make things easier, instead you look for a way to make them harder.

There's more than one way to skin a cat, and for a project with even minimal complexity there are going to be tons of perfectly legitimate choices for how to bring it to fruition. In theory this is great, it's so easy to find a tool that works for you, but it's also very easy to get into analysis paralysis. If that's something that really bogs you down and makes the experience unpleasant, then you need a way of easily reducing the number of options. If you set out from the beginning to make a challenge out of it and add some stupid requirement that you have to satisfy, that can do the trick. You're no longer looking for the optimal choice, just an acceptable option.

There are other benefits: a handicap makes doing boring routine things stimulating and forces you to think about problems in new ways. If you choose a handicap that forces you to use something you don't have a lot of experience in, then it's a great way to learn. You tend to develop a deeper understanding of the fundamental principles underlying what you're trying to do. You can also be a bit easier on yourself about the quality of the end product since hey, it's pretty amazing that you could get it to work at all.

[NortySpock]

Your long list of desired features and properties, especially cross compatibility, is sucking all the fun out of the project. I also suspect the hobby project you chose (whatever it is) has so much idealism in it that it implies a lot of toil, e.g. a cross platform messaging app or one-storage-system-to-rule-them-all or The Next Great MMORPG.

The goal is too big and you are but one person with a day-job.

Don't quit your day job.

If you want to finish a project and have fun: Do not attempt to solve world hunger or censorship or any big problem, because you will find it is big and thorny.

Do: make a list of tiny projects. Extra tiny. Make sure they are fun, e.g. asteroids or Snake or displays-a-random-emoji or something silly.

Make a list of non-goals for your project: e.g. it will not be cross-compatible, it will not be multi-threaded, it will not support multiple users, it will not be scalable, it will not support multiple resolutions, etc. Try to make it so dang simple you think you can knock it out in 2 days. (It might still take a month)

If you need a framework or library, pick one and only one library. (write the rest yourself) Pick the smallest one you can find that covers the part of the project you don't wanna do, whether that's game physics calculations or databases or whatever.

And then write your project, preferably all in one big ugly file that does not meet anyone's definition of organization or documentation or quality.

That's when it's fun, when the scope is small and understandable, and there is no expectation of having to fix anyone else's bug reports but your own.

(To be clear, these rules are only for personal projects, I do not recommend this level of anarchy on a team or a "real project", just a project where the goal is to have fun.)

I've made snake, asteroids and Galaga clones in JavaScript. I had fun with them, and I threw the code over the wall for other people to look at; but for personal projects I am not promising anything other than that I had fun writing the code and playing the game I wrote.