Since the date of Java shutdown in Chrome is approaching, I would like to write a review of Java uploader vs. its HTML5 counterpart. What features you will lose if you switch from Java to HTML5? Are they critical? Let's try to figure out.
I am going to exclude ActiveX and Flash uploaders from this review. ActiveX has almost the same features as Java while it is limited by IE. Flash is the yesterday's news, likewise Java.
All your users will notice this difference - HTML5 uploader cannot have that "File Explorer-like" user interface with the "tree" and "folder" views. Now they can add files using only Open file dialog (this mode is known for Java uploader owners a "one pane layout").
This limitation could be serious several years ago, however the modern user experience is more or less tolerate to an Open file dialog. So, it is not worth worrying about it, but take into consideration that if you have any instructions for your users, you may need to rework them.
The ability to upload not just files but also folders along with its file structure always was a great trump card of Java uploader. Unfortunately HTML5 specification still does not allow implementing this feature in all browsers, however in a happy coincidence Google added a non-standard HTML5 extensions to Chrome which allows opening a folder open dialog.
We haven't added this feature to the uploader yet, however it will appear in the nearest release of Upload Suite (presumable, right after Christmas holidays).
So if the folder upload is a critical feature, we recommend to use both HTML5 and Java uploader together depending on a browser.
Uploading a large amount of photos should be done carefully
In the past, HTML5 uploader suffered from memory inefficiency when a number of files exceeded few dozens. However in 2014 we did a good job improving the memory friendliness. Now you can upload several hundreds of files along with generation of any number of resized copies.
If you need uploading more files (e.g. several thousand), you should turn off not only resized copies but also previews and auto rotation and use it to upload original images only. If you need any resized copies, you should create them on the server. If you are an ASP.NET guy, it is highly recommended to take a look at Graphics Mill - it is really good for this kind of task.
Uploading very large files in chunks
This great feature allows Java uploader sending really huge files (gigabytes or even tens of gigabytes). Unfortunately, HTML5 uploader cannot do it yet. This feature is in our priority list, however we did not have a chance to create a proof of concept yet.
So if this feature is important, I afraid all I can suggest is to offer your users switching a browser to, say, Firefox or IE (or Safari for Mac users).
HTML5 uploader still uploads files sequentially, one by one. Although an ability to upload several files simultaneously is very important to speed up the upload process, it is not so critical as users still can upload files. However we will surely add it sooner or later.
Uploading directly to Amazon S3
Unfortunately this feature is not available in HTML5 uploader yet and Java uploader is still the only option. So you should either use your server as a proxy or switch your users to Firefox or other browser. The priority of this feature will depend on your feedback.
No ability to create a custom upload list
In Java uploader, you could create a custom upload list, e.g. to provide several fields for each file (like in our Multiple Description or Photo Order demo applications). HTML5 uploader was not built with these features in mind, so we won't add these features in the nearest future. We have some ideas about a new API which will make it possible, but they are more global than just a product update and deserve a separate blog post.
Anyway, if it is a show-stopper, please let us know and we will see what we can do about it.
For most of the users the "photo" or "image" is an equivalent to "JPEG file". HTML5 uploader can process JPEG files before the upload - e.g. create thumbnails or generate resized copies. However if your users prefer other image formats like, say, TIFF, they won't be able to do that. Unlike Java uploader, which could recognize it as an image, for HTML5 uploader any TIFF file is a meaningless heap of a binary data. It can just upload the original file only without creating any resized copies.
Unfortunately there is no workaround unless the browser vendors add an ability to read TIFF files as images. If you need the uploader to convert TIFF files to JPEGs, you have to force users to switch a browser.
* * *
If none of these things are critical, migrating to HTML5 uploader should not be a problem for you. Moreover, you will receive some additional benefits:
No headache with Java updates and certificates.
Uploader will show up faster.
Support of mobile devices and tablets (iOS, Android, Windows Phone).