Going native

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

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.