Hacker News Reader

Comment by arsome | Hacker News Reader

Yep. We recently did an assessment of available UI libraries and pretty much concluded the best maintained libraries with a modern look and feel are all web-focused and we're likely to have to settle for building an electron app if we want to be able to take advantage of the best selection of 3rd party libraries without building as much ourselves. As much as I don't like the ecosystem or Javascript as a language, there's so much tooling around it and the libraries available seem to be miles ahead of other options. I'm hoping Redux and TypeScript can make it moderately bearable. Fingers crossed.

Seriously, what is there? Microsoft doesn't even have a clear direction for desktop apps - their most recent stuff like VS Code and Teams are built on Electron.

View on HN

Hi, I'm a Redux maintainer. Note that we have considerably changed the Redux patterns that we teach over the last couple years to make it easier for folks to learn and use Redux. We now teach using our Redux Toolkit package as the default way to write Redux logic [0], and the React-Redux hooks API [1] as the standard way to work with Redux in React components.

We recently rewrote our tutorials from scratch [2], and offer an opinionated set of guidelines on how to write Redux code effectively [3], such as "put all Redux logic for one feature in a single file", "use feature folders", and "prefer putting logic in reducers".

We also now recommend some TypeScript usage patterns [4] that simplify the amount of types you have to write.

Finally, we are about to release a new "RTK Query" data fetching layer that will be in the upcoming RTK 1.6 release [5]. It's in beta now [6], and we're just polishing the docs before it goes live.

Hopefully this will help you and anyone else who's using Redux!

[0] https://redux.js.org/tutorials/essentials/part-2-app-structu...

[1] https://react-redux.js.org/api/hooks

[2] https://redux.js.org/tutorials/index

[3] https://redux.js.org/style-guide/style-guide

[4] https://redux.js.org/recipes/usage-with-typescript

[5] https://deploy-preview-1016--redux-starter-kit-docs.netlify....

[6] https://github.com/reduxjs/redux-toolkit/releases/tag/v1.6.0...

Just wanted to say thanks for Redux Toolkit and the hooks API - they were truly the key features in making me consider it a solid benefit with TypeScript integration in mind and getting the interest of colleagues who were less familiar with the ecosystem.

Glad those are working well for you!

Yeah, one of the reasons we recommend the hooks API as the default _is_ because it's so much easier to use with TS. It's _possible_ to use `connect` with TS, but the typing overloads are a complete pain to work with. Fortunately, `useSelector` is just a simple function call, and `useDispatch` just gives you the `dispatch` method itself. Less abstraction, easier to type correctly, and easier to use.

Tbh if you're living in React-land and understand Redux, useReducer with useContext has subsumed the need for it in nearly all cases for myself and my team.

For the parts it doesn't match, truly global stuff or tonnes of mutation, MobX is nicer out of the box than Redux. Redux can be just as nice and in some ways more powerful, but thats only after installing and configuring X amount of middlewares, with all the type confusion that can add :(

Interesting, I did look at MobX briefly but pretty quickly concluded it seemed like overkill for our use case where Redux, Redux Toolkit and Thunk would pretty much solve everything we needed and seemed comparatively simple to follow, I'll definitely take a look into useReducer and useContext though, that looks like a potentially viable option for the majority of cases.

I've got experience with MobX (from about 3y ago) and more recent experience with RTK. I still feel that MobX is easier to reason about -- but RTK is a big improvement over vanilla Redux. /$.02

Out of curiosity, any particular concerns with RTK? Also interested in hearing any specifics about how MobX is "easier to reason about" for you.

Fortunately, you no longer need to "install a bunch of middleware" yourself - Redux Toolkit's `configureStore` gives you a good default setup out of the box [0], and we have TypeScript usage guidelines that infer all the needed state and dispatch types automatically [1]

It's also worth noting that there are some significant difference between `useReducer+useContext` and Redux. Not saying those are bad and that you should avoid them : ) just that it's important to understand the intended use cases and technical behavior differences [2].

[0] https://redux.js.org/tutorials/fundamentals/part-8-modern-re...

[1] https://redux.js.org/recipes/usage-with-typescript

[2] https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

You bet there’s a big difference! In my experience, too many teams misunderstood what Redux is excellent at, and made a mess of things due to that misunderstanding. In those teams, useReducer alone gets us 80% of the way there, useContext combined with a well constructed reducer solves another 10-15% — and for most of the projects I’ve worked on across different teams with differing skill sets, often 100%.

I’m glad to hear the Typescript inference issues I ran into a year, year and a half ago are solved. That wasn’t Redux’s fault per se, but composing middleware in such a way that the types flowed through correctly was such a hassle previously. Nice to hear it’s better now

Yep, my recurring theme is "take the time to understand the use cases and tradeoffs of the tools you're looking at, and pick whatever actually solves _your_ problems".

Btw, it is actually possible to use Redux Toolkit's `createSlice` API to create reducers just for passing to `useReducer`, even if you don't have a Redux store in your app - after all, reducers are _just_ functions. I've done this several times myself for cases where I wanted a well-TS-typed reducer with some complex logic in a plain React app.

And yeah, my co-maintainer Lenz Weber is a TS genius, and has done an amazing amount of work over the last couple years to improve our TS handling in a lot of cases.

If you're building a desktop app, just plain C# in visual studio has an extremely powerful GUI (WinForms) that is fairly easy to use. Lots of widgets abs very good charts and graphs that you can zoom-in on and annotate in a million ways. It's miles ahead of Python (saying this as a Python guy). Click Once means installs are fairly simple (assuming a Windows deployment).

That's true, but it seems like WinForms is basically a dead end at this point, not much maintenance work is put into it and you have to jump through some serious hoops to make basic stuff like DPI scaling work even last I checked. Completely agree though, the 3rd party component story is very good on .NET, but the applications you're producing don't exactly have a modern look and feel unless you're investing serious UI design effort in them on top of things.

WPF (and whatever they've taken to calling the UWP version of it now) is a little more modern, and it's what I was initially leaning towards, but also doesn't seem to be moving much and it feels like the future is very unclear, while even MS themselves have started putting out Electron apps. It really doesn't breed confidence.

Coming off of an extremely disappointing Build - I don’t think any news even made it to HN this year, and not a peep about desktop - I agree that the future is unclear.

WinUI is the future, but they’ve admitted it will be years before it reaches the maturity of UWP, which is embarrassingly bad even 5 years on.

WPF, in my opinion, is the best choice for “native” windows apps. The actual best choice is Electron, as most teams doing new work at MS have noticed.

WPF, for native, hits the sweet spot of supporting newer technology (high DPI), having decent performance, and being well implemented; it has been solid for at least 10 years now. Also easy to style and theme, similar in concept to web, but just more annoying.

I was too busy this week to watch any of the Build stuff, but it is surprising how it's basically just been crickets. I can't remember a year with less buzz about anything that Microsoft has queued up...

After being burned with their C++/WinRT reboot without tooling matching C++/CX after 4 years in the works, and the whole situation as you describe, I have decided to eat my UWP hat and just focus on WPF/Win32 in what concerns Windows desktop applications.

The migration wizard for .NET apps was a CLI script, really? In the land of "Developers, Developers,.." and GUI wizards.

Maybe if enough of us keep doubling down on Forms/WPF/Win32 and ignore the whole WinUI/Reunion reboot, they finally understand want we really want for desktop Windows.

WPF is pretty good, actually. It is kind of 'done' at this point and thus the maintenance mode.

The future could be MAUI though; and it is around the corner

I dunno. Yeah it was declared dead, but still works great. We have an app some engineer developed to make his job easier that has probably 50 distinct charts in it. Each one is a SQL query that hits a database for a user selected time slot. It's used by over 100 staff now for analysis and building reports. Works great and is easy to support. I don't think we'd gain anything by making it an electron app. I've been pretty disappointed with those kinds of bloated apps, and I'm not sure if they'll ultimately last as long either.

Myself, I'd just build some command line script that hit up a database and pipe data to build a GNUPlot script and just generate a PDF report. That seems to be the best way to hook into a well maintained GUI project. It isn't sexy, but it's dead simple, should last forever, and be very simple to port to a different OS or language in a single afternoon.

Everyone always says WinForms is dead. And yet it is consistently the go to GUI year after year for a lot of people.

WinForms is alive. And will be for some time.

And not being on the assumed target platform, I am grateful the web is seen as such a strong target. Either I'll get a solid in-browser experience or an Electron experience, but regardless I actually get access to the application. Android has a decent-enough story for PWAs as well.

Redux making something "bearable" is confusing.

Redux?! Bearable?! What is happening?!

> Seriously, what is there?

Take a look at Sciter [1]. You build your UI using HTML/CSS/JavaScript, and your application logic in any language with a C FFI [2], and it supports Windows, Linux, Mac OS, and Android. The distribution size is tiny: only a single dynamic library of around 10 MiB. It's not open source, though.

[1] https://sciter.com/

[2] Available bindings, apart from C and C++: https://sciter.com/developers/sciter-sdk-bindings/

Think of MS stuff from top to bottom as on maintenance, plus a little extra. Less investment than in the old days as foundational tech is becoming commoditized.

The focus and revenue is from cloud now, since MS has comparatively little hardware or advertising profits.

Develop desktop apps in something focused on it, such as QT. Flutter may mature.

The likes of DevExpress, ComponentOne, Telerik and friends.

was Flutter included in the comparison?

I did look at Flutter but pretty much concluded that it was still fairly immature and didn't have great 3rd party libraries available for things like graphing and data tables (sort, filter, group, etc, with all the UI work done for you). This was a year or two ago so things may have improved since, but in React-land there's plenty of very capable and well maintained options in both the commercial and open source world.

Reply on news.ycombinator.com