We're writing a platform for building apps that are able to run on any browser and we were thinking, is there a way to do this with Python? Or should we better go with Java and Java Applets?
I was also wondering, how hard is it to write a custom browser plugin? How long would it take e.g. in man-hours?
Thank you!
The universal API for browser addons is javascript. It is well supported in Firefox, Chromium/Chrome, and Opera at least; it is the only extension API available on the last two. Intersting API subsets are firefox's Fuel, Chromium's trimmed down extension api, and the very portable GreaseMonkey functions.
A second runtime would have its own startup costs, garbage heap, and ffi overhead. It would require special privileges, and would still have to translate its API calls into javascript. That would make it fairly unattractive.
Edit: you were asking about web content with possible plugin or addon support? You also have the option of the NPAPI (also the Pepper project around it). This api is C-level and can render to a rectangular area on its own (using OS APIs), at the cost of very little support from the browser and being a portability nightmare.
Related
I am trying to develop an application that can be embedded in the HTML code of a website. I looked into using a Java Applet, but I am turned off of this option from the fact that Applets are decreasing in popularity, and that I am not totally comfortable with Java.
I have experience with Visual Studio C# and VB, and I was wondering if there was some sort of option where I could write an embed-able application using Visual Studio, and if they have some sort of equivalent or similar tool to Applets that I could utilize.
Thank you for your responses.
This depends on whether you want the C# code to run on the client or server side.
Server side you will have to use ASP.NET.
If you want to run on the client side (which it sounds like), this is essentially impossible due to security concerns and technological limitations (a .net clr would need to be invoked and the code passed to it for execution).
You could potentially look into using javascript based activex/com objects to invoke the clr.
Embedding C# code was possible in earlier versions of Internet Explorer, but no longer.
Google has recently announced their intentions to remove client-side Java support from Chrome in the near future. I, a Java developer by nature, have built nearly all of my web-based applications on top of some form of Java.
As such, I am looking for a workaround for Chrome's discontinuation of Java support, without having to rewrite all of my client-side web apps from the ground-up in another language.
Furthermore, I'm searching for a workaround which does not require Chrome's built-in NPAPI workarounds, as I need basic users to be able to continue to use the applets as they are.
The best option I'm aware of is Java Web Start (tutorial), which doesn't run in browser but does allow users to easily run a Java application you serve from a website. Oracle provides some documentation on how to migrate to JWS, but the gist is to simply replace the <applet> tags with a link to a .jnlp file with the same information the <applet> tag had. You may have to tweak Chrome's application defaults as well.
There is also the Google Web Toolkit, which isn't for applets, but does let you write Java that compiles into JavaScript.
If your applets are more integrated into the browser, unfortunately you may not be able to keep using Java. Chromium does offer some alternatives on their NPAPI deprecation page, but they're not pretty. Options include HTML5/WebGL, WebRTC, NaCL, or Chrome Extensions. The Chrome Experiments site is worth browsing if migrating off of Java becomes your best option.
Oracle's official recommendation, however, is to avoid Chrome. That's pretty heavy-handed, and won't work for most website owners, but it's worth mentioning.
My society was hit in the face with the NPAPI deprecation in the google browser.
We were using Silverlight for a long time and we are curently looking for any replacement solution.
What was good about applets and silverlight was the easiness for the applications to access the file system and get the rights to automatically save anything into the computer.
Beside it was compatible with the major OS and almost all Browsers, which was a great thing for our customers.
But chrome decided that NPAPI causes too much security problem, and they will remove it by september.
I'm looking for a simple way to provide access, at least to the file system of the customer.
asp.NET gives us anything we need, on the server side, but it can't do a thing on the client side. With silverlight we were able to use the clipboard,save multiples files on specific directory, send mails from the client etc.
I thought about making our own plugin on several OS, but that would be a lot of work. So i was wondering if there were a simple compatible solution that already exists.
You could build a FireBreath2 plugin to provide this functionality -- FireBreath2 will work on chrome w/ native messaging, and the functionality you describe shouldn't be too hard to do cross-platform. Keep in mind that you've got some serious security risks to protect against, though.
FireBreath2 as of this writing isn't quite production ready, but it's pretty close. ActiveX support isn't complete yet, but it shouldn't take that much work to finish it. It would require a good understanding of C++ and a willingness to help with the project since it's not 100% ready for prime time yet.
I would like to replace Java Applet which currently needs to use client's resources, i.e. external readers, and to communicate with a server via socket.
Reason:
1. I have thousands of client machines using this Java Applet program, and most of them are running out-dated JRE. When the Java Applet program is updated / added new features, all client machines will need updating the latest JRE.
Expected Solution:
The Java Applet program would be expected to be replaced by a web-based application, which allows to compile and run source code at client's side such that the new web-based application could still use client's resources and communicate with server via socket.
Can I use JavaScript to achieve it?
I would very appreciate your help/suggestion for this problem. Thank you!
JavaScript is a scripting language that gets evaluated in the browser.
I would not describe it as compiling and running but yes, it does mean you can run code in the client and is commonly used to create applications that run in the browser.
There's a staggering amount of frameworks that you can use to write your application. Take a look at the TodoMVC site to see the same TODO app created using several different frameworks.
If you come from Java applets, GWT may be interesting to look at.
If you wish to let the JavaScript client listen for messages from the server, take a look at websockets.
The smart card reader is going to be a problem, though!
See Architectures to access Smart Card from a generic browser? Or: How to bridge the gap from browser to PC/SC stack?
By the way:
The real issue with outdated JREs is not that your code will not run on old JREs, you can create perfectly fine applets using java 1.4 or java 5. Any libraries you may need you can deploy alongside your applet. The pain is a security problem. Anything but the latest version Java plugin is getting actively exploited and puts the user at risk. Occasionally, even the latest version is not safe.
try socket.io
I think this is the latest technology you can use to communicate with client browsers. it support the latest browsers and mobile browsers too.
hope this will help you.
Javascript has become very powerful with HTML 5.0. Here is a list of new elements that you can use to access all kinds of resources, including local files, audio, video, GPU rendering (canvas + WebGL) and GPU compute (WebCL). Here are even more things you can do, including database connections and networking. You can even create offline Javascript applications.
jQuery and jQuery layout make robust GUI development a lot easier. Rich tool suites, such as Google Closure offer optimization and a compiler for improving performance and detecting obvious mistakes early in the development process.
W3 offers useful stats for making an informed decision on how many users on average have access to which features. Note that the most annoying guy in that list arguably is IE8 due to it's lack of proper HTML 5.0 support.
In case you want to stick with Java, then one alternative would be to use my http://bck2brwsr.apidesign.org project. It's goal is to create small Java that can run in 100% of modern browsers without any plugin installed.
There are Java bindings to HTML (via knockout - one of the four most popular frameworks for HTML5) and that is why one can code whole business logic in Java and just render it via HTML. Should be enough to replace most of the applet UI.
In addition to that there is an experimental API to render on HTML canvas. People use it to write Java games that run in a pure browser.
There is a simple way to communicate with server via JSON REST API or via WebSockets. A live example is here.
I am wondering if there are specific cases where GWT is not suitable? For example would it be approriate to re-develop Stack Overflow using GWT?
I am developing an app which has a Java Restlet API and I was planning on using GWT (previously I would just have used bog-standard HTML/CSS with back-end PHP code calling an API). I am wondering if there are reasons why I shouldnt choose to do this?
My answer is not full but I believe the following bullets may be useful.
GWT should not be used for applications that mostly present textual information and some pictures, i.e. not very interactive. For these applications GWT does not bring you a lot of benefits.
GWT should not be used by teams that have strong web skill and relatively weak java skills.
Do not use GWT if you are required to support browsers that GWT does not support officially. For example MSIE 6.
have a look at this topic GWT for big projects?
GWT is best choice to manipulate complex actions in a single page. like Google wave, Google mail ... you can easily update (ajax) any part of the page.
Because of the GWT is java-to-javascript compiler, user should wait the loading of .js files and it causes many and many problems if your web app is big. The bigger your project, the bigger javascript files, the more user should wait the loading of .js files
IMHO If you have a static looking website like a blog, news portals, etc which each page has its own identity and represents an entity and is requested separately don't use GWT alone (you can still mix it with server-side generated pages like FB).
For most of other web apps especially if users sign in to use your app or your app is interactive and there is no technical problem use GWT (like Gmail design).
I would propose to avoid GWT at any cost. I have experience developing huge project with GWT and it is nightmare, because of long development circle. If you have application in angularjs/react/jquery, you update source code, click F5 and reload it. You can quickly debug clicking F12.
If you use GWT on huge project, you have to wait ~1 min for app to compile. And then there is no good way to debug it. Google provided special browser plugins, but they worked unstable and didn't support last versions of browsers, so I had to downgrade FF. Also huge GWT app debuggin takes tons of java memory, so you have to provide more memory to tomcat. And finally in practice you can't avoid learning js, you will have to learn it if you do modern web development.
UPDATE 15.05.2017: My answer was downvoted by GWT fans, but I'd like to note, that my info is up to date: 1-page hello world app rebuild cyrcle takes about 30seconds with last IDEA and 10Gb mem SSD notebook. I also asked friends having GWT in production for serious project: they claim 2min is average redeploy time.