I was getting sick of Visual Basic and Excel, and besides, my VB license was more than a decade old. So I went “language shopping” by trying out the same two tasks in a whole bunch of languages. And I also let myself be influenced by online discussions, blogs, etc. Between computers at work and at home, I tried out each language on both Windows and Linux. One of the tasks was computational and graphical, the other was controlling a widget connected to USB.
I ended up with Python, and have been loyal to it for 13+ years. Did I make the best choice? I can drum up a list of pro’s and con’s, but it would be based on hindsight.
Well, depends on the context.
In my domain (professional, non-software engineering) Linux users don't matter as Linux users generally don't like to pay for products, and Mac users don't matter because they do not exist in this context. Zero incentive to bother with anything that is NOT Microsoft ecosystem.
This isn't a criticism of the article, but rather a tangential observation about why so many people turn to the web instead of using native toolkits to build apps, and why so many of native toolkits feel uninspired and lacking any real innovation.
If I choose to build an app using web tech, I get:
- Universal distribution
- No download and install process
- No "please wait while we update this"
- Users can easily share my app
- Users can link to individual pages within my app
- Users get autofill for forms and passwords and credit cards
- Users can block ads
- Users can scale and zoom my content
- Users can find text on any page in my app
- No "SmartScan couldn't verify if this app is safe" because it wasn't signed with a cert.
- A clearer security model: web apps prompt the user for access to e.g. microphone, camera, or secure disk locations. Native apps can kinda do whatever they want.
Why would I give up all those things to write a native app? A knee-jerk answer is often "performance", but honestly, most web apps load faster than their native counterparts these days.
Another common answer is app store distribution, but web apps can now be published to the major app stores without Electron or other frameworks. Google Play and Microsoft Store both support PWAs, and iOS App Store supports web apps via web view.
There are some scenarios where a native app is warranted. For example, hooking into some native component or OS API; e.g. HealthKit on iOS. But for many apps, the web is good enough.
I can't comment on the learning materials as I was following it since the project started and I was already accustomed to the Android Developers website.
Kotlin has a few reactiveness concepts that make reactivity easier but might scare off developers from other languages. The most important ones are Flows and Coroutines.
Say you want to have a UI that shows the current list of connected devices that should always show up to date info. The function to get the list would be something like this:
val devices = manager.getDevices()
But you need it to be declarative instead of imperative, so you use a Flow: val devices = flow {
while(true) {
emit(manager.getDevices())
delay(1000)
}
}
Devices is now a cold flow. It does nothing unless it's being collected. When you start collecting it, e.g. by using collect: devices.collect { list -> ... }
Now it starts running the while loop and you get the up to date devices list in your lambda every second. You can also make the lambda run only when the list has changed, or debounce it, or run only for the latest value, and more with trivial function chaining.
But this function is suspending, which is Kotlin's way of async functions, and suspend functions take turns running on the threads that are managed by the coroutine scope they are in, so you need to provide it a coroutine scope by wrapping your collection in scope.launch { ... } .And your viewmodel can now collect the flow in a way that's going to be accessible without suspending (async) functions by turning it into a StateFlow:
val devicesStateFlow: StateFlow<List<Device>> = devicesFlow.stateIn(scope, some more arguments...)
// Now synchronous code can call like this:
print(devicesStateFlow.value)
// And Compose (reactive ui) code can do this in Composable functions:
val devicesState by vm.devicesStateFlow.collectAsState()
I think that was the source of confusion you had when you were trying to use datastore. It's designed for reactive applications so you were supposed to use it in a viewmodel, turn it into a stateflow and collect it as state in your ui.The distribution alone is hard to beat — if someone can open a link and try the app instantly, it removes a huge amount of friction.
If you type 'shell' into arch wiki the first line talks about POSIX On my system typing 'man sh' brings up a posix programming manual. On systems with dash the man page refers to POSIX. On Wikipedia linux mentions it all over the place, on unix's page the offical site link is a link to opengroups. Even 'man man' (man-db) mentions POSIX. Oh, and the coreutils info page mentions it right at the start (and 234 times in total) which based on my admittedly poor count is the second most used nonstandard word behind env beating out coreutils/cp/du/cksum/printf/uniq/.
Until we hit the YOTLD users will continue to be exposed to standards.
Hire a proper tech writer, not a student for a bowl of rice, who will fix this shit.
I don't really understand what this means. Without explaining that, the rest of this blog post is just rambling notes about developer ergonomics. Of all the things to focus on, that's going to be by far the lowest priority in app dev.
Maybe I'm just too young to have ever experienced the kind of stability expected here. My opinions of tools are based on what they are capable of doing and how well it lines up with what I expect them to do. That's my definition of "feel" as an app dev. I don't care if the interface is stable. I want the capabilities to be stable. To make an analogy, when I buy a new work truck I care more about the specs and not the stuff on the dashboard.
> ... if you don't resort to web tech such as Electron
And that's precisely why everything is now a web app for over a decade, and why W3C standards and big tech bureaucracy won out.