3 ms·

> robust client side interface applications are thriving. But a huge amount of them use web technologies which are pretty much OS independent. I'm using Linux

by stymaar 10y ago

> robust client side interface applications are thriving. 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).

leadingthenet 10y ago
I see this argument often, but think about it this way: people use Electron style apps because they have no other real choice. If I had the same app written natively and another implementation based on Electron, I'd pick the native app every single time. It's developers who are pushing for JavaScript, not users.
- pjmlp 10y ago
  > It's web developers who are pushing for JavaScript 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.
  - rpeden 10y ago
    I feel the same way about Electron, because I don't like shipping subpar applications to users. 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.
- stymaar 10y ago
  > It's developers who are pushing for JavaScript, not users. 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).
Piskvorrr 10y ago
That's very nice, but I feel that the price we're paying for running the Web-stack on top of normal application stack is atrocious, especially where a native, local application would be far more efficient. It works, yes; and I'm glad I'm not getting as many "Linux? Go away" issues these days; yet the bloat and latency of web-stack is something that remains largely unadressed in 2017. 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)
- vamur 10y ago
  With local apps there are issues of updates, security and platform lock-in. No such issues with web apps. And thanks to modern JS engines, web apps are now fast enough for most tasks. >>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.
  - jacobush 10y ago
    Well, now the lock in is at the server side instead... Google Docs anyone?
  - wila 10y ago
    > With local apps there are issues of updates, security and platform lock-in. No such issues with web apps. 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.
pjmlp 10y ago
> but it's less the case anymore because for many use-cases everybody uses web applications instead of native software. 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.

by stymaar 10y ago

leadingthenet 10y ago

I see this argument often, but think about it this way: people use Electron style apps because they have no other real choice. If I had the same app written natively and another implementation based on Electron, I'd pick the native app every single time. It's developers who are pushing for JavaScript, not users.

pjmlp 10y ago
> It's web developers who are pushing for JavaScript 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.
- rpeden 10y ago
  I feel the same way about Electron, because I don't like shipping subpar applications to users. 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.
stymaar 10y ago
> It's developers who are pushing for JavaScript, not users. 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).

Piskvorrr 10y ago

That's very nice, but I feel that the price we're paying for running the Web-stack on top of normal application stack is atrocious, especially where a native, local application would be far more efficient. It works, yes; and I'm glad I'm not getting as many "Linux? Go away" issues these days; yet the bloat and latency of web-stack is something that remains largely unadressed in 2017. 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)

vamur 10y ago
With local apps there are issues of updates, security and platform lock-in. No such issues with web apps. And thanks to modern JS engines, web apps are now fast enough for most tasks. >>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.
- jacobush 10y ago
  Well, now the lock in is at the server side instead... Google Docs anyone?
- wila 10y ago
  > With local apps there are issues of updates, security and platform lock-in. No such issues with web apps. 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.

pjmlp 10y ago

> but it's less the case anymore because for many use-cases everybody uses web applications instead of native software. 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.