1. I completely agree with you, which was a point in one of my talks. Companies want to brand their UI/UX. For instance, Pinterest doesn't want an OSX or Windows button; they want a Pinterest button. Designing once for a universal look is much easier, as different operating systems have different sizes of elements such as tabs, headers, menus, panels, scrollbars, which requires you to consider layouts for each OS. Essentially, you're making a different skin for each OS. Nobody does this! 2. A nice Nim API is a given. Compiling to a DLL is a nice feature. We've thought about this, and it's one of the reasons for 'genny'. It can generate a DLL with a plain C API and a Nim "header" file for use. 'Genny' effectively downcasts all of Nim's cool features to "plain C" and then upcasts them back to full Nim. 3. All widgets are custom now. Even a humble button can have many [hover animations](https://i0.wp.com/codemyui.com/wp-content/uploads/2016/11/3d-parallax-button.gif?fit=880%2C440&ssl=1), [icon transition states](https://dribbble.com/shots/7861076-50-Free-Animated-Icon-Set), [push states](https://css-tricks.com/how-to-recreate-the-ripple-effect-of-material-design-buttons/). I believe you only need to provide a default set of widgets as examples. You need to provide frames, rectangles, and text elements as building blocks, not full-fledged buttons. Instead of offering a low-level API, I feel like it should be mostly a low-level API. 4. Nim still hasn't solved multi-threading. We need to have [Atomic Arc](https://forum.nim-lang.org/t/10177#67447). As it stands now, 'ref objects' can't be passed between threads. Only raw pointers can. This is made even more complex by your DLL requirement. 5. This is one point I don't really agree with. Designing one paradigm well is hard enough. Designing two? In the same library? I think this is way too difficult! I would suggest picking one or the other but not both, and doing it well. 6. Everyone wants a fast, small, and performant solution. But it's hard to achieve. Just opening up an OpenGL context already requires ~20MB, and stripped-down Electron apps are in the ~80MB range. The UI requirements of something like [this](https://dl3.pushbulletusercontent.com/POrVXlpENmHSn7DshdfLn53z9KziYhiU/image.png) are way different from [this](https://dl3.pushbulletusercontent.com/DPopSvvz1ZRGRqYnvLZGirUglWREbMVN/image.png). I think using ~100MB is undesirable but acceptable. With the sheer number of fonts, icons, images, animations a modern app needs to have, it's unavoidable. 7. Modern Text Mode apps can be [really cool](https://dl3.pushbulletusercontent.com/IuIAprdmjtWMGCmcY6mulrrJTLGwOy84/image.png), like [btop](https://github.com/aristocratos/btop) for example. But again, I think it's too hard to cram everything into a single library with two paradigms. I say if you want to do text mode, immediate mode, or embedded well, just do that! Don't try to chase everything!
* * * My wish list would be much simpler and less prescriptive: > A Nim UI library that a startup can use effectively. 1. By 'Nim UI library,' I mean it needs to be pleasant to use from Nim, feel native to Nim, and be predominantly written in Nim. 2. By 'startup,' I mean it's very challenging to have an existing company switch to something new, but startups are created all the time and are open to trying innovative things. Modern startups typically target web, Android, and iOS platforms. 3. By 'effective,' I mean it should be better and faster than writing three separate apps for the web, Android, and iOS. * * * With [fidget](https://github.com/treeform/fidget), I discovered that writing a simple UI library is not that difficult. I have proven that it's possible to target the web (WASM and JS mode), Android, iOS, Windows, Mac, and Linux with a single code base! However, writing a good UI library is significantly more challenging. It's a massive undertaking that will span years. One needs to have many foundational elements first: GPU, OS APIs, vector graphics, raster graphics, fonts, and many more!
