Live data from Hacker News

Going native

blog.getpostman.com

191–200 of 245 posts

Re: Going native

#191

Earlier quoted context omitted.

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.

[deleted]

Re: Going native

#194
post #188

Earlier quoted context omitted.

Words have meaning. Native doesn't mean browser in a window. Same as realtime doesn't mean "it'll get there faster. Maybe"

Words do have meaning but "native" has pretty unclear meaning. Is JavaScript native? JavaScript is interpreted when it first starts, but eventually turns into machine code through JIT by most JS engines. So is JavaScript native because it gets converted to machine code, just as C++ does? If you say no, then you're saying only AOT compiled languages are "native". So that eliminates Python, Erlang, Java. Even C#, the "…

[deleted]

Re: Going native

#195
post #95
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…

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. How many of those would an Electron app have to use before it's considered "native"? Or what about an app like Spotify, which only uses a web view for certain components of the UI and everything else is written in C/C++? Does merely using an interpreted language like JS or Python anywhere in your app mean it's no longer native?

Also, keep in mind that this blog post was written for Postman's users, it's not a technical write up. Postman's users may be more technical than most, but they still shouldn't have to know or care what underlying technology was used to build Postman's desktop apps. From their perspective calling them "native" apps is perfectly accurate, as they behave as native apps in every respect.

Re: Going native

#196
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…

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 delay tolerance and consistent UI. Electron can only provide the second (and sometimes the third.)

Re: Going native

#197
post #181

Earlier quoted context omitted.

No, you've "made" a native browser that opens HN in the first tab.

By that logic Postman native is a native browser hardcoded to open only one tab and load Postman's javascript code upon start-up

Basically this is true but the browser (Electron) is designed to be single-purpose (your app) and has pathways to the filesystem that you can't get in a web browser.

Also, it is treated as an application by the OS rather than a Chrome window (and all the benefits that come with that shift).

Re: Going native

#198
post #196

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…

That's a valid concern and I believe all developers who are working on the platform will address this. If memory/power consumption on laptops was so draining just because something was in HTML/CSS/JS, I believe people would have stopped using browsers or probably just stuck to 1-tab per browser.

Re: Going native

#199
post #179

Earlier quoted context omitted.

Paw founder here. I'm very sorry to hear this. If you don't mind, I'd love to know more details on what's happening. The logs available in Paw menu > "Get Debug Info…" are very helpful. If you don't mind sending these details to support@paw.cloud, we'd be very grateful! Thx!

Do you have any plans for Windows or Linux? I love Paw, but would like the option of knowing I won't be left out if I decide to move away from Mac

Since true native (UI/UX) is core to our focus to do an window/linux we would need to do that same, currently most of our code is still in obj-c (new code is in swift) but it would be a massive task to produce a native window and a native linux app.

however we do have extensive support for exporters to many formats through our open source lib (API-Flow) https://github.com/luckymarmot/API-Flow this converts between (paw, swagger, api-blueprint, postman etc) we realy dont want you to feel locked in with your data.

Re: Going native

#200
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…

Why not call it "standalone app" (Chrome-less! though that might be confusing for other reasons.)

Naming things is tricky. Postman exists in the following places:

1. In-browser Chrome extension with a UI (Postman legacy app)

2. In-browser Chrome extension without a UI (Postman Interceptor)

3. Stand-alone/desktop Chrome app (can be run withput Chrome)

4. Command line tool (newman - runs the same runtime as Postman)

5. Stand-alone/native apps that can be installed (where most of the debate on this thread is)

6. Server-side runtime

We chose to use "native" because it avoids the confusion with the existing Chrome desktop app and informs people about the advantages of this version v/s the previous version in one word.

Post reply on HN