Indie, Solo, Developer ·

Finding the most effective dev stack for a solo developer. Over the past year, I've been looking at many tech stacks that would be 'best' for me, as a solo, indie, developer to deliver a desktop app (Windows & Mac) plus mobile - iOS mainly. Initially, Xamarin started to stand-out. Using .NET Core as the run-time, Xamarin as the native API provider and Xamarin Forms for the UI seemed to solve all issues. But, the cracks soon started to appear. Xamarin Forms is mobile only; the Windows incarnation is different. There is no Mac UI solution (you have to code it natively in Mac OS Storyboard. I was also worried how Xamarin Forms , if I was to use it, was going to cope, in future, with Apple's new SwiftUI and Google's new Fuchsia.

This plethora of techs for the UI-layer made me reach for the safer waters of using Web-techs for the UI. Lovely! Consistency everywhere (well, mostly). But that consistency evaporates when platform issues are addressed. There are so many web frameworks!

But, I made a simple decision. It's just me...I am clever, but there is no army of coders here. And I have big plans for a business app. How could just 1 developer go-on to deploy a decent app to Windows, iPhone, iPad & Mac OS? I remembered earlier days when I've used Microsoft's ASP.NET to scaffold - generate - loads of Code for a web-app that I needed for several charities that I worked with. What 'generators' exist that do a lot of the platform-specific rubbish, allow the necessary customisation of such platform integration and provide a decent UI?

I've placed my colours to the Quasar Framework mast. Oh dear, that means Electron desktop apps doesn't it? Well, Ive had enough of loads of Developers saying that "the menus won't look native" or "it uses too much RAM" and so on. I've been using non-native UI-wrapped apps for ages - the date picker in Outlook on iOS is way better than the native date-picker and I'd been using it for years without getting hot under the collar about it. Developers do get so hung-up on things that busy Users hardly notice; don't you think?. As to the RAM usage issue; that's a bit true. But Users only really notice when an app uses so much RAM that the machine starts to page-out. Electron contributes towards that horizon but does not cause it. My Users will be business-users after all. Somewhat decent machines.

Looking forward to all that lovely Vue.js around my TypeScript and all those really, really, b e a u t I f u l UI controls of Quasar Framework . Still not sure that 1 dev can deliver all that... but I'm up for trying...

READ LESS
8 upvotes·5 comments·1.5M views
Jonathan Pugh
Jonathan Pugh
·
August 31st 2019 at 7:13PM

I also found developers complaining about speed with web based frameworks and it's true that low performance apps with poor user experiences do exist, and perhaps these are written by people who chose the web option as the lowest barrier to entry into the app world and didn't care much. My experience creating an app using web tech was that if you spend time to optimise it the performance is actually really great. I'm sure the same will apply for the memory use in Electron.

·
Reply
Greg Neumann
Greg Neumann
·
September 1st 2019 at 2:24PM

In my several decades of programming, I have noticed that programming *has got easier* in that it is easier to **get started**. After-all, many people can just 'google' (I use Bing!) and get started - or so they think. It's actually really really hard to program right. This means not just to achieve the functional spec, but also to do it in an efficient way (often having the *consequence* of good performance) but also in a way that is good for future maintainers of that code.

In 1992, we were using a code generator for something which had a program **structure** - many places in the program logic to do the **right thing**. One programmer didn't understand this and did all of his work in one place. Yup, the program worked - achieved it's function - but was unmaintainable and did not perform - execute - as efficiently as it could have done.

So, yes, I think many web programs are poor performers, and maybe _some of those_ give ElectronJS it's possibly bad name. But that's not the technologies fault.. it's programmers who - come-on!; we've all seen them... they clearly copy-and-paste some logic from StackOverflow, or some blog, into their work and then, almost immediately, they post "it didn't work".

I remain _amazed_ by this as it means that there are people who genuinely think that others deliberately take the (often, long) time to write a __wrong__ post/answer. They do not stop to think that, perhaps, there is more to the code than just what is written in that code-block. Pre-dependencies etc. So they just keep banging-in somewhat _disconnected_ code blocks.... and you get a poorly performing program - but **Hey! Look Mama! It works**.

I will try to do it **right** and see how performant I can get ElectronJS.

PS Seems Comments do not support markdown - soz!

·
Reply
Ian Watson
Ian Watson
·
March 20th 2020 at 11:58PM

... and now MS Blazor is gathering pace. MS, iOS and Android. No Javascript required, the razor engine does it all and then, my understanding is, it is converted.

·
Reply
Brian Fogel
Brian Fogel
·
March 25th 2020 at 6:23PM

I am at a similar decision point. I've come to Quasar or Ionic. The only thing holding me back from Quasar is its current lack of an iOS themed app extension and unfortunately I don't have the chops to produce it myself. What are your thoughts about Quasar components currently only Material Design?

·
Reply
Greg Neumann
Greg Neumann
·
March 26th 2020 at 9:11AM

Material-only seems to be the 'accepted' way for web-based apps (other than React Native of course). By this, I mean that it's web developers (= tend to be Google-focused) who write the themes so they use what they know. And Material IS good for the web.

Unfortunately, I think that it means that if you NEED Apple UI on Apple, Material on 'Droid and (lol! Fluent on Windows), then you have to use the native UI chain or native renderers such as Xamarin Forms.

I personally think that if the UI-experience HAS to be native, (largely because of the expectations of the Buyer of your app), then we still have to go native. Vastly more work just to get that navigation pattern/button 'the same' as all native apps - but you do tend to get a better performing app (small pay-back for large workload).

In short, Steve Jobs did a really powerful job in getting Users to demand the Apple UI patterns for the premium users. But don't dismiss the 'Droid fan-boys who hate Apple and have to have it their way. Most People tend to stick with what they already know - and they know the UI behaviour of their preferred device. And there's no shifting it!

·
Reply
Avatar of Greg Neumann

Greg Neumann

Indie, Solo, Developer