The author's argument that news sites should go native and (presumably) forgo web ignores the fact that the web is highly shareable and discoverable, where native apps are a walled garden. Ignoring news sites' need to generate revenue for a moment, the ability for a user to search the web for a particular topic and discover a relevant news article from three years ago is a built-in advantage for the web. You can't duplicate that on a native app.
Web vs. native: let’s concede defeat
191–200 of 515 posts
Re: Web vs. native: let’s concede defeat
#192We already did concede and invented asm.js. Unreal Engine runs in my browser.
Re: Web vs. native: let’s concede defeat
#193Earlier quoted context omitted.
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.
> It also benefits hugely from urls, which allow users to share what they've found. how about http://some.storage.service.tld/path/to/video.mkv or even rtmp://some.streaming.service.tld/path/to/stream ? For sharing that would be sufficient. Of course there are some business realities (ads, copyright, paying for storage) that make direct, free access to videos unlikely. But that's basically arguing that the web is a s…
That's certainly not what I want to share. One of the things that good video sites provide is context. E.g.: Who made this? What else have they done? How can I find them? Has this been widely seen? What do people say about it?
Raw streaming urls don't get me any of that. URLs aren't just pointers to bytestreams. From a user sharing perspective, they're humans pointing to a unique thing. And what they're pointing to is often much more complex than a single raw file.
Re: Web vs. native: let’s concede defeat
#194Earlier 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…
I don't see how willfully blending these two things is helpful for anyone.
In this context, it can be safe to assume that everyone knows this technical distinction (even for those of us who are not web programmers). In other contexts with less computer-technical people, I don't think being annoying and correcting every "technically incorrect" mention of "The Internet" when they mean The Web is helpful. But I think it is helpful to remind them of the distinction if you are actually talking about the subject (as opposed to just saying things like "look at your internet, I just sent you a facebook message"). Computers are magical enough as it is; it doesn't help anyone to make it even more so when they are even slightly interested in discussing some part of computing or IT.
Explaining that The Internet is the infrastructure and the Web is just one the things that uses this infrastructure seems simple enough to grasp, and isn't an oversimplification at all. People understand that the electricity grid has to exist in order for them to make toast.
Re: Web vs. native: let’s concede defeat
#195Earlier quoted context omitted.
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.
> It also benefits hugely from urls, which allow users to share what they've found. how about http://some.storage.service.tld/path/to/video.mkv or even rtmp://some.streaming.service.tld/path/to/stream ? For sharing that would be sufficient. Of course there are some business realities (ads, copyright, paying for storage) that make direct, free access to videos unlikely. But that's basically arguing that the web is a s…
The business realities make direct, free, downloadable videos impossible rather than unlikely at scale.
Re: Web vs. native: let’s concede defeat
#196Html is for documents served thru http. What we need is a language to build apps natively and serve them securely thru the browser using an app:// protocol. Working with html to build apps is a nightmare. Google, Apple and Mozilla should take the best from android and ios and work on something universal and truly disrupting. No, not java. No, not obj-c. Perhaps swift, go, nim or something better. Remember the hobbyis…
Forgot to add. Let's use an emulator and not a browser to serve apps thru the app:// protocol. We don't need bookmarks, toolbars, addressbars, etc. We just need a surface and an app store, just like a mobil os, with the triangle, square and circle as universal UI for navigation.
Best of both worlds.
Re: Web vs. native: let’s concede defeat
#197Earlier quoted context omitted.
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.
Huh I also have a "developer" mind, and very few people would call me a designer, and those that do should re-think what a designer is.
However, from my observations over the years, the cost of "browser specific" behaviors is equal to or less than the cost of learning entirely new styling paradigms every time someone puts out a new UI framework. CSS also has the benefit that over time browser specific behaviors fade away as standards take shape, which is inherently not the case with UI frameworks.
As far as the namespace goes - I guess, but there is nothing to stop you from coming up with your own namespacing scheme using nested CSS classes.
Re: Web vs. native: let’s concede defeat
#198What about the benefit that the web brings to updating the user's install? I know that it is technically possible to push a new Java or .NET app out to users. I've done it. The one thing it requires is a lot of coordination. Notify the users to keep their equipment on the network from time X to Y. Notify the infrastructure team to schedule a push. Have the dev team on standby in case the push goes bad. Have the softw…
> What about the benefit that the web brings to updating the user's install
What about the detriment the web brings to having apps that work offline reliably and ensure control over their own data?
> Notify the users to keep their equipment on the network from time X to Y
Not your problem. Have your packaged app in the place its expected to be updated from (a HTTPS server for something like Sparkle framework, and/or the respective App stores).
The client will periodically check for updates and download the new version.
If your back-end functionality somehow changes in a way that breaks the old version (or something changes such that the old version cannot be allowed to operate, such as a law changing) - you simply use a versioned API in your backend, and respond to requests to the old version of the API, with an error message telling user an update is required.
> Your app is not the product. Your app is tool to get the product: information
That makes a huge assumption about the purpose of the app. If the app in question is a game, or an image editor, or a word processor or any number of other types of app - the app very much is the product.
> If it lacks UX for native, don't target native. Target app-y
And say goodbye to customers. People like the experience of a real native app.
Re: Web vs. native: let’s concede defeat
#199I 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 read that Appcelerator Titanium and NativeScript are a much better way. You can use much of your JavaScript skills and still get to go native.
Unless that platform has changed completely in the last year or so then they are wrong. Appcelerator (and things like it) generally make "Hello World" super easy and even the first week or two will be awesome. Then the cracks will start to show. You will add a listener on a button and the app starts crashing with a cryptic error, you start having to litter your code with `if(isAndroid)`/`if(isIOS)`, or for some reason a view will be really show to render to lag between clicking and doing something. When you get down to it you'd be better off learning native or just accepting a mobile website instead. Normally (IMHO) the only apps worth using appcelerator for are simple websites and at that point you'd be better off just doing a mobile website.
I'm excited to play with React Native but I fear it will suffer from the same issues.
Re: Web vs. native: let’s concede defeat
#200There are several reasons mobile devices made it so that Web runtime and Web apps would not be the consensus app environment:
1. Web apps are no longer the answer to breaking Windows hegemony on apps.
2. The Web is a mouse UI. That may seem like a small thing, but look at how much trouble Microsoft has had turning Windows into a touch UI.
3. Mobile devices are the end of overlapping windows. The Desktop Metaphor was a cute idea, but it isn't appropriate for mobile devices. Web browsers, and Web apps, are made for resizeable windows.
4. The Web is great for simple interaction with dynamic content. Which is another way of saying "The Web is a big, linked, interactive e-reader." You can stretch it to try to do other things, but it isn't a comfortable stretch.
5. Pure canvas apps... ... ...
6. No one development idiom. Nor two. Nor five. This is much less of a consensus than Android or iOS. IOS developers will be making a language transition, and Android developers will probably incorporate a dependency injection idiom into nearly all Android coding once a consensus is reached on what flavor of DI is favored, but that's about it for uncertainty.