Can we not conflate "native" and "electron" applications? Thanks.
Going native
41–50 of 245 posts
Re: Going native
#42These '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).
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 can only imagine explaining to someone from 15 years ago what software looks like now. "Oh yeah in the future we all use IRC, except its a proprietary IRC implementation and supports animated gifs. The client is 380 megs" "Calm down - I know thats bigger than your hard drive. No its not 3d or anything - it just has nice colors."
I don't understand why people hate on apple for not making laptops with 32 gigs of ram, but they have no problem using apps like slack which waste resources like it was water.
Thankfully slack seems to be much more lean when run inside a safari browser tab.
Re: Going native
#43"The native apps cover all the features and functionality of the Chrome app and Chrome extension together, and more. The native apps run on Electron overcoming a lot of the restrictions of the Chrome platform." My understanding was that Electron is just an embedded instance of Chromium, so I'm reading this sentence more like "The native apps run on [embedded Chromium] overcoming a lot of the restrictions of the [stan…
Yup. Luckily, there is Paw[0] if you want a native experience on the mac. [0]: https://paw.cloud
[deleted]
Re: Going native
#44With 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/
With a name like "Apple", you'd think they're selling fruit!
Vinyl records, perhaps?
Re: Going native
#45Hmm, does Electron really == "native" ??
It's a native binary executable with standard access to system APIs, so in the technical sense, yes.
That just makes the platform native, which doesn't say anything at all. Presumably the app itself is still written in javascript, so its not native at all - its just bundling its own (native) copy of chrome.
Re: Going native
#46These '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 actually a perfect bad example. When they switched to Electron, the app got much shittier (at least on OS X). Many native features, like force-push on words/links, vanished, and there's a bunch of random bugs (including a really annoying one with input and smart replacements where the caret jumps around making you mistype things).
Re: Going native
#47These '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 guess there is a region where it's ok. I love Postman and think it performs great. I'd make the same argument for Slack; however because I have to open 24/7 there is a big pain on the battery which Slack needs to worry more about than Postman. VSCode on the other hand I expect to be performing and run under some crazy circumstances and the non native aspect of it prevents me from using it.
Re: Going native
#48Earlier quoted context omitted.
It's not just an embedded instance of Chromium. There are APIs that bridge the gap with the operating system. One way to look at this is that the UI layer runs on HTML/CSS/Javascript. VS Code, Slack etc. are other common examples. [Electron APIs]: https://electron.atom.io/docs/api/
Right. It's Chromium + JS APIs + some packaging. E.g. an API to write a file.
All OS related functionality is through Node.
Re: Going native
#49You don't have to be native although it looks like Chrome Apps will be gone. SecApps (https://rest.secapps.com) for example utilises a Chrome extension and while it is not perfect it is still a webapp.
My point is that the Web is very powerful platform and I don't think we should always undermine it because it is not native!
Re: Going native
#50I am really getting tired of the constant "need an account" for _everything_ - nvidia being the one that drives me the most crazy. I appreciate the fact that Postman allows you to continue without registration[0] [0] http://i.imgur.com/8XVCu5u.png
What I would love would be a git friendly app. keep the collection as a file that I can keep on the repo and them commit the new changes in the code.
Paw uses git under the hood when you use its sync service (available for free), it seems.
Unfortunately, you can't sync with your own repo, which is a shame for a fairly expensive rest client, compared to alternatives.
I use and love it way more than Postman nevertheless.