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

221–230 of 245 posts

Re: Going native

#221

Post by Mithaldu »

a85 wrote: post #215
Mithaldu wrote: post #214

Earlier quoted context omitted.

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.

Not sure you can do anything there, unless you intend to change the chromium source. The problems here are on the hardware level, which you're, owing to sitting on top of chromium, far removed from.

That said, i don't use Postman, heard of it the first time today. But you might be able to reproduce some of the issues by loading a very animation-heavy imgur page like https://imgur.com/a/0L8Bu , scrolling to the gifs, maybe zooming out a little to get more on screen, and starting up a bunch of different electron apps. Particularly helpful would be using https://technet.microsoft.com/en-us/sysinternals/processexpl... to keep an eye on the interrupt CPU usage. Once you start seeing lots of red activity you're getting close.

Re: Going native

#222

Post by dkersten »

CountSessine wrote: post #22
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 don't think that that's always true. I think the gold-standard for this is Slack (at least on OSX). Spotify is nice too. Both seem to combine the very best of web dev (nice presentation and service integration) while cancelling out its worst problems (like accidental browser navigation).

Slack is a severe resource hog and sometimes hangs or just runs slow. When 90% of the time, all I want from slack is basic IRC-like rooms/messages, this is ridiculous (I don't mind it using those resources the other 10% of the time).

You might think its not a problem because our machines are so powerful now, but it eats battery and occasionally I need to run a ton of stuff (eg a ton of docker containers) and having a chat application get in the way is rather annoying.

Re: Going native

#223

Post by debaserab2 »

Ajedi32 wrote: post #216
swiley wrote: post #196

Earlier quoted context omitted.

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

People conclude things based on their experience using them. There are a lot of bloated feeling electron apps out there that are popular right now, which leads to people concluding (not incorrectly) that electron apps tend to be slower than native ones based on their experience.

Re: Going native

#224

Post by dkersten »

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

I still have no idea what it is.

Re: Going native

#225

Post by debaserab2 »

a85 wrote: post #211
debaserab2 wrote: post #129

Earlier quoted context omitted.

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?

I'm not trying to define what a native app is, I'm only explaining the way many users such as myself perceive it today. The waters are obviously getting much murkier on what fits the definition of native and it does look like the writing is on the wall that the state javascript on the desktop is just going to continue to improve.

Re: Going native

#227

Post by a85 »

Mithaldu wrote: post #221
a85 wrote: post #215

Earlier quoted context omitted.

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.

Not sure you can do anything there, unless you intend to change the chromium source. The problems here are on the hardware level, which you're, owing to sitting on top of chromium, far removed from. That said, i don't use Postman, heard of it the first time today. But you might be able to reproduce some of the issues by loading a very animation-heavy imgur page like https://imgur.com/a/0L8Bu , scrolling to the gifs,…

We don't need to change the chromium source. Everything is not sitting on top of Chromium. I haven't tried this just yet but node-pre-gyp allows packaging C++ too. https://github.com/mapbox/node-pre-gyp

Re: Going native

#228

Post by a85 »

kelvin0 wrote: post #180
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 had to read a few comments on HN and Google your product to understand what it is. reading on your website told me (almost) nothing about your product. (I am more a desktop dev, very new to web). From https://www.getpostman.com/ "A powerful GUI platform to make your API development faster & easier, from building API requests through testing, documentation and sharing" Then searching, I found this: https://seesparkb…

We are always working on making things better. Some videos here: https://www.youtube.com/channel/UCocudCGVb3MmhWQ1aoIgUQw

Re: Going native

#229

Post by a85 »

hayden592 wrote: post #93

Big fan of Postman for quickly iterating on API's, microservice integration tests, and one off requests. However, my team keeps the collections in git and they are very difficult to diff. This almost always require a detailed commit (doesnt usually happen) or me asking the dev what they changed. Any suggestions on how to improve comparing two collections?

Thanks for the comment! If you are on Postman Pro you can export to Github directly. There is versioning built-in Pro too. That said, we have improved the format a lot over the years to support diffing just with Git.

Re: Going native

#230

Post by yblu »

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.

> The view process is very limited, just standard web APIs.

Nitpicking here, but the view (rendering) process in Electron can actually use the Node API [1]. The difference in API access privilege between the two types of process is in what Electron API (not Node API) they can use. For example, main process can use native GUI API but renderers can't and must IPC to main if they need to, say, show a system dialog.

[1] https://github.com/electron/electron/blob/master/docs/glossa...

Post reply on HN