There's been a lot of talk about Google being forced to go with UIWebView for Chrome for iOS, and Facebook ditching HTML5 entirely for their iOS apps because UIWebView was too slow. I'll soon be needing to port an HTML5 application that requires lots of intensive Javascript computations (too much code to rewrite natively given my time constraints) but none of the display functionality that a browser provides (i.e. it works fine headlessly on Node.js). I've never heard of anyone trying to embed Google's V8 into an iOS app, but given that MobiRuby does practically the same thing (linking in the mruby interpreter), would it be permissible to do something similar, linking in Google's V8 interpreter within the same process? As long as code isn't downloaded, and processes aren't forked, it doesn't seem to be against the rules, but has anyone ever tried this?
EDIT: I'm aware of PhoneGap/Cordova and similar technologies, but they all work with a full UIWebView, and due to Apple's paranoia, UIWebView cannot JIT-compile Javascript code (which, as I said, is essential for my application).
According to what is mentioned in this this thread on the v8-dev mailing list, it may now be possible. You may be interested in the state of the work on this issue.
Related
I am thinking of building an application, kind of like TiddlyWiki in the sense that everything is self-contained in an HTML file, or at least in a bundle where a user won't have to install anything. It works on just about any browser, and on mobile phones (Android and iPhone), and in some browsers (e.g. Firefox), manages to save to the local filesystem without a plugin (albeit, it launches many security warnings, but there are other solutions for that). Other browsers happen to use a Java plugin to bypass this restriction.
Are there any technologies that exist that make this possible? HTML5's web storage sounds like it would be almost perfect, except that the data would be tied to the browser.
Any assistance would be appreciated (even if that just means editting / retagging the question to get more folks looking).
Whats about the fileapi: http://caniuse.com/#search=fileapi
I am just adding a relevant comment with this but not exactly an answer...
When you are saying that you want to develop application which contains everything... Then I would like to add about Titanium, PhoneGap, and others (Corona)...
This softwares provides JavaScript base which will be running on all the mobiles (if mobile applications), desktops (if desktop applications) and so on.... But Titanium (as i am working on it) works on the SDK of all the other languages for development...
Now TiddlyWiki, what i have understood from the link is that it is creating a web application or something like that which will work on all the other mobile devices. But this is NOT Good always, Since some application needs to be a NATIVE environment (which is supported by Titanium). Native applications will be much more faster than any other developed applications..
I need to implement a paint type program that will run on all major browsers as well as can be packaged as an app on the iPad/iPhone. After some investigation I have learned the following facts (correct me if any are wrong):
Javascript is entirely too slow to handle an app of this type by itself
HTML5 seems like a good solution, it has a canvas tag and everything and can easily be packaged into a UIWebView for a Cocoa app. However, I need to be able to reach the majority market for web users, which unfortunately includes most IE users who aren't using the public beta for IE 9.
Flash vs. Apple
Right now I'm debating just making two completely separate apps, one in OpenGL ES for iPad/iPhone and another in something like Flash for web browsers. I was just wondering if anyone had an immediate solutions in mind to make one app instead?
I'd question the accuracy of your first point (Javascript is too slow). Since it's possible to run Quake II in pure Javascript, it's likely that your paint application is less resource-intensive and thus could also run. Of course, one could ask how much optimisation effort and/or experience is required to write performant Javascript of this standard - I can't give you an answer there.
But I'm certainly sure that it's possible to get enough performance out of Javascript to implement such a paint tool, in any modern browser. That doesn't preclude the other options, though; using JS along with HTML 5 sounds like the ideal solution here for "out of the box" cross-platform compatibility.
I'm developing an HTML / Javascript application meant to run on an Android device running Froyo (2.2). Assuming I don't need multitouch functionality, will the emulator's browser be a reliable means of debugging HTML, CSS and Javascript? Or is it possible that I would work out all the bugs in the emulator but find the actual device handles things differently?
The underlying code for WebKit is identical in the emulator and the actual device. The only thing you need to worry about are the other components inbetween (some carriers have proxies, for example. I used to have problems with T-Mobile where it would simply send me a outdated cached version of a site instead of even contacting the site).
I've been researching writing an app for iPhone. I really like the look of PhoneGap which basically allows you to contain a webpage in an app. My skills are primarially in HTML/Javascript so this tool allows me to make the most of my skills without having to spend many hours learning how to write an app natively for the iPhone.
I've been doing some tests on my iPhone for Javascript, and some seemingly simple examples run painfully slow. Really slow. This unfortunatly is a big problem for my task!
Any work arounds? If I want to do anything interesting am I going to have to write a 'proper' app?
An explanation on why Apple have seemingly created such a bad implementation of Javascript would be interesting as well (possibly to make more money? Less web apps = more apps in the store?)
References
http://ajaxian.com/archives/ipad-javascript-shockingly-slow
Javascript is not particularly slow, but the DOM is very slow.
I think it is the same as a desktop browser, but magnified.
I would check first all DOM manipulations, if they can't be optimized.
Another option, is to use a templating engine.The main DOM manipulations are done through innerHTML injection, which is fast even on mobiles.
We've built a mobile version of our web app, and we use PURE (an open source JS lib we created) to render the HTML from JSON data, and it is very responsive.
We went the HTML5 way(not native) but I think generating the HTML could be done the same way when wrapped in PhoneGap.
I don't think Apple has created any special implementation of Javascript for Mobile Safari. Probably it's the same as or very similar to the desktop Safari.
These devices are small and have strict power constraints, so the CPU is slow.
Apparently iOS won't do JIT compilation of JavaScript (unlike Android) due to a security feature: http://daringfireball.net/linked/2010/07/22/android-ios-js-benchmarks
Good point about DOM access being the issue though: I don't know how much these benchmarks test DOM operations.
#Rudiger: Just a thought - A lot of the improvements to desktop computer speed since "8 years ago" have been attained in part through the use of multiple processors. Javascript is single-threaded, and so presumably would not be able to take advantage of such multiple processors. Yes, I know that browsers can take advantage of it, and that putting the other stuff on the other processors can provide more CPU power to the Javascript thread, but I have an app that is mostly raw Javscript internal processing, where the main thing that is going on is search and array manipulation.
So, when comparing desktop power to mobile processor power, for my purposes, maybe the slowdown would not be so bad? I currently run at very acceptable speeds on Safari on a six-year-old notebook computer with a single processor. So I'm thinking that Safari on iPhone or iPad for me might not be that much worse. Do you think this is reasonable?
Actually, I think Apple has a vested interest in keeping javascript out of the Iphone as much as possible.. they seem to want to regulate things through their appstore by requiring applications that run natively.. I'm curious if javascript is also slow on Android phones, (I've never used one before).. if its not then I think it is a bit strange that the Iphone would be slow with javascript, at any rate, they are already losing market share and will have to address the issue at some point I am sure, I think people are catching on to Apple's games and idiocy in trying to micromanage everything now that more legitimate alternatives are coming out in the mobile device space.
Is JavaScript multithreading possible in IE6?
Are there any third party libraries for this?
JavaScript does not support native multithreading in current web browsers. Even if it did, I bet IE 6 wouldn't have supported it :)
Running your scripts in multiple iframes could be one workaround, as Jason Kester suggested in another answer.
In addition, for modern browsers you might be interested in checking out Web Workers, but this is definitely something out of the IE 6's league:
Stack Overflow: JavaScript and Threads
Dive into HTML 5: Web Workers
Firefox 3.5: Web Workers in action
John Resig: Computing with JavaScript Web Workers
Run your tasks in IFrames
Assuming you're talking about multitasking on the client side, you can open n frames on your page, each pointed to a page on your domain.
There are lots of ways to architect it from there. Probably the easiest would be to have a single .js include that you run from each frame. It phones home to parent.readyToGo() or whatever, and gets some work assigned. The worker methods can call something like parent.taskFinished() to report when they're done.
Most importantly, don't listen to anybody telling you not to run your mission critical multithreaded javascript application on IE6. I'm sure you have good reasons:)
There is no way - definitely not in IE6. You can fake it by using lots of window.setTimeout()s.
See Why doesn't JavaScript support multithreading?
Well, HTML5 is coming up with Web-Workers. But i highly doubt there is a library which creates a wrapper for using it in IE6.
Does my browser support web workers?
Google Gears is a plugin that works with IE6 and includes something called WorkerPools. Google Gears does not seem like it is being very actively developed anymore, because it has tried to move most of the ideas of Gears into HTML5. WorkerPools are basically background processes that do not share state and only communicate through messages. In HTML5 this has turned into WebWorkers. You can find more info here: http://code.google.com/apis/gears/api_workerpool.html
If you merely want to write synchronous code and thus avoid having to deal with writing event handlers all over the place, you can try: Strands