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