> 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 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.
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.
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.
> 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.)
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.
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)
Delphi has an amazing RAD environment. For building small, self-contained desktop apps (with cross-platform support!) it beats any other modern offering... if you can get past the ecosystem. The language and ecosystem very much show their age.
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.
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.
it's a bet for sure. but if you squint or zoom out, you can see that dioxus labs is creating a whole new land of possibilities with blitz, taffy and their rust hot-reload. nothing is more motivating to a founder than adoption so i think developers should look at the big picture and contribute more to help speed things up. a big blocker for me was video in blitz but i solved it myself. ultimately it's up to developers to take a risk and give dioxus some credible case studies. flutter really dropped the ball on web and dioxus has a huge opportunity on the line. hopefully people will give it a real shot to help build some momentum. they are miles ahead in a lot of ways simply due to the vastly available rust crates
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.
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.
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.
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.
I once ran out of disk space while Chrome was running and, despite me clearing the space again shortly after, the damage was already done and Chrome had already decided to wipe all my local storage and cookies. It didn't keep it in memory to save again once there was space, it just deleted it all permanently.
I’ll never understand “stripped down browser” like it’s some curse. Any managed language brings its own runtime. C# brings CLR runtime, Java brings JVM, Go brings its own runtime.
I tried a web search for "Minimal text editor" and Minimal vs Obsidian" and couldn't find any results that seemed to be an obsidian or notion equivalent.
> 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.
McDonald's is probably most popular... "food serving place" in the world.
I'm convinced that the real problem here is that people preferring websites only know how to make websites and won't learn anything new. The rest is just to frame it as a rational technical decision.
Because your product is a program and some of the features are paid. So you have a screen for the user to start/manage/cancel their subscription? It doesn't have to be some JS heavy thing, just that it will be a page in your app and you get autofill for free from the browser.
Native apps are where power users and other non-developers can do programming. The type of things that an engineer who lives in the terminal might make a CLI or TUI for, an accountant or project manager might want to do with a GUI. This is where VB6 and VBA lived, probably also HyperCard. Web tech has too much complexity for that.
I also find building apps for the web is much easier than any of the native frameworks. You can start by writing plain text in a file and then progressively add HTML, CSS, and JS. The app described in the article is trivial to implement in the web.
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.
Can't agree more. The web has won, and for the vast majority of apps, it's not even close.
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.
> and why so many of native toolkits feel uninspired and lacking any real innovation.
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”.
This hit a nerve as I am in the middle of developing a webapp for myself using NiceGUI.
I find CSS, especially its layout framework, pretty confusing and sometimes downright intimidating to work with. `inline`, `block`, `flex`, `grid` seem reasonable when you read about them. But when using it, especially within frameworks when flexboxes are nested within grids which are nested within flexboxes and so on, it becomes hard to reason about. And then you throw in media-queries in the mix and it becomes even more dense.
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 tried Tcl/Tk back in 2005 and abandoned it in favour of Qt/QML (and much later Flutter), mostly because UI was so bloody ugly it was embarassing to show to any other user except myself. Has anything changed since then?
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. 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.
Good that someone is calling out Compose. Android team and Google and JetBrains should be ashamed of the state of documentation around it. It’s all over the place, outdated the moment it is posted and generally feels like written by ADHD students. “Hello world” format virtue signaling they’ve posted on YouTube is an embarrassment and we’re clearly made as ones promo checklist.
Hire a proper tech writer, not a student for a bowl of rice, who will fix this shit.
I'm a semi-retarded product manager that was interested in what it was like building linux desktop apps. With a hand from Claude, I was surprised to get a simple Gnome/gtk widget that was functional and understandable. I was also able to iterate on it without any headaches.
> it's simply not clear why a new developer would or should bother to invest in Microsoft's ecosystem
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.
fsflover | 22 hours ago
NetMageSCW | 20 hours ago
maleldil | 17 hours ago
WalterGR | 20 hours ago
> 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.
sublinear | 22 hours ago
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.
BoppreH | 22 hours ago
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.
[OP] jmusall | 22 hours ago
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.
analog31 | 22 hours ago
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.
Mielin | 19 hours ago
MrZorro | 19 hours ago
analog31 | 17 hours ago
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.
zahlman | 17 hours ago
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.)
dvh | 22 hours ago
NetMageSCW | 20 hours ago
doesnt_know | 19 hours ago
They didn’t need to because they already had WinForms as a baseline experience for Windows UIs.
vunderba | 18 hours ago
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)
Tallain | 15 hours ago
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.
satvikpendem | 20 hours ago
spacecadet | 20 hours ago
dfee | 20 hours ago
to that end, while i find beauty in dioxus, i've been more willy to play with expo.
satvikpendem | 20 hours ago
jtesp | 14 hours ago
haolez | 19 hours ago
[0] https://www.lazarus-ide.org/
cadamsdotcom | 19 hours ago
Why would you back Lazarus?
haolez | 18 hours ago
However, Electron & the web stack has clearly won.
olcay_ | 19 hours ago
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.memothon | 17 hours ago
gavinray | 5 hours ago
judah | 19 hours ago
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.
p-t | 18 hours ago
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.
LtWorf | 4 hours ago
raincole | 18 hours ago
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.
ChadNauseam | 18 hours ago
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.
dragonwriter | 17 hours ago
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.
LoganDark | 15 hours ago
wiseowise | 12 hours ago
But muh 0.00001W of energy!
Swizec | 18 hours ago
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.
wiseowise | 13 hours ago
arthurofbabylon | 15 hours ago
wiseowise | 13 hours ago
MDCore | 9 hours ago
wolvesechoes | 10 hours ago
McDonald's is probably most popular... "food serving place" in the world.
zahlman | 17 hours ago
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.)
LtWorf | 13 hours ago
wiseowise | 13 hours ago
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.
zahlman | 12 hours ago
When using my program, why would the user need to supply a password or a credit card number?
wiseowise | 12 hours ago
Because they’re logging in to your application and then buying a thing with a credit card?
zahlman | 6 hours ago
Spivak | 5 hours ago
nevdka | 15 hours ago
wiseowise | 13 hours ago
Too much complexity like checks notes Google Sheets, VS Code, Notion.
nevdka | 11 hours ago
wiseowise | 10 hours ago
?
ximm | 14 hours ago
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.
kindkang2024 | 14 hours ago
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.
wiseowise | 13 hours ago
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”.
avilay | 12 hours ago
lelanthran | 11 hours ago
This is so off-the-mark I am skeptical of the rest of the claims in this list.
Spivak | 5 hours ago
jrapdx3 | 19 hours ago
veqq | 18 hours ago
jrapdx3 | 17 hours ago
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.
divan | 10 hours ago
casey2 | 16 hours ago
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.
stackedinserter | 16 hours ago
diego_sandoval | 14 hours ago
satGuess | 13 hours ago
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.
wiseowise | 12 hours ago
Hire a proper tech writer, not a student for a bowl of rice, who will fix this shit.
potatoproduct | 12 hours ago
wolvesechoes | 10 hours ago
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.