161–170 of 245 posts
Earlier quoted context omitted.
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.
You're not the target market if you couldn't figure out what they are. I've never heard of it but one look at the screenshot told me exactly what it is.
Earlier quoted context omitted.
Why not call it "standalone app" (Chrome-less! though that might be confusing for other reasons.)
Mattermost (and Telegram?) call the electron-based apps "desktop apps", which is I feel is a nice tradeoff: not native but not browser.
Earlier quoted context omitted.
But sublime isn't really a native app either. When did we start corrupting the meaning of native? When electron apps appeared, and we wanted to divide "compiled" versus "interpreted webapps" on the desktop? Cross platform toolkits, be it proprietary, one-off like Sublime's, or things like Qt, GTK, WxWidgets, Java Swing, were NEVER considered native. Just because an app is written in C or C++ doesn't make it platform…
How would you create a native GUI app on Linux for either Gnome or KDE, considering that GTK and Qt are not allowed by this definition? And yes, you may think: "Easy, if a GTK app runs on Linux its native, if it runs on another platform, it's not". Does that mean JavaScript apps for Gnome[1] can be called native, because they have officially blessed bindings to the underlying framework/platform and are fully integrat…
Actually, yes, by definition a javascript app written with gobjects is native to a Gnome desktop. It fully integrates with the standards of the system be it text boxes, keyboard shortcuts, general behavior and widget look. The most important, even more than our personal little preferences, is that a native app can be accessed by things like screen readers which is the only way for a person with a disabled sight to use a computer. Anything not written with GTK on Linux is going to be a black box for Orca. In fact webapps would be less of a pain than a compiled app that uses a random crappy cross platform toolkit. While the web's accessibility could do with some improvements, it's still better than the absolute nothing that cross platform toolkit represents.
Sometimes devs put extra effort into making cross platforms apps accessible but they're the exception rather than the norm : https://www.parhamdoustdar.com/2016/04/03/tools-of-blind-pro...
The reason being is that native apps get "most of the work" done for them for free when they use the native tools to make apps, while cross platform apps require a severe amount of work to get them to talk to screen readers correctly.
Android Studio seems to be gaining on that side despite the original platform being pretty poor. And of course Sublime Text is absolutely unusable in that scenario.
Some apps do crossplatform the right way, although they're rare: they have have a platform-specific GUI rather than use a generic cross toolkit. Transmission is a solid example :
The app has a Cocoa, GTK, Qt, TUI and Web end user interface. It's native on all the officially supported OSes. There's a non-native, Qt-using windows port but it's a third party fork and not supported by the main devs.
Since the author is in the comments just wanted to ask one thing. Is this [1] supposed to be misaligned?
Earlier quoted context omitted.
Mattermost (and Telegram?) call the electron-based apps "desktop apps", which is I feel is a nice tradeoff: not native but not browser.
I think Telegram uses Qt.
> How we avoided going native, and built an App with Electron instead
Earlier quoted context omitted.
Mattermost (and Telegram?) call the electron-based apps "desktop apps", which is I feel is a nice tradeoff: not native but not browser.
I think Telegram uses Qt.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
Yup. Luckily, there is Paw[0] if you want a native experience on the mac. [0]: https://paw.cloud
Ugh. This used to be true until version 3. The Paw native experience is now terrible. I'd welcome a nice embedded app in electron.
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'd argue that the HTML/CSS/JS layer is more powerful and more extensible than any native rendering layer. We are building some awesome UI components using this: http://blog.getpostman.com/2017/02/28/introducing-the-new-da... Things that we build for the app are also available for our web components instantly. React makes this even easier.
It gets better when you start adding in the things that javascript makes hard, like concurrency and parallelism. For example, with C#, I can do something like
var results = URLs.Select((t) => { Task.Run(SomeLongRunningFunction(t)); } );