301–310 of 322 posts
Earlier quoted context omitted.
I think the author is already addressing this: Yes, you can build 2007 websites much better now. They will be consistent across platforms and perform great. But my 12 year olds don’t want 2007 websites. They want 2016 apps.
What exactly differentiates a "2007 website" from a "2016 app"?
Earlier quoted context omitted.
What exactly differentiates a "2007 website" from a "2016 app"?
Google maps was way better then. A little less screen for viewing the map, but way more usable.
Earlier quoted context omitted.
I'm not sure exactly what you mean by each of these, but at least in Android apps can register to open URLs. So you can search for and share, say, a Facebook link. Tap it, and it opens in the Facebook app (or the browser, or any other app registered to handle the URL, your choice!).
I think these are the definitions that he/she goes by: Searchable: It being possible to find contents on the service via web search engines (Google, Bing, Yahoo!, DuckDuckGo etc.). Deep linkable: It being possible to link to specific content on the service (and not just to the service as a whole). Shareable: It being likely that your service as a whole is linked to. While you can share with someone that an app exists…
So, the question is, without a web presence or API of some type, how exactly is data expected to be searched and shared by third-party participants? If the argument is that apps don't solve the problem of having a universal ontology, then I think the GP is not quite understanding just how intractable a problem that has been in computer science for a very long time.
Earlier quoted context omitted.
So argument isn't so much that we should have binary HTML but we should actually just run Java* apps in a sandbox. I'd say there is merit to that argument and we'll probably get there the long way around. Perhaps webassembly will succeed where Java applets failed. * Or your virtual platform of choice.
Sandboxed apps are not really a good thing IMO. I agree that webassembly is a good thing too. BUT, my critic is about the DOM and the text-only approach, and also HTML not being strict enough so that all browsers can use it. It is the same compromise between having a compiled or an interpreted language. A compiled language will always be faster and smaller. If you put the burden on a HTML compiler instead of how the…
Interesting because isn't that sort of what you advocating for. Ultimately what's the difference between strict compiled binary executable "HTML" and something like a Java applet?
> BUT, my critic is about the DOM and the text-only approach, and also HTML not being strict enough so that all browsers can use it.
But really the problem isn't the syntax of HTML/CSS/JS but the semantics. Everybody can parse this stuff pretty much equivalently now but they still do different things with it. I don't see how compiling to binary would change that.
Earlier quoted context omitted.
I don't understand why people think this is a huge friction point. Installing apps is comfortable, familiar, and easy for people. By comparison, finding a mobile web application in the browser on a phone has significantly more friction.
Because when you're browsing the web on your phone and you come to a page and you get a giant banner that says "HEY INSTALL OUR APP" what do you do? If you're 90% of the world, you hit the close button on that banner.
I can totally relate to some of this. If you take a look at Meeker's 2016 Internet trends report that came out last week, you will see that 3 apps dominate 80% of the usage on phones. I decided when I started my food side project a year back, that I was not going to do a native app. I have been trying to make the front end look better, but I did not want to use very heavy frameworks, so I settled on using the SASS mi…
I don't really see how user time-share is relevant unless your goal is to start a social network/messaging system. 80% of user time is spent in those 3 apps, that doesn't preclude very profitable apps from being developed. After all, people spend 16+ hours a day at home/work, but there are still plenty of reasons to open restaurants. Unless you profit directly from time-spent-in-app this doesn't seem like a consequen…
But I think user adoption is just that much easier if all they have to do is open up your mobile web app in their phones browser. You could always build the app later after you have gotten the traction and growth.
Earlier quoted context omitted.
And not being searchable or deep linkable or shareable.
I'm not sure exactly what you mean by each of these, but at least in Android apps can register to open URLs. So you can search for and share, say, a Facebook link. Tap it, and it opens in the Facebook app (or the browser, or any other app registered to handle the URL, your choice!).
Earlier quoted context omitted.
Can't a UI be designed such that minor fontsize differences aren't a disaster?
Yes. But the article paints the picture that these weren't minor font size differences.
They're doing something funky. They can call it a "2016 website" but the problems described in the article don't really make sense to me as anything but design-related. Now, I know that you can't design your way out of every problem, but if they're going to use IE6 as a hellmouth and not IE8, they may be using a greater number of bad practices than necessary.
Earlier quoted context omitted.
Stuff like Cordova and Phonegap almost universally produce crappy apps. Doubly so if the person doesn't think they need to style the app for the individual platform, instead of just shipping the default (usually iOS) styling. Shipping an app with one of those is almost universally saying, "I don't care about user experience, I just want to shovel something out the door as cheaply and quickly as possible."
> Stuff like Cordova and Phonegap almost universally produce crappy apps. Again, don't blame the tool. Blame the bad usage of the tool. You're just saying: "Let's ban knives, assassins use them to do bad stuff!" > [...] style the app for the individual platforms [...] Ionic does this for you automatically. Surprise! http://ionicframework.com/docs/v2/components/ It's easier to complain about the tools than acknowledge…