nerdywordy

What router are you using? One in the svelte ecosystem or a vanilla js router?

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.

RE: Microsoft

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

No, it's not a bad thing.

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.

Email in profile if interested.

Sort of. But not an embedded browser. And .NET instead of JS.

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

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.

Can this CRDB Serverless offering handle the burst connections of a serverless function based app? Are pooling or query queueing features built in?

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

Intrigued by this approach!

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?

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.