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

111–120 of 245 posts

Re: Going native

#111

Post by nuggien »

smlacy wrote: post #89
tragic wrote: post #79

Earlier quoted context omitted.

In the time it took you to write this post, you could have googled it like thirty times. What's your point? It's just a gui version of curl with helpful things like an editor for post bodies, persistence of old requests, stuff like that.

Point is that if they're selling a product, they could make it more clear what the thing they're selling is. I'm EXACTLY the target market, and they failed to entice me.

You're not the target market if you couldn't figure out what they are. I've never heard of it but one look at the screenshot told me exactly what it is.

Re: Going native

#112

Post by kartickv »

kitsunesoba wrote: post #106
Veratyr wrote: post #72

Earlier quoted context omitted.

The point isn't entirely that "true" native apps are superior, the point is really that WebView wrappers are no more a "native" application than a standard HTML web application, because that's exactly what they are and pretending otherwise is deceptive. As for applications built with OS components being inherently better, there are a few reasons for me: - They are guaranteed to fit in with OS styling - They near-univ…

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.

Re: Going native

#113

Post by kartickv »

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.

Electron apps are more native than Chrome apps. Electron apps integrate much better with macOS than do Chrome apps:

- With a Chrome app, I found that pressing Cmd-Q quits Chrome, not just the Chrome app.

- Electron apps have more useful menus than Chrome apps.

- Electron apps like Simplenote usually work offline, while some of the Chrome apps I've used don't.

... and so on.

I agree with you that it's still not 100% accurate to call them native apps, but trying to communicate shades of grey in a blog post risks confusing readers, even technical ones, who want to do whatever Postman does, not understand the finer points of Electron vs Chrome vs Cocoa apps.

I'll take clear communication over communication that's confusing because it's accurate in ways I don't care about.

Re: Going native

#114

Post by kartickv »

a85 wrote: post #103
viraptor wrote: post #99

Earlier quoted context omitted.

> When we tell people we have a native app, they get it. Are people here not... people? You seem to describe a desktop app. Bring able to install it has nothing to do with being native or not.

I could have used the term "users" to say the same thing. And everyone here might not be a user. And our existing users perceive the existing Chrome app as a "desktop" apps too. Postman existing as in-browser extension, then a Chrome "packaged"/desktop app and finally in it's current form. They are also "installed" in a particular way. I'd still prefer the term native over desktop apps.

I agree. Calling it a desktop app only causes confusion, since it contrasts it with a mobile app.

Re: Going native

#115

Post by shawndumas »

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…

It's akin to microsoft's HTA.

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

Re: Going native

#116

Post by kartickv »

viraptor wrote: post #102
kuschku wrote: post #81

Earlier quoted context omitted.

> Slack is 380 MB For comparison: The entire Java 8 (Windows, 64-bit, offline) JVM plus all libraries (which, thanks Java 9, will no longer be necessary) is 62MB: http://javadl.oracle.com/webapps/download/AutoDL?BundleId=21... Why do people complain that Java is sooo wasteful again? You can literally bundle the entire JVM multiple times with every single Java program, and still use 6 times less space! SIX. For compar…

Another extreme electron example: https://github.com/manosim/gitify/releases 48.8MB when packed. All it provides is a status bar notification window.

Great point, but unless a significant fraction of people refuse to install the app because it's too bloated, it doesn't matter at the end of the day — I would still choose Electron over Cocoa.

Re: Going native

#118

Post by a85 »

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…

"tech-illiterate massess...."

I am very well aware that our audience is a developer tool and well again, people do not use tools because of the languages they are written in but because of the experience they deliver. You are bringing up extreme examples to support your viewpoint. Bad developers will write terrible experiences in any language. Writing native apps requires a level of expertise that is not with the average developer either. Look at other comments in the thread talking about a "native" app going from good to bad.

> "HTML based components..."

Well, one of the reasons why one has not come up is that most users don't care about OS styling as such. Again, UX benefits over pedantic comparisons.

> "They can perform equally well..."

Why is the browser a bad environment assuming the level of performance required is known? I don't see any technical limitation here. CPU/memory impact on the machine can be handled equally well in Electron by offloading components onto native languages if required. I guess then one should always write in assembly languages? As far as I recall, games were written in C and specific parts were optimized in an assembly language. Those lower level constructs are still available in other ways. I am not sure you understand that technological choices are made with specific constraints towards a goal rather than purity of abstractions.

> "Qt developers..."

And I am sure so can any competent developer through any of the choices available in the market. A copy of a product is easy to create. A product is harder to iterate and maintain.

Re: Going native

#119

Post by a85 »

therealmarv wrote: post #117

Can I still use login on a web interface (cookie and interceptor) and use an API with that cookie in place? It was my workflow with the Chrome app.

We are working on connecting the Interceptor with the native apps. Need a few tweaks in the codebase. :)

Re: Going native

#120

Post by a85 »

viraptor wrote: post #107
a85 wrote: post #105

Earlier quoted context omitted.

I believe there is some inherent bias here with regards to existing experiences and as technology improves those biases will go away. I am not talking about simple single-dialog box based apps either or advocating every single piece of software should be written as an Electron based app.

As I wrote - it may not be obvious in case of huge apps. But the bloat is still there. It may be a good idea if it saves time for the dev team. But as you said, there's​ still a lot of tech improvement to be done for the experience. And some things you're just not going to get around. Objects are heavier than their equivalents in native code. You still have a whole copy of the browser runtime to ship. These things wi…

What you define as bloat depends on the system where you expect things to be running on. If we were building a super thin client which probably runs on a low memory device - it's worth saving the bloat on memory and CPU.

Saving dev team time is exponentially rewarding as a product matures. I'd rather say that as the team gets better at saving dev time on testing and platform parity, they can use that to optimize the experience across all platforms simultaneously. Meanwhile, if you are a small startup (like we are), you would have validated your business proposition and have a larger team to take bigger challenges. That's exactly what we have seen in our experience.

Post reply on HN