Going native
blog.getpostman.com
blog.getpostman.com
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.
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.
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.
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.
Native doesn't mean browser in a window. Same as realtime doesn't mean "it'll get there faster. Maybe"
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.
Things change.
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.
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.
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.)
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.
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.
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.
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...
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.
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'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 ?
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.
If not, I still can't make the switch. :(
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.
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.
I appreciate the fact that Postman allows you to continue without registration[0]
Unfortunately, you can't sync with your own repo, which is a shame for a fairly expensive rest client, compared to alternatives.
I use and love it way more than Postman nevertheless.
Not to be confused with Postman Corporation, which is a "computer repair shop" near CIA headquarters.
Blog has no product description, and even the product description on getpostman.com (below the fold) is amazingly vague:
"A powerful GUI platform to make your API development faster & easier, from building API requests through testing, documentation and sharing."
So... It's a text editor? A test framework? What languages does it work with? Web APIs or native? Why would I use it over my existing toolchain?
It's just a gui version of curl with helpful things like an editor for post bodies, persistence of old requests, stuff like that.
But for developers, who see hundreds of libraries and services being posted every day, it matters if there is a clear explanation at the top or not.
smlacy's response felt pretty much like trolling to me.
QT isn't native either.
So I'd say Qt is more native than e.g. Electron, but it is definitely not completely native. Except on Linux of course.
Because that's the meaningful sense.
Also, it is treated as an application by the OS rather than a Chrome window (and all the benefits that come with that shift).
> How we avoided going native, and built an App with Electron instead
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.
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.
On desktop, all native apps are desktop apps but not all desktop apps are native.
On mobile, all native apps are mobile apps but not all mobile apps are native.
For most users, desktop apps = things that run on the desktop.
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.
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.
So "guarantee" is too strong of a word.
Your point that native applications don't always have to use OS-provided components is taken though.
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.
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? :)
[1]: https://developer.gnome.org/gnome-devel-demos/stable/beginne...
[2]: https://developer.apple.com/library/content/documentation/Co...
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.
Sometimes devs put extra effort into making cross platforms apps accessible but they're the exception rather than the norm : https://www.parhamdoustdar.com/2016/04/03/tools-of-blind-pro...
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.
- 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.
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.
One difference here is there a lot of JS developers available to hire an much fewer Qt or even C++ devs.
Also IME, Electron apps are generally an of magnitude better than mobile webview apps.
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.
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.
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.
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 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.
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.
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.
This never happens with non-electron software.
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.
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.
There's probably a better term for this. "Native-enabled", perhaps? "Unsandboxed"?
Personally I prefer using Burp rather than Postman.
- 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.
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.
Now I've been using Postman for many years, so I certainly trust the quality and intent of your work.
Since the author is in the comments just wanted to ask one thing. Is this [1] supposed to be misaligned?
UPDATE: I stand corrected. One can download without signing up. Sorry, I guess I'll try this after all :)
You don't have to sign in to use it
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!
[1] https://github.com/postmanlabs/postman-app-support/issues/22...
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?
But it's currently geared towards running collections created in the Postman App (i.e, it's not for one-off requests like cURL is).
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.
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.
For comparison:
The entire Java 8 (Windows, 64-bit, offline) JVM plus all libraries (which, thanks Java 9, will no longer be necessary) is 62MB: http://javadl.oracle.com/webapps/download/AutoDL?BundleId=21...
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)
Where did our society go wrong?
48.8MB when packed. All it provides is a status bar notification window.
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.
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.
You’re serious?
I’m not quite sure what to answer.
On the one hand, that’s embarrassing (and tells tales of the quality of compsci education), on the other hand, there’s Groovy, I guess?
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.
We are building some awesome UI components using this: http://blog.getpostman.com/2017/02/28/introducing-the-new-da...
Things that we build for the app are also available for our web components instantly. React makes this even easier.
Nice UI is not good UX
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)); } );
Native experiences aren't always better.
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.
Paw's a great tool but I've had problems with version 3 that have made me want to open it less often.
I understand that not everyone seems to be having that issue.
Will email the logs and hope you can find something.
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."
[0]: https://paw.cloud
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.
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.
The Paw native experience is now terrible. I'd welcome a nice embedded app in electron.
There seem to be updates coming out regularly but they don't seem to fix the issues I'm having.
[Electron APIs]: https://electron.atom.io/docs/api/
E.g. an API to write a file.
The view process is very limited, just standard web APIs.
The background process is basically a node process and can do anything you can in node.
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.
[1] https://github.com/electron/electron/blob/master/docs/glossa...
Chrome sucks in terms of providing support to developers and building robust features.
(Coming down to Indiranagar for a treat from your end. :P)
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 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.
* 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.
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?
Insomnia does everything I want it to do and does it quickly.