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

61–70 of 245 posts

Re: Going native

#61

Post by kangoo1707 »

hizanberg wrote: post #53

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.

If an app can be installed the same way a "native" app does, it is a native app. Users do not care about the technology behind the scene and what they are called.

Re: Going native

#62

Post by a85 »

hizanberg wrote: post #53

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.

I am not sure why something would be inherently superior if it is using pre-built OS components. Any software can have memory leaks, buggy behavior, weird input issues etc. I'd rather look at the user experience and qualify something as better/worse after using it. Postman had issues in the beginning when we started porting things over but these were quickly solved and in fact gave us much more power over the experience.

Re: Going native

#63

Post by smlacy »

dom2 wrote: post #59
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."

So this is a text editor?

Re: Going native

#64

Post by smlacy »

blizkreeg wrote: post #13
Animats wrote: post #9

With a name like "Postman", one might expect this has something to do with mail, or messaging. The blog post gives no clue as to what it's for. It's apparently a test tool for testing HTTP-based APIs. [1] (HTTP "POST", get it?) Not to be confused with Postman Corporation, which is a "computer repair shop" near CIA headquarters. [1] https://www.getpostman.com/

It's a fairly well known tool if you're a consumer/producer of APIs for web/mobile dev. May be that's why?

No its not. :)

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?

Re: Going native

#65

Post by derefr »

hizanberg wrote: post #53

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.

In the case of this specific post, they seem to be using "native" to mean "has features that require access to native OS APIs, and which cannot exist purely within the HTML5 abstract machine."

There's probably a better term for this. "Native-enabled", perhaps? "Unsandboxed"?

Re: Going native

#66

Post by charlieegan3 »

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

Re: Going native

#67

Post by derefr »

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…

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.

Re: Going native

#68

Post by derefr »

JSDave wrote: post #60
paulddraper wrote: post #30

Earlier quoted context omitted.

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.

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

Re: Going native

#70

Post by badminton1 »

hizanberg wrote: post #53

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.

Well, many widget libraries use markup languages, Qt has QML, WPF has XAML, and could give more examples but you get the idea.

Personally I prefer using Burp rather than Postman.

Post reply on HN