11–20 of 22 posts
I like this title better: Why Our Application Was An Excellent Use Case For Developing In HTML 5, YMMV
I must toss https://github.com/rogerwang/node-webkit/ into the mix. I have found it incredibly easy to develop with...and even easier to distribute.
HTML5/Javascript/CSS is native to Windows Metro (as is C++ and .NET)... so I don't know what is this headline about
I've done non-trivial projects in both HTML5 (with/without PhoneGap, with/without jQuery Mobile), Native (ObjC, WinMobile), and hybrid mix of HTML5/Native (views in HTML, model/controller in Native). I've heard all the pros and cons of both sides but most of them are either non-issues or wrong. ARGUMENT: Native is ALWAYS faster than HTML5 MY EXPERIENCE: So what? Speed depends on what you're trying to do and how. Anim…
My personal opinion based on my experience having written both native and html5 mobile apps is that the closest you can get to a "silver bullet" is a well thought out responsive HTML5 design packed in phonegap/cordova with native navigation elements. You get the benefit of snappy, native navigation while being able to go cross platform very easily with one code base.
The problem with HTML5 as an app interface isn't getting something to appear on the screen on any of the browsers, it's getting the user experience to match the native platform. A similar post in 1999 would have been titled: "Why native development sucks and Java Swing rocks: Porting to Mac OS 9"
HTML5/CSS/JavaScript are finally moving in the right direction.
However, what we should be doing is making the browser nothing more than an x64 VM. That way, all of the underlying OS calls could be wrapped in an OS-independent way, and for those that are specific to a particular platform, a generic way to access host-specific features.
Because each generic OS call maps into a real OS call, every call can undergo a security check. We can use ACLs or web-based authentication, or distributed authentication, etc. Or perhaps none at all for something like "give me the current date".
Each "app" (and, they would be real apps!) would run inside a separate VM. Communications to other parts of the system - for example, to another running app - would be done via messages (or some other method that could also be authenticated).
Now, some of the beauty of this scheme is that existing apps could run without modification on this platform because the VM would trap all the "real" OS calls and authenticate them, validate them, etc. As in unix, I/O would get mapped to arbitrary streams; for example, if the existing app was console-based and did printf() and scanf(), those would be mapped to the user's keyboard and output of the VM on the screen.
I wrote a much longer version of this and sent it to Alan Kay, but I must not have his "real" email, as I've gotten no reply. (Or maybe I'm nuts...)
What is astonishing to me is that if one of the "big guys" (Google, Yahoo, Microsoft, ???) were to build this "Web-Enabled Application Platform" (WEAP sigh...) [perhaps using Xen] it would TAKE OVER the entire OS market. The only "program" a user would run (at least what was visible to her) would be WEAP.
Years ago, this would have been a crazy idea. But today's machines are so fast that I believe we're finally ready to accept the need for better security and authentication, and, at the same time, accept a bit of a slowdown of our apps to trade for robustness and safety. Not to mention the side benefit of getting rid of HTMLx CSS and probably JavaScript !
I've never seen this idea written up anywhere else, so I hereby put this into the Public Domain.
This concept needs much more detail before doing a reference implementation, and I definitely haven't considered every corner case. But, given the exceedingly poor state of "the web" these days, something like this will (clearly!) eventually happen.
I like this title better: Why Our Application Was An Excellent Use Case For Developing In HTML 5, YMMV
Right. No real access to contacts, camera, files/database, accelerometer, GPS, etc. We tried in vain with application cache, offline storage, etc. but not seeing contacts/camera was a show-stopper. Even location isn't the same as native GPS because users get a warning on opening the HTML that usually scares them away.
http://msdn.microsoft.com/en-us/library/windows/apps/br21138...
I've done non-trivial projects in both HTML5 (with/without PhoneGap, with/without jQuery Mobile), Native (ObjC, WinMobile), and hybrid mix of HTML5/Native (views in HTML, model/controller in Native). I've heard all the pros and cons of both sides but most of them are either non-issues or wrong. ARGUMENT: Native is ALWAYS faster than HTML5 MY EXPERIENCE: So what? Speed depends on what you're trying to do and how. Anim…
1) speed - while not 100% fluid, with the latest phones this year and Android 4.1, rendering speed is easily kept within reasonable FPS (>40). On Android, even native apps aren't always fluid.
4) porting - This is true, however I think you underestimate both the power of HTML5 and the easiness of using PhoneGap or interfacing between native libraries and JavaScript on most platforms. Our prototype app isn't just a CRUD app - its a presentation maker with lots of GUI that needs to access to local files/images.
(Of course, in-app purchase and platform-specific libraries mean harder to port apps)
Earlier quoted context omitted.
Hell, looking at Safari, I see no reason why you couldn't put together an interface like this in HTML/CSS. To the grandparent's point about Java Swing, I don't have much experience with Swing, but I did see a little as I was entering college in 2003 and it objectively sucked. And that was 4 years after the hypothetical article title presented. I think the biggest thing hindering the HTML/CSS thing on certain occasion…
We'll see what happens to browser performance when most apps on the Win8 desktop are HTML/JS/CSS based and when typical displays have 300-400dpi... We'd probably get better performance if we resurrected NeWS.