Hacker News Reader

Comment by Razengan | Hacker News Reader

Speaking as a desktop user, I despise webview apps.

Until WebViews or web apps can offer the same buttery smooth scrolling and responsiveness as native apps, until they don't immediately look and feel out of place from the rest of my environment, until they not drain my CPU and battery, until they can offer standard menus and seamlessly interface with all the features of my operating system, like notifications, a unique icon in the Dock/Taskbar/app switcher, and OS X services and the like, native is the way to go.

Most of the purported advantages of web views in these arguments read like the excuses of lazy developers (or small teams with limited time), unwilling to acquire expertise in each of the major OS platforms and [re]learn all their APIs and GUIs and their quirks. It's understandable, but it definitely results in a diluted experience for the user.

View on HN

The battery thing is huge. I'm not a professional GUI developer but I've done quite a bit of GUI work as part of my real job, Motif, Tcl/Tk, PowerPlant, MFC, a range of different technologies over the years. Something that wouldn't have even moved the load average needle on a SPARC 20, 20 years ago, shouldn't be pegging a cpu core on a modern machine and making the fan spin like an aircraft taking off.

This cannot be said enough. I do not like talking about the past a lot as that is useless but yes: I did make a lot of complex apps natively on unix and windows machines many years ago and recently for fun or symbos: if you make similar apps on current system with web tech the cpu gets a massive hit for things that should not even be moving the needle. And on native tech it doesn't: but on tcl/tk it does not either which is not native.

I know this is the future, but with my job in which I do a lot of embedded software and mobile software next to web stuff, the web stuff really seems to be the cpu and memory killer which in turn drain the battery very fast.

Not sure if there is a solution if the biggest companies in the world cannot prevent their applications from doing that though.

Since you bring up Motif and SPARCstations, I should point out that people also complained about the performance of X GUIs back in the day. [1]

[1]: http://www.art.net/~hopkins/Don/unix-haters/x-windows/disast...

That is not how an engineer should think. An engineer designs the right tool for the job and does so as efficiently as possible (think money and time-wise). Say customer wants an app where its clients login, fill a couple of forms, do a couple of queries. What would a well trained engineer do for such app? Spend 4x to gain a 5-10% better UI experience and maybe a 30-40% battery efficiency? Or, would she sacrifice a bit of both but deliver a single code base that solves the problem?

Now, if such engineer faces a game or a camera/gps intensive app, she would probably choose native.

In any case, the good engineer never generalizes the solutions. Context is crucial.

And then every "good engineer" who adopts this means of defining success is in part responsible for the unresponsive UIs and spotty battery lives of devices running anything other than stock software.

"Why is my phone running so hot and always in need of charging halfway through the day?" Well, 5% CPU here, a battery-draining busy loop there... But the solutions solved the minimal target; so suck it up, end-user.

>What would a well trained engineer do for such app?

If those were the limits of the requirements, then yes. Your job is to fill the requirements while minimizing dev costs. Sometimes that means some compromises in latency, or other aspects of UI polish.

As a dev, that's understandable. As a user, it's annoying, and I'm going to look for any option that lets me do the same thing while avoiding the annoyance. The software has to provide an overwhelming benefit to make it worth my while (e.g. my laggy banking app that lets me remotely deposit a check).

Honestly, I don't know much about UX and customer engagement or how much it hurts a company if a customer waits to get to their PC to use a service, but it seems like a concern that's often downplayed when the requirements list is being written.

In fact, it may be just me but the whole WebView/Electron/whatnot thing feels like a tool that may have been intended for internal prototyping but got sneaked into a user-facing release, and now everyone is pretending they meant for that to happen..

The problem is that the platform gatekeepers (Google and Apple) have no incentive to make "webview" apps better. It seems they just want to lock you as a developer into their platform.

How do you reduce javascripts cpu use below something like c/c++?

Before you go off on "lock in", note that native apps have a distinct advantage over any web app using javascript. I hate having 20% cpu use for a stupid chat app on a modern i7 system. Most of that "app" is spinning around chasing its own tail making the cpu fetch memory incessantly and blow through cpu cache/tlb. I don't see that happening with native apps nearly as bad.

We have ASM.js/WASM, and it is pretty mature. If these platform owners really wanted to make it work, they had done so by now.

Excellent, are there any comparisons for the amount of energy used between that and a more native program? With comparisons for things like impact to cpu cache and memory?

Just throwing out a technology doesn't invalidate my point that javascript likely has a lower bound on energy and cpu/cache impact.

WASM isn't even ready for day-to-day use yet, and while ASM.js is mature, V8 has no special optimisations for it.

Furthermore, you're still running the code on the Javascript VM/interpreter, so it's unlikely to give much of a speed boost. The motivation behind WASM and ASM.js both is to cross-compile code from other non-JS languages (generally, C/C++) into code usable from JS.

Reply on news.ycombinator.com