That's a line graph, there are other types :PQuote:
Originally Posted by Enforcer
Printable View
That's a line graph, there are other types :PQuote:
Originally Posted by Enforcer
Someone starts trolling about app stores, and the best argument you guys can have is whether something's a graph?
You're both right. Enforcer is pretending he's a mathematician and interpreting "graph" in the strictest sense he can. Tripzero is demonstrating the populous "If excel can draw it, it's a graph" opinion.
Gary (-;
Quote:
Originally Posted by chunkyks
Nothing like deviation. ;)
Actually, you are not too far off... about me trolling.Quote:
Originally Posted by chunkyks
Just look at the CPU and resource usage of running google wave in a browser.....good luck trying to run more complex applications!!
Back on topic!
So, let's admit that yes, Google may be trying to make opinion real simply by asserting it, but let's also remove two limitations and see whether we think they're full of it or not.
1. Assume that bandwidth, whether cable/fiber or mobile is effectively unlimited. That is, bandwidth is not an issue.
2. Assume that he was not talking about today's computers running the apps of tomorrow but instead is depending on computers becoming ever faster for the same price for the forseeable future.
The hypothesis is, then, "IF bandwidth and processor speed are not limitations, THEN the future of computing is primarily browser based."
Disagree? Agree? Discuss.
And what does this mean for all the automotive applications? Should mp3Car encourage developers here to develop applications and front ends that are browser based?
Or are we just going to have general web apps and some how if you are in the car driving, the web app will change so that it meets safety and distraction standards set for the vehicle environment.
Now that the autoappmart.com is on the path to pulling together all of the apps the community has built in the past. What do we do about the future?
Quote:
Originally Posted by Bugbyte
HTML5 is promissing... but it's not completely implemented yet. And IIRC, google is still trying to add stuff to the standard.
The advantage of having browswer-based apps is that they run everywhere (provided the browser supports it). No rebuilding to run on MeeGo or Android or iOS. You build it once and you stop caring about what OS or what device its running on.
The disadvantage is that web development is still not as elegant as developing a C++ or C# or even Java application for many developers (myself included).
Also noteworthy, is that there are W3C standards being developed to allow browsers and web apps to get information from hardware such as geo coordinates from the GPS, etc.
Heather brings up an interesting point. One trend I see is web-runtime engines like adobe air and that which runs on WebOS which runs web apps hosted on the system (not from the cloud). This is nearly the same idea except it bypasses the bandwidth issue because everything about the app is still local.
Interesting you compare it to developing for C#....which is also write once run everywhere. This a a HUGE point that shouldn't be overlooked. Developing browser based apps is far more time consuming and complex then developing traditional applications (aka more expensive for a company to produce a web app then a traditional application).Quote:
Originally Posted by tripzero
Now to bugbytes clarification I am going to have to disagree. CPU usage is not something you can just overlook. Even if 3 years from now todays browser based applications run smoothly...the desktop application equivalent will still be able to do 10x as much with that CPU power.
C#/Java are close, but mono doesn't run on any of the major mobile OS's right now (monotouch excepted). There's also that big thing going around that mono is evil, which I totally disagree with.Quote:
Originally Posted by justchat_1
I'd love to see C# bindings for the meegotouch framework... but that's another topic.