Hacker News Reader

Comment by stymaar | Hacker News Reader

> 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).

View on HN

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)

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.

Well, now the lock in is at the server side instead... Google Docs anyone?

> 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.

>>With web apps there are issues such as vendor lock-in of your data

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.

Updating a local app is under your own control.

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.

It is also perfectly possible to build a clean PHP app. Yet, the overwhelming majority of PHP apps are piles of hacks and the overwhelming majority of JS apps are bloated behemoths, because those are languages that are sloppy or hungry (respectively) by default, these are the paths of their least resistance. With the current "ship it first, fix it maybe later, never pause to think it through" mentality, all you'll ever get is the default.

(And don't get me started on Web security, or rather lack thereof: security is not inherent to web apps"; DROP TABLES; --

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.

> 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.

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.

> 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).

> 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.

Reply on news.ycombinator.com