Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye, Native Apps

medium.com

Post reply on HN
Print view View original

91–100 of 231 posts

Re: Goodbye, Native Apps

#91

Post by wtallis »

Silhouette wrote: post #83
Razengan wrote: post #49

Earlier quoted context omitted.

> It's totally possible to build a PWA that behaves like a native app but Apple actively tries to destroy them. Ugh, no. No it's not. At least not yet. Accessibility features alone are almost always woefully crap in web-apps, compared to what native apps have access to, at least on macOS (and SwiftUI is amazing in how it lowers the barriers in implementing accessibility in your app from the get-go.) Shit like Electro…

Shit like Electron and PWAs seem to be championed by user-hostile developers that just want things to be easy for themselves, without considering what's best for the users and their hardware resources. There is a standard counter to that argument at this point. Developers on native platforms might be able to achieve a better experience on that platform than a web app given the same time and resources . However, if th…

> While each native developer is still worrying about whether they're aligning and labelling a button in the platform-standard way, the web team is already refining their UI using the results of their third round of usability testing and has determined that the button shouldn't have been there in the first place and designed and implemented a more intuitive UI

Your hypothetical scenario seems to be treating the app's UI as if it exists in a vacuum, rather than existing alongside other apps.

If there's a platform-standard UI convention that applies to a button, then UI testing in the context of that platform is probably not going to tell you to remove that button entirely—you shouldn't be surprising users by removing functionality they expect to find present. And if there is a UI convention that tells you how to position that button, you probably shouldn't A/B test the positioning of that button and should focus your usability testing on the UI elements that are not dictated by the platform's standards and conventions.

Re: Goodbye, Native Apps

#92

Post by gcanyon »

As an example I haven't seen elsewhere of why web apps suck (maybe this could be coded around?): I can receive a notice from Slack of a new message, with who it's from and a snippet preview, as I'm leaving my office's WiFi, and then the actual Slack app won't show me the actual message until I return to WiFi :-(

Re: Goodbye, Native Apps

#93

Post by twodave »

gcanyon wrote: post #92

As an example I haven't seen elsewhere of why web apps suck (maybe this could be coded around?): I can receive a notice from Slack of a new message, with who it's from and a snippet preview, as I'm leaving my office's WiFi, and then the actual Slack app won't show me the actual message until I return to WiFi :-(

Sounds more like an implementation detail to me. The notification doesn’t contain the entire message (it goes through a different channel altogether). By the time the app tries to poll to retrieve the message (I assume here that it’ll wait until you try and view it) there’s no connection.

Re: Goodbye, Native Apps

#94

Post by twodave »

schwartzworld wrote: post #6

VSCode is a poor example. Its a fully featured IDE, and sure it would be lighter without electron, but it still wouldn't be a lightweight piece of software. I use JetBrains which is not Electron, but also uses it's fair share of ram.

I like to joke/not really joke that (insert JetBrains product)’s main feature is converting laptop battery charge into heat and fan noise ;)

Re: Goodbye, Native Apps

#95

Post by Silhouette »

wtallis wrote: post #86
Silhouette wrote: post #79

Earlier quoted context omitted.

The important question is, does that matter ? Slick web apps are taking over the software world, whether the likes of Apple want them to or not. Looking like any specific native platform is less important, if it's even relevant at all, in an era when users are working with different web apps each with their own look-and-feel all the time anyway.

Does it matter? Yes, of course. The desire for consistency and usability may not be strong enough to reverse the current trend away from native apps, but that doesn't remove their advantages. And I find it very telling that even your own comment continues the trend of over-emphasizing look over feel . I'd be happy with apps randomly launching in night mode, if they would just have all the right controls in the right…

The problem with that argument is that you're assuming consistency with native platform standards is the dominant consideration. I contend that, today, it often is not. Many users are spending much of their time using web sites and applications rather than native ones; this trend does not appear to be in dispute here. Moreover, the basics of how web sites (and by extension web apps) work have a longer history of established conventions than any of the major native platforms; the likes of Jakob Nielsen were making the case for consistency and following user expectations more than two decades ago, long before the likes of iOS and Android and whatever we're calling Windows' UI today were glints in their respective creators' eyes.

Also, web technologies can perform just fine the vast majority of the time. Modern JS engines have excellent performance, obviously not rivalling expertly coded C and assembly, but certainly comparable to your average native application for most purposes. Modern browsers also have good support for hardware acceleration and can render UIs that respond quickly enough to user interactions that again for most purposes there is no perceptible delay or jank. Today we're looking towards WebAssembly as a vehicle for potentially more efficient languages and runtimes, though clearly that technology is still in its infancy and its future is far from certain. Now, you can undermine all of that potential if you bloat your web site/app with tens of megabytes of junk scripts that are all competing for resources and blocking stuff and phoning home and whatever, but that's not really the fault of the web technologies, it's just bad developers and/or bad managers creating a bad application.

Re: Goodbye, Native Apps

#96

Post by reader_mode »

How is this getting uovoted ? Is nobody reading the article ? A few paragraphs in and I can see the author has terrible writing skills and doesn't know what he's talking about

>In fact, writing software with C/C++ was hard because developers had to work with different operating system API(Application Programming Interface).

Seriously ? Writing C++ apps is hard because you had to use different APIs ? That's the least problematic part about C++ app development, behind say the fact that your app can segfault when dealing with strings... (and especially pre C++11) or that you could take lunch breaks during builds which kills GUI iteration.

I feel like this doesn't belong on front page and people upvoting this are doing the site a disservice by upvoting based on title alone.

Re: Goodbye, Native Apps

#97

Post by nicoburns »

jordwest wrote: post #85
nicoburns wrote: post #62

Earlier quoted context omitted.

Indeed, my prediction is that native apps will make a comeback when the UI toolkits catch up. Flutter is in this vein. And some of the Rust UI ecosystem looks promising (although very early stage).

Agreed, I think the web was simply first in being a highly versatile, capable, and relatively cheap to develop with cross platform UI toolkit. I’m much more optimistic about the future of native apps, the best ideas from the web are already making their way into Rust and the recently announced .NET MAUI, and with WebAssembly I think we’ll start to see native performance on the web instead of the other way around.

> with WebAssembly I think we’ll start to see native performance on the web instead of the other way around.

I wouldn't be so sure about that. WebAssembly doesn't do anything to help the rendering bottleneck. To do that you really have to replace (or innovate in some way) the DOM.

Re: Goodbye, Native Apps

#98

Post by amelius »

heavyset_go wrote: post #63
nicoburns wrote: post #62

Earlier quoted context omitted.

Indeed, my prediction is that native apps will make a comeback when the UI toolkits catch up. Flutter is in this vein. And some of the Rust UI ecosystem looks promising (although very early stage).

> And some of the Rust UI ecosystem looks promising (although very early stage). Can you recommend any projects to check out?

https://www.areweguiyet.com/

Re: Goodbye, Native Apps

#99

Post by Silhouette »

wtallis wrote: post #91
Silhouette wrote: post #83

Earlier quoted context omitted.

Shit like Electron and PWAs seem to be championed by user-hostile developers that just want things to be easy for themselves, without considering what's best for the users and their hardware resources. There is a standard counter to that argument at this point. Developers on native platforms might be able to achieve a better experience on that platform than a web app given the same time and resources . However, if th…

> While each native developer is still worrying about whether they're aligning and labelling a button in the platform-standard way, the web team is already refining their UI using the results of their third round of usability testing and has determined that the button shouldn't have been there in the first place and designed and implemented a more intuitive UI Your hypothetical scenario seems to be treating the app's…

In God we trust; all others must bring data.

(Origin unknown)

Your arguments use the word "probably" a lot. As someone who does a lot of UI design professionally, I prefer to rely on the kind of user testing you apparently dismiss, precisely because prior expectations about what works well so often turn out to be inaccurate. Indeed, there have been plenty of native platform standards that have awful usability in recent years, which have rightly been criticised for it by professionals wielding empirical evidence.

Re: Goodbye, Native Apps

#100

Post by bluedino »

reader_mode wrote: post #96

How is this getting uovoted ? Is nobody reading the article ? A few paragraphs in and I can see the author has terrible writing skills and doesn't know what he's talking about >In fact, writing software with C/C++ was hard because developers had to work with different operating system API(Application Programming Interface). Seriously ? Writing C++ apps is hard because you had to use different APIs ? That's the least…

It is a shit article.
Post reply on HN