I've worked on low budget one man shows. Nevertheless I did TDD all the way and, I still wrote my cap scripts to deploy and asked the client to validate the implementation was right.
You might not tick all the boxes on the list for one man projects, but you can definitely do them with a team of two.
Amir, thanks for following up. Like I said in the article, I've used RubyMotion in production in the past. We were one of the early adopters and launched at least half a dozens apps in it. We payed for all our licenses. I love the product and this was money very well spent. It allowed us to use the same language (Ruby) in a larger portion of the projects. This was particularly important when some of our clients were small startups with an existing Rails app, and it was important for them to keep the same language for the mobile app.
I just think the support for Android should have happened a lot sooner. But of course this is easier said than done.
Moving forward to React Native is part of the same approach. It's important for us to use a technology that delivers fast in multiple channels and has a great chance of still being relevant in the next 10 to 20 years. And for me, these are the strongest points on Javascript.
And you're correct, React Native is not truly native, but it does the job pretty well without major impacts on usability. RubyMotion is truly native and very well designed IMHO.
I've been using Rails since 2008, and participated in more than 100 projects in these last 10 years. Either by coding or managing them. Most of these were Rails projects. Moving to node is part of planning the tech that we're going to propose to our clients during the next 10 to 20 years.
I didn't conduct a thorough analysis on the reasons why I've seen big corps rejecting Rails, so what I'm about to say is based on the the experience of being through all these projects.
But most Rails projects are connected to the innovation departments and once they passed through the PoC stage, their IT departments asked for a re-write on a tech already in their ecosystem. Supporting additional techs raises complexity and forces them to support another stack.
We were indeed able to push some Rails apps to production on enterprises, but these were usually apps that performed a specific goal for one of the departments, and once we went for the big projects within their core, tech stack was always an issue.
We're on the verge of baselining a reference architecture in JavaScript for all our projects. We did the research with parity of features that already exist in Rails (Rails Admin, Devise, Sidekiq, etc).
You might not need a year to, at least, get my thoughts on that.
I avoided desktop because the last time I don't develop for desktop since 2008.
But I take a look at some options for Ruby near that time, and I don't think the ecosystem is much different now. There were a couple of options but very incomplete.
Regarding the JavaScript ecosystem, yes. Electron is a perfect killer.
I see the JavaScript ecosystem at the same level that Java was in 2006. If you pick it, you can virtually deliver to any channel.
You need to look under which title that is, and take the context into consideration. That is one of the reasons used to justify why the community is more active that the Rails one.
I avoided the tech part because, to be honest, I don't think it is relevant now. There is many information about that on the web. And from the technology standpoint both are fit for purpose if you're going to develop a web app.
The central point for me is exactly the adoption on the startup and enterprise world.
I wonder if they built the analytics system themselves or are using a COTS.