[macsj200]

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

[a85]

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.

[Electron APIs]: https://electron.atom.io/docs/api/

[paulddraper]

Right. It's Chromium + JS APIs + some packaging.

E.g. an API to write a file.

[JSDave]

Electron gives you a view process, background process, and a way for the 2 to communicate.

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.

[derefr]

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

[yblu]

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

[1] https://github.com/electron/electron/blob/master/docs/glossa...

[Rapzid]

That's a bit too simplistic of an explanation IMHO. It's a mashup of chromium and nodejs; the entry point is a nodejs app.

[pininja]

Window, Menus, clipboard, etc.. (not just being able to write to a file) https://electron.atom.io/docs/api/

[pier25]

All OS related functionality is through Node.

[EduardoBautista]

Yup. Luckily, there is Paw[0] if you want a native experience on the mac.

[0]: https://paw.cloud

[eknkc]

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.

[xenadu02]

I had the pleasure of emailing the creator of Paw when he was looking at applying to YC. It's a great app and I recommend it.

[cyberferret]

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.

[bitexploder]

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.

[eyko]

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.

[a85]

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)

[gschier]

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 :(

[charlieegan3]

I really can't recommend this any more either - it used to be really nice but it seems to crash most times I come to use it now.

There seem to be updates coming out regularly but they don't seem to fix the issues I'm having.

[theonemind]

I've found the developer pretty responsive to bug reports, which is nice.

[BillinghamJ]

Unfortunately it is increasingly unstable and has dire performance issues - particularly when using the cloud/team sync system :(

[statictype]

Ugh. This used to be true until version 3.

The Paw native experience is now terrible. I'd welcome a nice embedded app in electron.

[hishnash]

@statictype What issues are you having?

[abrowne]

Yeah, kind of a stretch to call it "native".

[shawndumas]

It's akin to microsoft's HTA.

https://en.m.wikipedia.org/wiki/HTML_Application

[derefr]

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.

[LeifCarrotson]

Sure, if you translate "embedded" as being more powerful/low-level than "standalone".