Help me decide what technology should I use for this project
I’m a solo freelance programmer and want to write an app for internal project management, somewhere I can add projects, milestones, tasks, etc. and track them as I work on them, occasionally remind me of things like take a break, lunch time, etc. and over time I can track on which category I worked how many hours, etc.
I’m actually confused between whether to build this as a Web or Windows Desktop app. I’m considering latter because it can run efficiently on my laptop in the system tray using least memory and resources, web-based on the other hand will force me keep running an apache server too which will be an overhead (unless I host it on Google Cloud or someplace which might be an option?)
The only reason for considering web-based is that eventually I’m planning to make this tool open source and with web-based, many others can find this useful too (including OSX/Linux users). At that point, I may consider expanding its schema to include multi-user connectivity, client login, etc. but that’s going too far at this point!
The idea is that this tool should be useful not just for me but other freelancers, students, etc. who might be in my shoes. From that perspective, what do you think is the right technology to use? Web based or Windows based?
(I’ve extensively worked on C#/WinForms projects before and I’m thinking Visual Studio Express for desktop development. If web-based, it’ll be php/mysql based)
I've worked on personal web app projects in both PHP and C#, and I enjoyed C# far more. ASP.NET Core is so nice to work with and comes with so many easy features out of the box. I haven't done frontend UI in C# but I've heard that Blazor (with C#) is very nice to work with.
For hosting, I have a cheap raspberry pi that I run my app+database on. C# supports Linux now, and so deploying it plus my database to the pi was very painless.
Most corporate places nowadays use web apps for their internal tooling. It makes it easier to deploy changes... would you rather ask all your users to update their desktop apps, or just silently update the web app in one pass? There's also less headache with installers and executables, local permissions, etc.
As a counterpoint: I love a well-written dedicated application that isn't just another browser tab. Tends to be more performant and even just having it mesh with the rest of the OS UI is quite nice.
Oh absolutely. As an end user, I always prefer installing an app or desktop program if it's available. Unless it's an Electron app, the experience will almost always be better than their website.
I think there's a big divide right now between what users prefer and what developers prefer. Users want that clean, integrated experience that doesn't require different intuition or knowledge to start using, and so usually a native app that looks like the rest of their OS is best.
But devs prioritize the development experience, sometimes at the cost of the end product. Just look at Javascript... the JS ecosystem has tons of libraries built to make the dev experience stellar, and so many frontend devs seem to genuinely enjoy working in React, Typescript, Vue, etc. Or languages like python, new developers love how clean and readable it feels. Never mind how much memory both JS and python can consume, how slow they can chug along compared to compiled code.
So yeah, if I'm an end user, I want a native Windows desktop app written in C# with WPF; if I'm on iOS, I want a Swift app; Android, Kotlin. But if I'm a developer (or a company employing that dev), there's a strong chance I'm gonna pick React and Electron :( Just look at Microsoft right now... they just shipped MAUI, a C# framework for frontend mobile apps... and yet Microsoft Teams is written in React.
I'd second the suggestion to take a peek at Blazor Webassembly. Especially since OP has experience with C#. I'm exploring this myself at the moment and the devcycle is excellent so far (especially compared to the monster yarn cycle I have to deal with at work). Steve Sanderson has a few conference presentations where he shows of some nice features and also where things might be heading with WASI.
In the end, if it's mainly for yourself you should write it in whatever frameworks you are most comfortable with, since that will involve the fastest iteration.
That being said, if you are for sure going to distribute this to others, "optimizing" for distribution flexibility will lead to writing it in React. That gives you immense flexibility in how you distribute it.
You can distribute it as an electron, or tauri (which has small binaries and is relatively efficient in comparison) as a desktop application.
You can distribute it as a webapp, with a server handling persistence.
You can even distribute it on mobile via React native.
If you want to go the desktop route, using Avalonia UI (similar to WPF) for a cross platform UI is a good option.
End user perspective (with zero software experience, so take as you will):
If you are making this just for yourself (as you say), desktop. If you want to expand it beyond Windows, write it in such a way that it is easy to port.
If you anticipate packaging this for corporate use (or proposing it should you get a job with a firm), there’s an advantage to a well-done web app, not just for the dev (you), but also to the end user, in that it can easily run on multiple devices and OSes, making hybrid or remote work easier, and often functioning better than the predecessor. The site I work for has for the last few years been transitioning to web apps, and it’s nice being able to use the same application on your government phone as on your desktop. Additionally, we’re moving away from janky middleware stuff like HCL Notes, Oracle, and FileMaker Pro.
I would say work with what you are familiar with. There are C# developers out there if you wish to open source, and Microsoft documentation is honestly some of the best documentation there is (I'm primarily a Java developer fwiw).
You could write it in a web based language - even Electron where you get the desktop toolbar features with the Javascript language that most people are familiar with, so can contribute.
But first? Make your idea. Use whatever langauge you feel is best. I guarantee you that you will make mistakes along the way, and then you'll think "hmm, I should've done this or that" etc. You may even think "yeah my idea wasn't so great" and shelve it - but at least you tried it and iterated over it and found flaws in your product/idea before actually getting serious with another framework/tool you weren't familiar with.
TL;DR - stick with what you know. Don't think - just build, build, build.
Thanks for the insightful feedback! Yeah, I did work for many years in the corporate IT sector before starting freelancing and that was mostly in C# and MS technologies. I'm familiar with agile processes, test driven development (TDD) and iterative build cycles, I'll stick with the framework/library/tool once I decide which one to use! That phase isn't really a problem for me, it's just the idea phase and getting the initial design and business logic right.
It’s the same as anyone. The most important thing is using whatever you can to iterate quickly on your ideas so you can see what works and what doesn’t. Best of luck to you 👍
This sounds like a single-person time tracker so I don’t think it matters, but consider if you’d want to access it from more than one device. How would you sync the data?
If it were a multi-user app for a team then I’d go with a web app for cross-platform support and to avoid having stale versions on team members’ various devices.
I recently wrote a web app for reading a serial port, and it’s just for myself, but it was nice being able to just use it from a different machine without installing anything. Hopefully a static website on Netlify won’t age too quickly.
You can read the serial port with a web app?? 😃
Yes, but only on a Chrome-based browser on desktop. They support the Web Serial API. Firefox is opposed due to security concerns.
From a structure/design perspective, and since you're familiar with C#, I would build the majority of the logic in a plain old C#.NET class library (or set of libs). Then you could build the UI in any framework you like and consume those libs. That way if you decide to switch to a different UI in the future, there's a lot less to move around/rewrite.
Say you build it in WinForms first and then later you decide you want to support a web client too. The core logic stays the same, you just have to build a new UI in something like Blazor, or set up an ASP.NET API and do the whole JavaScript front-end thing.