Live data from Hacker News

Web vs. native: let’s concede defeat

quirksmode.org

431–440 of 515 posts

Re: Web vs. native: let’s concede defeat

#431
post #33

Web APIs are in essence becoming an abstraction layer between OS and applications. It's not just about browser anymore. Browser is just one of the host for these APIs. In next decade or so, we should have all the power built in to standards that eliminates pretty much any advantage that native application can possibly have - even for heavy duty 3D gaming and offline video editing scenarios. Web APIs will and should b…

> In next decade or so, we should have all the power built in to standards that eliminates pretty much any advantage that native application can possibly have Agreed. I was just watching this talk the other day called 'Making web apps appy' froom Chrome Dev Summit: https://www.youtube.com/watch?v=QbuLq4f6DGQ It talks about a lot of new incoming features, like push notifications from the browser, adding icons to home…

Those features have all launched; see: http://blog.chromium.org/2015/03/chrome-42-beta-push-notific...

Re: Web vs. native: let’s concede defeat

#432
post #10

Earlier quoted context omitted.

Is a "win" for the developer necessarily a win for the users? Whose experience takes precedence?

If cost of developing app is halved, many more apps will be built. The choice is often not between "expensive native app" and "cheap hybrid app", it's between "why is it so expensive? but I can afford this (hybrid app)" and "no way that's too expensive (native app)".

But is it better to have more apps, if most of those apps work like shit? Wouldn't it be better to have fewer apps, (although I reject the premise that it would happen) but higher quality apps?

Re: Web vs. native: let’s concede defeat

#433
I strongly disagree. Why wouldn't we want to continue making progress on the web? Where would we be today if cavemen decided spears are good enough so let's just stop there.

I think the web should continue innovating and that trying to compete with native apps is a worthy goal.

The web is the most compatible and universal format. There is a lot of benefit to having a universal development platform. With Node.js the web has been brought server-side as well. There is a huge convenience factor to being able to use 1 platform for browser, server, and mobile.

I don't like being locked into a vendor or being uncertain if this platform will be around 5-10 years later. Having the web around as an app platform creates certainty that encourages commitment from companies.

Re: Web vs. native: let’s concede defeat

#434

Rehashing part of my comment from a different article: I don't see why any reasonable developer would choose building the same app on multiple platforms over building it once on a standardized platform and having it just work everywhere. That is, of course, if the standardized platform had all the capabilities and great UX of the proprietary platforms. This is where the web often falls short, and the companies behind…

"I don't see why any reasonable developer would choose building the same app on multiple platforms over building it once on a standardized platform and having it just work everywhere."

Because it provides a better experience for the user, and because it allows for access to hardware native features.

Re: Web vs. native: let’s concede defeat

#435
post #315

Telling mobile devs not to use web tech is an example of where this argument (request? demand?) falls down. There are a lot of advantages to using web tech (cross-platform, easier to develop, easier to push updates), and the result is not necessarily worse; it may be better. CSS is a very expressive and powerful layout language, for all its rough edges. Apple uses WebViews in their own apps (like the mobile App Store…

>>> There are a lot of advantages to using web tech (cross-platform, easier to develop, easier to push updates) Yeah. This shouldn't be overlooked. In some cases (solo founder, bootstrapped, etc) a hybrid app might be a great choice for v1.0. Sure, it won't be fast on the phone... But it probably will be pretty fast to develop and release on multiple platforms. Especially if you don't have experience in iOS/Android d…

I think quite a wide variety of app devs might find it more important to be able to, say, develop an app faster than have a snappy start-up time, especially if there's no fundamental limitation at play but just limitations of the current tools!

I trust app devs to choose the best tools for the job.

Re: Web vs. native: let’s concede defeat

#436

Earlier quoted context omitted.

I don't recall plugins ever offering much choice. "Please install Flash to view this content" is what I remember. If I could stream directly to VLC or a player of my choice I'd be happy with that.

Netscape could do this back in 1995. One of its preference settings let you associate external applications with certain MIME types; when you clicked on a link pointing to a resource of that type, it would automatically open the external program to view the file, as if you had double-clicked on it. Similarly, you can do this right now on Android. When you click on a link, it fires off an Intent with the URL. Apps can…

>It turns out that for certain types of content, users really, really don't like to wait for external programs to load.

I'm not sure how that's a valid point. My native media player loads in literally less than a second. (I timed it at 0.59s from when I double-click a file and it starts playback.) This is faster than any webpage can ever dream of loading. And unlike Flash or HTML5 video it gives me completely hitch free playback, whereas browser integrated player tend to drop frames quite frequently.

I would much rather use it than any player integrated into a web browser.

Re: Web vs. native: let’s concede defeat

#437
post #155

Earlier quoted context omitted.

I would like to complement that native youtube(the one used on mobile) is far better at playback while keeping nearly every other advantage that it has on the web.

> that native youtube(the one used on mobile) is far better at playback. No, it is not. Playback would get stuck, sound would go away for no rhyme or reason and what not. Better experience? - no - quite the opposite. I got rid [1] of the native nuisance completely. And the experience of search, comment and history on native was simply terrible . Much lesser control on ad-blocking too, and really the ads on YT are som…

If you block the ads, how does the site make money to support your viewing habits?

Re: Web vs. native: let’s concede defeat

#438
post #423

Earlier quoted context omitted.

I'm sorry, after reading you say "they are now the same because they are flat", I sincerely hope you fail. You are clearly not a designer, yet attempt to market a development tool as such.

It's just an observation: for real-world apps, iOS and Android visual styles and conventions are growing closer rather than diverging (and Windows 10 is trying hard to fit into the same mold). For a random example, look at Periscope's new Android version -- the differences from the iOS version are minor, yet it fits in nicely on Lollipop: http://www.theverge.com/2015/5/26/8657349/periscope-android-... As for the "I s…

Your observation about iOS vs Android is very narrow-minded, either deliberate or inadvertent. There are profound design language differences between iOS and Android material design. Claiming "flatness" is very shortsighted indeed.

A word on Windows 10, mobile or otherwise. It is indeed a mess, with almost no coherent design language, something that Phone 7, Phone 8 and Windows 8 actually had, for better or worse. Windows 10 throws many of the good design choices for a faux Android look, and a very bad one at that due to complete lack of consistency. Android also lacks consistency throughout, but at least a somewhat coherent design language exists now.

I do not wish to argue here. Do not take my wishes personally. As someone who wishes to only see good technology succeed, and I do not see this as good technology. I do not wish personal failure to anyone individual, and wish you personally all the best.

Re: Web vs. native: let’s concede defeat

#439
post #434

Rehashing part of my comment from a different article: I don't see why any reasonable developer would choose building the same app on multiple platforms over building it once on a standardized platform and having it just work everywhere. That is, of course, if the standardized platform had all the capabilities and great UX of the proprietary platforms. This is where the web often falls short, and the companies behind…

"I don't see why any reasonable developer would choose building the same app on multiple platforms over building it once on a standardized platform and having it just work everywhere." Because it provides a better experience for the user, and because it allows for access to hardware native features.

Yes, but that's a side effect of native already having better UX and more capabilities.

"That is, of course, if the standardized platform had all the capabilities and great UX of the proprietary platforms. This is where the web often falls short, and the companies behind proprietary platforms have some very sweet incentives to keep it that way, i.e. developer lock-in and maintaining complete control over the platform's direction."

Given the choice of a standardized platform that offers the same UX and features, would anyone still choose to develop for proprietary platforms?

That ideal standardized platform doesn't exist right now, but the web is getting closer and closer to being that platform. It doesn't make sense to give up all the progress we've made so far and resign to native when the web is already almost there.

Re: Web vs. native: let’s concede defeat

#440

Earlier quoted context omitted.

This is only true right now It will always be true forever, or at least for as long as a web browser is a program run within an actual operating system. It's not a competition. Pick the right tools for the job. If the job is getting your eMail or playing a relatively simple game, and a web browser abstracting as an OS can support your needs, knock yourself out. If the job is something a bit bigger than that, use a mo…

Take a look at what's currently available in desktop web browsers: maps, document and spreadsheet editing, highly interactive charts, video conferencing etc. (things previously thought impossible/impractical for a web browser to do) If you need huge amounts of data to even run your application, the argument to go native makes some sense, but the browser (even on mobile) isn't as inherently limited as the article desc…

I'm not limiting the web. You're not limiting the web. The web has limits. Actual, hard physical limitations (along with confidentiality and privacy limits); limits that something running entirely locally, directly with your actual operating system simply suffers, and will always suffer, to a much, much, much lower degree. Your opinion (and my opinion) is meaningless when confronted with actual, physical reality.

Right tool for the job. That's all.

Post reply on HN