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 things to be.
2. We have worked hard on optimizing our UI layer over the past several months including mapping of keyboard shortcuts and smoothening out performance issues.
3. We are able to provide a consistent experience for Windows, Linux and macOS users and people love that EVERYONE in the team can use the same app. That has very clear advantages when development teams are chosing tools. Postman is used by everyone who comes in touch with APIs - product managers, sales, customer support, dev evangelists and a cross-platform app allows everyone to standardize much faster.
4. Reusability in the code base through node packages is amazing to have.
5. We use React and are aiming for reusability of these components in the browser. This includes stuff like visualizations, data rendering etc. Our time to market has come down like crazy.
6. With node, not only do we get reusability across OSes but also between the app and our server-side stuff. We have a command line tool called newman that uses the same runtime (postman-runtime, open-sourced on Github) and the same runtime powers our monitoring service that runs on the cloud.
That's just some of the advantages. There is a lot of work going on in optimizing our code base. Ultimately we are validated by whether we do a good job for people who use the application. I have been building Postman over the past 5 years now and that has been the core guiding princple.
>> 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.
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.
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.)
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.
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.
>> 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.
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.
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.
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.
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.
>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 ?
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.
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 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).
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.
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:
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 things to be.
2. We have worked hard on optimizing our UI layer over the past several months including mapping of keyboard shortcuts and smoothening out performance issues.
3. We are able to provide a consistent experience for Windows, Linux and macOS users and people love that EVERYONE in the team can use the same app. That has very clear advantages when development teams are chosing tools. Postman is used by everyone who comes in touch with APIs - product managers, sales, customer support, dev evangelists and a cross-platform app allows everyone to standardize much faster.
4. Reusability in the code base through node packages is amazing to have.
5. We use React and are aiming for reusability of these components in the browser. This includes stuff like visualizations, data rendering etc. Our time to market has come down like crazy.
6. With node, not only do we get reusability across OSes but also between the app and our server-side stuff. We have a command line tool called newman that uses the same runtime (postman-runtime, open-sourced on Github) and the same runtime powers our monitoring service that runs on the cloud.
That's just some of the advantages. There is a lot of work going on in optimizing our code base. Ultimately we are validated by whether we do a good job for people who use the application. I have been building Postman over the past 5 years now and that has been the core guiding princple.