nerdywordy

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.

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).

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.

[1] https://github.com/rakeshkky/graphql-engine/blob/dynamic-con...

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.

This is a greenfield rewrite of a tightly coupled ASP.NET frontend to React+API.

Email in profile if interested.

There are some promising developments with Blazor and .NET MAUI. But it all seems too speculative to build on at this point.

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.

Or would users face connection limits at some upper bound until the old function connections get spun down?

It's very polished. Kept up to date. Follows best practices for RoR. The author is one of the most active RoR community members.

https://excid3.com/

edit:

If you like PHP then https://spark.laravel.com/ is an official Laravel project. I haven't used it but I've seen discussions where folks recommend it.

Is the source shareable?

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?

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.

[1]: https://fast-weigh.com / https://docs.fast-weigh.dev

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.

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.

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.

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."

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.

If we had staff to dedicate directly to this then it wouldn't be an issue. But paying for a managed service that gives us production grade data access is a no-brainer for any non-trivial application we build.

It provides a nice boiler plate for the modern web app and pulls together a lot of the single packages mentioned here so you don't have to worry about wiring things together.

I've built a few small apps with it and thoroughly enjoyed the dev process.

(GoBuffalo.io)

Contained developer environments, simple command line deploys to VPS, and a free tier that can handle most hobbyist application needs.

I deploy Rails & Elixir / Phoenix apps with Nanobox

Medium & kin infuriate me with the popup toolbar.

It's something that is bound to happen. There are a finite number of words, names, and spellings to make use of.

Piecing together libraries can absolutely be daunting, but once you get a starter app built your productivity will go way, way up.

I'd really recommend this (paid) course at https://www.usegolang.com

It walks you through pulling in different libraries (Gorilla Mux, GORM, etc), gluing them together, and structuring your code in a maintainable way.

A couple of other folks have mentioned Buffalo. It's a great ecosystem for building applications quickly, but I would strongly urge you to go through gluing the packages together yourself first to really understand what is going on underneath the magic.

Comcast's recent Gig advertising around here is almost laughable. We've called in to discuss upgrading but their sales and support are clueless.

Side note: As I was trying to comment on this my business class Comcast connection dropped. Go figure.