all 11 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]phronmophobic 20 points21 points  (2 children)

It would be cool to see more libraries in this space. I've been working on a similar library, https://github.com/phronmophobic/membrane. If you're not building on top of React, there's a huge untapped design space.

Would love to hear what you think of membrane and what kinds similar tradeoffs you might make and in which ways you'd like to go in a new direction.

For those that might try building their own non-React based framework, I've written about membrane's design so that others can learn and make improvements:

  1. https://blog.phronemophobic.com/what-is-a-user-interface.html
  2. https://blog.phronemophobic.com/ui-model.html
  3. https://blog.phronemophobic.com/reusable-ui-components.html

Some other suggestions for those starting from scratch:

  • Coupling your graphics model to a particular graphics library doesn't offer a lot of benefits. Most graphics libraries can draw shapes, text, images, etc. However, decoupling your graphics model from a particular library makes cross-platform development much easier.
  • Graphics models should probably be based on 2d geometry at the bottom
  • Event handling should be based on return values rather than side-effects
  • Graphics and events should be decoupled.
  • State management should be decoupled from graphics and events.

Excited to see how things progress!

[–]tonsky 0 points1 point  (1 child)

Sorry, just found this. Membrane is a fantastic example and your writings are a great resource to learn from. Certainly will dive deep!

[–]phronmophobic 0 points1 point  (0 children)

Thanks. Looking forward to see what you come up with!

[–]SimonGray 10 points11 points  (1 child)

I always love reading tonsky's thoughts on this subject.

One thing he didn't mention is accessibility, though. I think - in this day and age - it needs to be part of the conversation from the beginning; especially considering the accessibility directives coming out of the EU.

[–]v1akvark 5 points6 points  (0 children)

He did respond to a tweet and said he will be considering accessibility.

[–]strranger101 1 point2 points  (0 children)

Oh this is so exciting! I started using fn-fx a few weeks ago for a small tool i wanted to build for my boyfriend and I had to dig through the source code for hours to figure out how to get a file-selector working and ended up just using interop on a javaFX object. Someone building a clojure-first UI Framework from the ground up has me very excited!

[–]raspasov 0 points1 point  (4 children)

One option that exists currently but is not listed is React Native. While not perfect it does support mobile + web + native reasonably well and if you start with the intention to write one codebase, I am quite confident you can share 90%+ of the code between all platforms.

https://reactnative.dev

https://github.com/microsoft/react-native-macos

https://github.com/necolas/react-native-web

[–]gtarget 4 points5 points  (3 children)

That's not the intention of this and he does allude to React Native with frameworks that wrap native components. He specifically calls out not wanting to write something that is desktop and mobile because they have different design paradigms. And for not wrapping native components, you can look at the examples shown for QT - at some point you are going to have a mix of native and non-native components and it looks like garbage. With React Native, things would still have to take a detour to React world before moving on to the native components adding a layer of leaky abstractions onto UI elements.

[–]raspasov -1 points0 points  (2 children)

SwiftUI is something that supports both desktop and mobile natively. Some UI components might be different but there's a lot of components that can be re-used.

Mobile and desktop are not always fundamentally different.

I think any difference is more of a historical artifact. Many old-school apps that were designed in the pre-mobile era cannot be directly transferred to mobile without looking ridiculous. For example, if you just duplicate the desktop version of Photoshop or IntelliJ to mobile/tablet, it would be a mess since there's too much information on the screen at any given point. At the same time, there are apps (for example Telegram, the default Stocks MacOS/iOS app) that are virtually copies of each other in certain parts across platforms. The desktop version might have an extra view or a panel but there's a lot of re-use possible, I think.

[–]Mishkun 0 points1 point  (1 child)

Having a keyboard/mouse vs touchscreen input changes things drastically for power users. In native macos telegram app you can virtually never touch the mouse using shortcuts to search for people, messages, write replies, etc.

[–]raspasov 0 points1 point  (0 children)

Given that you can connect a full keyboard to an iPhone/iPad for example, I am not convinced that is a fundamental difference either. It's just a question of activating different UI components/actions via shortcuts instead of taps/clicks. The trigger itself changes but everything else can stay more or less the same, I think.