Job Tip: Does the Future Belong to Xamarin.Forms?
I've written about managing your skills portfolio. That includes developing skills that are currently "niche" so that they may become your future "current" skillset -- and generate some lucrative jobs along the way. If you asked me now what I thought your next niche skillset should be I'd say Blazor ... but to do it through Xamarin.Forms. Here's why.
When I'm working in Xamarin.Forms, I create my UI in XAML. I then build my application and get packages that run on Android, iOS and Universal Windows Platform (UWP) using native UIs.
That makes Xamarin.Forms sound suspiciously like one of those universal "application generators" that I'm normally suspicious of. However, Xamarin doesn't fall into that category: Xamarin just generates the platform-specific UI and a deployment package -- I still have to write all my business logic in C#. When I'm writing that code I have access to all the classes in the .NET Standard library (which means, effectively, almost everything that runs on Mono).
Lately, I've been experimenting with Blazor, which allows me to write code in C#, access the classes in the .NET Standard library, and deploy the resulting package to any of the current crop of Web browsers (thanks to an industry standard called WebAssembly that supports downloading a version of Mono to the browser). Effectively, Blazor can take JavaScript out of the equation when creating Web apps.
With JavaScript gone, is it my imagination or is there any reason that my Xamarin.Forms XAML couldn't generate HTML-based UIs as effectively as it generates Android/iOS/UWP-based UIs? If not, and I can truly create code that runs anywhere, why wouldn't I want to build my next application in Xamarin.Forms?
I'm not the only person asking that question, by the way, as quick search on the terms "Blazor Xamarin.Forms" shows. Makes me wonder about the technologies I should be acquiring.
Posted by Peter Vogel on 10/17/2018