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

211–220 of 245 posts

Re: Going native

#211

Post by a85 »

debaserab2 wrote: post #129
alnitak wrote: post #124

Earlier quoted context omitted.

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.

What if the application does have compiled libraries generated from the authored source?

Re: Going native

#212

Post by a85 »

martin-adams wrote: post #177

I absolutely love the Postman app, well done and thank you! My biggest frustration with native apps are things like the Google login. Without it being in a browser, I have no way to verify that I'm looking at a legitimate login, or a fake one, right through to 2 factor authentication.

Thank you for the comment! I think there are ways to represent this better (just with a URL bar for example). Will look into it.

Re: Going native

#213

Post by on_and_off »

fn1 wrote: post #153
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…

I used PostMan on the Mac for a couple of projects and now I'm thinking thrice before even starting the app. The UI makes no sense to me, but I would need an UX study to find out what's up exactly. I just know . that I keep searching for buttons . that somehow Postman never remembers my state. I have these "tabs" open, close them all, close the app, and when coming back there are tabs open again. When I want to close…

>that somehow Postman never remembers my state. I have these "tabs" open, close them all, close the app, and when coming back there are tabs open again. When I want to close them it asks me about unsaved changes. (Which changes???)

that's an anecdotal remark but it seems to me that I hear this a lot about webapps.

is there anything that makes cleanly handling state harder in a web based app ?

Or is it just that the quality bar is lower ?

Re: Going native

#214

Post by Mithaldu »

a85 wrote: post #206
Mithaldu wrote: post #176

Earlier quoted context omitted.

Have a 100% solid reason why: There's already too many of them, and some hardware doesn't like having too many chrome instances running at once. My PC is an i7 with 4 hyper-threaded cores, and an Nvidia Quadro 2000M. I usually have running, as far as electron goes: Chrome, Discord, remote-working app. As soon as i add another electron app to the mix the hardware interrupt activity of my machine goes out of control, p…

We'll investigate if that causes issues with Postman. I haven't faced that problem and I don't think there is a hard limitation on the platform where it can't be optimized. Hardware acceleration is not something that happens continuously - only when things are rendering. More true for games than desktop software perhaps.

I know it's a rare case, and i haven't been able to reproduce it 100% reliable, but in most cases when 4+ chromes want to do stuff, my hardware goes "nope, fuck that" and degrades performance for everything while spooling the CPU up noticably. The same hardware handles a single chrome just fine even when doing full-on 3d stuff. Sometimes just scrolling through twitter with 3 electron apps running starts the stutters.

So for me electron apps are simply only viable if i absolutely need them, and i curse the name of anyone who thinks they're a good idea for anything but rapid prototyping every single day.

Mind, i'm aware you have what you have right now, and going another path would be quite the expenditure. However i think it's not much to ask to refrain from calling it native, when it's actually electron, and thus helping people impacted by this kind of performance issue figure out that your app is one of the contributing ones.

Re: Going native

#215

Post by a85 »

Mithaldu wrote: post #214
a85 wrote: post #206

Earlier quoted context omitted.

We'll investigate if that causes issues with Postman. I haven't faced that problem and I don't think there is a hard limitation on the platform where it can't be optimized. Hardware acceleration is not something that happens continuously - only when things are rendering. More true for games than desktop software perhaps.

I know it's a rare case, and i haven't been able to reproduce it 100% reliable, but in most cases when 4+ chromes want to do stuff, my hardware goes "nope, fuck that" and degrades performance for everything while spooling the CPU up noticably. The same hardware handles a single chrome just fine even when doing full-on 3d stuff. Sometimes just scrolling through twitter with 3 electron apps running starts the stutters.…

Hmm. If you are on Postman, I'd love to get your help in debugging this. Performance issues that I have seen exist at massive scale for us - ~10K requests or hundreds of collections. Of course, working on optimizing for all of these cases.

Re: Going native

#216

Post by Ajedi32 »

swiley wrote: post #196
Ajedi32 wrote: post #195

Earlier quoted context omitted.

I think the line's a lot more blurry than you make it out to be. Not only are Electron apps often visually and functionally indistinguishable from "native" applications on their respective platforms, but there are also varying degrees of integration with the underlying platform you can have within Electron apps. For example, Electron supports including native modules which have to be compiled for a specific platform.…

Electron apps are most certainly not functionally indistinguishable from native apps. They are always much larger and always seem to consume orders of magnitude more resources (memory, CPU.) If despotify still worked I would absolutely use that instead of the slow, buggy webview based official client. People want native apps because they don't want the cooling/memory/power consumption from the web, as well as their d…

Performance is a property of an application as a whole, not just the framework it's built on.

While you can certainly argue that apps which use webviews are slower on average than their native counterparts; Electron-based apps aren't necessarily always going to be slow; and native apps aren't necessarily always going to be fast.

Therefore, since a user cannot conclude that an app is "not native" merely by observing its performance, Electron apps cannot be said to be functionally distinguishable from native apps merely because they're slower, on average, than other applications.

Re: Going native

#217

Post by kuschku »

ashark wrote: post #205
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…

Java was and is wasteful. Some of us remember something very similar to this Electron mess happening in the Distant Past when Java fans tried to convince everyone that UI slowness and general system-wide performance issues when Java programs were running were just in our heads, and to just get over it because Java was the Way of the Future™. Of course now computers are so fast that no-one much minds Java anymore. So…

I’m just wondering why the fuck we don’t simply just use Java, and get exactly the same advantages as electron provides, while still getting better performance.

An argument can be made that devs might want to not care about memory allocation or anything, but Java does that just as well as JS, with a better build system, better community tools, better speeds, easier UI tools, and better dependency management.

Re: Going native

#218

Post by dkersten »

Veratyr wrote: post #72
a85 wrote: post #62

Earlier quoted context omitted.

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

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…

- They often (although certainly not always) use less battery

Re: Going native

#219

Post by sctb »

fatal510 wrote: post #161
nuggien wrote: post #111

Earlier quoted context omitted.

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.

We finally have someone with a brain here. Pathetic that these people could figure out what it was just from the front page.

The personal attacks you've posted in this thread are not OK on Hacker News, and we ban accounts that continue like this. Please stop.

Re: Going native

#220

Post by dkersten »

a85 wrote: post #207
wishinghand wrote: post #90

Earlier quoted context omitted.

All native apps are desktop apps, but not all desktop apps are native apps.

So native would not cover mobile apps?

It depends on the host platform.

On desktop, all native apps are desktop apps but not all desktop apps are native.

On mobile, all native apps are mobile apps but not all mobile apps are native.

Post reply on HN