Hacker News Reader

>> 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 installed in the same way. Yet, some are native and others use WebViews.

I am making no comment on Postman's quality (in fact I am a customer). However, advertising Postman as native seems a bit disconcerting to me.

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.

You're right about the meaning of 'native', but if you expect to have a 'reasonable expectation of performance' just because an app is written as a native binary, you may be sorely disappointed. There are plenty of poorly performing native applications out there, and it's also certainly possible to write minimal, fast HTML/CSS/JavaScript.

Absolutely. But you don't start out with a large memory footprint like an electron app, you actually have to code yourself into that problem instead of immediately inheriting it.

I'd still argue that most people are going to assume that a native app is probably faster than your average electron app, for a whole host of reasons.

That's comparing outlier to outlier. If you compare two averagely coded apps, something written in C++ will make an absolute joke of something written in Javascript.

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

What if the application does have compiled libraries generated from the authored source?

I'm not trying to define what a native app is, I'm only explaining the way many users such as myself perceive it today. The waters are obviously getting much murkier on what fits the definition of native and it does look like the writing is on the wall that the state javascript on the desktop is just going to continue to improve.

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

I wish I upvote this more than once.

Words have meaning.

Native doesn't mean browser in a window. Same as realtime doesn't mean "it'll get there faster. Maybe"

Words do have meaning but "native" has pretty unclear meaning.

Is JavaScript native? JavaScript is interpreted when it first starts, but eventually turns into machine code through JIT by most JS engines. So is JavaScript native because it gets converted to machine code, just as C++ does?

If you say no, then you're saying only AOT compiled languages are "native". So that eliminates Python, Erlang, Java. Even C#, the "native" language on Windows is not AOT (in most cases).

So that doesn't work, AOT has nothing to do with native. JavaScript is just as native as any other language.

So maybe the problem is the UI, right? That's where most people seem to have a problem. So as long as you are using Cocoa on OSX, GTK on Gnome, Metro on Windows, you're native, right? Oh, wait, Metro apps can be written using HTML, JS, and CSS. They are essentially identical to Electron apps. In fact, Microsoft supports (and encourages) you to create .appx packages from Electron apps [1].

Oh, and all of those Qt apps out there (like Calibre, by far the best ebook management software), not native (despite being C++ in a lot of cases).

So yeah, "native" has meaning, but the meaning is as clear as mud.

[1]https://github.com/felixrieseberg/electron-windows-store

Just commenting that that is a very good definition of what realtime isn't! :)

Ah! 15 years back I knew APIs were those Win32 ones listed by Microsoft to access insides of Windows.

Things change.

Why not call it "standalone app" (Chrome-less! though that might be confusing for other reasons.)

Mattermost (and Telegram?) call the electron-based apps "desktop apps", which is I feel is a nice tradeoff: not native but not browser.

I think Telegram uses Qt.

Yep, Telegram on Desktop uses Qt. It's even open-source and on GitHub: https://github.com/telegramdesktop/tdesktop

There's a separate macOS version as well: https://github.com/overtake/telegram

They used to have two apps, one using Cocoa (named "Telegram") and the other Electron (named "Telegram Desktop"). They transitioned the Electron app to QT and kept the "Telegram Desktop" name.

Electron is a browser though, just one with a lot of the chrome cut out.

Chrome without the chrome.

Naming things is tricky. Postman exists in the following places:

1. In-browser Chrome extension with a UI (Postman legacy app)

2. In-browser Chrome extension without a UI (Postman Interceptor)

3. Stand-alone/desktop Chrome app (can be run withput Chrome)

4. Command line tool (newman - runs the same runtime as Postman)

5. Stand-alone/native apps that can be installed (where most of the debate on this thread is)

6. Server-side runtime

We chose to use "native" because it avoids the confusion with the existing Chrome desktop app and informs people about the advantages of this version v/s the previous version in one word.

I think the line's a lot more blurry than you make it out to be.

Not only are Electron apps often visually and functionally indistinguishable from "native" applications on their respective platforms, but there are also varying degrees of integration with the underlying platform you can have within Electron apps.

For example, Electron supports including native modules which have to be compiled for a specific platform. How many of those would an Electron app have to use before it's considered "native"? Or what about an app like Spotify, which only uses a web view for certain components of the UI and everything else is written in C/C++? Does merely using an interpreted language like JS or Python anywhere in your app mean it's no longer native?

Also, keep in mind that this blog post was written for Postman's users, it's not a technical write up. Postman's users may be more technical than most, but they still shouldn't have to know or care what underlying technology was used to build Postman's desktop apps. From their perspective calling them "native" apps is perfectly accurate, as they behave as native apps in every respect.

Electron apps are most certainly not functionally indistinguishable from native apps. They are always much larger and always seem to consume orders of magnitude more resources (memory, CPU.) If despotify still worked I would absolutely use that instead of the slow, buggy webview based official client.

People want native apps because they don't want the cooling/memory/power consumption from the web, as well as their delay tolerance and consistent UI. Electron can only provide the second (and sometimes the third.)

That's a valid concern and I believe all developers who are working on the platform will address this. If memory/power consumption on laptops was so draining just because something was in HTML/CSS/JS, I believe people would have stopped using browsers or probably just stuck to 1-tab per browser.

Performance is a property of an application as a whole, not just the framework it's built on.

While you can certainly argue that apps which use webviews are slower on average than their native counterparts; Electron-based apps aren't necessarily always going to be slow; and native apps aren't necessarily always going to be fast.

Therefore, since a user cannot conclude that an app is "not native" merely by observing its performance, Electron apps cannot be said to be functionally distinguishable from native apps merely because they're slower, on average, than other applications.

People conclude things based on their experience using them. There are a lot of bloated feeling electron apps out there that are popular right now, which leads to people concluding (not incorrectly) that electron apps tend to be slower than native ones based on their experience.

Agreed. However, perceptions change as technology improves and overall the arc of software tools has been towards higher level abstractions unless absolutely required to go deeper.

>> The term "native" is used to describe apps developed for a specific operating system.

I would have said that "native" means compiled for a specific operating system or a processor. If someone develops an app using Qt which then works on multiple operating systems, it would still be considered native.

I used PostMan on the Mac for a couple of projects and now I'm thinking thrice before even starting the app.

The UI makes no sense to me, but I would need an UX study to find out what's up exactly.

I just know

. that I keep searching for buttons

. that somehow Postman never remembers my state. I have these "tabs" open, close them all, close the app, and when coming back there are tabs open again. When I want to close them it asks me about unsaved changes. (Which changes???)

. the panes can be resized in a way that you can hide their content, but have to fiddle around with the mouse to find the invisible point where you can size them up again.

. when saving a large response (1MB) from somewhere it keeps trying to sync that to the library which means that everything else is becoming really slow.

. It's really not easy to rename anything. I click on a Tab, duplicate it, now I have two Tabs with the same name (it does not even say 'duplicate' or 'copy'). I click the title to rename it, nothing happens.

. Oh and the title is displayed twice, once in the tab and once beneath it. Clicking on neither of them gives the option to rename. You have to find the invisible pencil icon first.

. I think the Tab metaphore isn't appropriate, especially the new Tab page. I would like to close everything.

. There should be a feature to auto-name requests or something. I keep being confused between the request, the description, the two titles.

. Don't get me started on managing environments.

Feel free to email me at help@getpostman.com and we can go through each of these concerns :)

There is a big discussion on tab behavior on our Github tracker. There are different ways and workflows that you can adopt and settings that you can tweak.

On environments: we have autocomplete and inline editing for variables on the way. That should help.

>that somehow Postman never remembers my state. I have these "tabs" open, close them all, close the app, and when coming back there are tabs open again. When I want to close them it asks me about unsaved changes. (Which changes???)

that's an anecdotal remark but it seems to me that I hear this a lot about webapps.

is there anything that makes cleanly handling state harder in a web based app ?

Or is it just that the quality bar is lower ?

I think calling it "standalone app", rather than native would have been more correct. Yeah, go ahead and do exactly that.

Reply here: https://news.ycombinator.com/edit?id=13949208

> When we tell people we have a native app, they get it.

Are people here not... people? You seem to describe a desktop app. Bring able to install it has nothing to do with being native or not.

I could have used the term "users" to say the same thing. And everyone here might not be a user. And our existing users perceive the existing Chrome app as a "desktop" apps too. Postman existing as in-browser extension, then a Chrome "packaged"/desktop app and finally in it's current form. They are also "installed" in a particular way. I'd still prefer the term native over desktop apps.

I agree. Calling it a desktop app only causes confusion, since it contrasts it with a mobile app.

I had to read a few comments on HN and Google your product to understand what it is. reading on your website told me (almost) nothing about your product. (I am more a desktop dev, very new to web).

From https://www.getpostman.com/

"A powerful GUI platform to make your API development faster & easier, from building API requests through testing, documentation and sharing"

Then searching, I found this:

https://seesparkbox.com/foundry/api_testing_with_postman

"...for interacting with HTTP APIs. It presents you with a friendly GUI for constructing requests and reading responses"

It's a bit sad I (an experienced dev) need to google outside your site to find out what your product does. Hope this helps.

We are always working on making things better. Some videos here: https://www.youtube.com/channel/UCocudCGVb3MmhWQ1aoIgUQw

I appreciate that you consider these all to be big advantages, but as a user they fall somewhere between "doesn't matter" and "makes the product worse". The only benefit to your users is the faster time to market, and that's debatable.

As a user, I want an application that performs well (which Electron apps typically don't, my main issue with Atom and Slack), and I want an app that fits in well with my platform, which an app designed to be the same on all platforms just isn't good at.

Time to market means the difference between dying and not dying. I built Postman as a solo developer for 18+ months so have seen the extreme end.

Also, platform parity is not easy to achieve. Even within Javascript environments. Other tools like Fiddler, Charles Proxy etc. for example have NEVER been ported natively to another platform for this reason.

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

Does it support NTLM authentication yet?

If not, I still can't make the switch. :(

Highest priority item on the list! :)