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:
This appears to be an electron program. Is that native? I thought it was a specialized browser just for the program. I thought native was more akin to the wikipedia definition:
Maybe not Postman but at least you don't need an account: https://rest.secapps.com/ - https://httpview.secapps.com/ - #disclosure I am the author and we are making some substantial changes to make our tools available without registration
We use libgit2 server side, Paw does not talk GIT it talks json to our syncing service. (the repo format we have would not be very nice if you wanted to embed it in another project, since we split out each object in Paw into a separate yaml file to reduce merge conflicts, this means even small projects in Paw can be 1000s of files) During merges etc we run extra validation on the project to ensure we dont get corruption. (this is not easily possible with repos hosted on github etc) (paw backend dev here)
With a name like "Postman", one might expect this has something to do with mail, or messaging. The blog post gives no clue as to what it's for. It's apparently a test tool for testing HTTP-based APIs. [1] (HTTP "POST", get it?)
Not to be confused with Postman Corporation, which is a "computer repair shop" near CIA headquarters.
Point is that if they're selling a product, they could make it more clear what the thing they're selling is. I'm EXACTLY the target market, and they failed to entice me.
You're not the target market if you couldn't figure out what they are. I've never heard of it but one look at the screenshot told me exactly what it is.
The target market are developers who are in need of a very specific solution that postman provides. How do you think most postman users end up at the site? They probably search for some very specific keywords on google, asked some very specific question on stackoverflow, or got referred to it by reading some very specific article on reddit/hn/etc. They aren't people with 2 second attention spans who can't be bothered to read beyond the tag line.
smlacy's response felt pretty much like trolling to me.
Basically this is true but the browser (Electron) is designed to be single-purpose (your app) and has pathways to the filesystem that you can't get in a web browser.
Also, it is treated as an application by the OS rather than a Chrome window (and all the benefits that come with that shift).
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.
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.
My 2 cents. Try and add a notification within your Chrome App that there's a native version of your app as well. 'Cuz since now, although I've been using your app for more than a year now, I didn't know about the native version of the app.
PS: Paying customer :)
I've been on the native app for a while and was very glad to switch. The pseudo-standalone Chrome app had some very weird and obnoxious behavior when navigating between applications and windows on MacOS.
My guess is they are doubling down on Progressive Web Apps.
Many users don't understand the "browser is an app store" model.
Making installing an "App" a seamless transition for websites you constantly use, seems like a UX improvement, if Progressive can deliver on it's vision.
Yeah. That plus I believe it became exponentially difficult for the Chrome team to deliver a set of APIs for apps to replicate native experiences. One example was the menu bar. Apparently it would have required rewriting parts of Chromium in a generic way so Chrome could have its own menu bar AND allow customizability for apps. I was tracking bugs on the Chromium tracker for a while but don't have these links handy at this moment.
Big fan of Postman for quickly iterating on API's, microservice integration tests, and one off requests. However, my team keeps the collections in git and they are very difficult to diff. This almost always require a detailed commit (doesnt usually happen) or me asking the dev what they changed. Any suggestions on how to improve comparing two collections?
Thanks for the comment! If you are on Postman Pro you can export to Github directly. There is versioning built-in Pro too. That said, we have improved the format a lot over the years to support diffing just with Git.
When did we start calling Electron Apps, Native Apps? Is it now a marketing ploy to call your App native when it's not?
If your App renders in a WebView then by definition it's not native and shouldn't be labelled as such so it doesn't devalue Apps that use Native OS's UI components and idioms that are truly Native. If it has a mix of native and WebView controls then it's at best a Hybrid App.
I am not sure why something would be inherently superior if it is using pre-built OS components. Any software can have memory leaks, buggy behavior, weird input issues etc. I'd rather look at the user experience and qualify something as better/worse after using it. Postman had issues in the beginning when we started porting things over but these were quickly solved and in fact gave us much more power over the experience.
The point isn't entirely that "true" native apps are superior, the point is really that WebView wrappers are no more a "native" application than a standard HTML web application, because that's exactly what they are and pretending otherwise is deceptive.
As for applications built with OS components being inherently better, there are a few reasons for me:
- They are guaranteed to fit in with OS styling
- They near-universally perform better (and I don't see how this can change, given the way browsers are forced to render things)
- The underlying functionality is written in native code, which allows for optimizations that cannot be made on web applications
- They don't have the insane and unnecessary bloat of a modern web browser attached.
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 quite significant) would be better spent on what your product actually does and the user experience surrounding that.
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.
I think there's a lot of variables at play, all of which need to be considered. The answer won't be the same for everybody.
To me the ideal candidate for electron is moderate complexity with an audience that's likely to value day-1 cross-platform support over other factors. If it veers toward the simpler side of things like Simplenote, electron is overkill, as developing separate native front ends isn't going to pose too much of a challenge (especially if platform agnostic code is shared). On the other end of the spectrum with a high complexity app (e.g. same class as Photoshop, Maya, etc), you're frequently going to find yourself at odds with the limits and performance issues of web tech and whatever conveniences it affords you are largely rendered moot.
As for if a wrapper offers value, with ever increasing OS-browser integration I'd say whatever value that's there is quickly being eroded. Personally, if I have the choice of running an Electron wrapped-web-app vs. running a web app in my browser and a true native app isn't available, I'll take the latter in most cases for the greater control it affords me. It allows me to take resource consumption into my own hands (to an extent) by choosing Safari or Firefox instead of embedded Chromium and it lets me controls what scripts are running, what domains are being accessed, etc.
They aren't. For example, if you move your cursor to a word in macOS, and force touch, pop up will appear with word's definition from Dictionary.app. This is not a case in "native" applications that render text differently, Sublime Text is my offender, but there must be others.
But sublime isn't really a native app either. When did we start corrupting the meaning of native? When electron apps appeared, and we wanted to divide "compiled" versus "interpreted webapps" on the desktop?
Cross platform toolkits, be it proprietary, one-off like Sublime's, or things like Qt, GTK, WxWidgets, Java Swing, were NEVER considered native. Just because an app is written in C or C++ doesn't make it platform native.
Textmate is a native editor for MacOS. Sublime is not.
How would you create a native GUI app on Linux for either Gnome or KDE, considering that GTK and Qt are not allowed by this definition?
And yes, you may think: "Easy, if a GTK app runs on Linux its native, if it runs on another platform, it's not". Does that mean JavaScript apps for Gnome[1] can be called native, because they have officially blessed bindings to the underlying framework/platform and are fully integrated with GTK?
If not, does that mean as soon as you use any kind of binding/bridging technology "nativeness" is ruled out? Think of C++ apps for Gnome, they use bindings…
If yes, we are only left with defining what the "official" way for doing GUI's on a given platform is. Whatever the vendor gives us and preinstalls on its OS? Ok, no Electron, it uses the Chrome rendering engine, that is definitely third party and NOT native!
But… What if I open a WebKit WebView from Objective-C[2] to render my HTML from there and write my logic making use of JavaScriptCore[3] on macOS? Are we native yet? :)
> How would you create a native GUI app on Linux for either Gnome or KDE, considering that GTK and Qt are not allowed by this definition?
>And yes, you may think: "Easy, if a GTK app runs on Linux its native, if it runs on another platform, it's not". Does that mean JavaScript apps for Gnome[1] can be called native, because they have officially blessed bindings to the underlying framework/platform and are fully integrated with GTK?
Actually, yes, by definition a javascript app written with gobjects is native to a Gnome desktop. It fully integrates with the standards of the system be it text boxes, keyboard shortcuts, general behavior and widget look. The most important, even more than our personal little preferences, is that a native app can be accessed by things like screen readers which is the only way for a person with a disabled sight to use a computer. Anything not written with GTK on Linux is going to be a black box for Orca. In fact webapps would be less of a pain than a compiled app that uses a random crappy cross platform toolkit. While the web's accessibility could do with some improvements, it's still better than the absolute nothing that cross platform toolkit represents.
The reason being is that native apps get "most of the work" done for them for free when they use the native tools to make apps, while cross platform apps require a severe amount of work to get them to talk to screen readers correctly.
Android Studio seems to be gaining on that side despite the original platform being pretty poor. And of course Sublime Text is absolutely unusable in that scenario.
Some apps do crossplatform the right way, although they're rare: they have have a platform-specific GUI rather than use a generic cross toolkit.
Transmission is a solid example :
The app has a Cocoa, GTK, Qt, TUI and Web end user interface. It's native on all the officially supported OSes. There's a non-native, Qt-using windows port but it's a third party fork and not supported by the main devs.
I wouldn't say it is pretending if the end user experience is the same. Users don't use things because they are developed in a particular language.
- HTML based components can be made to fit into OS styling quite readily and by keymapping shortcuts you can get the exact functionality as native OS controls. Most HTML components don't have keyboard shortcuts mapped properly as the browser takes over. This is not the case with Electron.
- They can perform equally well. The web platform itself is an example of this. Browsers have improved quite rapidly over the past few years.
- Optimizations can be made in JS code as well. Other comments here have some examples.
The advantages of having a cross platform application developed in 1/3rd the time especially for new applications are huge (faster time to market, larger number of people for validation)
The JS ecosystem has grown much faster and will continue to do so. The building blocks that are available will also improve in quality and I believe that more and more developers chosing Electron will speed up this process.
> Users don't use things because they are developed in a particular language.
If the users in question were the standard near tech-illiterate masses, you might have a case but we're talking about a developer tool in this specific instance. I'd also suggest that you go take a look at the reviews on the Android app store for most banking apps, which are typically webviews. They're nearly always terrible and often due to the webview itself. Users don't distinguish between native and webview wrappers because they don't understand the common factor in the terrible experiences they're subjected to.
> HTML based components can be made to fit into OS styling quite readily
Yes, this is technically possible but I'm yet to see someone actually do it.
> and by keymapping shortcuts you can get the exact functionality as native OS controls.
To do this properly requires the developer to implement keymapping properly, which again, is possible but I very very rarely see it done.
> They can perform equally well.
No, they cannot. HTML components are always burdened by the overhead of a browser. At absolute best, you can come somewhat close. Futher, performance includes not just UI latency but the CPU and memory impact on the machine, which again, can never match true native apps due to the overhead of the browser, which is insane.
> Optimizations can be made in JS code as well.
Unless something extreme has happened in JS runtimes recently, you can't optimize your code to use SIMD instructions and parallelize, you have to leave that to the compiler. In native code this is not the case.
> The advantages of having a cross platform application developed in 1/3rd the time especially for new applications are huge (faster time to market, larger number of people for validation)
I'm not entirely sure the premise here is accurate. I suspect that an experienced Qt developer could produce a basic native application in roughly the same time as an Electron developer, but with a fraction of the overhead.
I am very well aware that our audience is a developer tool and well again, people do not use tools because of the languages they are written in but because of the experience they deliver. You are bringing up extreme examples to support your viewpoint. Bad developers will write terrible experiences in any language. Writing native apps requires a level of expertise that is not with the average developer either. Look at other comments in the thread talking about a "native" app going from good to bad.
> "HTML based components..."
Well, one of the reasons why one has not come up is that most users don't care about OS styling as such. Again, UX benefits over pedantic comparisons.
> "They can perform equally well..."
Why is the browser a bad environment assuming the level of performance required is known? I don't see any technical limitation here. CPU/memory impact on the machine can be handled equally well in Electron by offloading components onto native languages if required. I guess then one should always write in assembly languages? As far as I recall, games were written in C and specific parts were optimized in an assembly language. Those lower level constructs are still available in other ways. I am not sure you understand that technological choices are made with specific constraints towards a goal rather than purity of abstractions.
> "Qt developers..."
And I am sure so can any competent developer through any of the choices available in the market. A copy of a product is easy to create. A product is harder to iterate and maintain.
>> The advantages of having a cross platform application developed in 1/3rd the time especially for new applications are huge (faster time to market, larger number of people for validation)
> I'm not entirely sure the premise here is accurate. I suspect that an experienced Qt developer could produce a basic native application in roughly the same time as an Electron developer, but with a fraction of the overhead.
One difference here is there a lot of JS developers available to hire an much fewer Qt or even C++ devs.
Even if it's not superior, this is still false advertising.
But, embedding the app in a browser always adds bloat - there's no way around that. It may not be obvious in case of huge apps, but there are many examples of trivial things shipped with electron - which make a simple single-dialog box app a 300MB monster.
I believe there is some inherent bias here with regards to existing experiences and as technology improves those biases will go away.
I am not talking about simple single-dialog box based apps either or advocating every single piece of software should be written as an Electron based app.
As I wrote - it may not be obvious in case of huge apps. But the bloat is still there. It may be a good idea if it saves time for the dev team.
But as you said, there's still a lot of tech improvement to be done for the experience. And some things you're just not going to get around. Objects are heavier than their equivalents in native code. You still have a whole copy of the browser runtime to ship. These things will not go away. You're going to waste resources compared to an actual native app.
What you define as bloat depends on the system where you expect things to be running on. If we were building a super thin client which probably runs on a low memory device - it's worth saving the bloat on memory and CPU.
Saving dev team time is exponentially rewarding as a product matures. I'd rather say that as the team gets better at saving dev time on testing and platform parity, they can use that to optimize the experience across all platforms simultaneously. Meanwhile, if you are a small startup (like we are), you would have validated your business proposition and have a larger team to take bigger challenges. That's exactly what we have seen in our experience.
There's already too many of them, and some hardware doesn't like having too many chrome instances running at once.
My PC is an i7 with 4 hyper-threaded cores, and an Nvidia Quadro 2000M. I usually have running, as far as electron goes: Chrome, Discord, remote-working app.
As soon as i add another electron app to the mix the hardware interrupt activity of my machine goes out of control, presumably because too many chrome instances are trying to share the same device for hardware acceleration.
We'll investigate if that causes issues with Postman. I haven't faced that problem and I don't think there is a hard limitation on the platform where it can't be optimized. Hardware acceleration is not something that happens continuously - only when things are rendering. More true for games than desktop software perhaps.
I know it's a rare case, and i haven't been able to reproduce it 100% reliable, but in most cases when 4+ chromes want to do stuff, my hardware goes "nope, fuck that" and degrades performance for everything while spooling the CPU up noticably. The same hardware handles a single chrome just fine even when doing full-on 3d stuff. Sometimes just scrolling through twitter with 3 electron apps running starts the stutters.
So for me electron apps are simply only viable if i absolutely need them, and i curse the name of anyone who thinks they're a good idea for anything but rapid prototyping every single day.
Mind, i'm aware you have what you have right now, and going another path would be quite the expenditure. However i think it's not much to ask to refrain from calling it native, when it's actually electron, and thus helping people impacted by this kind of performance issue figure out that your app is one of the contributing ones.
Hmm. If you are on Postman, I'd love to get your help in debugging this. Performance issues that I have seen exist at massive scale for us - ~10K requests or hundreds of collections. Of course, working on optimizing for all of these cases.
Not sure you can do anything there, unless you intend to change the chromium source. The problems here are on the hardware level, which you're, owing to sitting on top of chromium, far removed from.
That said, i don't use Postman, heard of it the first time today. But you might be able to reproduce some of the issues by loading a very animation-heavy imgur page like https://imgur.com/a/0L8Bu , scrolling to the gifs, maybe zooming out a little to get more on screen, and starting up a bunch of different electron apps. Particularly helpful would be using https://technet.microsoft.com/en-us/sysinternals/processexpl... to keep an eye on the interrupt CPU usage. Once you start seeing lots of red activity you're getting close.
We don't need to change the chromium source. Everything is not sitting on top of Chromium. I haven't tried this just yet but node-pre-gyp allows packaging C++ too. https://github.com/mapbox/node-pre-gyp
In the case of this specific post, they seem to be using "native" to mean "has features that require access to native OS APIs, and which cannot exist purely within the HTML5 abstract machine."
There's probably a better term for this. "Native-enabled", perhaps? "Unsandboxed"?
Electron apps are more native than Chrome apps. Electron apps integrate much better with macOS than do Chrome apps:
- With a Chrome app, I found that pressing Cmd-Q quits Chrome, not just the Chrome app.
- Electron apps have more useful menus than Chrome apps.
- Electron apps like Simplenote usually work offline, while some of the Chrome apps I've used don't.
... and so on.
I agree with you that it's still not 100% accurate to call them native apps, but trying to communicate shades of grey in a blog post risks confusing readers, even technical ones, who want to do whatever Postman does, not understand the finer points of Electron vs Chrome vs Cocoa apps.
I'll take clear communication over communication that's confusing because it's accurate in ways I don't care about.
If an app can be installed the same way a "native" app does, it is a native app. Users do not care about the technology behind the scene and what they are called.
Aren't we conflating "desktop app" with "native app" in that case? Why do users have to be exposed to the word "native" at all? Just say "desktop app".
This is where I believe we'd differ. Postman already had a "desktop" app in the sense that Chrome apps also existed as desktop apps and when we ask users to switch, they wouldn't.
For most users, desktop apps = things that run on the desktop.
I absolutely love the Postman app, well done and thank you!
My biggest frustration with native apps are things like the Google login. Without it being in a browser, I have no way to verify that I'm looking at a legitimate login, or a fake one, right through to 2 factor authentication.
I'm not sure how easy that is to solve, because again, a rogue app could fake the URL bar. It's just the nature of desktop apps vs the browser as the browser is there the trust is. Maybe passing it to a browser for authentication is the only option.
Now I've been using Postman for many years, so I certainly trust the quality and intent of your work.
I'm a big fan of postman, and I've been using the native app for a few months. It's great for exploring apis then dumping the code into either curl or requests for Python.
You don't have to be native although it looks like Chrome Apps will be gone. SecApps (https://rest.secapps.com) for example utilises a Chrome extension and while it is not perfect it is still a webapp.
My point is that the Web is very powerful platform and I don't think we should always undermine it because it is not native!
Great news. I hope this means getting Postman to use the system proxy [1] would be seamless. Gave it a shot a few months back, didn't bother debugging though.
On my current job we use the Postman Chrome app to test out apis. I'm looking for a FOSS command-line alternative to it because it's very slow on my laptop (Linux, Celeron, HDD, 4GB RAM) and the UI makes no sense to me.
I know I could just use cURL (which I do) and/or HTTPie but it would be nice to have options.
Is there any alternative that would suit my needs?
Hey, that looks useful! I'll take a look at it later. Thanks! :)
Oh, btw: I read my comment again right now and it sounds a little bit arrogant. I'm sorry about that... By saying it's slow and that I don't like the UI, I mean no offense to you guys.
Actually, I think Postman is a very useful tool and my co-workers seem to love it. I's just not for me and my crappy laptop hahah.
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.
That might be true, all UI development over the last few years has gone into the JS environment. But the responsiveness of native always wins out for me.
Things like WPF/XAML can also use an XML-style tree, and the manipulation tools that entails, for UI. However, there are a number of other things they bring to the table that quickly outstrip anything that web-based objects can provide. For example, one can define custom elements, so instead of having a bunch of <Div>s defining things and needing to define things based on ids, you can create a custom tag, like <StatusBar> that gives everything you need plus makes your app layout that much cleaner.
It gets better when you start adding in the things that javascript makes hard, like concurrency and parallelism. For example, with C#, I can do something like
var results = URLs.Select((t) => { Task.Run(SomeLongRunningFunction(t)); } );
to start a series of background tasks handling HTML requests. The equivalent for JavaScript involves the much more restrictive WebWorker API, and requires me to put those small worker functions in their own page/file, or use much uglier data uris which aren't universally supported. HTML/CSS/JS just fall apart once you start getting into more interesting applications.
Not sure if you know but in native APIs like Qt you are not limited to the built in components, if you need a custom widget you usually use OOP inheritance and override some methods like paint, maybe hook into some events and you get a custom widget. If you want a fancy button(that you can't get by tweaking existing properties or using styling) you inherit the Button class and add your stuff.
What I hare in Web is that there is not a reusable gridView/listView that is optimized, you always have to create your own or find one specific for the framework/library/thing you use in this project.
I see you have to respond to everyone in the comments when they call out that this isn't actually native. It is true, and normally, Electron would imply _significant_ performance issues. But, considering this whole thing is a network I/O visualizer, making a truly native app would not help at all in the long run. Also, you get the benefit of a common cross-OS experience. You made the right decision.
Paw founder here. I'm very sorry to hear this. If you don't mind, I'd love to know more details on what's happening. The logs available in Paw menu > "Get Debug Info…" are very helpful. If you don't mind sending these details to support@paw.cloud, we'd be very grateful! Thx!
Since true native (UI/UX) is core to our focus to do an window/linux we would need to do that same, currently most of our code is still in obj-c (new code is in swift) but it would be a massive task to produce a native window and a native linux app.
however we do have extensive support for exporters to many formats through our open source lib (API-Flow) https://github.com/luckymarmot/API-Flow this converts between (paw, swagger, api-blueprint, postman etc) we realy dont want you to feel locked in with your data.
I guess there is a region where it's ok. I love Postman and think it performs great. I'd make the same argument for Slack; however because I have to open 24/7 there is a big pain on the battery which Slack needs to worry more about than Postman. VSCode on the other hand I expect to be performing and run under some crazy circumstances and the non native aspect of it prevents me from using it.
I don't think that that's always true. I think the gold-standard for this is Slack (at least on OSX). Spotify is nice too. Both seem to combine the very best of web dev (nice presentation and service integration) while cancelling out its worst problems (like accidental browser navigation).
Gold standard? Slack is 380 megs in size, and when its open it somehow seems to constantly use about 5% CPU usage (which probably knocks out a few hours of battery life, since the CPU can't properly sleep). Every so often I catch it sitting on 100% cpu usage (this is all while in the background). Restarting slack fixes it.
I know that programmer time is more important than CPU time, but its my CPU and my battery. I can only imagine explaining to someone from 15 years ago what software looks like now. "Oh yeah in the future we all use IRC, except its a proprietary IRC implementation and supports animated gifs. The client is 380 megs" "Calm down - I know thats bigger than your hard drive. No its not 3d or anything - it just has nice colors."
I don't understand why people hate on apple for not making laptops with 32 gigs of ram, but they have no problem using apps like slack which waste resources like it was water.
Thankfully slack seems to be much more lean when run inside a safari browser tab.
Why do people complain that Java is sooo wasteful again? You can literally bundle the entire JVM multiple times with every single Java program, and still use 6 times less space! SIX.
For comparison, the new Minecraft Launcher uses Electron. The entire JVM + every Minecraft version ever, plus assets, plus all mobile editions uses less space than it. In a usual minecraft installation, the actual game uses on average between 7 and 15% of the required space, the remaining 85 to 93% being used by the launcher (specifically, the bundled Chrome runtime)
Great point, but unless a significant fraction of people refuse to install the app because it's too bloated, it doesn't matter at the end of the day — I would still choose Electron over Cocoa.
Java was and is wasteful. Some of us remember something very similar to this Electron mess happening in the Distant Past when Java fans tried to convince everyone that UI slowness and general system-wide performance issues when Java programs were running were just in our heads, and to just get over it because Java was the Way of the Future™.
Of course now computers are so fast that no-one much minds Java anymore. So we had to invent web apps and Electron to make sure desktop computing doesn't actually become pleasant. That'd simply be unacceptable.
I’m just wondering why the fuck we don’t simply just use Java, and get exactly the same advantages as electron provides, while still getting better performance.
An argument can be made that devs might want to not care about memory allocation or anything, but Java does that just as well as JS, with a better build system, better community tools, better speeds, easier UI tools, and better dependency management.
Bad example. Apache Groovy has the downsides of both Java (e.g. requiring the memory hogging JVM) and JS (e.g. errors arising from dynamic typing, like one-char strings auto-converted to chars).
Slack is actually a perfect bad example. When they switched to Electron, the app got much shittier (at least on OS X). Many native features, like force-push on words/links, vanished, and there's a bunch of random bugs (including a really annoying one with input and smart replacements where the caret jumps around making you mistype things).
Slack is a severe resource hog and sometimes hangs or just runs slow. When 90% of the time, all I want from slack is basic IRC-like rooms/messages, this is ridiculous (I don't mind it using those resources the other 10% of the time).
You might think its not a problem because our machines are so powerful now, but it eats battery and occasionally I need to run a ton of stuff (eg a ton of docker containers) and having a chat application get in the way is rather annoying.
"The native apps cover all the features and functionality of the Chrome app and Chrome extension together, and more. The native apps run on Electron overcoming a lot of the restrictions of the Chrome platform."
My understanding was that Electron is just an embedded instance of Chromium, so I'm reading this sentence more like "The native apps run on [embedded Chromium] overcoming a lot of the restrictions of the [standalone Chromium] platform."
It's not just an embedded instance of Chromium. There are APIs that bridge the gap with the operating system. One way to look at this is that the UI layer runs on HTML/CSS/Javascript. VS Code, Slack etc. are other common examples.
Including, importantly, the ability to fork+exec other native processes. You can ship an Electron client app that spawns and then interacts with a native C background service, if you like. (I believe that's how Keybase's native client works, in fact.)
> The view process is very limited, just standard web APIs.
Nitpicking here, but the view (rendering) process in Electron can actually use the Node API [1]. The difference in API access privilege between the two types of process is in what Electron API (not Node API) they can use. For example, main process can use native GUI API but renderers can't and must IPC to main if they need to, say, show a system dialog.
I paid for Paw and can't stand using it. One of few macOS apps that I gave up after purchasing.
Things like entering JSON body requires using a gui resembling the plist editor or going for raw text input. But then you need to add a content type header manually. And there is no syntax highlighting or anything like that when you do it that way. Postman handles this better.
Or that the left menu has a manually managed request list. I'm not sure if there is a history listing all changed requests I made in order. Maybe there is because I see a History menubar item that can clear history. How can I see the request I made just before this one? No idea. Postman is also better on this. Left list shows all requests.
I guess the workflow is not firing it up and trying out some things but constructing a project with environments, requests etc.. Never bothered to do that in detail (see next item). Want to have a decent UI to contruct HTTP requests and execute them..
Even if I tried to use the project stuff, having that project file on a git repo is cumbersome because it's a binary file and Paw touches it even if you just open it up so Git shows a diff.
It used to require a protocol (http://) before the url. I think it does not anymore. Why would an http client not default to http protocol?
Guess it's not for my type of usage. I mostly go with httpie these days.
Paw looks like a really nice, slick, professional tool. I've been using Postman for years and really like it, and am used to it. I've yet to see a 'use case' where Paw can do something that Postman cannot, so I would appreciate it if anyone familiar with both tools can point out a value proposition for switching apps.
Take a look at Burp. It is a big giant native app that has its home in information security, but it is generally the best testing proxy I have ever seen. My customers end up having postman for various things and it is almost always my first mission to get things into Burp.
You may be turned off that it is not a pretty app (It is a Java GUI app after all). But I have used it for 9 years and found that the UX is generally very good, just not flashy. Compared to some aggravations I have had with Postman and the general lack of depth in the tooling.
Amongst information security practitioners Burp is basically the gold standard and whenever I introduce developers to it they like it.
Finally, there is mitmproxy, which I have been using more and more. Between these two tools Postman feels like a fiddly bastard.
Finally, I took a look through the Paw docs. I watched some videos. Based on how they were demoing things I think it would drive me crazy. The flow in Burp or mitmproxy is so much faster.
Step 1.) Proxy a bunch of traffic.
Step 2.) Go find the requests you liked and send them to repeater and or save them.
Step 3.) Modify the requests into nice test cases.
Step 4.) Replay the requests
Repeat. You end up with a nice test suite. My test suites are often better than what the developers have available with the added bonus of finding security vulnerabilities :)
Other benefits, these tools are designed to do sneaky things, like transparent proxying. I can transparently proxy some or all app traffic, even SSLd apps (e.g. production builds). These tools like Postman and Paw, these basic HTTP clients, are like crude hammers when we need a finely tuned and weighted hammer of an exacting specification to do repeatable assessment work.
Anyway, my perspective isn't /quite/ right for software developers. My tool requirements are based on needing to transparently proxy virtually any sort of HTTP(S) client. Development shops often want a tool that lets them build repeatable client requests that are easy to work with to test their backends without screwing around with the full app (mobile app, SPA, whatever it is). So I trade off some niceness in terms of built in organization (though, honestly, not a lot if you use Burp correctly), for ultimate flexibility and security testing features that you would not need as much.
That said, I can't help but look down my nose a little at all of these new tools like Postman and Paw. (Especially given how much Paw costs). But I know dev shops that get along fine with Postman and it is a nice and easy enough tool.
I didn't see a single feature in Paw I don't use all the time in Burp. The one feature that Burp doesn't have is making client request code. The best part is it being, basically automatic after having exercised the client.
Bah it is late, and I am just throwing a bunch of stuff at ya. Anyway, give the Burp trial a whirl and see what you think.
I liked paw, but postman is free. I'd consider paw at half the price because I don't spend that much time testing REST APIs, but when I do I don't mind using a better tool than httpie or curl. Postman does the job (quite well) for free.
We do have a subscription service now called Postman Pro - does API documentation (api.getpostman.com), API Monitoring, Mock servers, Team collaboration and it has a powerful API (api.getpostman.com). More coming soon! Postman - the app will always remain free. :) (Founder here)
There's another free REST client called Insomnia (https://insomnia.rest), which I've been working on for the past two years, but I don't think there are any other popular "native" options. For some reason, all of the REST clients seem to be Chrome apps. It will be unfortunate when Google sunsets Chrome apps next year :(
Electron is to desktop computers as PhoneGap is to mobile devices: not just a framework that embeds web views, but also an API bridge that allows said web-views to access APIs that web-views are normally sandboxed from accessing.
Been happily using postman for a couple years now and happily don't care that you called an electron app a native app. Sorry HN is so aggressively pedantic!
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.
I am pretty surprised how some commenters here are using this argument. Of course, EVERY utility app should NOT be written in Electron.
I have commented on the UI and keyboard shortcuts elsewhere. These are easily doable and I believe libraries to pre-package and solve this exist already.
This Fails my simple "I've never heard of Postman, can you please explain it?"
* Blog post (linked) is very vague, no "About Postman" or similar link.
* Toplevel of blog page is the same, no "About Postman" or "What is Postman" link.
* Toplevel of "postman.com" is amazingly, similarly vague, with the most descriptive text above the fold being:
> "Developing APIs is hard. Postman makes it easy. Download the free Postman App"
* Still, there's no "About" link or anywhere obvious to actually describe what the product is. I clicked on ALL of the tabs in the upper right: "Products", "Pricing", "Documentation" and "Cummunity" and NONE OF THESE has any text explaining what Postman is or why I would want it.
If your site(s) don't have a simple "Postman is a ..." or "Postman can help you..." paragraph, then you've absolutely failed to attract your target market.
Main page scroll down, "A powerful GUI platform to make your API development faster & easier, from building API requests through testing, documentation and sharing."
You are saying... "A powerful GUI platform to make your API development faster & easier, from building API requests through testing, documentation and sharing." makes you think a text editor, really?
I gave up using postman a while time ago because I was thinking that they had not an app outside the Chrome. I started using insomnia(https://insomnia.rest/) and I am satisfied
Developer of Insomnia here, and I'd just like to say that it makes me happy to see people in the wild are enjoying the app! Oh, and there are some big, fancy, and awesome things coming ;)
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.