We would like to port our application running on some other browser, to run in Cobalt.
Our application uses extensively JQuery.
Running it in Cobalt is quite a challenge. Does any one have some idea about alternatives to JQuery that run in Cobalt?
Note: We are targeting Cobalt 20.stable
The answer to this question depends on what do you need JQuery for. JQuery used to be a browser abstraction layer but lost most of its appeal since browsers improved their support of web standards.
If you need a component model, try Angular. There are known production apps that use Angular on Cobalt (but it doesn't mean that everything will work out of the box).
Related
I've been really impressed by a couple of examples of 'raw' Web Components in the wild, most recently Addy Osmani's latest version of the TodoMVC, called Componentized Todo. Now, with Chrome 36 hitting stable, this example works without Polymer's platform.js shim (which is awesome!)
I wondered how easily, then, it would be to convert this project to use platform.js alone, and get it working on (at first) Firefox stable and (later) Safari, IE, mobiles etc. Because that sounds to me like a really big step forward for Web Components, when they become true extensions to browsers (either natively or through platform.js as a shim), rather than being tied to Polymer as a framework.
I added platform.js to that example and got this running, but couldn't access the template element in the individual files, so had to make some compromises. I've submitted this as a PR: https://github.com/addyosmani/componentized-todo/pull/1
My question is, is this a viable direction for platform.js to be taking - to be breaking beyond its role in Polymer and becoming truly a shim for Web Components in older browsers?
What's your experience in using web technologies (HTML, XML, CSS, JavaScript) to implement part of the functionality of a GUI application? Pros and cons, please.
No servers, relational databases, AJAX, or cookies for session management, nor an existing webapp either, but rather a GUI app that uses web widgets (like Qt WebKit) to render and handle substantial parts of the UI, while taking advantage of a GUI framework to achieve an even richer interaction and better desktop integration.
I've already validated that the approach is possible using PyQt. Content can be rendered from the file system or from strings, and URL requests (images or clicks) can be captured and served by the form's event handlers. CSS and JavaScript are supported, perhaps with some limitations.
# ...
self.webView.page().setLinkDelegationPolicy(
QtWebKit.QWebPage.DelegateExternalLinks
)
#...
class TotiMainWindow(QtGui.QMainWindow):
def linkClicked(self, url):
pass # events arrive here
Note: This question is different from this one and this one made before, among other things because there is no requirement to use web technologies on the GUI, but there is the requirement that the application should work without a network connection available, and should integrate well with the default desktop over different platforms, without previous infrastructure requirements (no .NET, Java, browsers, or database servers).
Note: I posted a different version of this question on PMS but found very little experience with this approach there.
Closing Note
I just found most of the information I was looking for in a series of blog posts by André Pareis.
I think the largest advantage to using web markup like HTML/CSS and other web technologies is that desktop apps may very well have their days numbered.
As we speak, Google engineers are working on the Chromium OS, which essentially consists of a single GUI application... the browser...
Now, while nothing may never actually come of it, there is clearly a rising trend in the number of applications accessible through a web browser, accessible anywhere. It seems to me that this is the future of application development.
By using these technologies, this becomes one less headache you have to deal with when or if you determine that your app should be available as a web application.
Update: A few years ago, we developed an Agent Desktop for our call center that is essentially a local application that opens sockets to integrate with the phone system. The user interface the agents use is built with HTML, CSS, and JavaScript, and the experience is stunning. When we released our latest update in 2010 with a professional CSS redesign, our agents were all very impressed with not only how easy it was to interact but also how easy it was to use.
In the future we will port this 100% to the browser, but for now it needs to be a local application because of the COM integration with the phone system.
We did exactly this for a project back when Windows XP was new.
This gave my team several benefits:
A good-looking UI with relatively little effort
Easily change the style of the UI in a consistent manner using CSS
Relatively simple integration with C++ (invoking functions from the ui and vice versa)
The drawbacks we saw were:
Some not-so-good firewalls considered accessing internal resources (ie other html pages in the ui) to be a web request
Adding and accessing the needed resources could in some cases be a bit cumbersome
It was possible set properties in Internet Explorer that would prevent JS from running in the application
Note that some of Windows XP:s programs are using this approach.
This probably works best with small, more Wizard-like parts of the ui (which our ui consisted almost entirely of).
I have since then not really been involved in ui projects, so I cannot really tell you whether this approach is still valid... I know that MFC-based applications will let you use HTML-based dialogs though.
In a similar situation in 2005 I created a stand-alone webapp using XForms, CSS, JavaScript, XML and XML Schema for offline data retrieval and verification. With a good XForms -> HTML + JS transformer (Chiba) it did the job with no bug fixes after the initial release. It was used for 6-12 months (IIRC) by about a dozen engineers for a project gathering test data in the tunnel of the Large Hadron Collider. The biggest surprise of that project was just how much you get for free when going for a web platform, even for offline use. Highly recommended.
The major problem is that it reduces your development speed, or the quality of your user interface. A lot. Unless you're using Seaside, it is much faster to develop a desktop app.
There is quite some number of applications built on top of Mozilla platform. It isn't 100% web technology, as instead of HTML you use XML based XUL, but the rest is indeed web stack (JavaScript, CSS). The most successful of these it the OpenKomodo and it's commercial big brother Komodo IDE.
On the other hand, as far as Qt goes, the newest version 4.7 you can build GUI using QML language. Don't let the name mislead you, it's not markup, it acctually JavaScript with app-specific extensions.
I'm wondering if someone has tried already to port jQueryMobile on top of Zepto.js (http://zeptojs.com/) instead of the required jQuery?
The main feature of Zepto.js over jQuery is its file size of ~10kb (minified, not gzipped) instead of jQuery's ~80kb. If you were to replace jQuery wuth Zepto.js then you'd still have to include jQuery mobile, which weighs in about 95kb (JS & CSS).
jQuery and jQuery mobile: 175kb
Zepto.js and jQuery mobile: 115kb
You'd save about 1/3rd of the download weight (not including HTML, images and other JS), making making a port of jQuery Mobile to Zepto.js unlikely to be worth the time.
Zepto.js currently also only supports WebKit browsers, meaning you'd be loosing support of Firefox Mobile and IE7&9 Mobile too.
Update: Zepto now supports a lot more platforms.
dave1010 makes good points.
You may also be interested in a back & forth between the creator of Zepto (madrobby) and jQuery (John Resig) on Hacker News
I think it's simply to early for that. jQuery Mobile hasn't seen an official release yet (only alpha2) and zepto.js is also still in its infancy.
Furthermore, zepto.js states "[...] that emulation of all features of jQuery is not a project goal", they just want to emulate the most useful parts. With this direction it is questionable if zepto.js can ever serve as a drop-in-replacement for jQuery in the mobile context.
However, a possible success of zepto.js could inspire the jQuery team... maybe we will soon see a "jQuery for Chrome Smartphones" build that has all IE/Firefox/Opera stuff compiled out.
jqtouch already support zeptojs, you may want to give it a try.
I started on a web project and I really, rally wanna use Zepto, but the current users developing for Zepto is really low. Not a big community, not to many plugins and I don't see why not using google's CDN for jQuery.
Zepto is great for senior JavaScript developers maybe.
Can JavaFX replace what AJAX do? i went through a couple of articles like this http://www.ajaxlines.com/ajax/stuff/article/ajax_vs_javafx.php. But I am still confused. anyone help??
I don't think this will happen, certainly not at the moment. JavaFX depends on java, there's very little support cross-platform (windows mobile does work but it's very limited). There was talk about set top boxes coming out to run javafx but it doesn't seem to have taken off :\ It's a real shame, in many ways I really like JavaFX. It's a shame they won't open the source. Also for deployment there is a dependancy on a sun server to get some jars (not possible to host on your own server), so when it goes down (and it is a when) then everyones apps stop working!
Javascript keeps my vote unfortunately.
Technically, yes JavaFX can do everything that AJAX can do and more - on a supported platform. Unfortunately JavaFX isn't supported on most smartphones so you won't get the same reach as AJAX. You also need a browser plugin which you don't need for AJAX.
But if these limitations aren't a problem, then I think you will have less misery using JavaFX instead of AJAX.
I want to settle on a GUI framework, and use AJAX, as simply as possible.
Assuming adequate skills in both JSF and Flex, but not too skilled at AJAX/javascript, and assuming Java as the language for the application, and using a DB, which is a good choice, or both have equal set of pros/cons?
Try using Richfaces. As RichFaces library will provide ready made Ajax Enabled JSF Components. You can use them in your JSF Application.
RichFaces is a rich component library for JSF and an advanced framework for easily integrating AJAX capabilities into business application development. The RichFaces components come ready to use out-of-the-box, so developers can immediately save time in taking advantage of component features to create Web applications that provide greatly improved user experience more reliably and more quickly. RichFaces also includes strong support for the skinnability of JSF applications. RichFaces also takes full advantage of the benefits of the JSF framework including lifecycle, validation, and conversion facilities, along with the management of static and dynamic resources.
http://www.jboss.org/jbossrichfaces/
...and the pros of Flex are:
Flex Framework-built SWF files runs in the Flash Player JIT, which is 100x faster than browser-native JS, unless you've got a JS Jit-enabled browser which uses SquirrelFish, for example. So user performance may vary considerably, whereas the Flash Player works at the same performance across all browsers, all platforms.
The Flex Framework is open source, so you can customize it to your heart's content. And since it runs on the Flash player, it runs the same everywhere. Unlike an AJAX framework, where you usually have to be highly expert at browser compatibility coding to customize it.
Flex tools are also free, as the Flex SDK is open source.
Having said that, you can code desktop apps in AJAX using Adobe AIR, without using Flex or ActionScript, if you want to.
How to make HTTP requests with Flex:
http://www.adobe.com/devnet/flex/quickstart/httpservice/
AJAX using JQuery (one of many JS frameworks):
http://docs.jquery.com/Ajax
Both of these are pretty simple once you've played with 'em a bit. You specify a URL and a callback function to read the text response once it's finished loading. Assuming you're familiar with the pros of Flex, the pros of JS are:
It doesn't require a browser plugin
You don't weigh down the page with the Flex framework.
You'll probably find more developers in the market who are familiar with it because the development tools are free and the code is usually visible to anyone who wants to learn from it.