Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Going native

blog.getpostman.com

Post reply on HN
Print view View original

51–60 of 245 posts

Re: Going native

#51

Post by BillinghamJ »

EduardoBautista wrote: post #4
macsj200 wrote: post #2

"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 [stan…

Yup. Luckily, there is Paw[0] if you want a native experience on the mac. [0]: https://paw.cloud

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

Re: Going native

#52

Post by eknkc »

EduardoBautista wrote: post #4
macsj200 wrote: post #2

"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 [stan…

Yup. Luckily, there is Paw[0] if you want a native experience on the mac. [0]: https://paw.cloud

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.

Re: Going native

#53

Post by hizanberg »

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.

Re: Going native

#54

Post by statictype »

EduardoBautista wrote: post #4
macsj200 wrote: post #2

"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 [stan…

Yup. Luckily, there is Paw[0] if you want a native experience on the mac. [0]: https://paw.cloud

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.

Re: Going native

#55

Post by smlacy »

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.

Re: Going native

#56

Post by LeifCarrotson »

macsj200 wrote: post #2

"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 [stan…

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

Re: Going native

#57

Post by ttd »

a85 wrote: post #29
johnflan wrote: post #12

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.

I'd argue that the HTML/CSS/JS layer is more powerful and more extensible than any native rendering layer. 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.

Any thoughts on WPF in comparison?

Re: Going native

#58

Post by statictype »

johnflan wrote: post #12

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.

On the other hand, there's Paw, a delightful native app in the same category that has morphed into an unusable tool that hangs every few minutes.

Native experiences aren't always better.

Re: Going native

#59

Post by dom2 »

smlacy wrote: post #55

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 Postm…

Main page scroll down, "A powerful GUI platform to make your API development faster & easier, from building API requests through testing, documentation and sharing."

Re: Going native

#60

Post by JSDave »

paulddraper wrote: post #30
a85 wrote: post #17

Earlier quoted context omitted.

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/

Right. It's Chromium + JS APIs + some packaging. E.g. an API to write a file.

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.

Post reply on HN