Live data from Hacker News

Web vs. native: let’s concede defeat

quirksmode.org

71–80 of 515 posts

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

#71
post #53

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…

No, the web means web. Internet means internet.

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

#73
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…

Youtube is an interesting choice of example, since in a way it's "just documents" - those documents happen to be video, and are surrounded by hyperlinks to other video's pages. The real achievement here was cutting through the intellectual property thicket so that everyone could have an in-browser video player in HTML5.

The first site I ever saw that used Javascript to produce a useful application rather than annoying frippery was Google Maps.

(Rhetorical question: why does everyone use youtube rather than hosting videos on their own sites? Unpacking this question will show the obstacles that "redecentralisation" faces)

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

#74
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…

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#/WPF for a simple app - load a glade layout file, hook up callbacks - bam everything works together. The MVC is already there because the content pipeline (model) is already separated and views are defined in glade files. I had a prototype functional by the end of the day - it would take me that much just to choose which tools to use if I went Javascript client/Python server.

Seriously - couldn't believe how fast you could get stuff done with it - everything works as expected, you get all the controls you need - no need to learn random stuff like that qtscript, no build process (this is actually huge !), insanely fast iteration (faster than web-dev). I always thought of GTK like some obscure C gui lib but the Python wrapper makes it very usable.

My only complaint so far is that Glade seems to be getting progressively slower as you remove/add stuff so you need to restart it from time to time (eg. once per hour) but it starts instantly so it's not really an issue.

Note : I haven't yet tried to get it running on Windows or OSX since we all use Linux internally.

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

#75
post #6

> 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. But what if the browser is the OS? I agree with the point though that we shouldn't be trying to emulate native to the T with web applications, that we shouldn't be…

> I think the Google IO 2015 web app [1] is a good example of what can be done on the web right now with minimal overhead.

Recreating the glory days of whole-page Flash sites, or those old Macromedia multimedia CDs?

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

#76

Perhaps what we really should be thinking is that 90% of applications can, in theory, be made using either web standards, native or a mix of both. Unfortunately lots of websites and web apps are not very well developed. They serve bloated HTML that hasn't been minified, let alone compressed. The page is unresponsive or blank until a dozen JavaScript files have been loaded. Hardly anything is cached. jQuery is loaded…

> Sure, you can't write a great 60 fps first person shooter game for the web

you can, you know WebGL is hardware accelerated and there is Asm.js - even the Unreal game engine runs in Firefox and Chrome.

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

#77
post #59
post #47

Earlier quoted context omitted.

There's an answer to your questions. It is documented here: http://motherfuckingwebsite.com/

This is what you want => http://bettermotherfuckingwebsite.com/

Isn't that guy sorta missing the point of the first website?

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

#78
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. All the tooling we've created and all the progress of the open web platform that has made that site happen is incredible.

Flash DRM replaced with another closed source DRM. No progress whatsoever. And now it has embedded in the browser itself, greatly increasing its vulnerability.

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

#79
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. All the tooling we've created and all the progress of the open web platform that has made that site happen is incredible.

What exactly is incredible about YouTube today (apart from it being a huge repository of videos, of course)?

That it almost works like a 2000 era video player, only slower and clunkier? The new fangled DRM? That it can bring a decent computer to its knees with the fans blaring playing HD video? The automatic non-skippable ads?

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

#80

Earlier quoted context omitted.

> 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…

> 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. Actually yes this is the use-case I was referring to. HTML has semantics to define sections, headers, etc.. but it doesn't manage them in any way. If you write HTML that define sections, for example, it's no different than if you write HTM…

What is your opinion of the section-structured HTML documentation itself? http://www.w3.org/TR/html/ It's all neatly sectioned with anchor links and so on.
Post reply on HN