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.
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.)
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.
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.
You should take a look at the current releases, you might be pleasantly surprised.
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()
val devices = flow {
while(true) {
emit(manager.getDevices())
delay(1000)
}
}
devices.collect { list -> ... }
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()
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 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.
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.
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.
McDonald's is probably most popular... "food serving place" in the world.
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.)
A lot of them. Enough for me to wish I could have OS bookmarks for specific app screens.
> Why does my program need this information?
Because I as a user don’t want to copy paste sensitive information? Also, not sure what the OPs point is, you can have autofill on native apps too.
> Why would my program present ads?
Because you’re a penny counter at big tech who subsidizes their product by stealing user information?
> Is that supposed to be a plus? Consider the user's side, too. Also, consider that things like Google Safe Browsing exist.
Web has one of the most hardened sandboxes out there, just because it was an attack vector for decades. Yes, it’s a good thing - less friction.
> Care to give an example?
VSCode loads faster than Xcode. Google Sheets loads faster than Numbers. On Windows you can start VSCode and brew coffee until VS is ready to roll.
I wish I figured this out years ago. I spent significant time learning and building with Flutter, iOS native — chasing that "native feel" — only to realize that for most of what I was building, a well-crafted web app would have been not just good enough, but actually better.
A lot of that comes down to the huge community and the shear amount of documentation that exists. OTOH, nowadays you will quickly be distracted by frameworks and build systems.
IMHO the biggest hurdle is hosting, but github pages makes even that somewhat easy.
This is so off-the-mark I am skeptical of the rest of the claims in this list.
You ever thought that it’s the reverse? That native toolkits were left to rot, because it’s always the cost center (looking at you Android team, you’re a fucking disappointment), while web continued to evolve?
> - Users can block ads
Google fuckers are desperately trying to fix the “feature”.
Too much complexity like checks notes Google Sheets, VS Code, Notion.
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.
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.
Why would you back Lazarus?
However, Electron & the web stack has clearly won.
They didn’t need to because they already had WinForms as a baseline experience for Windows UIs.
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)
Anyway, I think this generation is missing out on the experience of building in a real RAD environment. I'm more on the backend, but from what I see the pinnacle is fast hot reload, which pales in comparison to what could be.
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.
to that end, while i find beauty in dioxus, i've been more willy to play with expo.
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.
Hire a proper tech writer, not a student for a bowl of rice, who will fix this shit.
> 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.
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.
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 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.