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

81–90 of 245 posts

Re: Going native

#81

Post by kuschku »

josephg wrote: post #42
CountSessine wrote: post #22

Earlier quoted context omitted.

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

Gold standard? Slack is 380 megs in size, and when its open it somehow seems to constantly use about 5% CPU usage (which probably knocks out a few hours of battery life, since the CPU can't properly sleep). Every so often I catch it sitting on 100% cpu usage (this is all while in the background). Restarting slack fixes it. I know that programmer time is more important than CPU time, but its my CPU and my battery. I c…

> 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 comparison, the new Minecraft Launcher uses Electron. The entire JVM + every Minecraft version ever, plus assets, plus all mobile editions uses less space than it. In a usual minecraft installation, the actual game uses on average between 7 and 15% of the required space, the remaining 85 to 93% being used by the launcher (specifically, the bundled Chrome runtime)

Where did our society go wrong?

Re: Going native

#82

Post by overcast »

Animats wrote: post #9

With a name like "Postman", one might expect this has something to do with mail, or messaging. The blog post gives no clue as to what it's for. It's apparently a test tool for testing HTTP-based APIs. [1] (HTTP "POST", get it?) Not to be confused with Postman Corporation, which is a "computer repair shop" near CIA headquarters. [1] https://www.getpostman.com/

I don't think anyone on HN, besides you, confuses the Postman App with a CIA cover shop.

Re: Going native

#83

Post by richthegeek »

lalmachado wrote: post #75

I gave up using postman a while time ago because I was thinking that they had not an app outside the Chrome. I started using insomnia( https://insomnia.rest/ ) and I am satisfied

Exactly the same experience here. Postman always felt a little laggy and the in-app pushing for premium features was getting annoying.

Insomnia does everything I want it to do and does it quickly.

Re: Going native

#84

Post by elmigranto »

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 are guaranteed to fit in with OS styling

They aren't. For example, if you move your cursor to a word in macOS, and force touch, pop up will appear with word's definition from Dictionary.app. This is not a case in "native" applications that render text differently, Sublime Text is my offender, but there must be others.

So "guarantee" is too strong of a word.

Re: Going native

#85

Post by a85 »

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…

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 case with Electron.

- They can perform equally well. The web platform itself is an example of this. Browsers have improved quite rapidly over the past few years.

- Optimizations can be made in JS code as well. Other comments here have some examples.

The advantages of having a cross platform application developed in 1/3rd the time especially for new applications are huge (faster time to market, larger number of people for validation)

The JS ecosystem has grown much faster and will continue to do so. The building blocks that are available will also improve in quality and I believe that more and more developers chosing Electron will speed up this process.

Re: Going native

#86

Post by flukus »

scaryspooky wrote: post #80
badminton1 wrote: post #70

Earlier quoted context omitted.

Well, many widget libraries use markup languages, Qt has QML, WPF has XAML, and could give more examples but you get the idea. Personally I prefer using Burp rather than Postman.

QT has direct bindings to the host platforms C code. How you express layout of a view is very, very different than how you directly use OS APIs.

For some things, but it still implements it's own widgets and I don't think it obeys the OS theme by default (at least on windows).

Re: Going native

#87

Post by flukus »

kangoo1707 wrote: post #61
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.

If an app can be installed the same way a "native" app does, it is a native app. Users do not care about the technology behind the scene and what they are called.

Java apps could be installed and never used to be considered native. Native means "uses the OS UI components".

Re: Going native

#88

Post by a85 »

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 things to be.

2. We have worked hard on optimizing our UI layer over the past several months including mapping of keyboard shortcuts and smoothening out performance issues.

3. We are able to provide a consistent experience for Windows, Linux and macOS users and people love that EVERYONE in the team can use the same app. That has very clear advantages when development teams are chosing tools. Postman is used by everyone who comes in touch with APIs - product managers, sales, customer support, dev evangelists and a cross-platform app allows everyone to standardize much faster.

4. Reusability in the code base through node packages is amazing to have.

5. We use React and are aiming for reusability of these components in the browser. This includes stuff like visualizations, data rendering etc. Our time to market has come down like crazy.

6. With node, not only do we get reusability across OSes but also between the app and our server-side stuff. We have a command line tool called newman that uses the same runtime (postman-runtime, open-sourced on Github) and the same runtime powers our monitoring service that runs on the cloud.

That's just some of the advantages. There is a lot of work going on in optimizing our code base. Ultimately we are validated by whether we do a good job for people who use the application. I have been building Postman over the past 5 years now and that has been the core guiding princple.

Re: Going native

#89

Post by smlacy »

tragic wrote: post #79
smlacy wrote: post #64

Earlier quoted context omitted.

No its not. :) Blog has no product description, and even the product description on getpostman.com (below the fold) is amazingly vague: "A powerful GUI platform to make your API development faster & easier, from building API requests through testing, documentation and sharing." So... It's a text editor? A test framework? What languages does it work with? Web APIs or native? Why would I use it over my existing toolcha…

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.

Re: Going native

#90

Post by wishinghand »

kangoo1707 wrote: post #61
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.

If an app can be installed the same way a "native" app does, it is a native app. Users do not care about the technology behind the scene and what they are called.

All native apps are desktop apps, but not all desktop apps are native apps.
Post reply on HN