I'm still using https://github.com/TehShrike/abstract-state-router which I wrote years ago after thinking "ui-router is great, but I need a version that can keep using no matter what component library I want to use in the future"
1) MSFT has already used React for far longer than 2 years.
2) They have basically never used the technologies you mentioned (WPF, Silverlight, WinUI). They offer them as UI toolkits that run in their Windows environment and that’s it. Their failure to market and support these technologies is independent of what they do for their own development strategy.
3) They bought GitHub and effectively own electron now. Many of their biggest apps are on electron (Teams, VS Code, Azure Data Studio).
2. Yes they have. Half their developer tools were rewritten in WPF, they offered huge stacks including CRM on top of Silverlight and a huge chunk of windows 11 front end is WinUI.
3. Teams fucking sucks. VS Code is heading in the same direction. I've never used Azure Data Studio.
> Many of their biggest apps are on electron (Teams, VS Code, Azure Data Studio).
Huh? Those are Microsoft's biggest apps? Not, MS Word, the NT Kernel or ... windows 11? The XBox operating system project? Outlook express? Visual Studio? ... Github?
I'll grant that Electron is used by a few teams at microsoft. But I'd be surprised if even 1% of microsoft's engineers worked on products built with electron.
We were on Hasura Cloud and really did not have a problem with it. But we moved away to self-hosted Hasura for more control over deployment and cost as we have 10s of same-schema MSSQL databases that we were orchestrating and the management and synchronization of metadata was becoming a bit of a pain.
They just announced dynamic connection routing[1] which is a feature we have sorely needed as it would allow us to run a single instance. Fantastic stuff.
It is marked as "cloud / enterprise" only feature. Fine. Just yesterday we began to explore moving back to the hosted cloud service to prepare ourselves for availability of the feature.
And then today they announce this pricing change that 10x's the amount we would pay! On top of that the max for dynamic connection routing for the Pro plan is listed at 1! What's even the point???
Our opinion of Hasura has always been high and we've been quick to recommend it. But with the strategy and pricing in flux it's hard to justify picking it for future API needs. They seem to pushing aggressively towards Enterprise or bust deals which is a shame because the features they are gating off behind the Enterprise wall are fundamental to many application architectures.
It's how (nearly) everyone using React (or any frontend framework) + Tailwind will structure their code. And I'm not sure the author is arguing against Tailwind's utility in static styling scenarios.
I think the article's author would argue that once you move beyond static classes that Tailwind's class building becomes messy.
So <SideBarItem padding={4} active={true} /> would be cleaner in the authors mind if the exposed props get applied by some other tooling better suited for dynamic styling instead of simple string manipulation.
There is some merit to that argument. Building the class string can be cumbersome in some scenarios. But Tailwind "clicks" for me where other solutions do not. So I do it anyways.
We (tacinsight.com) are rebuilding our entire front end from scratch and are looking for a senior javascript engineer. Preferably with prior experience in a large React project.
This is a greenfield rewrite of a tightly coupled ASP.NET frontend to React+API.
We have a Windows POS app for mines, quarries, sand and gravel, etc.
When we broke ground on this version Microsoft was hardcore pushing UWP. We were building for the future so we built our app within the constraints of UWP with the expectation that it would grow with Microsoft’s vision…
Fool me once, as they say. UWP is dead.
We are currently redeveloping the entire thing with a series of Win32 base classes and intend to layer on a WPF front end for now. WinUI is early and promising. But so was UWP.
Long term we’re exploring outside the box UI options like running a local server and popping a browser. C# and .NET are very powerful. But the fractured landscape for desktop development gives little hope for the future.
If your goal is to build a rich UI, then you may have to suffer through learning whichever flavor of XAML you decide to go for. But if your goal is to interact with local hardware functionality I’d probably steer clear and use WinForms, a browser interface, or a console interface.
Also their entire office suite is migrating to an webapp. I use it at work and it's quite impressive even though it has issues and is inferior to native. But hey, it's only the beginning and can be used on every platform without the need to install. Web tech is awesome.
I'm mainly on WPF, so I might say something wrong, but I think adjusting your UWP app for WinUI would be a breeze compared to redeveloping everything with Win32.
A hard +1 to Jumpstart. I stan Chris a lot in the comments here, but Jumpstart combined with Hatchbox[0] is a pretty awesome mix to get started. Especially with the recent upgrades, the whole process of getting the framework up takes minutes.
We have an enterprise app that was originally built as a UWP application via Xamarin.Forms (Hot mess, I know. But the decision predates me).
We've been prototyping a rebuild in React and Electron but if we could port into WebView2 and reuse a lot of our existing business logic with a port into a local api layer a lot of time could be saved.
I'm a web guy, so not sure how the nuts&bolts of this would work. Does the WPF app bootstrap a REST API on localhost on startup that is callable?
We have layered Hasura over an existing set of SQL Server databases to provide a public facing API for our product. [1]
Overall the experience has been fantastic. The performance and authorization scheme is very good. It has allowed us to wash our hands clean of bespoke endpoint writing for our enterprise customers with complex integration requirements (for the most part... waiting on mutations!).
One thing I wish was handled differently would be Same Schema, Different Database support.
We have multiple multi-tenant databases as well as many single tenant databases. All share the exact same table structure. As it stands, we have to maintain a separate Hasura instance for each of these databases as the table names conflict and there is no way to rename or reference them differently. That leaves us with the minor annoyance of needing to instruct users on their appropriate server prefix (server1.fast-weigh.dev/graphql vs server2.fast-weigh.dev/graphql... etc). Yes, we could proxy in front of these and route accordingly. But that's just one more layer to deal with and maintain.
It sure would be nice to have a single instance to maintain that could handle database availability based on the role of the incoming request.
Even with the minor inconvenience of multiple instances, I 10/10 would recommend. It's a huge timesaver assuming you've got the data access problems it seeks to make easy.
> We have multiple multi-tenant databases as well as many single tenant databases. All share the exact same table structure. As it stands, we have to maintain a separate Hasura instance for each of these databases as the table names conflict and there is no way to rename or reference them differently.
We have the exact same scenario and solved in with the exact same workaround. As things stand, spinning up the Hasura instance is currently the last piece of the process we need to automate before we are fully able to onboard new clients without manual ops action.
Hasura V2, currently in alpha, is supposed to support multitenancy as its flagship new feature. However, the "same object name in different database" issue is still open and on the roadmap, so presumably it's a _very_ early alpha.
Also in the process of writing an app that has no ssr needs. There are some minor annoyances with SvelteKit and interested in other options.