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

121–130 of 245 posts

Re: Going native

#121

Post by hornetblack »

Veratyr wrote: post #109
a85 wrote: post #85

Earlier quoted context omitted.

I wouldn't say it is pretending if the end user experience is the same. Users don't use things because they are developed in a particular language. - HTML based components can be made to fit into OS styling quite readily and by keymapping shortcuts you can get the exact functionality as native OS controls. Most HTML components don't have keyboard shortcuts mapped properly as the browser takes over. This is not the ca…

> Users don't use things because they are developed in a particular language. 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 t…

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

One difference here is there a lot of JS developers available to hire an much fewer Qt or even C++ devs.

Re: Going native

#122

Post by kitsunesoba »

kartickv wrote: post #112
kitsunesoba wrote: post #106

Earlier quoted context omitted.

I would add consistent widget behavior to the list of benefits. More often than not, controls in browser hybrids and web apps fail to take all kinds of little subtleties (some of which are platform specific) into account, dragging down user experience by way of death by a thousand cuts. This can be compensated for obviously, but I'd argue that the time and energy tied up addressing these finer points (which can be qu…

That's a great point, but does addressing these finer points take more time than building two separate apps, for Mac and Windows? Or if a service doesn't find it feasible to build two native apps, aren't their users better off with an Electron app than accessing the web app in their browser? For example, Simplenote has an Electron app for the Mac, and I much prefer that to having to use simplenote.com in a browser.

I think there's a lot of variables at play, all of which need to be considered. The answer won't be the same for everybody.

To me the ideal candidate for electron is moderate complexity with an audience that's likely to value day-1 cross-platform support over other factors. If it veers toward the simpler side of things like Simplenote, electron is overkill, as developing separate native front ends isn't going to pose too much of a challenge (especially if platform agnostic code is shared). On the other end of the spectrum with a high complexity app (e.g. same class as Photoshop, Maya, etc), you're frequently going to find yourself at odds with the limits and performance issues of web tech and whatever conveniences it affords you are largely rendered moot.

As for if a wrapper offers value, with ever increasing OS-browser integration I'd say whatever value that's there is quickly being eroded. Personally, if I have the choice of running an Electron wrapped-web-app vs. running a web app in my browser and a true native app isn't available, I'll take the latter in most cases for the greater control it affords me. It allows me to take resource consumption into my own hands (to an extent) by choosing Safari or Firefox instead of embedded Chromium and it lets me controls what scripts are running, what domains are being accessed, etc.

Re: Going native

#123

Post by gschier »

richthegeek wrote: post #83
lalmachado wrote: post #75

I gave up using postman a while time ago because I was thinking that they had not an app outside the Chrome. I started using insomnia( https://insomnia.rest/ ) and I am satisfied

Exactly the same experience here. Postman always felt a little laggy and the in-app pushing for premium features was getting annoying. Insomnia does everything I want it to do and does it quickly.

Developer of Insomnia here, and I'd just like to say that it makes me happy to see people in the wild are enjoying the app! Oh, and there are some big, fancy, and awesome things coming ;)

Re: Going native

#124

Post by alnitak »

psyklic wrote: post #95
a85 wrote: post #88

Postman founder here HN folks. Great to see the post get featured on the homepage! Lots of discussion about what is exactly native. I have posted some replies but some other points about the choice of words: 1. Postman has 3 million users and about 1.5 million MAUs. When we tell people we have a native app, they get it. People go to our apps page, download the installer and see everything exactly as they expect thing…

>> When we tell people we have a native app, they get it. People go to our apps page, download the installer and see everything exactly as they expect things to be. The term "native" is used to describe apps developed for a specific operating system. By this definition, clearly Electron apps (and hence Postman) are not native apps. Having to download an installer doesn't make it native. On smartphones, all apps are i…

The pedantic force is strong here.

Re: Going native

#125

Post by colordrops »

josephg wrote: post #45
colordrops wrote: post #39

Earlier quoted context omitted.

It's a native binary executable with standard access to system APIs, so in the technical sense, yes.

That just makes the platform native, which doesn't say anything at all. Presumably the app itself is still written in javascript, so its not native at all - its just bundling its own (native) copy of chrome.

So are you saying anything with a runtime is not native, even if embedded in an executable? Is a go app native?

Re: Going native

#127

Post by shamasis »

psyklic wrote: post #95
a85 wrote: post #88

Postman founder here HN folks. Great to see the post get featured on the homepage! Lots of discussion about what is exactly native. I have posted some replies but some other points about the choice of words: 1. Postman has 3 million users and about 1.5 million MAUs. When we tell people we have a native app, they get it. People go to our apps page, download the installer and see everything exactly as they expect thing…

>> When we tell people we have a native app, they get it. People go to our apps page, download the installer and see everything exactly as they expect things to be. The term "native" is used to describe apps developed for a specific operating system. By this definition, clearly Electron apps (and hence Postman) are not native apps. Having to download an installer doesn't make it native. On smartphones, all apps are i…

Ah! 15 years back I knew APIs were those Win32 ones listed by Microsoft to access insides of Windows.

Things change.

Re: Going native

#128

Post by lowboy »

Veratyr wrote: post #109
a85 wrote: post #85

Earlier quoted context omitted.

I wouldn't say it is pretending if the end user experience is the same. Users don't use things because they are developed in a particular language. - HTML based components can be made to fit into OS styling quite readily and by keymapping shortcuts you can get the exact functionality as native OS controls. Most HTML components don't have keyboard shortcuts mapped properly as the browser takes over. This is not the ca…

> Users don't use things because they are developed in a particular language. 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 t…

IME, most devs use tools because of the features they provide and not for the tech used to build them.

Also IME, Electron apps are generally an of magnitude better than mobile webview apps.

Re: Going native

#129

Post by debaserab2 »

alnitak wrote: post #124
psyklic wrote: post #95

Earlier quoted context omitted.

>> When we tell people we have a native app, they get it. People go to our apps page, download the installer and see everything exactly as they expect things to be. The term "native" is used to describe apps developed for a specific operating system. By this definition, clearly Electron apps (and hence Postman) are not native apps. Having to download an installer doesn't make it native. On smartphones, all apps are i…

The pedantic force is strong here.

Not really. Especially not on Hacker News. There's an expectation when someone says native app that you're getting a binary that you compiled from source you created with a reasonable expectation of performance.

No one thinks native as being a webview wrapped executable where the authored source is actually a series of HTML, CSS, and javascript. They just don't. Calling it "native" is a misnomer.

Re: Going native

#130

Post by gschier »

eyko wrote: post #16
EduardoBautista wrote: post #4

Earlier quoted context omitted.

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

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.

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 :(
Post reply on HN