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

Web vs. native: let’s concede defeat

quirksmode.org

Post reply on HN
Print view View original

111–120 of 515 posts

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

#111

Post by rimantas »

mromanuk wrote: post #102

> Technically, it’s simple. The web cannot emulate native perfectly, and it never will. Native apps talk directly to the operating system, while web apps talk to the browser, which talks to the OS. Thus there’s an extra layer web apps have to pass, and that makes them slightly slower and coarser than native apps. This problem is unsolvable. Really weak argument, it reminds me of High level languages will never replac…

Except in this case we are not developing high level languages, we are trying to patch poor ASM. I see the height of the web in the early 2000s, when web standards, accessibility, clean markup meant something. Now it is just a pile of frameworks (as someone twitted: JS frameworks are standards fanfiction) thrown together. And not even for apps, for a simple text page :( I will repeat Tantek's definition: if it is not curlable, it is not web.

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

#112

Post by baldfat »

the8472 wrote: post #85
fizk wrote: post #42

Remember Flash? Narrow the gap, add a bit of Steve Jobs and Boom! The web Won. Look at a site like YouTube today. All the tooling we've created and all the progress of the open web platform that has made that site happen is incredible. If we've just given up 10 years ago, saying to ourselves that the web should only be for documents, then we would be missing out big time right now. It’s not for every site to try and…

> Look at a site like YouTube today. And yet any media player beats it at its core functionality: video playback. Often I find myself using youtube-dl to fetch a youtube video and just play it in a regular media player because it just works better than what browsers have to offer. There even are addons to export YT playlists to VLC and stream them. pdfjs is great. but every 3rd scientific paper I read tends to be som…

shhhhssss there is no such thing as youtube-dl! I believe that the tool should be like Fight Club or it gets noticed and gets shut down through a drawn out war of changing code and apis.

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

#113

Post by lloeki »

fizk wrote: post #42

Remember Flash? Narrow the gap, add a bit of Steve Jobs and Boom! The web Won. Look at a site like YouTube today. All the tooling we've created and all the progress of the open web platform that has made that site happen is incredible. If we've just given up 10 years ago, saying to ourselves that the web should only be for documents, then we would be missing out big time right now. It’s not for every site to try and…

> It’s not for every site to try and push the envelope. And mimicking native can often lead to bad results. But to go from that and say that we shouldn’t try. That’s just sad.

The article says exactly that! It just says we shouldn't shoehorn native stuff into the web (e.g look at Synology's UI mimicking a nested desktop and windows).

> We shouldn’t try to compete with native apps in terms set by the native apps. Instead, we should concentrate on the unique web selling points: its reach, which, more or less by definition, encompasses all native platforms, URLs, which are fantastically useful and don’t work in a native environment, and its hassle-free quality.

Youtube example perfectly fits that bill.

Yet there is also a critical difference to be made between "the web" and "web technology": while the former is operated in a browser, platforms such as Electron leading to apps such as Atom or Slack that totally don't try to mimic the native platform they're running on, powering cross-platform applications that nonetheless do try hard to respect† the platform they're running on, achieving something Java's cross-platform WORA GUI toolkit thoroughly failed to††.

† there's a clear, visible boundary between the native system and the webtech app, but that boundary is easily crossed, whereas historically we've been trying to erase the boundary and pretend it doesn't exist, only to veer straight into an uncanny valley.

†† dare I say Firefox sits right there too, forever battling the tide of mimicking native components with each OS release, from UI elements appearance (vanishing scrollbar, input fields...) to behaviour (non-"sheet" modal windows on OS X), in subtle but aggravating ways, if only because it erodes the product's image and detracts development resources from other efforts.

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

#114

Post by ascagnel_ »

datashovel wrote: post #35
ubernostrum wrote: post #22

Earlier quoted context omitted.

This post leads me to believe the author probably assumes there will always only be a handful of native platforms. No offense, but I'd trust PPK's beliefs about the mobile ecosystem more than any random HN user.

None taken. It's probably not worth arguing who is right or wrong since none of us can reasonably assume we know what the future will be, but I will say that in general (1) diversity in ecosystems is good. (2) Monopolies are bad. Given only these two basic assumptions I think it's obvious that there should / will be a push for more diversity in mobile, and thus a larger number of platforms to develop for. This can on…

> It's probably not worth arguing who is right or wrong since none of us can reasonably assume we know what the future will be, but I will say that in general (1) diversity in ecosystems is good. (2) Monopolies are bad.

Diversity is good, but too much diversity can be detrimental. A one-mobile-OS world is a terrible thing, since there's no need to push forward and improve. A two-mobile-OS world is better, as long as it's easy for users to switch to whatever is better at the current time. Once you get beyond three, you end up with a situation where it takes more and more development time to cover less and less of the market, and it becomes more likely that a single winner emerges (for example, the DOS-to-GUI transition in the 1980s-1990s).

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

#115

Post by mreiland »

onion2k wrote: post #5

Unless you're making something that needs really good performance (3D gaming for example) building a hybrid app wins every time. Something based on Cordova (eg PhoneGap, Ionic) with Crosswalk can get you to about 90% of the performance of a native app, with about 1/2 of the development time because it's all built with web technology. 90% is easily good enough for most applications. Cordova wraps a uiWebView in some b…

I really dislike steam's hybrid approach.

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

#116

Post by whoisthemachine »

pjmlp wrote: post #107
whoisthemachine wrote: post #94

To a certain extent, I think this is true. Many mobile sites still need to be more engaging, but they need to do it by taking advantage of their strengths - server side rendering, a nice easy way to stylize (think CSS is bad? try styling your application in Android's framework, or WPF for that matter) - rather than going the route of the "SPA". Once a web app tries to look and feel like a native app, other things out…

> try styling your application in Android's framework, or WPF for that matter I will take any of those over CSS, thank you very much.

Hmm what advantages do those have that makes you prefer them over CSS? I work in both of those daily and they're usually just an exercise in frustration.

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

#117

Post by jsingleton »

pavlov wrote: post #28

I feel we’ve gone too far in emulating native apps. Conceding defeat will force us to rethink the web’s purpose and unique strengths — and that’s long overdue. This, a million times. Mobile websites and mobile apps have completely different strengths. The current trend is to develop them both with the same HTML-based toolchains and make them as similar as possible, which ends up being to the detriment of both. Users…

What do people think of frameworks like https://jquerymobile.com and similar?

I tend to think it's good when running in a browser but not when it's made mobile web app capable and running full screen without native controls. Unless it's a super simple single page app.

At the other end there are things like Instagram where you basically can't do anything on the website (can't sign-up, can't upload photos). Everything requires the app.

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

#118

Post by jasode »

weland wrote: post #92
jasode wrote: post #53

Earlier quoted context omitted.

>The web works best as a document platform. This is only true if you constrain the "web" to mean the Tim Berners-Lee document-centric HTML and its http hyperlinks. The "web" also means the whole internet stack, TCPIP, DNS routing, etc. In that case, the web is a foundational tool for anything that connects people or Internet Of Things. To say the "web works best as a document platform" is like saying "the electricity…

> The car works best as a transportation device. This is only true if you constrain the "car" to mean the Henry Ford, transport-centric engine-and-chassis. The "car" also means the whole transportation stack: pavement, asphalt, road signaling, etc. In that case, the car is a foundation tool for anything that transports people or inanimate objects. To say the "car works best as a transportation device" is like saying…

I'm not saying I like for "the web" to be interchangeable with "the internet".

Instead, I'm pointing out that the world out there without permission from any savvy HN readers has moved on. The "web" has become the "internet" for both documents and applications.

It's descriptive, not prescriptive. (See my other replies to illustrate how usage of http has evolved to coexist with corporate firewalls that lock down ports.)

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

#119

Post by datashovel »

pdpi wrote: post #36
datashovel wrote: post #26

Earlier quoted context omitted.

It seems we have different assumptions we're basing our arguments on. I get the impression that the huge diversity of linux distros is enabled primarily by the fact that more and more development these days is web and not native.

You're missing my point. There's no purpose in having a huge diversity of linux distros, if they're just glorified browser shells.

I'm guessing they all (the linux distros), in one way or another, add value given each project's mission statement. Or at least they believe they are. Otherwise they probably wouldn't be doing it.

And I don't think we'd have to fear the OS will become a "glorified browser shell" if it wasn't the primary "app development platform".

Right now native app development is feasible. You have pretty much 3 platforms you really need to worry about developing for in order to have access to the largest amount of market share for the least amount of effort. Imagine even one more player enters the market and gains any respectable amount of market share.

Instantly every mobile app development team's efforts need to grow or every developer on each team's responsibilities grow linearly with the total number of platforms they need to develop for. From an operational standpoint it's not sound economics to make business decisions based on approaches that don't scale well.

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

#120

Post by rimantas »

sytelus wrote: 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…

  > Web APIs will and should become the standard way of
  > developing apps across platforms
God forbid. There are few lamer things than those Web APIs. Why do you think the gazzilion of frameworks exists, if not to work around all the things broken? And take a look at the web in 2005 and now, see what real progress was made. Yep, we got a bunch of half-baked APIs, which will never mature, because all the crowd already run forwrad to tick another checkbox.
Post reply on HN