This question has been asked and answered here and here. However, both threads are 18+ months old and things are evolving rapidly in the javascript world. So I'm asking again to get an up to date answer.
For our use we need a single background thread that will be running pretty regularly. It's for a rich editor and whenever the user edits, this background thread needs to recalculate the layout of the rich text.
It looks like Web Workers are the best approach. However, according to wikipedia "It is removed in newer Android browser versions".
Questions:
Are Web Workers the best approach or is there something better.
Are there browsers that are not going to support Web Workers going forward? And if so, which ones?
Is there a list of what version of the main browsers are required for Web Workers?
I would recommend WebWorkers as your first option.
True, they were removed from Android in 2.2, but were also re-added in 4.4 and are now supported by the latest version of all major platforms. See http://caniuse.com/webworkers to see in which version WebWorkers are available.
For browsers without support for WebWorkers I would recommend a fallback with postMessage() or setTimeout(), as detailed in Javascript - how to avoid blocking the browser while doing heavy work?
Related
Is there any way to recognise pen pressure using javascript.
Preferably I don't want to make any use of Flash and try get this done as pure JS.
EDIT: okay I realised that it is kind of possible for Wacom tablets as they come with software that can work with their javascript api to make it possible (demos). But it's no good for people with Trust tablets or any other brand... So no good really.
Any body know how to do it in C# if not JS?
Yes - if the user has a Wacom tablet installed, then their browser will have a plugin for it that you can access. http://www.wacomeng.com/web/index.html
edit from author: I wrote this a very long time ago. Please see the comments below
Microsoft implemented something called Pointer Events in IE 11. It allows you to access pressure property along with stuff like pen tilt and size of contact geometry.
So far it only works on IE11 (and IE10 with vendor prefixes) but there is a W3C candidate recommendation so maybe it will be standard in future.
Javascript as a programming language in itself has no more ability or lack of ability to read this kind of data than any other language.
The language isn't important. What is important are the APIs available to you from within the language.
Javascript can be run in a number of different environments, some of which may possibly have access to APIs for this kind of hardware. However most Javascript is run in a web browser environment, and this is clearly what you mean.
The web browser environment provides a number of APIs. The most obvious is the DOM, which gives you the ability to manipulate the page, etc. There are other APIs available in the browser as well though. For example, the Geolocation API.
All these are standard APIs which have been defined by the W3C (or in some cases are in the process of being defined by the W3C), meaning that all browsers that support them should make them work the same way.
Unfortunately for you there isn't a standard API for working with pressure pads, so the direct answer to your question is no, it can't be done.
Whether one will become available in the future remains to be seen, but I have my doubts.
There is one way that you can do it though: ActiveX.
ActiveX is an API provided by Microsoft in older versions of IE. It basically provides a way of accessing virtually any Windows DLL code from within the browser.
Since the pressure pen device driver for Windows will be provided as a DLL, this means you should theoretically be able to access it in the browser via an ActiveX control. So therefore yes, you would be able to program it using Javascript.
The bad news, though, is that this is not something I'd recommend. ActiveX as a browser-based technology has long since been abandoned, due to the massive security holes it caused. I don't think the latest versions of IE even support it (I hope not, anyway), which means you'd be forced to use old versions of IE (and only IE - no other browser ever supported it) in order to run your code. Not ideal.
No, that's not possible. Probably not even with Flash.
You can only do so in an Native app. Javascript does not have access to pen pressure information
as I am getting more and more into Android PhoneGap app development, I can see more and more nuances and little details between built-in Android browsers throughout the versions. I searched for some official or fan document, which would deal with these browser version differences. But I can't find anything useful.
It's a lot frustrating, because you have to test everything on all versions of Android emulator and if app grows big, it's A LOT of work to test all the features in all versions.
Everyone is excited about HTML5, I was too, but only to the point when I moved to doing the real thing. I realized that there is so many problems when dealing with different versions of Android behaving sometimes a lot differently.
If anyone has some good resource to share, I would be very happy. Thanks
EDIT: Added example of different behaviour betweeen Android browser versions ( but there is many of them):
This works in Android browser in 1.6, 2.2, 2.3 and 2.3.3. But it failes (application crashes or stops JS execution) in Android 2.1:
Object.keys(var).length
You asked a pretty general question. The general purpose answer is that any sort of cross browser development (even cross versions of the same browser) requires that you develop a familiarity with what features are safe across the targeted browsers, which features are not safe across the targeted browsers and which ones must be used only with careful testing or feature detection with fallback.
While one wouldn't exactly expect the type of difference you saw with the one example you referenced, it is clear that that is a fairly new feature in ECMAScript and it's not consistently implemented across normal browsers so I would put it in the category where it is not safe to assume that it works on all versions of Android, even if you've seen it some versions of Android. That means to me that you should only use it if you've explicitly tested that it's reliable in all the browser versions you are targeting or devise a feature test and only use it when you know it's present and reliable or develop a safer work-around.
As I think has been mentioned previously, this thread has a bunch of proposed work-arounds for the specific issue you mentioned.
I am not aware of any detailed written material that would document in advance for you the details of the differences between different Android browser versions. Since it's open source, there are probably developer checkin notes and some level of release notes, but that will probably be like looking for a needle in a haystack and may not even contain what you want. It is rare for any developers to produce such detailed information. We don't generally get that level of detail from any of the existing desktop browsers or iOS browsers and, even if you were on the development team itself, you probably would only see part of this info. I don't think you're going to find official documentation that covers what you want.
You're going to have to learn to treat is as more of an unknown and learn what areas are "safe", what areas require extensive testing before using and what areas are just too risky. Even when doing that, you'll find Android bugs in some version that trip you up. That's just the nature of building on someone else's platform. At least the Android set of browsers are a much simpler target than trying to target all desktop browsers from IE6 to IE9, Firefox 3 to 5, Safari 3 to 5, Opera 9 to 11, Chrome 9 to 12, all Android, all iOS and use HTML5 when available which is what I'm working on.
Once you've been through this wringer a couple times, you will realize that if the newer language/library feature carries any risk, you shouldn't use it at all unless it's absolutely central to what you're trying to accomplish and then you will have to test the hell out of it. If it's something like getting the length of the associative array which is just a programmer's convenience, then it's probably simpler to stick with a work-around that is guaranteed to be safe and just not spend your time dealing with any browser-support risk.
The only official documentation I am aware of is part of the Android developer documentation. If I were a betting man, I would bet that it only covers a subset of what you are seeking.
The general idea behind cross browser Javascript is inline feature testing (at least how I've come to accept it.) I don't know exactly what "features" you are specifically looking for but it's generally wise to test for the existence of a feature set then use it and have a fallback if that doesn't exist. (Even if the fallback is, "This site requires a browser that supports 'foo'")
Since you didn't give any examples, I'll pick on Ajax. It's always best to check for the existence of window.XMLHttpRequest, then act upon it. Of course, this is not performant if you are doing it for every instance of need so you could write a check procedure or a wrapper to accept your list of necessity let your wrapper cache/call the appropriate methods to perform that task.
Without examples of "features" that you are talking about being different from browser to browser though, it's hard to give any concrete advice on direction.
I know a fair amount about the current javascript engines. What techniques have arisen in the intervening time? Please provide links to freely available information.
edit:
To clarify, I'm looking for new techniques that are being implemented or have recently been thought up for improving javascript execution speed.
I think most of your question is answered here: What optimizations do modern JavaScript engines perform?
Here are some references that came from the top of my head:
V8
Webkit
Spidermonkey
Gecko
accelerated compositing in Chrome
Native Client
WebGL
installable web apps
crankshaft
Please notice that at this moment (in the modern browsers) javascript isn't the bottleneck anymore in execution speed of the page. now that that problem is solved a lot of the browser manufacturers are focusing more on other aspects in the process of bringing a page from the server to the user. For instance a lot of the graphically rich pages that are standard now would benefit from the power of modern GPU's. It is often overlooked but rendering a typical page now takes generally more time than executing its scripts.
Javascript virtual machines in the future will have a method JIT and a tracing JIT like firefox 4 and JägerMonkey/TraceMonkey.
They use the GPU.
General details can be found at wikipedia.org and more detail at the Sun microsystems website and its links to associated sites. Some techniques now in use with recent versions of IE and Firefox and other browsers are forms of dualprocess or multiprocess operating in their own control structure to enhance performance specifically and for improving the general browsing experience. The use of javascript is decreasing in some nations and increasing in others as the relevant public internet server population changes over time. Only when the javascript parsing and interpreting code is rewritten in a faster language or some form of multiprocess is introduced to code on the servers or operating in the user's computer will the speed increase.
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.
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