Related
(I have a problem with Google Chrome improvements that will drop support for my current solutions.)
I work on project where I move desktop system to an Intranet web application.
The crucial requirements are:
to move desktop system to a web application
to reproduce every single functionality from the desktop system in the webapp
While 95% of work requires creating casual web application, there is one thing which is non-standard to handle: my application must perform some actions on the client computer. These includes:
connecting with libraries
launching desktop apps
file manipulation in background
The example scenario is to integrate my system with some machine in the lab. I have to integrate my web application with drivers on client computer via DLL (desktop app did this, so my app have to do this as well).
Theoretically scenarios of the desktop actions may vary and I just want to implement some interface that will handle all the "client-machine" job the desktop app has done, so there is no need to work on every single scenario (but of course every scenario should be tested).
My solution was Java Applet. It worked. But then Google Chrome decided to drop support for NPAPI plugins, so in September'15 Java plugin (and my applet) won't be supported (http://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html).
So my another solution is Java Web Start. It works. But now Google Chrome decided to drop support for background operations of external protocols (https://code.google.com/p/chromium/issues/detail?id=348640), so from Google Chrome 45 my Java Web Start solution won't be supported.
(Both above solutions work on Firefox and IE.)
The question:
What other technology can I use to interact with a client machine from my web app?
Other remarks:
I am reluctunt to write my own PPAPI plugin or Chrome Extension - I prefer one solution working on all major browsers.
I know that StackOverflow community does not like discussions about technologies, so please focus on describing possible solution to my problem.
We struggled with a similar problem as we need to connect/access electronic devices over JNI->DLL. The only technology where this is currently possible are applets. Period. (And even that is tricky since certain combinations of browsers/java versions/operating systems do not work or have problems, but this is another story...)
There are web technologies like HTLM5, JScript which can replace some functionalities of applets however in certain scenarios (like yours) there is no current alternative available - and you named some of those:
connecting with libraries like *.dll, *.so etc.
file manipulations
launching applications
And doing that across browsers and operating systems!
Solutions?
Tell your users that certain browsers can't be used (like Chrome and
Opera Next)
Write individual plugins for each browser (which probably is beyond your budget ;-)
Did you consider writing standalone application(s) in form of an executable file? The user must download and run it however e.g. java or plugins also need to be installed. But then there is the security aspect of that (downloading an and executing an executable file) - certainly not an easy decision
Have a look at FireBreath 2 - (just read about it in some posts, however didn't try it)
There are lots of discussions on SO to this topic so take a read:
alternative technologies to replace applets
applet alternative launch from browser
alternatives to java applet to launch microsoft office applications
alternative-java-applet-network-drive-access
what are the alternatives for java applet to launch client programs using chrome
alternative of npapi plugins for flash java applet
python alternative to java applet
npapi alternative for live file editing
... and many, many more!
Now that TideSDK is effectively dead, I've been looking into alternative 'wrappers' to run HTML/CSS/JS applications as stand-alone desktop applications. The three viable options I have run across so far, are NW.js (formerly node-webkit), brackets-shell, and Electron (formerly atom-shell).
The problem is that there does not appear to be a sufficiently complete comparison between the three in terms of feature set, compatibility, etc. I'm hoping to turn this into a more-or-less canonical thread on the (objective) differences between the three, in particular regarding:
Platform support; operating systems, dependencies, etc.
Language feature support, as far as HTML5, CSS3 and JavaScript are concerned. Think things like "does HTML5 video work, and if yes, what codecs are available?"
Non-standard extra features, such as tray icons, popup notifications, and OS-rendered menu bars.
Extensibility; eg. ability to 'plug in' native code, talk to Node.js, and so on.
Architecture; in particular the architectural differences that affect daily usage as a developer.
Debugging; included development tools, compatibility with commonly used tools like node-inspector, etc.
... and so on.
What are the objective, technical differences that matter when making a choice between them as an application developer?
I did similar research about two months ago, and in the end I went with node-webkit. The biggest upside on node-webkit is node.js and npm. The package management of npm is really nice, and node has well done filesystem access.
Brackets-shell looked interesting, but other than a nice IDE I didn't really get what made this one as good or better than the rest. They are very clear that "The brackets-shell is only maintained for use by the Brackets project ", that screams run away to me.
https://github.com/adobe/brackets-shell#overview
Atom-shell seems to be recently active, but it seems much like brackets in that they are really writing and editor/IDE that just happens to be attached to a webkit runtime. It also is built on top of node.js. This one has the downside of being difficult to search for stuff online without being reminded of your middle school chemistry.
I really don't want an new editor, and most programmers have their favorite already. For the actual application development, they pretty much work the same, and should, since they all use webkit. You basically write 90-95% of it like a website, and then deal with the native parts, and some config.
These things are true for all three of them
platforms - runs on Windows, Mac, and Linux
language support - HTML5, CSS3 and Javascript : since they run javascript you can download and run nearly any library/framework that you want.
The big caveat on webkit is codec support. Typically you will have problems with non-free video codecs, unless you rebuild the dll/so to support them. For example the shipped node-webkit won't play mp4 video.
I've been playing with Atom-Shell over the last few days, and I am loving it so far.
The best part about it is that it's backed by GitHub.. which should allow you to settle into the platform for the long term, especially if it gains a large following. It's also made possible by direct Node.js improvements courtesy of a contract with StrongLoop, who is a major Node.js contributor (they claim to employ more Node.js core developers than any other company, even Joyent).
I've also found it rather comfortable to get started. It took me about a day to learn the structure and get my first proof of concept running. Very cool.
Bullet Points:
Platform support: Windows, Linux, Mac OSX (More Info Here)
Language feature support: HTML5, CSS3, JS via Chromium - so far, zero issues, but I have not tested video specifically.
Native Features: Native App Menus, Task Tray Support, Global Hotkeys, Protocol Handler Support (that I've seen so far)
Extensibility: Excellent Node.js integration, both the client and server can "require" Node.js modules and natives. I've also successfully tested Bower libraries (incl jQuery) without issue.
Architecture: Covered in the other points, but in general its very smooth.
Update (11/25/14): I've not yet found use case for Atom-Shell in any official capacity, but I have used it to build a few small apps for my own use, the most complex being an app that pulls my time logs from my PM software and creates Paypal invoices.
My opinion of the platform remains positive. It's pretty awesome.
On my time invoicing app I successfully brought in Bootstrap 3's Dashboard Example Template and a few node modules (bluebird, Paypal SDK, Teamwork PM Client) to create a mildly complex app. It took me a few days and does its job well.
I really cannot think of anything negative to say about Atom-Shell, its solid, stable, fast, and easy to code for. I hope this helps someone.
Besides fully support Web standards, NW.js supports a list of non-standard features for native app development including:
Protect JS source code by compiling them into machine code: https://github.com/nwjs/nw.js/wiki/Protect-JavaScript-source-code-with-v8-snapshot
Jailed devtools: https://github.com/nwjs/nw.js/wiki/Devtools-jail-feature
Additional security model with which you can do more in DOM: https://github.com/nwjs/nw.js/wiki/Security https://github.com/nwjs/nw.js/wiki/Changes-to-DOM
enhanced file dialog: https://github.com/nwjs/nw.js/wiki/File-dialogs
kiosk mode: https://github.com/nwjs/nw.js/wiki/The-Kiosk-mode
supports for a growing list of chrome.* API, include chrome.webRequest so you can intercept HTTP requests from DOM: https://github.com/nwjs/nw.js/issues/518
support for rich notifications, print preview, many more chrome.* APIs, Chrome Apps and other Chromium features starting from 0.13.0-alpha0
There is much more to see in the wiki including Menu, Tray, etc.
I've been working with brackets-shell for some time now, here are some of my findings:
brackets-shell is primarily developed as a shell under the brackets IDE project, but the project can run any web application. You just need to point it to your own html page. Clint Berry wrote an excellent tutorial about doing just this: http://clintberry.com/2013/html5-desktop-apps-with-brackets-shell/
The project is backed by Adobe and has a lot of activity
Documentation could be better
platform support They support Windows, Mac and Linux. An installer package can also be created. I only tested it on Win and Mac, it works great.
feature support html5, css3, js. Html5 video does not work out of the box, but is very easy to enable (by default the ffmpegsumo.dll is not copied into the installer, if you change the script to copy it it will work).
native features menu bar, 'open file with', file system access. I am not using any of these, as all I need is the communication with the node process.
extensibility a nodejs is built in, and you can communicate with node from your web application. In this way, you can use node to access the filesystem etc.
architecture The project is well set up, keeping a nice separation between the shell project and your own web app running inside it. In your own application, a global appshell object is available which gives you access to the brackets functionality (filesystem access, communication with node process, ...).
One thing to note (if you care), is that the Electron officially does not support Windows Vista. Vista's market share is about halfway between OSX 10.9 and 10.10 (both of which are fully supported by Electron). Vista is also still supported by Microsoft until 2017.
NW.js works fine in Vista, as well as OSX 10.9+. NW.js works on Ubuntu, Debian, Zorin, Manjaro, Arch, and most other Debian based Linux OS's. Electron has refused PR's to fix Ubuntu specific bugs on their platform which is concerning.
NW.js works in XP too. Currently 18% of the market is still on XP. So if you're desktop application is more general purpose or wants to have access to the late adopters still on XP, you're probably better off with NW.js (0.14.7) as Electron only supports Win 7 and up.
If you use NW.js 0.12.3 you can also support OSX 10.6+ and very old versions of Debian based Linux OS's like Ubuntu, and Win XP+. It is recommended that you do special builds just for those legacy systems though and use the newer versions of NW.js for newer OS's.
All,
I'm working on an HTML-based web app (i.e., not native app) targeted for iPhones.
I typically use Safari's Debug Console to track down JavaScript errors; it's pretty handy.
However, when I'm working on some complex JavaScript function - it's incredibly tedious to switch back and forth between the web app and the console window. Also, there are times when I'd like to see BOTH the window and the app at the same time, so I could see console messages WHILE I'm interacting with the app.
So - is it possible to "mirror" the Debug Console to another device, or too a Mac or PC?
In other words - I'd like to be able to use a web app (or web page) on my iPhone, and have the output from console.log() (or .warn() or .error() or .info()) show up in a window on my development machine.
Adobe has something called Shadow (http://labs.adobe.com/technologies/shadow/) that looks like it does something close:
Adobe® Shadow is a new inspection and preview tool that allows
front-end web developers and designers to work faster and more
efficiently by streamlining the preview process, making it easier to
customize websites for mobile devices.
... but it's not quite what I'm looking for. (At least, it doesn't sound like it from the description).
Sorry in advance - I'm pretty new to this type of development, so I'm probably unaware of some tool that everyone else knows.
Either way - thanks for any pointers.
jsconsole.com can do this. Read http://jsconsole.com/remote-debugging.html for more info.
http://youtu.be/Y219Ziuipvc shows you how to do it.
weinre does exactly what you're wanting. Their docs are reasonably thorough so I'll let them tell what you need to do to get it running.
PhoneGap actually offer a mobile web app debugging tool that is powered by weinre and is a cinch to set up so you might want to check that out first.
I have an idea of studying user behavior on the browser, for which I intend to make a Chrome/Firefox extension to study the behavior dynamically. I have some predefined libraries in Java and Python to analyze the results, which will be impossible to program in plain JavaScript.
Now for my question: is it possible to use third party libraries, especially those of Python or Java like plain function calls?
I have a vague idea about something like Java XPCOM or PyXPCOM for Firefox. However, for a beginner, it all looks so scary. I started making Add-On for Firefox, but got lost somewhere in the huge API.
I found Programming Chrome extensions easier than Firefox, but I couldn't come across something similar to XPCOM in Chrome.
How can I decide which one to go for?
Chrome - seems easy but I am not sure of its power.
Firefox - Seems powerful, but is it really possible to use any Java/Python Library?
Additionally, I came across this link that may be useful: How does someone use thirdparty libraries to be included in Firefox addons/extensions?
But seems like it mostly talks about C++ and XPCOM.
I have a vague idea about something like Java XPCOM or PyXPCOM for Firefox. But for a beginner, it all looks so scary.
I am not a beginner and JavaXPCOM/PyXPCOM are very scary (in addition to being barely maintained). As Firefox goes, it should be much easier to wrap your Java/Python library in an application and run it as an external process: https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIProcess. Note that you cannot get data back (other than an exit code) so the application should write it to a file that you can then read in your Firefox extension. Not very elegant but it has the advantage of being doable.
As to Chrome, its extensions run in a sandbox and using Java or Python isn't possible. Only option is adding an NPAPI plugin to your extension. It is binary code meaning that it could do anything.
When writing Chrome extensions, you're limited to JavaScript unless you choose to use an NPAPI plugin, which lets you do pretty much anything, but is not recommended.
The other approach you could take is to implement your Java or Python code on the server and make requests from the chrome extension's JavaScript.
We're building a web-based application that requires heavy image processing. We'd like this processing load to be on the client as much as possible and we'd like to support as much platforms (even mobiles) as much as possible.
Yeah, I know, wishful thinking
Here's the info:
Image processing is rasterization from some data. Think like creating a PNG image from a PDF file.
We don't have a lot of server power. So client-side processing is a bit of a must.
So, we're considering:
Flash - most widespread, but from what i read has lackluster development tools. (and no iPhone/iPad support for now).
Silverlight - allows us to use .NET CLR, so a big ++ (a lot of code is in .NET). But is not supported for most mobiles ( rumored android support in the future)
HTML5 + Javascript - probably the most "portable" option. The problem is having to rewrite all that image processing code in Javascript.
Any thoughts or architectures that might help?
Clarification: I don't need further ideas on what libraries are available for Silverlight and Javascript. My dilemma is
choosing Silverlight means no support for most mobiles
choosing Flash means we have to redevelop most of our code AND no iPhone/iPad support
HTML5 + Javascript we have to redevelop most of our code and not fully supported yet in all browsers
choosing two (Silverlight + Flash) will be too costly
Any out-of-the-box or bright ideas / alternatives I might be missing?
This is the sort of issue that software architects run up against all the time. As per usual, there is no ideal solution. You need to select which compromise is most acceptable to your business.
To summarise your problem, most of your image processing software is written in .NET. You'd like to run it client-side on mobile devices, but there is limited .NET penetration on mobiles. The alternatives with higher penetration (eg. Flash) would require you to re-write your code, which you can't afford to do. In addition, these alternatives are not supported on the iPhone/iPad.
What you ideally want is a way to run all your .NET code on most existing platforms, including iPhone/iPad. I can say with some confidence that no such solution currently exists - there is no "silver bullet" answer that you have overlooked.
So what will you need to compromise on? It seems to me that even if you redevelop in flash, you are still going to miss out on a major market (iPhone). And redeveloping software is extremely costly anyway.
Here is the best solution to your problem - you need to compromise on your "client side execution" constraint. If you execute server side, you get to keep your existing code, and also get to deploy to just about every mobile client, including the iPhone.
You said your server power is limited, but server processing power is cheap when compared to software development costs. Indeed, it is not all that expensive to outsource your server component and just pay for what you use. It's most likely that your application will only have low penetration to start off with. As the business grows, you will be able to afford to upgrade your server capacity.
I believe this is the best solution to your problem.
Host you image processing on Amazon E2C, Azure, or Google. IIRC E2C has many common image processing problems packaged and all ready to go.
Azure probably more familiar ground in term of sharing code as a web service
You just pay for CPU cycles and transfers/storage etc
I'm sure there will be Silverlight and JS people posting examples. Here are some image editors written in actionscript:
Phoenix
PhotoshopExpress
There is an ImageProcessing library to start with.
Plus PixelBender is available in Flash Player 10, it's fast, it runs in a separate thread
and people do some pretty mad things with it.
HTH
Some help for the Silverlight part:
There is an Silverlight image editor called Thumba.
And Nokola recently made one called EasyPainter and he will also provide the source code in the furure.
For the image conversion I would recommend the open source library ImageTools that also includes some basic effects.
Silverlight has a class for pixel manipulation of bitmaps called WriteableBitmap. The open source library WriteableBitmapEx is a collection of extension methods for Silverlight's WriteableBitmap. The WriteableBitmap API is very minimalistic and there's only the raw Pixels array for such operations. The WriteableBitmapEx library tries to compensate that with extensions methods that are easy to use like built in methods.
Pixel Shaders can also be used to make some fast and advanced effects. Although they are limited by Shader Model 2 shaders can be used for fast bluring, tinting and such things.
DISCLAIMER: I consider myself as an advocate of the Flash platform. I admire Silverlights huge potential as a technology to deploy almost any .NET content through the browser, but it has low penetration, is horribly marketed and -although perceived as such by many (mostly people who don't know either Flash or Silverlight)- is no competitor of Flash, as much as Flash is no competitor of Sliverlight. The idealist in me loves the idea of doing everything in HTML+JS using a standard, instead of relying on 3rd party proprietary software. But the truth is, JS is slow and the API is limited, and implementations of JS, HTML and CSS are terribly inconsistent accross browsers.
If you really wanna stick to .NET and are so interested in targeting the iPhone and its siblings, then you might wanna check out MonoTouch.
Still, even though this may surprise you, I am going to tell you to use Flash. :)
Why? The image processing bit is the smallest part of your application. Whatever it is you are writing, I am very sure of that. I don't know about Silverlight, but in Flash the filters used by "Thumba" and "EasyPainter" can be created within a day, most of them simply using ConvolutionFilter, ColorMatrixFilter, DisplacementMapFilter and BitmapData::paletteMap or even simply by applying one of the other filters Flash offers out of the box. Any additional things can be created using PixelBender, which was pointed out by George. The kernel language is a subset of C, so porting classic filters shouldn't be too time consuming. Also alchemy (an LLVM backend targeting Flash Player 10) would be an option worth investigating, although it's not very stable yet.
The biggest part of your app will be a lot of GUI design, GUI implementation, Business Logics etc. Flash is really great when it comes to simple, yet reasonably fast image manipulation and with the Flex framework and MXML you have a powerful tool to productively create the GUI of your app, that can interoperate very well with a multitude of server solutions for virtually any platform.
Also, Flash has a great and active community, offering tons of tutorials, code snippets, libraries and frameworks, and a big ecosystem, with cross-compilation tools to deliver flash content to other platforms (including the upcoming Flash CS5, or the mentioned Elips). I don't understand, where you got the impression, that the Flash platform lacks developement tools. The difference to the .NET suite is that they are provided by a multitude of vendors. The upcoming Flash Player 10.1 was already pointed out by George, but never the less, I wanted to stress, that this makes many of the cross-plattform considerations obsolete.
Last but not least, I'd like to point out Haxe. It allows compiling to SWF, but also to C++, using the very same API provided by NME, to target the iPhone. Also there's work in progress on an android backend. If you're aren't playing to launch within the next 4-5 months, then this is definitely an option.
Your issue is a perfect target for the Haxe programming language. Haxe is written for the web and can compile to JavaScript, Flash and Objective-C (possibly Java/.NET soon).
So you do not choose which platform you are going to invest in but in which language. Haxe is easily adoptable for an AcitonScript programmer.
It makes no sense to run your imageprocessing algorithms in a JavaScript sandbox when Flash is available because it will be much faster. It makes also no sense to run heavy image processing algorithms on a mobile device like the iPhone with JavaScript. I would only support JavaScript as the worst fallback solution.
If you do not like to use Haxe I would go with Flash. You can deploy your Flash application for the iPhone aswell if that is your problem. This is also very great because you get native ARM code. There are actually great tools for professional Flash development available. FDT and IntelliJ IDEA are two of them. The best Haxe IDE is probably FlashDevelop at the moment of writing.
So I would definitly not use JavaScript as the only solution. Haxe is perfect for what you try to achieve. If you do not trust or do not want to invest in Haxe you can use Flash because of the iPhone/iPad export.
Depending on your usecase I would also encourage you to look at cloud hosting like Amazon EC2 and Google AppEngine for instance. Hosting costs are cheap and scaling will be easy for your task. The experience will be much better when it comes to complex operations that can take even a lot of time on a desktop system.
In addition to other answers, another option may be a hybrid solution. For example, use Flash/Silverlight for the majority of your target audience and use server-side processing for those that don't support it (or you could create a native app for iP[hone|ad])
You may have to do something like this anyway as the mobiles you are targetting may have insufficient processing power depending how complex your image processing gets.
Of course you still have the option of upgrading your server which, although you've currently discounted, is probably far cheaper than spending development time creating/deploying/testing a client-side solution.
You can use Silverlight for all Silverlight enabled clients and for non Silverlight clients, do the image processing server side. Since the Silverlight code is C#, you can double compile it to make (mostly)the same code work as Silverlight and non-Silverlight (i.e. server). This gets you the best of both worlds.
You don't say what language "all that code" you'd have to rewrite is in. Might a semiautomated translation to Javascript be practical?
Perhaps you could start out server-side, as CraigS suggests, and then move functions into the client over time instead of rewriting all at once.
Have you checked the editor of Pixlr.com ?
Take a look at their API as well..
The best solution is to use silverlight (so you already have the code ready). If the client can't run it (mobile phones, etc) then process it server-side.
It's the best compromise.
Depends on the type of image processing and the end user experience you are targeting.
As you are looking to target mobile phones your image processing will need to take into consideration the type of handset the user or the receipient has (if messaging via SMS/MMS), as different handsets have different resolution screens and handle different image formats for main images and thumbnails.
I'd suggest that you consider a hybrid cloud architecture as was mentioned in the Microsoft PDC keynotes this year. This would enable you to have your own server(s) to support your application, but if you require additional capacity due you scale out into the cloud using AppFabric.
Additionally, to maximise the market availability of your product pulling the image processing to a common reusable infrastructure allows you to target different platforms, exploiting the positives in each.
I have worked on a solution that hosted its image processing and delivery infrastructure server side and then built different UI offerings allowing sales via desktops, MNOs and AppStores. It can work and from a business perspective can offer economies of scale benefits.
Why not mention Java Applet ?
Good sides are:
almost all browser support ?
need install JRE ?
all OS support
Java provide Java Advanced Image kits, but if c++ dll can be called, that is best (JNI can call c++ dll )
In Python, one of the most popular libraries for image processing is pillow. Through the pyodide project (python running inside browser via emscripten), it's possible to use libraries like pillow and numpy for image (or matrix) processing, and convert the output to a base64 string (via Python standard library). This can then be passed to your <img> html element, either native JS document or with a library like React.
The way I see it, there's no one solution that meets all of your needs. Your best option, imo, is to go with Flash and hope that Adobe sets an agreement with Apple to get Flash on the iPhone/iPad. The major downside, of course, is you'll have to rewrite much of your code.
If the mobile sector isn't absolutely critical, then choose the Silverlight option for reasons you mentioned already. You could also use Silverlight in an out-of-browser mode to work as a desktop application.