Live data from Hacker News

Web vs. native: let’s concede defeat

quirksmode.org

121–130 of 515 posts

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

#121
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 are in essence becoming an abstraction layer between OS and applications.

Terrible ones at that. In native applications you can bypass abstraction layers when you need it. In a browser you are restricted to a almost comically crippled version of what any native APIs provide.

Look at the API. It's fairly modern, and yet I can't even turn off premultiplied colors, which I would need for doing even semi-decent image processing.

server sockets? udp? no dice.

even the most primitive file management? with the file API i can open individal files now. But can I grant a website access to some cordoned-off subtree of the filesystem? No. Which in turn gives rise to "store everything in the cloud" mentality, because there are no alternatives.

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

#122

But what should the author explain to Chromebook users? They can only have web applications on their desktop as an icon. Actually I think they're doing pretty good with that.

I never saw anyone with one in Germany, besides computer stores trying to get rid of them with massive discounts and still they gather dust.

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

#123
post #88

Earlier quoted context omitted.

"With all that, the last 20% of a Cordova app may well take 80% of development time, and that's rarely been budgeted in." To be fair, that could be said about most software projects. "80% done, now the last 80% remains." Not that I disagree with you, I had the same experience trying to make an Android app in Phonegap. It's lacking, like most cross-platform frameworks (for most types of apps, but typically not games)…

To be fair, that could be said about most software projects. Yes, absolutely true. The difference here is between "known unknowns" and "unknown unknowns", to paraphrase a certain renowned military strategist... With Cordova/PhoneGap, it's easy to get the initial impression that you're dealing with "known unknowns", just the typical web development project pitfalls -- "This is HTML, I know this stuff". When the "unkno…

I agree with that. With an abstraction layer on top of a native layer, inevitably you have to go below the surface unless you fit the intended use case perfectly. I learned this lesson with the Objective C-Python bridge. Spent needless time mapping differences between the two to the point where I had to learn Objective C anyway.

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

#124
post #85
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…

I think media playback is only part of the core functionality. The other key piece is discoverability, and on that front, YouTube is far, far better than a native media player. It also benefits hugely from urls, which allow users to share what they've found. So, arguably, YouTube's success is more about what the web does well than about it's media playback -- it just has to be "good enough" on that front.

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

#125
post #85

Earlier quoted context omitted.

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

> Maybe sometimes it would be better to provide better integration with native applications? That's it exactly. The author claims it's an unsolved problem, I think it's the inevitable solution (that web and native will merge).

You can always use custom protocols much like mailto: e.g. a link with sms: can send a text message from a mobile web browser.

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

#126
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/

> A little less contrast

> Size Matters

Strong disagree on both of these points. I view most webpages (including that one) at around 66% zoom these days, because the text is so goddamn big. And anyone advocating for less contrast needs a shovel to the head.

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

#127
post #84
post #23

> Is it the web’s purpose to emulate native by inserting yet more features? Certainly not. In my opinion, the problem with the web is that it has become too complicated. In an effort to make the web simpler for the ordinary user, the web has actually become a more complicated place for the (advanced) developer. HTML, CSS and javascript have grown so complicated that they lack certain desirable properties, such as ver…

Lack of support for shared state is no disadvantage! When you write multithreaded programs in a language such as C++ or C#, you try to impose on yourself the same restriction, in the interests of making your life easier... (I haven't used web workers, so maybe they're in fact awful to use. But from what I've read, it looks like the right decisions were made, pretty much.)

Why be so protective? Perhaps somebody invents some programming tool that makes it easy to reason about shared state. This is exactly the kind of mind-set that makes it difficult to develop for the web.

Also, shared immutable state is a useful (often perhaps even essential) property for building efficient code in a multithreaded environment, even when using the message-passing style.

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

#128
post #107

Earlier quoted context omitted.

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

They make more sense to my developer mind without designer background, don't suffer from CSS global namespace, inheritance side effects and browser specific behaviors.

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

#129
post #118
post #92

Earlier quoted context omitted.

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

> Instead, I'm pointing out that the world out there without permission from any savvy HN readers has moved on.

The world has not moved on. Part of the world has dug itself into a technological hole. Most of the people who work in it have never seen what's outside it, so they think the solution to all their problems is to keep digging.

Edit: crap, I sounded so snarky and aggressive. Sorry about that. It's not something personal -- I obviously got the point that you don't think everything about that is a good idea.

The point I'm trying to make is that not ever technological move is necessarily a "good" evolution. Every narrow street in technology was once thought to be a superhighway that everyone flocked to.

I remember everyone being so bloody enthusiastic about this whole Web 2.0 thing back then (and I was one of them). Then all this data crumbled as people paid less and less attention to information structure and semantics and focused on the flashy stuff. Then it turned out a lot of problems were intractable if you clung tightly to JS, CSS and the web browser.

Yet for some reason, people thought those problems happen just because we don't cling tightly enough to JS, CSS and web browsers.

Oh -- and twenty years after operating systems that aren't full of memory leaks, security problems (eh...) and performance clunks became reasonably accessible to people everywhere, people are trying to promote ditching those for web browsers. Which, I would estimate, will need another twenty years or so to stop having memory leaks, dubious security and privacy practices, and embarrassing performance clunks.

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

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

> Something based on Cordova (eg PhoneGap, Ionic) with Crosswalk can get you to about 90% of the performance of a native app

Companies like Famo.us have proven this is incorrect mathematically over 2 years ago. That is precisely why Famo.us built its own rendering engine that subverts the DOM and renderings content similar to a gaming engine (Unreal Engine). The DOM can't render as many surfaces as a native app in one view smoothly.

You can still make a very performant cross platform DOM based application (http://hn.premii.com is an excellent example), but in order to get that performance you need to limit your interface to very basic UI elements.

Post reply on HN