Live data from Hacker News

Web vs. native: let’s concede defeat

quirksmode.org

491–500 of 515 posts

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

#491

Earlier quoted context omitted.

When did having my own data stored in regular files become "strange"? If the data is tied to a browser, how do I back it up/save a copy of it? How do I persist it when the browsers local settings/cache are cleared (either by clearing or eg. when the OS is installed)?

When did having my own data stored in regular files become "strange"? I meant your wording was strange. I had to reread it several times to understand what you meant, and I think the parent poster also didn't understand what you meant. If the data is tied to a browser, how do I back it up/save a copy of it? In Firefox, back up your profile. How do I persist it when the browsers local settings/cache are cleared (eithe…

> In Firefox, back up your profile.

that's hardly the same as having a file i can copy and use anywhere.

> If you clear it intentionally then why should it persist?

In Safari at least, "local storage" is cleared when clearing other data like cookies etc. I would imagine that's not unique to Safari.

You also failed to cover the concept of "the OS is re-installed" or "a new device is purchased".

"Backup your firefox profile" is an unbelievably short-sighted suggestion - am I supposed to keep transporting a Firefox profile around forever? What if I want to use a different browser? What if I want to use my data on a device that doesn't expose the raw filesystem to the user, and thus I can't copy my profile to the correct location (assuming it was even binary compatible)?

I can't believe I have to explain the benefits of a regular file with data in it, to a directory containing a mix of browsing history, cookies, crash dumps, plugin information, and somewhere, an SQLite database containing my data.

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

#492

Earlier quoted context omitted.

Care to name the technology that allows a browser app to read/write file data to local storage that isn't inherently tied to the browser?

Why is it being tied to the browser a problem?

Because it's basically tied to that specific install of that specific browser on that specific device.

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

#493

Earlier quoted context omitted.

People had imagined and implemented that long back. They were called plugins. Thank god, media player plugins are dead.

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.

Actually this how things work, on Android/Firefox. I long tap a video and open in MX Player, for instance. Or open a magnet uri with put.io.

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

#494

Earlier quoted context omitted.

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

misses the point by a mile.

web and native will eventually merge to the point that for most intents and purposes the user can't distinguish between them. It'll never be perfect, but it'll be "good enough", that whether an app comes from the web or from the HD, the user won't really notice except perhaps in the initial startup time, and probably not even then (everyone expects to "install" an app).

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

#495

Earlier quoted context omitted.

When was the last time someone told you about an app idea and you had any vision of a Win32 (or WPF) app? What does a specific widget toolkit have to do with native applications in general? Sure, there are some legacy and niche apps that are native on desktop People still use office suites, raster and vector graphics editors, CAD, 3D modelers, meshing and texturing tools, media players, P2P clients, text editors, var…

You went on to list a bunch of niche app classes except for two: 1) Office suites --> Largely a legacy app suite... and web use is increasing for both Office and due to Google Apps. 2) Media Players -- Playing local media is done by native apps, but that is becoming an increasing niche scenario. I posit that Netflix, Pandora, and YouTube dominate other media players. The most important native app that most people use…

I think text editors should be included. I switched from Textmate to Atom and have not looked back. For everyday tasks I cant tell the difference performance wise.

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

#497
post #383

So the customer/users want a native app!? Fine, I'll just bundle the web app with Webkit (io.js) and they'll be happy, and I don't have to worry about the app breaking in new browser versions. Browser based applications are much easier to distribute and adds a security layer, so that you do not have to worry as much about trojan/viruses, compared to installing executables from cr4cksnh4cks.com The browser is the perf…

> And it also helps a bit that the API's are super easy to work with. Not in the least, you have to be comfortable in a half-dozen technologies at least to make a half-decent web application. You want performance, animations, etc then you better be an expert. And even then, your perfect container is a limited container. By comparison, building a native app is much simpler. The complication comes in with cross-platfor…

I disagree. I'm still a fairly new developer and I've tried developing both native and web apps. I found that there are thousands of great well documented frameworks that make developing web high performance web apps easy. Meteorjs for example took me about a weekend to learn, has a huge community with lots of prebuilt packages, and countless tutorials that make implementing smooth animation incredibly easy. Before Meteorjs I used Angularjs and found mostly the same thing. I'm sure it's similar with React or even just standalone Javascript Html and CSS3.

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

#498
post #165

Earlier quoted context omitted.

On the US market. Additionally how many of those laptops are actually running ChromeOS, instead of being replaced by a proper Linux distribution?

Ok, here's the UK market - http://www.amazon.co.uk/Best-Sellers-Computers-Accessories-L...

3rd place in Top 20. Still you haven't answered how many of those are effectively running ChromeOS.

Looking at Germany, which was was I mentioned on my post, the scenario doesn't look like that anyway.

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

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

I agree with PPK, but sorry to say this: you are just throwing garbage. > There's nothing more annoying to a mobile user than an "app" that takes 10 seconds to start up Try this on your mobile browser http://hn.premii.com/ Now download this. Android : https://play.google.com/store/apps/details?id=com.premii.hn Or iOS: https://itunes.apple.com/us/app/hacker-news-yc/id713733435 And play with it. Download top 5 native H…

Premii is a great example of spending a great deal of effort to fuck up basic native behaviour like scrolling. The inertia is completely wrong.

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

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

Yes and no. One thing that is more and more important is batterylife. The more layers involved, the more energy they suck.

That's kind of old world thinking, it's been bugging me. In traditional programming and processor architectures that statement would be true. But if it were true today then Google wouldn't have built the Dalvik and then ART layer into the OS. They'd be compiling them on the developers PC and you'd end up with a fully static App.

The VM approach allows the VM to synchronise application wake-ups which can increase battery life.

Google chrome on Android is acting much like a VM to developers and I'm willing to bet the Android Chrome team are spending a much time as the Java runtime team are on optimising.

Post reply on HN