I did something similar. I’m not a developer, but I use programming as a problem solving tool, and have written little apps for limited uses such as controlling a fixture in the factory — stuff that the devs won’t touch. My first language was BASIC on a mainframe, before I had access to a microcomputer.
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.
> I ended up with Python, and have been loyal to it for 13+ years
As another long-time Pythonista: I feel like I would have ended up with it anyway, but I do kinda wish I'd done more of that kind of experimentation around that time.
Certainly I've made mental lists of things I'd change about the language. (Not a lot of overlap with the complaints I hear most often, actually.)
I'd love to see that list, I'm really intersted in your perspective given the time you put in.
It was kind of a hodgepodge, since I gave myself a couple of rules. First, it had to be free. Second, it had to run on both Windows and Linux. Those were harder constraints in the 2010's.
To give a flavor, I tried Python, GCC, Javascript, and some higher level tools like Maxima and Octave. So I was certainly not systematic in my search. And trying Python coincided with a really pleasant and comfortable vacation where I had some blocks of time to play with it in peace.
The devs at my workplace had just jumped onto C#, but it was exactly during the time when C# was a mountainous download, hard to install without a good network connection, and Windows-only. I didn't relish staying dependent on Microsoft. Building a "hello world" app also seemed laborious.
Some of those issues have become meaningless, but here we are. On the other hand the growth of the Python community and ecosystem are hard to dispute.
You can see that among Python, Maxima, and Octave, you've got a REPL and a notebook style interface. At a previous job, I was a heavy Mathematica user. But Python was definitely gaining momentum compared to those other tools.
If I were to issue a complaint about Python, it's that the language has sprawled to the point where it's hard to claim that it's easy to learn unless someone helps you get started with a subset of it.
Im curious to see the whole list of languages you tried, and result with each. I suspect it was related to finding suitable library for each problem (usb, graphics) more so than the language itsel. But maybe ecosystem is what we need from a language.
[deleted]
I wish you had tried C# with WinForms which is still has the best GUI development tooling in Visual Studio.
If I was still doing Windows development, I would likely still be using Winforms to this day - you can't beat it from a purely functional prototyping tool even if it doesn't produce the most aesthetic GUIs ever.
It's a great successor to IMHO one of the other all time best RAD environments, Visual Basic. (Though I've head Pascal had some really nice out-of-the-box tools for GUI work)
> As mentioned, my past experience with GUIs was with WinForms, and so I wanted to see what had changed or improved in the intervening years.
They didn’t need to because they already had WinForms as a baseline experience for Windows UIs.
Probably not what most on HN would think of, but for writing a simple app with a GUI, I'd suggest that Tcl/Tk is hard to beat. Of course the simple approach wouldn't suffice if the program had to be compiled to a native binary. Though Tcl/Tk has an excellent C API, so a binary version of the app could be built if considerably more work to accomplish.
I second this, Tcl is a lovely language in general and quite lisp like. One of the nicest and most unexpected experiences was learning it last year. Tk is then trivial from Tcl, with nice native GUIs being 15 mins away.
Yes indeed, I concur completely with your comments. I've used Tcl/Tk for a few decades and for a long time enjoyed it's Lisp-like character. Of all GUI toolkits Tk is by far the best thought out, no wonder it's been adopted by a number of other languages.
Tcl does have a few disadvantages, for one the lack of distinction between string and list types makes certain programs hard to write. Also the absence of lexical environment for the apply command requires awkward workarounds. Many Tcl users dislike expr syntax.
Warts notwithstanding, Tcl has allowed me to be very productive. Over the years it's been steadily improved, and yet remains mostly compatible with code written even decades ago. That's a rare accomplishment in the programming universe.
I think most people starting on linux or *bsd (and macos power users) will learn about POSIX long before they start programming. Usually because a shell script they want to run breaks
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.
Until we hit the YOTLD users will continue to be exposed to standards.
When I need desktop app for my personal needs, I'm still writing them in Lazarus (text editor, git client, music player, spreadsheet, image cropper, various oddball one off desktop apps). It works on Linux and windows. If it really doesn't need to be desktop (typically visual apps that works on different files in different local dirs, or opening it in browser would be awkward) then I make browser app or extension in vanilla js. If it can be both desktop or browser, I chose browser most of the time, Lazarus is not exactly pinnacle of bug free apps.
I think Jetpack Compose is not actually as bad as you think. I think it's really great and I wish more people caught on actually.
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:
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.
This model is probably really strange to people who haven't spent a ton of time working in something like Clojure.
Lazarus[0] would probably have scored well in this exercise.
It’s a bit hard to see from their website what would make you say this, but I am very curious!
Why would you back Lazarus?
Just because of the other examples, which even include C applications or GTK ones. Not strong contenders against something derived from old Delphi like Lazarus.
However, Electron & the web stack has clearly won.
Increasingly, there just aren't enough incentives to write native apps.
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.
Mourning the lost art of native app is HN's ritual routine. In the meanwhile VSCode has become the most used editor by developers and it's not even close.
I think a lot of hatred toward web apps actually comes from the hatred toward cloud-first design. Notion feels sluggish compared to Obsidian, but is it really due to electron? Or the fact that one is cloud-first while the other is local-first?
Edit: well I just looked it up and it seems that Obsidian is electron-based too.
> In the meanwhile VSCode has become the most used editor by developers and it's not even close
Correct me if I’m wrong but isn’t VSCode an Electron app? ie a webapp shipped together with a stripped down browser
I know that GitHub Codespaces open as a full VSCode editor in my browser so I always assumed it was the same code.
Yeah. You cannot achieve native performance with web apps, but most tasks are simple enough that wasm is plenty fast. If you generate a frame in 7ms or 1ms, the user can't tell the difference.
I think cloud-first design is natural because webapps have nowhere good to store state. On Safari, which is the only browser that matters for many web developers, everything can be deleted at any time. So if you don't want to have a horrible user experience, you have to force your users to make an account and sync their stuff to the cloud. Then, the most natural thing to do is to just have the user's frontend update when the backend updates (think old-school fully-SSR'd apps). You can do much better than that with optimistic updates but it adds a lot of complexity. The gold standard is to go fully local-first, but to really do that right requires CRDTs in most cases, which are their own rabbit hole. (That's the approach I take in my apps because i'm a perfectionist, but I get why most people wouldn't think it's worth it)
With the files API, apps could actually replicate the microsoft word experience of drafting a file and saving it to your desktop and praying that your hard drive doesn't fail, but despite offering great benefits in terms of self-custody of data it was never a great user experience for most people.
> With the files API, apps could actually replicate the microsoft word experience of drafting a file and saving it to your desktop and praying that your hard drive doesn't fail,
Even withou the files API, with local storage, web apps can (and some—mostly extremely casual games that are free—do!) duplicate that experience with the extra risk of your data being lost because your disk became too full or some other event causing the local storage to be cleared.
> No download and install process
Plenty of Electron apps expect you to do this anyway. "Apps using web tech" aren't all web sites.
> No "please wait while we update this"
Not everyone has a fast web connection.
On the flip side, plenty of programs have no reason to use a web connection at all once they're downloaded and installed.
> Users can link to individual pages within my app... Users can find text on any page in my app
How many apps out there really have "pages"?
> Users get autofill for forms and passwords and credit cards
Why does my program need this information?
> Users can block ads
Why would my program present ads?
> No "SmartScan couldn't verify if this app is safe" because it wasn't signed with a cert.
Is that supposed to be a plus? Consider the user's side, too. Also, consider that things like Google Safe Browsing exist.
> A knee-jerk answer is often "performance", but honestly, most web apps load faster than their native counterparts these days.
Care to give an example?
(It also generally comes across like you just take for granted that your users will be on mobile.)
> most web apps load faster than their native counterparts these days
maybe i'm doing something wrong, but from what i've noticed, the browser is usually what takes up most of my computer's resources.
also, i assumed the reasoning for using a native app was for offline use, honestly.
[deleted]
They should've tried Flutter, which is what I primarily use for building apps, and it's hard to find a competitor that's as "write once, run everywhere," as Flutter. Only Dioxus with their native renderer might come close, but that's years away from being at a Flutter-level production capacity.
i worry about Dioxus. not because "they're going to be destroyed by their VC funding" directly, but indirectly. is this a sustainable endeavor? does the market really want them or care about them? it's hard to consider and commit to them, when it's unclear if they're sustainable or just running on the fumes of a passionate founder three months away from marking the project as unmaintained and walking away.
to that end, while i find beauty in dioxus, i've been more willy to play with expo.
That's what happened to Darklang, if I recall correctly. I've been hearing about it for almost 10 years now and they went through multiple language rewrites and ultimately went bankrupt and then open source. Turns out it's hard to make money in languages and tooling.
Flutter turned out surprisingly useful.
Now, make a web app and compare the effort and tooling.
First paragraph:
> After writing that (no-longer-)recent post on web development, I wanted to get a personal "feel" for what the "new developer experience" is actually like across all of the current platforms if you don't resort to web tech such as Electron.
With which framework and tooling?
Even vanilla js embedded in a HTML file would probably have been easier than most of these.
> I wanted to get a personal "feel" for what the "new developer experience" is actually like across all of the current platforms...
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.
> Without explaining that, the rest of this blog post is just rambling notes about developer ergonomics.
That's how I took it, and I enjoyed it thoroughly. If you're making a small app by yourself, sufficiently bad developer ergonomics can be the reason that the app doesn't get made at all, or the frustration makes me regret it. That's important for me.
> Maybe I'm just too young to have ever experienced the kind of stability expected here.
This could be it. I've been around many cycles of technology, and it always feels like a great waste when you have to abandon your tools and experience for something that's buggy and better in only a few small ways. I'm willing to tolerate a lot more bullshit for something that I know will be long-lived, like QT or a static website, than Microsoft's UI-framework-of-the-month.
I guess the author's perspective is one of someone who has little experience with current tools/frameworks, so "ergonomics" become somewhat more important. Most of the complaints are actually about lack of documentation, not instability of interfaces.
I also liked the article especially because it avoided web apps, which I think are a subpar solution to a problem the software industry created itself by not developing more standards like W3C.
I did something similar. I’m not a developer, but I use programming as a problem solving tool, and have written little apps for limited uses such as controlling a fixture in the factory — stuff that the devs won’t touch. My first language was BASIC on a mainframe, before I had access to a microcomputer.
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.
> I ended up with Python, and have been loyal to it for 13+ years
As another long-time Pythonista: I feel like I would have ended up with it anyway, but I do kinda wish I'd done more of that kind of experimentation around that time.
Certainly I've made mental lists of things I'd change about the language. (Not a lot of overlap with the complaints I hear most often, actually.)
I'd love to see that list, I'm really intersted in your perspective given the time you put in.
It was kind of a hodgepodge, since I gave myself a couple of rules. First, it had to be free. Second, it had to run on both Windows and Linux. Those were harder constraints in the 2010's.
To give a flavor, I tried Python, GCC, Javascript, and some higher level tools like Maxima and Octave. So I was certainly not systematic in my search. And trying Python coincided with a really pleasant and comfortable vacation where I had some blocks of time to play with it in peace.
The devs at my workplace had just jumped onto C#, but it was exactly during the time when C# was a mountainous download, hard to install without a good network connection, and Windows-only. I didn't relish staying dependent on Microsoft. Building a "hello world" app also seemed laborious.
Some of those issues have become meaningless, but here we are. On the other hand the growth of the Python community and ecosystem are hard to dispute.
You can see that among Python, Maxima, and Octave, you've got a REPL and a notebook style interface. At a previous job, I was a heavy Mathematica user. But Python was definitely gaining momentum compared to those other tools.
If I were to issue a complaint about Python, it's that the language has sprawled to the point where it's hard to claim that it's easy to learn unless someone helps you get started with a subset of it.
Im curious to see the whole list of languages you tried, and result with each. I suspect it was related to finding suitable library for each problem (usb, graphics) more so than the language itsel. But maybe ecosystem is what we need from a language.
I wish you had tried C# with WinForms which is still has the best GUI development tooling in Visual Studio.
If I was still doing Windows development, I would likely still be using Winforms to this day - you can't beat it from a purely functional prototyping tool even if it doesn't produce the most aesthetic GUIs ever.
It's a great successor to IMHO one of the other all time best RAD environments, Visual Basic. (Though I've head Pascal had some really nice out-of-the-box tools for GUI work)
> As mentioned, my past experience with GUIs was with WinForms, and so I wanted to see what had changed or improved in the intervening years.
They didn’t need to because they already had WinForms as a baseline experience for Windows UIs.
Probably not what most on HN would think of, but for writing a simple app with a GUI, I'd suggest that Tcl/Tk is hard to beat. Of course the simple approach wouldn't suffice if the program had to be compiled to a native binary. Though Tcl/Tk has an excellent C API, so a binary version of the app could be built if considerably more work to accomplish.
I second this, Tcl is a lovely language in general and quite lisp like. One of the nicest and most unexpected experiences was learning it last year. Tk is then trivial from Tcl, with nice native GUIs being 15 mins away.
Yes indeed, I concur completely with your comments. I've used Tcl/Tk for a few decades and for a long time enjoyed it's Lisp-like character. Of all GUI toolkits Tk is by far the best thought out, no wonder it's been adopted by a number of other languages.
Tcl does have a few disadvantages, for one the lack of distinction between string and list types makes certain programs hard to write. Also the absence of lexical environment for the apply command requires awkward workarounds. Many Tcl users dislike expr syntax.
Warts notwithstanding, Tcl has allowed me to be very productive. Over the years it's been steadily improved, and yet remains mostly compatible with code written even decades ago. That's a rare accomplishment in the programming universe.
I think most people starting on linux or *bsd (and macos power users) will learn about POSIX long before they start programming. Usually because a shell script they want to run breaks
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.
Until we hit the YOTLD users will continue to be exposed to standards.
When I need desktop app for my personal needs, I'm still writing them in Lazarus (text editor, git client, music player, spreadsheet, image cropper, various oddball one off desktop apps). It works on Linux and windows. If it really doesn't need to be desktop (typically visual apps that works on different files in different local dirs, or opening it in browser would be awkward) then I make browser app or extension in vanilla js. If it can be both desktop or browser, I chose browser most of the time, Lazarus is not exactly pinnacle of bug free apps.
I think Jetpack Compose is not actually as bad as you think. I think it's really great and I wish more people caught on actually.
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:
But you need it to be declarative instead of imperative, so you use a Flow: Devices is now a cold flow. It does nothing unless it's being collected. When you start collecting it, e.g. by using collect: 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:
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.This model is probably really strange to people who haven't spent a ton of time working in something like Clojure.
Lazarus[0] would probably have scored well in this exercise.
[0] https://www.lazarus-ide.org/
It’s a bit hard to see from their website what would make you say this, but I am very curious!
Why would you back Lazarus?
Just because of the other examples, which even include C applications or GTK ones. Not strong contenders against something derived from old Delphi like Lazarus.
However, Electron & the web stack has clearly won.
Increasingly, there just aren't enough incentives to write native apps.
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.
Mourning the lost art of native app is HN's ritual routine. In the meanwhile VSCode has become the most used editor by developers and it's not even close.
I think a lot of hatred toward web apps actually comes from the hatred toward cloud-first design. Notion feels sluggish compared to Obsidian, but is it really due to electron? Or the fact that one is cloud-first while the other is local-first?
Edit: well I just looked it up and it seems that Obsidian is electron-based too.
> In the meanwhile VSCode has become the most used editor by developers and it's not even close
Correct me if I’m wrong but isn’t VSCode an Electron app? ie a webapp shipped together with a stripped down browser
I know that GitHub Codespaces open as a full VSCode editor in my browser so I always assumed it was the same code.
Yeah. You cannot achieve native performance with web apps, but most tasks are simple enough that wasm is plenty fast. If you generate a frame in 7ms or 1ms, the user can't tell the difference.
I think cloud-first design is natural because webapps have nowhere good to store state. On Safari, which is the only browser that matters for many web developers, everything can be deleted at any time. So if you don't want to have a horrible user experience, you have to force your users to make an account and sync their stuff to the cloud. Then, the most natural thing to do is to just have the user's frontend update when the backend updates (think old-school fully-SSR'd apps). You can do much better than that with optimistic updates but it adds a lot of complexity. The gold standard is to go fully local-first, but to really do that right requires CRDTs in most cases, which are their own rabbit hole. (That's the approach I take in my apps because i'm a perfectionist, but I get why most people wouldn't think it's worth it)
With the files API, apps could actually replicate the microsoft word experience of drafting a file and saving it to your desktop and praying that your hard drive doesn't fail, but despite offering great benefits in terms of self-custody of data it was never a great user experience for most people.
> With the files API, apps could actually replicate the microsoft word experience of drafting a file and saving it to your desktop and praying that your hard drive doesn't fail,
Even withou the files API, with local storage, web apps can (and some—mostly extremely casual games that are free—do!) duplicate that experience with the extra risk of your data being lost because your disk became too full or some other event causing the local storage to be cleared.
> No download and install process
Plenty of Electron apps expect you to do this anyway. "Apps using web tech" aren't all web sites.
> No "please wait while we update this"
Not everyone has a fast web connection.
On the flip side, plenty of programs have no reason to use a web connection at all once they're downloaded and installed.
> Users can link to individual pages within my app... Users can find text on any page in my app
How many apps out there really have "pages"?
> Users get autofill for forms and passwords and credit cards
Why does my program need this information?
> Users can block ads
Why would my program present ads?
> No "SmartScan couldn't verify if this app is safe" because it wasn't signed with a cert.
Is that supposed to be a plus? Consider the user's side, too. Also, consider that things like Google Safe Browsing exist.
> A knee-jerk answer is often "performance", but honestly, most web apps load faster than their native counterparts these days.
Care to give an example?
(It also generally comes across like you just take for granted that your users will be on mobile.)
> most web apps load faster than their native counterparts these days
maybe i'm doing something wrong, but from what i've noticed, the browser is usually what takes up most of my computer's resources.
also, i assumed the reasoning for using a native app was for offline use, honestly.
They should've tried Flutter, which is what I primarily use for building apps, and it's hard to find a competitor that's as "write once, run everywhere," as Flutter. Only Dioxus with their native renderer might come close, but that's years away from being at a Flutter-level production capacity.
i worry about Dioxus. not because "they're going to be destroyed by their VC funding" directly, but indirectly. is this a sustainable endeavor? does the market really want them or care about them? it's hard to consider and commit to them, when it's unclear if they're sustainable or just running on the fumes of a passionate founder three months away from marking the project as unmaintained and walking away.
to that end, while i find beauty in dioxus, i've been more willy to play with expo.
That's what happened to Darklang, if I recall correctly. I've been hearing about it for almost 10 years now and they went through multiple language rewrites and ultimately went bankrupt and then open source. Turns out it's hard to make money in languages and tooling.
Flutter turned out surprisingly useful.
Now, make a web app and compare the effort and tooling.
First paragraph:
> After writing that (no-longer-)recent post on web development, I wanted to get a personal "feel" for what the "new developer experience" is actually like across all of the current platforms if you don't resort to web tech such as Electron.
With which framework and tooling?
Even vanilla js embedded in a HTML file would probably have been easier than most of these.
> I wanted to get a personal "feel" for what the "new developer experience" is actually like across all of the current platforms...
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.
> Without explaining that, the rest of this blog post is just rambling notes about developer ergonomics.
That's how I took it, and I enjoyed it thoroughly. If you're making a small app by yourself, sufficiently bad developer ergonomics can be the reason that the app doesn't get made at all, or the frustration makes me regret it. That's important for me.
> Maybe I'm just too young to have ever experienced the kind of stability expected here.
This could be it. I've been around many cycles of technology, and it always feels like a great waste when you have to abandon your tools and experience for something that's buggy and better in only a few small ways. I'm willing to tolerate a lot more bullshit for something that I know will be long-lived, like QT or a static website, than Microsoft's UI-framework-of-the-month.
I guess the author's perspective is one of someone who has little experience with current tools/frameworks, so "ergonomics" become somewhat more important. Most of the complaints are actually about lack of documentation, not instability of interfaces.
I also liked the article especially because it avoided web apps, which I think are a subpar solution to a problem the software industry created itself by not developing more standards like W3C.