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

91–100 of 515 posts

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

#91

Post by coldtea »

rimantas wrote: post #71
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…

No, the web means web. Internet means internet.

So, is a HTTP (Hypertext Transfer...) REST API used by a native mobile app "web" or not?

How about a native app based on a "web view" that uses HTML, CSS, JS, etc. (the whole W3C stack) and doesn't even talk to HTTP/S but uses some other port and transport mechanism?

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

#92

Post by weland »

jasode wrote: post #53
mozumder wrote: post #19

The web works best as a document platform. All the UI tricks that web developers work on all end up managing something related to just browsing/reading a document. It's amazing that modern browsers/HTML just don't have this basic user experience down. Why is it virtually impossible to read long articles on a web browser? After 25 years, why do web designers need to create their own page transition mechanics for long-…

>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 "the electricity grid works best as a lightbulb platform." We've gotten past the historical motivations of a horseless carriage and have done other things with it.

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

#93

Post by the8472 »

jasode wrote: post #81
rimantas wrote: post #71

Earlier quoted context omitted.

No, the web means web. Internet means internet.

Those were the historical and technical divisions. Because http & https is ubiquitous and they have a defacto pass through most firewalls, the modern "web" is the "internet" as far as application interfaces are concerned. The idea of a pure separation of concepts such that http is "documents" and some other protocol on some other port is "apps" is not going to happen. All those IT departments' security teams and Cisc…

If you really need to get across firewalls UDP sockets provide much better functionality than HTTP.

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

#94

Post by whoisthemachine »

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 of the web app developer's hands are going to make his app always look inferior. In fact, it may be some of those strengths I listed earlier.

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

#95

Post by robmcm »

LunaSea wrote: post #24

Native apps are by definition less portable than web based ones. As a developper I look at native app development the same way I saw the web in the early 00's. Different platforms, screen sizes, versions, programming languages, paradigms ...etc.

>As a developper I look at native app development the same way I saw the web in the early 00's. Different platforms, screen sizes, versions, programming languages, paradigms ...etc.

This is because you are using tools and paterns to avoid having to think about the differences. Those tools are also on native platforms, and those differences apply to the web.

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

#96

Post by pjmlp »

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…

You mean, RPC, CORBA, DCOM, XML-RPC, SOA,....?

As someone has written on his tweeter account "Web APIs are hipster RPCs".

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

#97

Post by Brakenshire »

pornel wrote: post #57

To me the worst side-effect of naively chasing "native" is permission prompts. The web platform wants to have powerful features that are dangerous and/or easy to abuse, but haven't found a good way to allow them safely. The "solution" we've settled for is to blame the user for clicking "OK" on permission prompts that have unclear consequences to non-technical users.

That's exactly the same as iOS native permissions, isn't it?

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

#98

Post by jasode »

pjmlp wrote: post #87
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…

> ... TCPIP, DNS routing.. Also known as Ethernet protocols, nothing to do with "The Web".

I thought I was clear that I'm not using the traditional definition of "web" but to explain what "the web" has become.

It's about the evolution of how society sees the web and not about what its original purpose is.

Dropbox uses html and http. Drew Houston and his team are not going to submit an RFC so that the internet has a new protocol and port "dropbox://myaddressoffiles:8675". No, Dropbox the application will just use "http://". It's because they did not pursue conceptual purity of having "dropbox://" that allowed everyone inside and outside of corporate networks to use the service and share files.

That is "the web" we have today and in that scenario, the non-technical use of "web" includes the underlying internet stack to make web apps possible.

What's the alternative? Tell millions of Dropbox users that such a service is outlawed because "the web is best as a document platform?"

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

#99

Post by pjmlp »

moonchrome wrote: post #74
72deluxe wrote: post #13

Earlier quoted context omitted.

Developing for native does not always take twice as long. I would write a desktop C++ app faster than attempting to write a web app and wrap it in desktop runtime capability. If you're not used to writing desktops apps, yes it will take longer.

I recently needed to build an internal GUI app - after seeing how much time it will take me to get a HTML client/server set up I looked around for a GUI framework in Python and I was thrilled when I found : https://python-gtk-3-tutorial.readthedocs.org/en/latest/ With Glade + Python 3 I was chucking out GUI code faster than the Visual Studio + Win Forms because there was no compile step. No over engineered MVVM ala C…

Pretty much this.

Anyone that has ever used RAD tooling for GUI applications can easily see how the HTML/CSS/JavaScript combo tooling is still miles behind from a 90's desktop developer experience.

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

#100

Post by felipeerias »

nkuttler wrote: post #49
mozumder wrote: post #19

The web works best as a document platform. All the UI tricks that web developers work on all end up managing something related to just browsing/reading a document. It's amazing that modern browsers/HTML just don't have this basic user experience down. Why is it virtually impossible to read long articles on a web browser? After 25 years, why do web designers need to create their own page transition mechanics for long-…

> After 25 years, why do web designers need to create their own page transition mechanics for long-form articles Why do you need page transitions for articles at all? The only reason I can think of is for more ad displays. Ok, if you have, say, a long manual with multiple chapters that would be several hundred pages when printed it can be nice to break it up, but that's probably not what you meant. > photo galleries…

Have you tried to disable pagination in reading apps like iBooks or Instapaper?

Long articles and books are more comfortable to read if they are paginated: one small tap, one pageful of new stuff. Far more convenient and less prone to losing your place than scrolling.

Post reply on HN