587 karma · joined August 2, 2012
I suspect you'll say "7 years is nothing" and maybe it is nothing. But it is still something. It is long enough that we made a couple bad framework/library dependency choices early on and to have learnt lessons from such mistakes.
By far the biggest technical challenge we've faced in that time is the .NET 5 migration - but even that might turn out to be a lot easier than I currently envisage.
UWP is the future of Windows - correct.
I'm not sure any significant part of UWP has ever been in the kernel per se.
It sounds like you're a consultant where taking risks on behalf of your customers, no matter how small or logical the risk, is obviously not part of your job description.
Your offerings of good luck appear to be disingenuous.
I wouldn't confuse Project Reunion and the arbitrary Windows Store requirement that apps be compiled with .NET Native. A requirement that, frankly, is on borrowed time anyway and I can't envisage it surviving much longer. Once .NET 6 delivers Mono-style AOT support - .NET Native's sole remaining purpose will cease to exist. Not that modern hardware ever needed it. It was intended for Windows Phones.
If the choice facing us was a simple as you describe then, for example, we wouldn't have ended up building a UWP app in F# back in 2018, would we? Not everything is black and white nor zero sum.
But even still - my app is sideloaded and never needed to care about .NET Native at all.
But honestly, its own async model is great - arguably better than TPL for business systems. It sacrifices a little top-end performance/power and in return you get a supremely clean abstraction.
Honestly I feel like this vaccine is going to leave the mRNA-based vaccines trailing in its wake in terms of global government adoption.
Xamarin Forms let us build 4 years worth of tech for Android only. And then, when we had time and the customer demand to do so, with a small amount of work - port our app to 2 other platforms in fairly short order.
I don't know of any other platform that could do this - particularly when considering the years involved.
Our app uses local databases on the device - so a web based app would not have cut it. And our app has roots in 2014 tech when many possible alternate approaches did not exist yet.
The charts are self-contained in a blob of JSON, so you can ship them around easily.
It supports both Canvas and SVG rendering, which is great if you need to export to a .png since Canvas is better suited to this. SVG is good for crystal clear vector graphics though. So we use SVG mode on the mobile app, and Canvas mode on the back-end.
We tried numerous other JS charting libraries (c3, chartist, chart.js, frappe, and a couple others I forget) but none of these were as professionally and comprehensively put together as Vega-Lite in our experience.
I am starting to view Vega-Lite as "the SQLite" of the charting world - I hope this view holds for the long-term.
That's my take anyway. Thoughts?