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).
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.
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.
REST itself is such an amorphous term nowadays that it's tough to even measure/define this. It seems to now mean basically any multi-endpoint based JSON API.
GraphQL is trendy and might take over "REST" for startups soon if it hasn't already. But in real-world adoption in established companies and dev teams I'm not sure that it ever will. REST / typical JSON APIs are so prevalent because they are fully backend agnostic and so darn easy to write (Note: not easy to write well). GraphQL has some architecture and typed overhead to learn prior to spinning up an endpoint and the underlying logic to stitch together the data. With REST, it's just HTTP call, backend processes call, return JSON, done.
I'm totally sold on server rendered, HTML over the wire web apps. What I'm not sold on is websockets for the transport layer.
Unless you truly need real-time, I'd argue that something like HTMX (https://htmx.org) is a much simpler and more reliable route. Simple HTTP calls keep the request stateless and give architectural freedoms that shouldn't be taken for granted.
https://miragejs.com/ is a great complement to frontend first development. Some folks on my team use it and love it. I tend to dev from back to front so I don't run into the need as much. If I do I typically just mock a JSON response in my frontend call function. Depending on the need I'll sometimes set the call to return an error response as well.
When you are looking for a new Windows app, does opening up the store even cross your mind?
I nearly always go to a web search + download first. Or if it's something dev-centric I look at scoop or chocolatey. The Windows Store is far, far behind in my mindshare.
There are a few glimmers of hope though. Python has begun to distribute via the store which is cool. And the Linux distros available are helpful in some edge cases or for a quick dev environment.
I get that it isn't supported. We have followed the recommendations mentioned in the docs but found the usage of these workarounds to be sorely lacking in performance and reliability.
Anyone with inside knowledge of Firestore care to comment on the ETA of more advanced query functionality?
We have played with Firestore quite a bit, but rely heavily on the ability to do aggregate queries. Reading all of the documents and performing this on the client side is nowhere near good enough. Nor is triggering functions to update a "count" or "sum" property on a doc.
Edit: Looks like a PM answered on another thread...
"It's a point of internal discussion on scalable ways to achieve this, but nothing we can promise. We definitely see the need for it."
C#
ASP.NET Core Razor Pages
SQL Server
Dapper
vanilla JS
Azure for hosting and peripheral services
It is truly a breeze to put together server rendered apps with this stack. I come from a JS heavy background but find myself so much more productive with C#.
It's not trendy, but that's mostly because it's Microsoft. But it is powerful and productive.
This is also great for avoiding binge drinking. I did this in college and it's incredibly hard to drink to the kind of excess most college folks do when you're needing to pee ever 15 minutes.
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.