Folks,
I am starting off to learn ExtJS. I had a look through Sencha's website. I went through some of the questions also already asked here.
But had some doubts,
What is the difference between ExtJS designer and Aptana ? Do we require both ?
How to start building your own 1st application in ExtJS ? Any tutorials for the total beginners.
Will I need to write JavaScript code manually or use a ExtJS designer to do that for me ?
Thanks.
I'll disagree a bit with the already-accepted answer.
They are both optional. I use neither.
OK, not too helpful. Aptana is a general-purpose IDE. It is based on Eclipse, but unlike vanilla Eclipse (which is Java-oriented) Aptana has lots of additions and plugins for doing JavaScript, PHP and other "web-centric" development. I actually use Aptana myself, even for Ext development, because it works for me. IDE discussions tend to get religious -- everyone has their own requirements and peeves, YMMV. Aptana does actually support framework-specific autocomplete, including for Ext JS (though I think they are still on an older version). Note that you can accomplish the same things as Aptana (generally-spekaing) using WebStorm, Komodo, NetBeans, TextMate or any old text editor -- just depends on what IDE-specific features you find helpful or not.
Ext Designer (now Sencha Architect) on the other hand is NOT a general-purpose IDE -- it is strictly intended as an Ext UI design tool. However, it does go beyond simply "placing widgets" on the page. You can easily drag-drop things into place and also preview how they will render, hook up data stores to databound widgets (again via simple drag/drop interactions), it includes context-specific config and property setting (which makes it much easier to know what options are available without having to refer to the API docs constantly), etc. Architect then generates classes, in best-practice code format, that you can drop into your app and then extend as needed with your own business logic. The output of Architect could basically become the input project for Aptana (or whatever) where you would build your application code (although many people stick exclusively to Architect).
Regarding tutorials, the docs site of Sencha.com was revamped recently and includes many tutorials updated for the most current versions of Ext. Of course the official examples are also a good place to start. The best book on Ext development is probably Jay Garcia's Ext JS in Action, though unfortunately it has not yet been updated for Ext 4 (he's currently working on that). It's a great overview of the concepts and best practices for Ext in general though, and a lot of what's in that book will still apply today.
Finally, while Architect will definitely get you started with good UI code, it will not wire your app together or write any business logic for you. For that, you'll have to use the existing tutorials and examples to help guide you to write your own code.
They are both optional. I use neither.
Depends on how “total” a beginner you are. Judging from your questions, I guess you aren’t familiar with JavaScript and web development in general. If that is the case, start by reading some tutorials on JavaScript and AJAX—you’ll need a solid grounding in those to make good use of Ext JS. I am yet to see a good tutorial for Ext JS (version 4) itself, and you’ll probably end up gathering pieces from the official docs, the Sencha blog, and the examples that ship with Ext JS.
You will have to write JavaScript (and maybe also HTML and CSS, depending on your scenario). The designer can only help you with placing widgets (like buttons or text boxes) on the page. In my experience so far, this has been the easy part, so unless you’re doing a complex user interface, you probably don’t need the designer.
Related
I have been a user of jQuery (and some of its minor plugins) for a while. The Javascript code I've developed over the years could be described best as... messy. It used a ton of global variables and functions here and there, didn't use standard ways of organizing the code, nor any design patterns whatsoever.
I am currently building the new version of a website, and I have completed doing the backend with PEAR::MDB2 and Smarty templates. The rest is just homebrew PHP with some classes.
Now I am at the point where I'll add the Javascript layer on top of the website to improve the user-friendliness of some features. (while making sure everything degrades gracefully) I want to write better, cleaner, more organized Javascript than I used to, so I did a little research. I read Stefanov's Object-Oriented Javascript to have a better grasp on some concepts I knew only loosely about (prototypes, constructors, etc.) as well. Now I'm stuck at a point where I wonder which Javascript frameworks I should use, and how to organize it all.
After conducting my research, I understood Cappuccino & Objective-J, and Sproutcore were not what I was looking for. To quote Cappucino's about page:
Cappuccino is not designed for building web sites, or making existing sites more "dynamic". We think these goals are too far removed from those of application development to be served well by a single framework. Projects like Prototype and jQuery are excellent at those tasks
So there's that. Then I found out about Coffee Script, which is more of a one-to-one "compiler" and wouldn't help me with the actual organization of my code.
I also stumbled on some articles that give guidelines:
Using Inheritance Patterns to Organize Large jQuery Applications
A JavaScript Module Pattern
I also found out about Backbone.js, Shoestring, JavaScriptMVC, Google Loader, jQuery Tools, jQuery UI. I don't really know what to do of all this... The things I know:
I don't want to invest too much time in learning something too complex, I want to keep things simple and flexible as much as possible (that is why I don't use Symfony on the backend, for example), yet clean and organized.
I want to use jQuery, the question is, what should I use with it? (that is compatible too)
Right now, I'd use jQuery and jQuery Tools and "organize" all that in a simple namespace/object literal with simple properties and methods and also, since the site is localized, I just plan on using the simple vsprintf (as I do on the backend) with key:value pairs loaded from an object literal provided by the backend. JavaScriptMVC seems interesting, but I fear it would bring way too much complexity for a project that is fairly small sized. That is where I need your advice! Thank you very much in advance.
Ok, my attempt at an answer:
There is no 'best' to way to do it. You now know what's there and I think you might have a preference for yourself for what you want. In that case, pick a framework and learn it inside-out. (sorry to burst your bubble, but each framework has a learning curve, some steep, some very easy, but in the end to use it well you have to invest in it. Just do it, you won't be sorry).
You of course have an preference for clean code, so you might take some considerations into account. You also say you have a preference for jQuery, which is fine, but there are some limitations (as also pointed out in the link provided by eskimoblood).
There are some nice lectures / and tutorials with advice on how to structure your code in jQuery:
How to manage large jquery apps
On Large jQuery apps
Essential Javascript and jQuery patterns (free ebook)
Some style guides:
Jquery core UI Styleguide
Google Closure Javascript Style Guide
Tools for checking your code
JSLint
JSHint (a more forgiving/practical fork)
Closure Linter (haven't tried it yet, but intend to)
Standard works (javascript)
Everything by Douglas Crockford
Quirksmode
There might be more.. perhaps more people can contribute, but I also think that you've almost reached the end of what you can learn before getting your hands dirty. Many of these guides are written in a very generic way, but the interesting thing is that javascript is called upon in many specific situations. It might be useful to just post some of the code that you regard as "messy" and we can help you figure out how to do it better. Good luck!
You should watch the video and read the links in this article and then you should ask yourself again if jquery is the right tool. Maybe you will use dojo, that is much better for larger projects or you take a look at backbone and where you can stay with jquery. After all both of them are more "javascriptish" then something like sproutcore, cappuciono or even GWT. And also much easier to understand when you come from jquery.
One framework that is to consider is definitely ReactJS from Facebook. This framework is pretty slick in many ways.
First thing you have to know is that it is a view framework. It can be used server-side to do the pre-rendering of pages, but it really shines on client side. Since it's a view framework, it can be used with backbone or any other "back-front"-end framework.
One of the main point of React is its rapidity. It keeps a virtual DOM in memory and virtualize all the webpages events. So the virtuals event are used to keep events browser agnostics.
The virtual DOM kind of make programming a dynamic site as if you were programming an old static website. You can just shoot the whole HTML to render to the view engine (as if you were "re-rendering" the whole page) and it will manage the DOM operations. It does a diff between the new virtual DOM and the current virtual DOM and only inserts nodes that needs to be inserted. This way you reduce the number of DOM ops and thus increase your render speed by a lot.
A good place to start is this tutorial which shows how to use "Flux" (the web flow designed by Facebook for its site) in order to realize a Todo application!
Ext.js is of interest to me because it appears to have a fairly complete widget set (though I've certainly run into shortcomings of the widgets after a very short time). The problems I potentially have with it, however, include these:
in my opinion it's very ugly, and looks like a cross between a Windows UI and some PHP content management system (yes I know I can write my own theme, but there may be limits to what I can change, and it may not be as easy as it should be, and I'd rather work with something that is clean, elegant, and attractive out of the box.)
the graphs currently use Flash, which limits the clients it can be useful on (version 4 promises to resolve this problem)
the license is a bit restrictive, which is not an issue now, but it makes me think twice about becoming intimately familiar with a tool that I may not be able to use in the future.
Honestly the look & feel is probably the biggest issue to me: I've seen in the past that developers (or companies) who don't place a high value on aesthetics often can't be bothered by other 'details' either.
So: is there a other better alternative?
UPDATE:
Another problem with Ext.js, is that it seems to be an all-or-nothing proposition. That's one reason I'm not looking seriously at SproutCore, which in other respects is awesome. (Well... it needs some performance improvements, but it'll get there eventually I think...)
Cappuccino seems to be the same way: you're not using it on a web page, rather you're building a Cappuccino app that just happens to use the web as its runtime environment.
In other words, ideally I don't want a JS version of Flex: it's own little walled garden. jQueryUI would be ideal if it were more complete, since it doesn't break with normal web development methods and paradigms. But if walled gardens are all there are, I'll live with it.
If you are looking for a RIA-Framework you shouldn't use jQuery(UI). Instead use one of the following frameworks.
Qooxdoo (www.qooxdoo.org): Pure Open-Source RIA-Framework with the most of the features of ExtJS. There were coming up some interessting new themes in the last weeks
Cappuccino (http://cappuccino.org): Nice framework with a nice GUI
ZK (http://www.zkoss.org/): ExtJS like RIA-Framework
SproutCore (http://www.sproutcore.com/): Apple-Style RIA-Framework
I undestand your pain - I use to got same - in ExtJS I saw only problems (those what you mentioned, and belive me much more others), however because I was a little forced to use it, I started to use it and I followed in love - It very complex and optimal solution for javascript driven apps.
You can go and look for alternatives like jQuery (I was there for 1 year), dojo, and others frameworks, but whoever says that they are better than ExtJS, he rather did not have ..... time to know ExtJS
It my very subjective opinion
I dont know much about PHP, and I am using ExtJS with ASP.Net MVC, they fit well. I wish I could use an integrated JS Widget set, but Jquery UI widget set was not rich enough when I last evaluated and I dont think it still is. But it is at least included in the last version of MVC.
My only complain about ExtJS would be the number of user extension controls that you need to use, I'd like to see those as part of ExtJS core widget set, but they are not, but still distributed with the library. ExtJS is a very nice fit for a cross-platform Rich Web Application. I would recommend trying ExtJS, I have really no complains about it other that what I already said above.
I would like your opinion about these two frameworks. I like a lot the features of ExtJS, but recently I saw SmartClient and it seems to be great too, and free (its Client side features) for commercial projects. I tried a little of SmartClient and it seems to be easier than ExtJS, and it has a better documentation tnan ExtJS.
BUT.. I didn't work with any of these frameworks and maybe I'm wrong. That's why I would like the opinion of people who has worked with them.
And BTW.. how does the license of ExtJS work? you've to but one license for each developer and then you're able to develop and sell every app you want or you have to buy a license for each app you sell?
Thanks in advance for your help.
This has been pretty well covered on SO. Specifically here and here.
Ext JS is licensed per developer not per app.
I'm an Ext JS developer so I'm partial to Ext, but I have no opinion of SmartClient good or bad. If licensing is the most important criterion SmartClient might be better for you. If you want to weight the technical merits see the links above, or even better evaluate them both based on your own needs.
I use SmartClient and am quite happy with it and the support provided by Isomorphic. The U/I widgets aren't the nicest out there, but you can see that they've been around for some time by the richness of their API.
It's also quite easy to roll out your own custom controls when the built-in ones don't suit your needs. For example, we integrated Raphael pie chart SVG drawings inside custom Isomorphic canvas classes. We also integrated Mondrian/JPivot analytical technologies which are legacy JSP pages, using Smartclient's HtmlFlow control. It's quite powerful what can be achieved.
One thing I regret about Smartclient versus other technologies such as jQuery, is a clearer separation between the work a web designer does versus the work a developer/programmer does.
With Smartclient, it's mostly done thru code, even the layout of components. There's no HTML per say. They've separated very well the skinning (css), but that's about it. Everything else needs to be done by a developer/programmer thru Javascript code. Smartclient is good for single-page apps.
I can't speak for ExtJS as I haven't used it real production environments, but in the end I think it all boils down to the licensing model and programing/design model you want to be using.
I have used both, and I would recommend Ext for the following reasons:
Layout flow is much easier, especially with the design tools.
The UI Builder from Isomorphic lacks the usability that the tool from Ext offers
The Javascript performance was better with Ext
CSS is easier to use with the Ext framework
Editing CSS/Themes/Skins in SmartGWT/SmartClient is major surgery (very tedious and time consuming)
Widgets are similar but "prettier" in Ext
Forum administrators on both sites can be "snippy", however premium support did not change
this on the Isomorphic site. They are rude and condescending even when you pay.
Ext has a dedicated MVC framework. The Isomorphic framework does not.
SmartClient charting DOES NOT support negative number values
Before starting new GUI for our new project arrival, I made some research.
Here are my findings (remove spaces from "http: // "; bcoz stackoverflow is preventing me to do so :)):
Prototype framework favorable links:
http://en.wikipedia.org/wiki/List_of_Ajax_frameworks
http://www.javabeat.net/articles/12-comparison-of-ajax-frameworks-prototype-gwt-dwr-and-1.html
http://www.devx.com/AJAXRoundup/Article/33209
Dojo framework favorable links:
http://blog.creonfx.com/javascript/dojo-vs-jquery-vs-mootools-vs-prototype-performance-comparison
jQuery framework favorable links:
http://blog.creonfx.com/javascript/mootools-vs-jquery-vs-prototype-vs-yui-vs-dojo-comparison-revised
Test speed of different RIA frameworks:
http://mootools.net/slickspeed/#
More comparasions:
http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks
http://jqueryvsmootools.com/#conclusion
Out of all these findings I started using SmartClient 5. Initially we faced some issues but as SmartClient matures I find it interesting in many terms:
1. APIs doc help and examples
2. Flexible controls
3. Forum
Today I am working on SmartClient 8 and few on my GUIs are in production running successfully. Actually the great help with SmartClient is that you find every thing at one place. No need to dug many other sites that is hard to do for any other open source RIA framework.
So my choice is no doubt SmartClient.
Thanks
Shailendra (shaILU)
I would prefer Jquery UI. Which is supported well by community. By combining plugins you can get similar -if not better- screens provided by extJS and SmartClient.
I am developing my first ASP.NET MVC application and I beleive that Script# can help me a lot. But it cannot find the resource necessary to support my development.
I could not find The codeplex site;
There is only one manual, which is very good, but it is not enough;
I could find very few tutorials;
I know that Script# was used to develop ASP.NET MVC scripts and that the source of MVC distributes the library.
But it seems that it is used only internally in Microsoft.
Where can I find other resources???
Do you really think that Script# will be continued and new versions will be deployed and it should be used by third-party projetcs ???
Thanks in advance
Don't be afraid of Javascript, it's a beautiful and powerful language. And with frameworks like jQuery, Prototype and Dojo, DOM manipulation and AJAX are greatly simplified and cross-browser issues are mostly history.
About Script#, I agree with this answer by mcintyre321. Last release over a year ago + closed source = no go for me.
UPDATE Jan/2010: there have been new Script# releases since the original writing of this answer. It's still closed-source but the author mentions open sourcing it after 1.0
UPDATE May 2011: Script# is now open source.
In short, my answer is: if you like powerful IDEs that run on Windows, OOD and C#, use ScriptSharp. It is more maintainable and structured, and demonstrably stable enough to use on serious projects. It can also be easily extended, as illustrated below and by other projects.
Since this is yet another Google indexed thread where people refer to Script# and jQuery as mutually exclusive I just wanted to point out some people are merging these two worlds, and in my case unleashing a lot of power by doing so. I'm offering a completely free and reusable library to access jQuery 1.4 from Script# projects, and full source code for the solution that generates it (almost exclusively from jQuery's own API documentation file):
http://www.christophercrooker.com/visual-studio-2010-rc-custom-tool-for-code-generation-and-jquery14-with-intellisense-for-scriptsharp
IMHO Script# fits well for large projects only, with really "rich" web client. Participating in such kind of project, I could only say that Script# helped us much. josephhemingway's remark about strongly typed is 100% true for such case. Also it allowed us to introduce new .NET developers without any JS background quickly. Assuming Nikhil Kothari's plans to open-source it in the summer 2008, we even decompiled (don't tell anybody! it's illegal) it and introduced generics, operators overloads, various bug fixes, etc.
BUT. Then Script# support faded away. Project on CodePlex with discussions and issue tracking was closed (interesting that parts of framework were published there shortly before). No updates, no future plans, no explanations. After such thing I'd consider Script# only after it goes open source to give the community ability to support it. E.g. on CodePlex.
I use Script#, I think it is great. You can use it with any framework, jQuery, dojo whatever, you would however have to wrap the framework, this could be a big job...
It's only benefit as I see it is that it allows you to develop javascript in a strongly typed environment. I think this is a HUGE benefit. I refuse to develop in weakly typed languages as maintenance is a nightmare.
If however you like to work in a weakly typed language then you wont need Script#.
Short answer NO. Wait for TypeScript.
Script# is really cool, but MS decided not to support it at all. The reason for that turns out to be that they were working on a better version of that - TypeScript (http://www.typescriptlang.org/)
It adds support for everything you need in a static language (intellisense, type checking, interfaces, classes etc.), but still looks very much like JS, and more importantly - confirms to the upcoming ECMA Script 6 standard. (unlike Script# or google's Dart)
Like the others have I would recommend some JavaScript (namely jQuery). Should you wish to continue with Script#, Nikhil Kothari's blog may be a good resource for you. http://www.nikhilk.net/ScriptSharpIntro.aspx -- That being said, I think you'll find that you are more productive with jQuery. There is a large database of community written plugins so you wouldn't necessarily have to reinvent the wheel on everything you want to do. jQuery plugins instead of ASP.NET Controls
Wow Val you got generics to work in
it, I'm impressed, was it hard?
Generics support would be great, so
would method and operator overloading.
josephhemingway
The whole point is that ScriptSharp's parser supports full C# 2.0 syntax. The only thing needed is to generate the proper JS. Not much work, considering JS dynamic nature. Generics would act as Java-style ones, i.e. no generation for each closed type argument set, just one class.
Are you sure that it is illegal to
decompile it, I will have to have a
look to see if it is the terms of use.
josephhemingway
Yep, it's illegal. EULA showed in setup clearly mentions that.
A release went out today, so it is good to see that it is still active.
Regardless of the previous lack of updates and that it not been open sourced I would still use it over plain js. You can stop using Script# at any time and more forward with the 'compiled' js if you don't like it.
I agree with you Val though that it really only fits large js based projects. I don't think you would get much benefit out of using it to perform basic page functionality like validate form input etc. It probably wouldn't be worth setting it up.
If however you are heavily using javascript and need to replicate OOP then I think it is a must. Things like refactoring becomes so easy, with plain js I would never refactor because it was just too hard to implement, over time my code became a mess.
Wow Val you got generics to work in it, I'm impressed, was it hard? Generics support would be great, so would method and operator overloading. Are you sure that it is illegal to decompile it, I will have to have a look to see if it is the terms of use.
The other advantage of using ScriptSharp that no one has mentioned is that if you need to interact with C# (using AJAX/REST/SOAP) you can use the same class definitions in both places and be sure that you have the interface defined properly, because it's the same source file! I have tried to use logic in shared source files with minimal success due to the way ScriptSharp's corelib is not 100% compatible with the C# corelib. But it works great for data file definitions.
I am using jQuery. It is really good. But I beleive that It is more confortable to me to work with C#. Even if it is a subset.
Also I would like to add that you certainly should use ScripSharp when you are planning to develop multiplatform projects. For example, at present time I write my image processing library code for .NET, JavaScript (ScriptSharp), Android (Mono) platforms on C#. Also I am planning to port my code on iOS (Mono) and Windows Phone in the future. And I think it's great code reusing and developer time minimization!
There's some discussion at my work about using Jack Slocum's EXTjs library as an extension to YUI (already in use) for a project in development. I'd like to help avoid a dependence on EXTjs's commercial licensing model if possible.
The primary two features desired from EXTjs are EditorGridPanel and ColumnTree.
As far as I can see, it looks like YUI since 2.6.0 has added EditorGridPanel functionality to their DataGrid. Is there some major caveat to using YUI's built-in functionality? Is there something still way slicker about EditorGridPanel?
As for ColumnTree... I don't see any easy YUI replacement for this feature set. Is there something in YUI that does this that I'm not seeing? Is there some other good option now that YUI is barely in use?
Is it best to just bite the bullet and pay for EXTjs (and deal with the commercial license dependence) for this kind of functionality?
I was looking for ExtJS alternatives like you. I'm intended to develope a Web Based application using Frameworks to avoid wasting valuable time.
You were too close to find the right page, here it is:
[What are alternatives to ExtJS?
Read the above article first, then you may want to see this other links:
BackBase
[http://demo.backbase.com/explorer/]
[http://demo.backbase.com/layouts/]
[http://demo.backbase.com/layouts/layout7/index.html]
jQuery
[http://ui.jquery.com/home]
qooxdoo
[http://qooxdoo.org/]
[http://demo.qooxdoo.org/current/demobrowser/]
[http://ui.jquery.com/themeroller/]
Good luck
My employer recently went through a similar evaluation with regard to the EXT widget library. Our criteria were slightly different in that we were looking for a widget library that would plug into GWT and provide a more polished widget set than those provided by the default GWT implementation. After a month of evaluation, our team concluded that the EXT license fees are a small price to pay for the functionality gained. Again, we're not using the raw javascript library, but we have been very pleased with GXT. In my opinion the library is a bit under-documented but it does work solidly across different browsers. One thing for sure, their editor grid is very slick.