I am going to start a new application which mainly consist NavigationPane, Grid, Toolbar. Layout should look like this demo page http://www.gwt-ext.com/demo/
I am quite confused which one to use in terms of writing less code, more performant, etc..
Could someone tell the pros and cons of all these technologies.
All the while I coded in javascript, so that way ExtJs seems to be the easy one for me to code. But I am curios to try GWT Ext, Is it true that it could do a lot just by writing few lines of java code.
For eg: To achieve the layout ( given in above gwt ext demo url), which one should I opt ExtJs or GWT Ext.
I read SmartGWT is relatively slower than GwtEXT. Does it have any advantage over GWT EXT. I am also looking for hibernate based data modules ( as my application is going to have many database calls). Anyone of SmartGWT or GWTExt has support for such modules. I came to know that smartgwt doesn't offer all of smartclient enterprise version functionalities, that we are allowed only a few of smartclient features. Will it be an issue?
Your response is highly appreciated.
The GWT-Ext main page now says
"GWT-Ext is no longer under active development and has been superseded by Smart GWT. Assistance will be provided to existing users of GWT-Ext looking to migrate to Smart GWT."
so why would anyone use it?
To write the least code, use SmartGWT Pro. It provides a wizard that allows you to just pick from a list of Hibernate entities you've created, and instantly you have the ability to perform all CRUD operations on that entity, no code required. Then you can add business logic.
The wizard:
http://www.smartclient.com/smartgwtee/showcase/#tools_hibernate_wizard
The link about is just screenshots, but there are several Hibernate samples in the showcase. See especially the Master-Detail Batch Load and Save sample.
As far as performance, real-world performance of most enterprise apps is dictated by how often the application has to contact the server. In this area SmartGWT has a large lead because of features like Adaptive Filtering (see the Featured area in the SmartGWT showcase).
Almost all reports we receive of SmartGWT being "slow" are due to having Firebug enabled. Disable Firebug and performance is fine, so normal end users will never perceive slowness.
About 6 months ago, we studied whether we would use ExtJS or GWT-Ext for an internal application. We wanted the back-end to be J2EE standard frameworks (struts, spring, hibernate for persistence, etc.). We ended up choosing ExtJS because it seemed to us that GWT was not stable enough (too many changes in the API that is still recent), and Ext-GWT was always lagging behind in development.
application which mainly consist NavigationPane, Grid, Toolbar.
Well, this tells us a lot about your app, doesn't it :)
I think it comes down to how good you are at either Java or JavaScript. They are quite a different languages you know :) But if you are well-versed at both but only used Ext JS, then picking up Ext GWT (or GWT Ext, if you meant that), shouldn't be such a great deal. And if that application you are planning is going to be as simple and small as your description of it, then it's probably a perfect opportunity to try out something new.
I use GWT-Ext and it is quite good especially if you don't mind tweaking things with JSNI to customize the already existing Ext widgets it is incredibly powerful. Unfortunately development is stagnant, so my future projects will probably be either in SmartGWT or Ext-GWT. SmartGWT is written by Sanjiv Jivan (same guy who wrote GWT-Ext) and it has most of the widgets we need. I must say most of the skins are quite dated except the Enterprise skin which looks good, but you can always roll your own skin.
Related
This question already has an answer here:
Does Adobe Flex have the ability to compile into HTML/JavaScript?
(1 answer)
Closed 6 years ago.
To give a brief background I am a C++ programmer who has worked mainly on back-end systems, but now has to develop a front-end gui (mainly an interactive dashboard with lots of charts and comparisons and so on) as well along with a back-end financial system.
Few years back I had worked on a similar project and used Flex to develop a dashboard. But searching the net, it seems that Flex is not well supported anymore (nobody pouring money on it) and will go out of fashion soon (Am I right???). So I continued searching and the names that popped up are ExtJS (which was prevalent few year back) and AngularJS (heard it for the first time now). Spent some time searching both and both seems fine. So can you dashboard developers please help answer the following questions (as well as provide important input that I may be overlooking right now):
Cross-Compatibility: Need to develop desktop and mobile apps along with web page.
Prevalence: I will need to learn the technologies. Would prefer it they are popular and widely used
Dashboard features: Stuff like ability to go into bar graph and pie charts and stuff.
Ease of programming: Quality of Editors/IDE available, speed of programming etc.
Anything important that I am missing
In my opinion, I would go with Flex, because:
You already know it
Flex is a "compact" solution to your problem. Web frameworks imply you to learn a lot of new things. AngularJS is certainly cool but every web tek require you to master JS, CSS (I hate it), HTML, FireBug, PhoneGap, .... Web teks are a mess (IMHO !!!)
Coming from C++, working with Flex is more comfortable than web tek. Dependency injection is cool but it's a new vision of the world. JS is really powerfull but is (also) a functional language and you will need to get a "lambda mind".
Two year ago I decided to try ExtJS to make a dashboard for an hospital. I gave up after some days when happened that finding and solving a simple bug in my simple app took me a full day! [I forgot a parenthesis. The page didn't open saying nothing at all).
I'm now trying to learn Flex because I need to produce a simple app for smartphone (I'm a newbie in that) that should be ready in a month and with Flex I think it's easier for me to succeed than with any web tech framework. I know that Flex future is obscure but I think it's too good to be killed even if Google's pressure is strong ;)
No-one seems to be keen to answer this question - I guess because it's a definitely going to be an opinon based answer. I'll give it a go...
To answer your first question - Flex is if not on the way out, at least on a low simmer. Adobe Flash Builder 4.7 (the main Flex tooling IDE) has not been updated for well over a year now and I can't see any updates on the horizon.
Apache, who now own the codebase are doing a nice job with updates, but progress is slow.
One possible bright area is FlexJS, a compiler that outputs Javascript and HTML. It's still alpha at the moment, but it could be an option.
I've never developed in ExtJS, but it seems it's time has come and gone - it's still used, but it's definitely been superseded by Angular and other frameworks such as Knockout.
Cross-Compatibility - AngularJS works is almost all browsers from IE8 up and that includes most modern mobile browsers. People often use JQuery Mobile in combo with Angular and Bootstrap to get the functionality they need. Bootstrap is responsive, so if you lay out your UI correctly, it should work for all devices.
Flex is also cross compatible in the form of Adobe Air, but it's less easy to get it onto people's devices - they need to download the Air framework.
AngularJS is the number one framework by a huge margin at the moment - and it's still growing. Check out this graph from google trends. The combination of technologies includes Javascript, CSS, Grunt, Bower, Node.js and concepts such as dependency injection, MVC and responsive layout - all this stuff is useful for other projects. Once you master Angularjs, you'll be ready for a lot of other stuff.
Learning Flex seems to be a bit of a dead end at the moment - you'll notice the absence of any recent Flex blog posts. It's not cool right now, and it's just too uncertain if it's going to survive.
Using Angularjs and D3 for example is reasonably straightforward - a web search will show lots of examples here. Plus you can do basic drawing using svg elements directly in your HTML code. Here's a nice article on the subject.
Since Angular is a Javascript framework, there are many many options here - you could use SublimeText, Atom, PhpStorm or one of many other choices. As I said earlier, your choices are much more limited if you choose Flex.
Finally, don't forget that this is all just my opinion, but Angularjs is just really fun to develop in - binding is just so cool. So are directives. Dependency injection just rocks. I think you'll like it!
Sorry for the bias here, but I can't help it!!
Hopefully this writeup helps you a little. Good luck.
AngularJS is a good choice for complex web application (both desktop and mobile).
There is a project that implements Dashboard/Widgets functionality with AngularJS.
GitHub source code https://github.com/DataTorrent/malhar-angular-dashboard
live demo http://datatorrent.github.io/malhar-angular-dashboard/#/
more advanced demo (charts, etc.) http://datatorrent.github.io/malhar-dashboard-webapp/#/
It targets desktop browsers so far but has a lot of features:
Adding/removing widgets
Widgets are instantiated dynamically (from corresponding directive or template)
Widgets drag and drop (with jQuery UI Sortable)
Horizontal and vertical widgets resize
Fluid layout (widgets can have percentage-based width, or have width set in any other unit)
Any directive or template can be a widget
Connecting widgets to real-time data (WebSocket, REST, etc.)
Changing widget data source dynamically (from widget options)
Saving widgets state to local storage
Multiple Dashboard Layouts
Disclaimer & Long Winding Question Approaching
I know topics like this have been beaten to death here so suffice to say I'm not asking about which framework is better, I don't really care about opinions on the better framework. They all do pretty amazing things.
The Question
Given that I have an existing web application, made of mostly regular HTML+CSS (jQuery where needed), which is the optimal framework to integrate a few "rich" pages into typically a regular stream of HTML.
Reason
I am trying to bring our proven application into the realm of awesome desktop like UI but I want to do it one small piece, one screen at time. But for our users, support personel and especially me taking it slow is the only option.
Also, with our branding requirements having a framework that just takes over the viewport isn't an option, it has to play nice with other HTML on the screen.
Imagine the example being a rich user manager in an otherwise plain HTML+CSS environment.
Experience Thus Far
Dojo + Dijit
Pros: The new 1.5 widgets plus the claro theme is the cure for what ails us. Dojo seems to be able to use markup to create the UI which is very appealing and has a fair amount of widgets.
Cons: Holy bloated lib Batman! Dojo seems to be enormous and I have to learn a custom build system to get it to stop requesting 4,800 javascript files. This complex empire of Javascript makes me believe I won't be able to create much that isn't already there.
ExtJS
Pros: Amazing set of widgets, does everything we could possibly want. Seems quick, every version brings new improvements.
Cons: I'm not sure how to use this without the entire display being EXT. I'm still building a web site, so I would prefer something that could integrate into what we already have. Some pointers here would be great.
YUI
Pros: Well, it's Yahoo isn't it? AWS console is downright wicked. Plenty of support and a giant community.
Cons: Well, it's Yahoo isn't it? AWS console is the only wicked thing. Complex for someone who's used to jQuery.
Help Me
I am willing to accept experience, links to ways to solve problems I've outlined, new toolkits (even though I'm pretty sure I've seen most by now) or even just advice.
Regarding ExtJS, it's pretty easy to start it in an existing div with something like this:
Ext.onReady(function() {
App = new Ext.Panel({...})
App.render('div-id')
});
The App panel can then have it's own layout manager.
This might be useful if you're familiar with jQuery, but not yet familiar with YUI 3 syntax: http://www.jsrosettastone.com/
Each of the libs you listed is excellent. When embarking on a larger scale project, the quality of a lib's documentation, community, and commitment to support become more relevant.
With Dojo, keep in mind that outside of dojo base, it only ever loads what you tell it to. But yes, without a built layer, that means it could easily end up requesting 50 JS files at startup for a large application using a bunch of widgets.
There are several pages in the reference guide documenting the build script: http://www.dojotoolkit.org/reference-guide/build/index.html
Rebecca Murphey wrote a nice blog post outlining an example app and build profile that you might find illuminative: http://blog.rebeccamurphey.com/scaffolding-a-buildable-dojo-application
If you get stuck, there's likely to be people in the Dojo IRC channel that can help.
RE ExtJS: I'm not sure what your exact situation is, but keep in mind that if you're intending to use it in commercial non-open-source software, you need to pay for licenses: http://www.sencha.com/store/js/
I'm a little curious as to why you think the size / number of requests is specifically an issue with Dojo though. I haven't used the others, but I'd expect it to be somewhat of a potential concern with any of them.
Browsing the Internet, I found the new Ample SDK JavaScript framework. From their about section:
Ample SDK is a standard-based cross-browser JavaScript GUI Framework for building Rich Internet Applications. It employs XML technologies (such as XUL, SVG or HTML5) for UI layout, CSS for UI style and JavaScript for application logic. It equalizes browsers and brings technologies support to those missing any.
Examples from their website look very promising.
Did anybody try using this framework in real projects? Which are the pros and cons of working with Ample SDK?
I'm mainly interested in your subjective real usage experience, and not in the information already available at their web-site.
Another very subjective opinion from the creator of Ample SDK ;)
Pros:
Standard technologies and APIs make it simpler to take off
Markup-based UI is easy to create and maintain
Good separation of concerns - UI, Logic and Style
Easy to create new UI elements and entire languages
Non-obtrusive - only takes over designated areas on the HTML page
Cons:
Does not aid well development of web-sites (for which jQuery is just enough), it is mainly suitable for client-side apps that run in browser and communicate only data with server.
We've used Ample in one of the components of our Enterprise Application.
Advantages we've experienced:
Programming against well established API's (DOM, Dom Events) led to better code readability, more stable implementation of the end product, no programming against specific browsers.
The development cycle was also reduced by up to 50% of our normal development time.
The ability to create custom namespaces for component markup helped us to created a library of common UIComponents that can easily be changed,modified and used in all our future products
The separation of the concerns of the UIComponents and the Application by creating a custom language itself is one of the big advantages. We now only focus on implementing the business logic instead of skinning components and fixing view related problems. The Q&A cycles we're also much shorter than normally because of the stability of the end product
Disadvantages.
Hardly any. the framework is really stable and so far we did not ran into any problems with Ample.
I used in one project for the moment: http://www.programma.tv/.
As for that experience, I did not use any "UI language" (except XHTML, of course) from the A-SDK, just the core. Also I wrote custom UI language ("channels", "days", "items" and some more elements) and that was really simple in case you know javascript well.
But: think twice before implementing your own UI language (i.e. custom components) - maybe it'll be faster use something from the A-SDK?
Anyway, if you'll ask me to choose one word to summarise my opinion, I'd choose this one: "SIMPLE".
We are going to be producing a RIA that will also be available using Adobe AIR for database management and manipulation with a php back end.
In an effort to speed up development we have decided on using YUI or EXT JS.
It appears that EXT JS out of the box will produce a better looking application than YUI but being essentially 100% JS I can foresee the application being much slower on any computers that aren't...say...up to date.
I am looking for any benchmarks comparing the two frameworks for UI & AJAX operations or any input about the speed of real world RIA applications using either framework.
Thanks for your help.
EDIT So is the general consensus that for a RIA where speed of use is a primary concern YUI is the better option? Or is it essentially, either will work?
EDIT EDIT We decided to go with YUI2 thanks for your help!
Don't fall into the trap of premature optimization. If only a small percentage of your users will be using "older" browsers, they will just have to deal with the slowness of any modern js framework - whether you choose YUI or Ext JS. Choose based on features and ease of development and applicability to your project.
When it comes to library size and speed of download to the browser - whichever library you choose, it can be customized to only include the components you need. And in production, you'll be minimizing and compressing it, so I think library size is really NOT a good measuring stick for making these types of decisions.
I posted a topic at the Ext JS forum years ago asking why the Ext Js doesn't come in packages and we are forced to use the kitchen-sink (almost). Their answer was "Ext JS is for RIAS".
I don't know what this tells you but in terms of size Ext JS is "big enough". I would recommend it for intranet apps. If you are to use it for public sites use all optimization techniques available to achieve fast loading times, compression, etc.
I also used YUI for intranet applications and i can tell you that it was lighter since not all packages where required.
We used to work with a gwt wrapper for ExtJs (gwt-ext). We developed a lot of modules with that. At some point we experienced some slow performance, specially with grid when the data was huge. In addition some memory leak with IE. But after they changed their licence policy, we started looking to other options. Perhaps some of those problems are fixed now.
Any way, now we are developing with OpenLaszlo.
I hope it helps you
If you're thinking of using Ext JS be aware that the current version (4.0.XX) has been found to be significantly slower than version 3.4, see http://www.sencha.com/forum/showthread.php?140180.
I've used YUI. It's fast. The newest library is highly modularized, so you only load modules you need. Also you can refer libraries from publicly available hosting services provided by Yahoo; it offers CDN for free.
I've worked with YUI data tables (data grids) with over 4,000 records and it still performed at an acceptable level.
With the increased power of JavaScript frameworks like YUI, JQuery, and Prototype, and debugging tools like Firebug, doing an application entirely in browser-side JavaScript looks like a great way to make simple applications like puzzle games and specialized calculators.
Is there any downside to this other than exposing your source code? How should you handle data storage for this kind of program?
Edit: yes, Gears and cookies can be used for local storage, but you can't easily get access to files and other objects the user already has around. You also can't save data to a file for a user without having them invoke some browser feature like printing to PDF or saving page as a file.
I've written several application in JS including a spreadsheet.
Upside:
great language
short code-run-review cycle
DOM manipulation is great for UI design
clients on every computer (and phone)
Downside:
differences between browsers (especially IE)
code base scalability (with no intrinsic support for namespaces and classes)
no good debuggers (especially, again, for IE)
performance (even though great progress has been made with FireFox and Safari)
You need to write some server code as well.
Bottom line: Go for it. I did.
Another option for developing simple desktop like applications or games in JavaScript is Adobe AIR. You can build your app code in either HTML + JavaScript or using Flash/Flex or a combination of both. It has the advantage of being cross-platform (actually cross-platform, Linux, OS X, and Windows. Not just Windows and OS X).
Heck, it may be the only time in your career as a developer that you can write a web page and ONLY target ONE browser.
SproutCore is a wholly JavaScript-hosted application framework, borrowing concepts particularly from Cocoa (such as KVO) and Ruby on Rails (such as using a CLI generator for your models, views and controllers). It includes Prototype, but builds plenty of stuff such as sophisticated controls on top of that. Its Photos demo is arguably impressive (especially in Safari 3.1).
Greg already pointed you to Gears; in addition, HTML 5 will come with a standardized means of local storage. Safari 3.1 ships with an implementation where you have a per-site SQLite database with user-settable size maximums, as well as a built-in database browser with SQL querying. Unfortunately, it will be a long time until we can expect broad browser support. Until then, Gears is indeed an alternative (but not for Safari… yet!). For simpler storage, there is of course always cookies.
The downside to this would be that you are at the mercy of them having js enabled. I'm not sure that this is a big deal now. Virtually every browser supports js and has it enabled by default.
Of course the other downside would be performance. You are again at the mercy of the client handling all the intensive work. This also may not be that big of a deal, and would be dependent on the type of app you are building.
I've never used Gears, but it looks like it is worth a shot. The backup plan would be to run some server side script through ajax that dumps your data somewhere.
Not completely client side, but oh well.
Nihilogic (not my site) does a lot of stuff with Javascript. They even have several games that they've made in Javascript.
I've also seen a neat roguelike game made in Javascript. Unfortunately, I can't remember what it was called...
If you want to write a standalone JavaScript application, look at XULrunner. It's what Firefox is built on, but it is also built so that you can distribute it as an application runtime. You will write some of the interface in JavaScript and use JavaScript for your code.
Gears might provide the client-side persistent data storage you need. There isn't a terribly good way of not exposing your source code, though. You could obfuscate it but that only helps somewhat.
I've done simple apps like this for stuff like a Sudoku solver.
You might run into performance issues given that you're completely at the mercy of the client's Javascript interpreter. Gears would be a nice way of data storage, but I don't think it has penetrated the market that much. You could just use cookies if you're not fussy about that kind of thing.
I'm with ScottKoon here, Adobe AIR is great. I've really only made one really nice (imho) widget thus far, but I did so using jQuery and Prototype.js, which floored in such wonderful ways because I didn't have to learn a whole new event model. Adobe AIR is really sweet, the memory foot print isn't too bad, upgrading to a new version is built into AIR so it's almost automatic, and best of all it's cross-platform...they even have an alpha-version for Linux, but it works pretty well already on my Eee.
Standalone games in GWT:
http://gpokr.com/
http://kdice.com/
In regard to saving files from a javascript application:
I am really excited about the possibilities of client-side applications. Flash 10 introduced the ability to create files for save right in the browser. I thought it was super cool, so I built a javascript+flash component to wrap the saving feature. Right now it only works for creating text based files (vcard, ical, xml, html, css, etc.)
Downloadify Home Page
Source Code & Documentation on Github
See It In Use at Starter for jQuery
I am looking to add support for non-text files soon, but this is a start.
My RSS feeds have served me well- I found that Javascript roguelike!
It's called The Tombs of Asciiroth.
Given that you're going to be writing some server code anyway, it makes sense to keep storage on the server for a lot of domains (address books, poker scores, gui configuration, etc.,.) For anything the size of what you'll get in Webkit or Gears, you can probably also keep it on your server.
The advantage of keeping it on your server is two-fold:
You can integrate it fairly simply as a Model layer in a typical MVC framework, and,
Users get a consistent view without being tied to their browser/PC, or in a less-than-ideal environment (Internet Cafés).
The server code for handling this can also be fairly trivial, particularly if it's written with this task in mind, so it's not a huge cognitive burden.
Go with qooxdoo. They recently realsed 1.0, although most users of it say it was ripe for 1.0 at least two versions ago.
I compared qooxdoo with YUI and ext, and I think qooxdoo is the way to go for programmers - YUI isn't that polished as qooxdoo, from a programmer's point of view and ext has a not so friendly licensing model.
A few of the strong points (for me) of qooxdoo are:
extremely clean code
the nicest OO programming model I've seen among Javascript frameworks
an extremely rich UI widget library
It also features a test runner for unit tests, an API doc generator and reader, a logging facility, and several useful features for debugging, grouped under something called Inspector.
The only downside is that there aren't readymade themes (something like skins) for qooxdoo. But creating your own theme is quite easy.