>>but it's slow and unable to keep up with edits > 500 nodes
It is perfectly possible to build a fast JS app. The one in your example is not well optimized.
(And don't get me started on Web security, or rather lack thereof: security is not inherent to web apps"; DROP TABLES; --
With web apps there are issues such as vendor lock-in of your data (like doing accounting in a webapp) try getting your data out.
Vendor updating to a new non functional version of their web app while you liked the old one.
Security issues because your data is now on the internet instead of on a local PC.
You are just trading one set of limitations for another and also removing your ability to address issues by yourself.
You can use self-hosted web apps or a vendor that allows export of data. You can use a vendor that allows loading/saving data locally.
>>Security issues because your data is now on the internet instead of on a local PC.
The same is true for most local apps. How do you know they are not leaking your data?
>>Vendor updating to a new non functional version of their web app while you liked the old one.
True for local apps as well
>>You are just trading one set of limitations for another and also removing your ability to address issues by yourself.
There are always limitations, but web apps have less, which is why they are winning.
While self hosting webapps certainly is possible, this is not an option for the average user.
With a local app you can make it certain that it isn't leaking by not connecting it to the internet?
I guess we will have to agree to disagree on this as you are clearly looking at this from a different angle as I do.
Case in point: OSM editors. iD has very low barriers to entry: it's all in-browser, integrated with the website, nice rounded corners, and no dependencies - but it's slow and unable to keep up with edits > 500 nodes (because it's a memory hog built on a memory-hog JS framework running in a JS+DOM memory-hog virtual machine inside a memory-hog application). JOSM, on the other hand, is not quite native (Java being a memory hog of its own), but is capable to use persistent caching and relatively efficient memory structures. (I'm explicitly not comparing the feature set, which stems from different usecases or ease-of-use, which is somewhat subjective: this is in comparison of rudimentary editing operations)