Live data from Hacker News

Going native

blog.getpostman.com

141–150 of 245 posts

Re: Going native

#141
post #45

Earlier quoted context omitted.

That just makes the platform native, which doesn't say anything at all. Presumably the app itself is still written in javascript, so its not native at all - its just bundling its own (native) copy of chrome.

So are you saying anything with a runtime is not native, even if embedded in an executable? Is a go app native?

Does a go app use the native toolkit?

QT isn't native either.

Re: Going native

#142

Earlier quoted context omitted.

I would add consistent widget behavior to the list of benefits. More often than not, controls in browser hybrids and web apps fail to take all kinds of little subtleties (some of which are platform specific) into account, dragging down user experience by way of death by a thousand cuts. This can be compensated for obviously, but I'd argue that the time and energy tied up addressing these finer points (which can be qu…

That's a great point, but does addressing these finer points take more time than building two separate apps, for Mac and Windows? Or if a service doesn't find it feasible to build two native apps, aren't their users better off with an Electron app than accessing the web app in their browser? For example, Simplenote has an Electron app for the Mac, and I much prefer that to having to use simplenote.com in a browser.

Does an electron app make any difference?

Re: Going native

#143
post #95

Earlier quoted context omitted.

>> When we tell people we have a native app, they get it. People go to our apps page, download the installer and see everything exactly as they expect things to be. The term "native" is used to describe apps developed for a specific operating system. By this definition, clearly Electron apps (and hence Postman) are not native apps. Having to download an installer doesn't make it native. On smartphones, all apps are i…

The pedantic force is strong here.

People who aren't pedantic in tech end up wasting thousands of dollars due to miscommunication.

Re: Going native

#144

Hmm, does Electron really == "native" ??

It's a native binary executable with standard access to system APIs, so in the technical sense, yes.

By that logic, if I fork chromium and make a custom version of it that's hard-coded to start up HN in the first tab, then I've made a native HN app.

Re: Going native

#145

I think it's really disappointing that so many of the commenters here have chosen to nitpick on the author's choice of the word native and then debating whether it was a good idea for them to use Electron. How about we all try out the app for a few days and the come report back about our experience?

It is not really nitpicking when most Electron apps use tens to hundreds of megabytes of memory. If all the utility apps that I use regularly switched to electron, I would need an order of magnitude more RAM.

Moreover, these applications are then completely 'unnative' in the sense that the widgets do not look native on my OS, the widget behaviour is not native to my OS, the usual keyboard shortcuts are broken, etc.

Electron apps are the Java Swing applications of this decennium.

Re: Going native

#146

Earlier quoted context omitted.

The pedantic force is strong here.

Not really. Especially not on Hacker News. There's an expectation when someone says native app that you're getting a binary that you compiled from source you created with a reasonable expectation of performance. No one thinks native as being a webview wrapped executable where the authored source is actually a series of HTML, CSS, and javascript. They just don't. Calling it "native" is a misnomer.

What about using electron with the cachedData option...? Or some webassembly thrown into the mix? Is native a development style or a product?

Re: Going native

#147

These 'native' wrapped apps on desktop and mobile are always less in some way than a real native app. I know there is a cost benefit argument, but I personally avoid them.

On the other hand, there's Paw, a delightful native app in the same category that has morphed into an unusable tool that hangs every few minutes. Native experiences aren't always better.

Something's either wrong with your computer or you have some pathological case with your .paw file. Paw in general is pretty damn stable and fast.

Re: Going native

#148

Earlier quoted context omitted.

So are you saying anything with a runtime is not native, even if embedded in an executable? Is a go app native?

Does a go app use the native toolkit? QT isn't native either.

Actually, Qt (as in Qt Widgets) is a peculiar case. Qt draws its own widgets, but on some platforms uses native theming APIs to draw widgets (e.g. HITheme in macOS[1]). Though they are apparently experimenting with native widgets now [2].

So I'd say Qt is more native than e.g. Electron, but it is definitely not completely native. Except on Linux of course.

[1] http://doc.qt.io/qt-4.8/qmacstyle.html#details

[2] http://blog.qt.io/blog/2017/02/06/native-look-feel/

Re: Going native

#149
I thought this might be a nice alternative to Paw. But nope, yet another Electron app misleadingly marketed as "native", nevermind.

Re: Going native

#150
post #88

Postman founder here HN folks. Great to see the post get featured on the homepage! Lots of discussion about what is exactly native. I have posted some replies but some other points about the choice of words: 1. Postman has 3 million users and about 1.5 million MAUs. When we tell people we have a native app, they get it. People go to our apps page, download the installer and see everything exactly as they expect thing…

Is postman interceptor going away too?

The biggest sore-point for me is that I still can't copy-as-curl-request a POST request from Chrome debugger tools (or other browser) and import it into postman. Relevant issue:

https://github.com/postmanlabs/postman-app-support/issues/26...

Post reply on HN