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.
Going native
191–200 of 245 posts
Re: Going native
#192Re: Going native
#193Re: Going native
#194Earlier 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 "…
Re: Going native
#195Postman 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…
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
#196Earlier 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.…
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
#197Earlier 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
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
#198Earlier 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…
Re: Going native
#199Earlier 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
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
#200Earlier 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.)
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.