But a huge amount of them use web technologies which are pretty much OS independent. I'm using Linux for 10 years now and I used to have trouble to work with others because they where all using Windows-only software (proprietary chat client, MS office, etc.) but it's less the case anymore because for many use-cases everybody uses web applications instead of native software.
> It turns out people want fancy, fat UI -- and rendering that server side isn't a very good idea.
That's why JavaScript is the dominant language out there. And with WASM comming, even what's currently out of reach of JavaScript will be doable on a web plateform (except high-end gaming maybe).
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)
>>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.
Fixed that for you.
I am a developer, with UI experience going back to Amiga/Windows 3.x days, and will only touch Electron if forced by customers/employer to do so.
I've found the development experience using TypeScript and React to be fairly pleasant, though. I know some people gripe about JSX/TSX, but it seems to me it's a lot like XAML - declarative XML that you can use to lay out your interface and hook up event handlers.
I've been enjoying the UWP, WPF, and macOS ports of React Native. They make it fairly easy to get up and running with something that'll let you share 80% of your code cross platform while still making it easy to write extensions with the native OS toolkit when needed. From what I've observed, RN desktop apps are much more CPU and memory efficient than Electron apps. In my mind, this is a much better way to create desktop applications using (mostly) web technology.
It's the business which is pushing for JavaScript: for most product nowadays you need to support both Windows and MacOS. Now you need to consider the following trade-off: do you want native apps at the expense of two code bases ? Or do you prefer a portable one at the expense of quality ?
In many cases the answer is a cleary the second option. Now you just have to chose which portable runtime you want: Java like it's 2000 or the web which is the current norm.
An hybrid approach is Qt since it wants to be a tool to build portable native apps, but in fact they are neither really native (the UI doesn't feel right) nor really portable (it often doesn't work out of the box).
As a user, when given the option, I always use native.
And I know many that do the same, specially in mobile apps.
At work, when given the option, I rather produce native applications than web ones.
Idk, maybe I a sheltered in Silicon Valley, and I know that most of the buisiness world has a lot of legacy windows apps you need to run your buisiness, and if it ain't broke no one is changing it. But, for new apps, I don't see why you wouldn't do SAS. It will be a slow process for sure but I can't see what will reverse it, except for maybe widespread privacy concerns about the cloud.
6 years ago we thought netbook thin clients paired with powerful backends would dominate. But here we are in 2017 - server side rendering of UI is waning while rich and robust client side interface applications are thriving.
I think that late 2000's/ early 2010's vision of local computing withering in the shade of cloud resources is over. It turns out people want fancy, fat UI -- and rendering that server side isn't a very good idea.