Comment by Piskvorrr | Hacker News Reader

Comment by Piskvorrr | Hacker News Reader

Parent Full thread

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

Reply on news.ycombinator.com