You can still do this!
The only difference is that a lot of apps prioritize cross platform UIs over good, fast native UIs.
WinForms and WPF are still well supported.
592 karma · joined July 9, 2017
The only difference is that a lot of apps prioritize cross platform UIs over good, fast native UIs.
WinForms and WPF are still well supported.
The Microsoft Teams client frustrates me daily.
How many people do you need to build JUST the native Android and iOS app for snapchat?
Is the "single" codebase really worth all the added complexity and additional risk?
I'd always go the native route if the user experience is business critical.
> What do you put in the common core? Android does HTTP requests one way. iOS does them another way. You go for the lowest common denominator an implement a third way, using libcurl or something?
If it's really functionality that cannot reasonable be shared don't share it.
It's probably more work to maintain bindings to a single API client in the core and fiddle with all the details of not using the native HTTP client implementations that it is to implement the API client twice.
Writing the API client twice is boring, but that's a good thing.
> Or do you just put business logic in the common core? Is there really that much business logic that doesn't issue requests or access a database?
The shared core is optional. You might have the need for it, then it's a good solution.
For an app like snapchat you'd probably share the video effects and have that in your core library.
One extra clarification: If the quality of your app is business critical you should really use the native UI toolkit to offer the best platform integration and user experience.
If your app is not business critical (you just have to offer it - example: dishwasher app, ..) you might get away with using a cross platform toolkit like flutter or react native. But even then this adds a 3rd party dependency as you mentioned which adds risk.
Writing an App in Swift on iOS is boring. The same thing is true for writing an Android app using Kotlin/Java. This is a good thing. Now your developers can concentrate on shipping great features.
How hard could it be?
I've stumbled over sixels [1], but movy seems to use something else that also enables color output and a higher resolution?
[1]: https://en.wikipedia.org/wiki/Sixel
EDIT:
> It renders frames as ANSI half block characters..
Seems like the resolution looks better than it actually is in the screenshots. It effectively seems to be 2 vertical Pixels per character.
How would you verify that the ported code actually works if you don't port the tests and examples?
I see tremendous use in a tool that could be used to port "any" library to any language. I'm very skeptical if this works if the library itself depends on other language specific libraries, ... but we'll see.
If you'd seriously want to use that port in production it only makes sense to port the tests and examples. How would you verify the ported code works otherwise? This also means that if the original library has bad test coverage.. you have too.
I think fact that Zig can be used as a C/C++ cross compiler is brilliant.
Had to look twice at the author name. Thanks for all the Avalonia related work you are doing!
I don’t like that there are 3+ ways of checking if a value is null tho.
F# has FuncUI - based on Avalonia. All just possible because of the ecosystem.
I'm know .NET in and out, so I might be biased. Most of the boring parts have multiple good solutions that I can pick from. I don't have to spend time on things that are not essential to the problem I actually want to solve.
I've used F# professionally for multiple years and maintain a quite popular UI library written in it. But even with .NET there still are gaps because of the smaller F# language ecosystem. Not everything "just works" between CLR languages - sometimes it's a bit more complicated.
The main point I'm trying to make is that going off the beaten path (C#) for example also comes with a cost. That cost might or might not be offset by the more expressive language. It's important to know this so you are not surprised by it.
With OCaml it's similar I'd say. You get a really powerful language, but you're off the beaten path. Sure, there are a few companies using it in production - but their use case might be different than yours. On Jane Streets Threads and Signals podcast they often talk about their really specific use cases.
True. It might be just me but I think the color makes it look cheap.
Red and Blue are IMO not needed as you can always add an accent using the band. Probably just makes everything more complicated.
It’s useful as an built-in quick docs / search that can spit out small code fragments.
Every time I gave it more space results were disappointing.
API quality is often not relevant to the business after it passes the “mostly works” bar.
I’ll just use plain http or RPC when it’s not important and spend more time on things that make a difference.