In a recent conversation, I mentioned that I was using JavaScript for a web application. That comment prompted a response: "You should use Flex instead. It will cut your development time down and JavaScript is too hard to debug and maintain. You need to use the right tool for the right job." Now, I don't know too much about Flex, but I personally don't feel like JavaScript is too hard to debug or maintain, especially if you use a framework. JavaScript is also one of the most used languages right now, so it would seem a better choice in that regard too. However, his reply piqued my interest. Would Flex be a good choice for a distributable web app for which 3rd party developers could build add-ons? What are the advantages of using it vs. a JavaScript framework? What are some of the disadvantages?
I have recently started to develop Flex applications, and I personally find it a refreshing framework for the web.
You get a state-ful application that runs completely client side. You get no worries about cross-browser portability that you do with JavaScript, and you get some really neat things such as effects, graphing, and rich user interface components.
Flex also makes it easy to communicate to webservices and the XML parsing via ECMA is insanely powerful and simple.
I'm glad I have made the switch. As far as how popular it is...I'm not really sure, but I am fairly certain that the developer base is expanding rapidly.
The only real disadvantage I can think of is a flash player requirement, but I would say it is pretty safe to assume that most browser support flash player; even konquerer in Linux is supported; much more so then a silverlight runtime (which I NEVER plan on installing)
Here is my experience: you really need to consider 2 things separately - development and the end-user experience. Flex shines in the first area:
ActionScript is a nice mixture of Java and JavaScript so you get a familiar language with strong support for OOP
debugging is far easier than what you can achieve in JavaScript
Flex framework is component-oriented and event-driven which helps in creating rich user interfaces (HTML was not really created to support application UI scenarios)
On the other hand, the end-user experience is worse when running a Flex app compared to an AJAX app. First, you need to have Flash Player installed but this is probably not an issue for most computers today. Bigger problems are with usability - Flash Player handles all UI interactions (instead of a browser) so the password manager doesn't work, text fields don't remember previous entries, Ctrl+T and middle-clicking doesn't work, text search doesn't work etc. etc.
My advice would be - if you are developing an application (rich UI, relatively separated from the rest of the web), go for Flex as it will save you time, money and will make your users happier by providing richer functionality and shorter periods between new versions. On the other hand, if your application needs to be tightly integrated with the web and you want your users to be able to use features of their browsers, go with AJAX.
Nice example is Google Docs vs Buzzword. Buzzword is much more feature rich (for instance, text can flow around an image from both sides which is something you could never ever achieve in DHTML) but Google still decided to go for an AJAX version because they are the "web company". There is no right or wrong in doing it the one or the other way, it's just different and it's important to consider who your end users are.
I would push you towards standard web development technologies in most cases. Javascript is no longer a great challenge to debug or maintain with good libs like jQuery/Prototype to iron out some of the browser inconsistencies and tools like Firebug and the MS script debugger to help with debugging.
There are cases when Flash is a better option, but only in cases where you are doing complex animations. And, if you are willing to invest the effort, most animations can be achieved without resorting to flash. A couple of examples...
Flash content is not as accessible as other content.
This will not only affect people with out flash, but also search engine spiders. There may be some hacks to help get around this now, but I think that most flash content will never be indexed by google.
Flash breaks the web UI.
For example:
If I click my mouse wheel on a link,
that link is opened in a background
tab. In a flash app there is no way
to simulate this behavior.
If I select text in my browser and
right-click I get options provided
by the browser that include things
like "Search Google for this text".
In a flash app those options are no
longer there.
If I right click on a link or an
image I get a different set of
options that are not available in a
flash app. This can be very
frustrating to a user who is not
"flash savvy".
GWT lets you do the same stuff as Flex for the most part, and handles all the browser compatibility issues, AND lets you code/debug in Java with your favorite IDE.
All without having to learn a new language (or pay Adobe $$$ for the flex IDE you'll need to do anything real).
Flex has some prettier UI widgets than GWT has out of the box, but there's a ton of 3rd party widgets (such as GWT-EXT-JS) you can use - or, you can use your existing favorite JS widgets with GWT.
Check it out if you haven't: http://code.google.com/webtoolkit/
I can't be sure if it was myself, or someone else who made that statement but I would definitely be one to say 'use the right tool for the job'.
Flex has a large community behind it, and is well hyped by Adobe's platform evangelism team. Now, as far as replacing JavaScript, that sounds like a very broad spectrum discussion point. Flex is not a replacement for JavaScript. What it does, it does well, however. That is, 3D, drawing, and data rendering whether in chart or table form. Flex also has the power of ActionScript 3 behind it which allows you to do much of what Flash does in cooperation with the MXML frontend components without ever touching the timeline or keyframes.
In a way, Flex is the .NET of Flash and Rich Internet Application development. It uses the same datasource concepts, and component focused design structures which make it easy, and fast to develop in.
The real question is, what are you trying to achieve? What is the end goal?
As to the debugging point, Flex has a true debugger and profiler within the Flex Builder IDE. JavaScript, unfortunately, has different syntax and execution between browsers due to the nature of JavaScript engines in modern browsers. Flex, because it is essentially Flash, uses the same rendering engine in all browsers due to the use of the Flash plugin.
Hope that clears a few things up. :)
Flex has a lot of extra overhead:
New language
Clients must have flash installed (might need to install, might not be able to)
Clients must download flex framework (few hundred kilobytes)
Flex content is not indexed by search engines (contrary to what Google might claim)
Flex has one main advantage:
- Better at building rich interfaces (see Picnik.com, etc)
For example, in Flex, it is easy to create a custom styled dialog box, complete with drop shadows, inner glows, animated open, whatever you might want.
In summary, use Flex if you need the extra richness.
Aside from what's already been mentioned here, another major difference is that JavaScript is dynamically typed and ActionScript is statically typed. Whether that's good or bad will depend on your point of view :).
If you want your web application to look like it's not a web application, Flex is pretty good. You also get to sidestep all the messiness of making HTML+JS look like a real app. For something which is essentially a website, Flex might not be the best choice, but if you really want to write an application which happens to be accessed through the browser, it's quick to develop with and gives great looking results.
You should try Google Gears instead. Create your application, add some Gears to it, and you can greatly increase the speed (and reliability) of your application.
http://gears.google.com/
Essentially Google gears gives you access to two useful things for any application: offline data storage, and native threading control (allowing updates/computations to run in the background and not slow down the users computer).
The really nice thing is, you can use whatever Framework you like for your application, as long as data storage/retrieval and server side communication is handled with JavaScript.
It also allows you to cache whatever files client side you want, which is especially useful when you want to avoid that 'flickering' look in the browser while some needed image is being downloaded by the browser.
A few reasons to consider Flex:
The control library is much richer in Flex than anything you can do with JS/DHTML. The charting controls are killer for business apps and things like the DataGrid / AdvancedDataGrid are pretty well ahead of anything you can do with HTML.
The Flex framework was designed for building applications. It abstracts away the "frame-based" concepts in the Flash Player to really make it easy to build apps. It has a well-designed component hierarchy that makes it easy to extend any of the standard controls. It also has a pretty intuitive event model for handles user inputs and makes it easy to have any of your controls dispatch custom events that can bubble up to parent components or get routed through a central event dispatcher. While it may be possible to do this with JS/DHTML, I don't think it's nearly as easy and it certainly wasn't designed for it.
You can take a Flex application and quickly deploy it to the desktop with the AIR runtime. AIR also offers additional APIs for things like local system access, embedded SQLite DB, etc. Gears offers something similar but it does require a browser. Granted, AIR requires the AIR runtime but at least it's purposed towards building desktop apps.
You can build a very rich, very sexy UI that will knock your users socks' off. As programmers we might not care about UX but our users do. Part of the reason why Apple is having a lot of success lately is because they really value UX and users/consumers are taking note of this.
The biggest con I think is that if you are really used to Java or C#, the ActionScript language will seem a bit limiting. If you're comparing it JavaScript, it's at par or maybe slightly better.
A lot of people will rail on Flash Player (or AIR) because it's not "standard-based." If we were only willing to use sites that were 100% standards compliant and free of plugins, we wouldn't have YouTube today. Or pretty much any other site that does interesting data visualization you can't do with HTML/JS (or at least, not with a sane level of effort). Adobe has been pretty progressive in opening up the Flex framework, Blaze DS (for backend Java development), publishing the AMF spec and starting the Open Screen Alliance to push Flash Player to mobile devices. Flash Player, Flex, Flex Builder and Blaze DS all have public JIRA bug trackers. I'd say there is a good chance that Flash Player itself will be open source within the next 2-3 years. I think Adobe is continuing to move towards being very open and that the criticisms of the platform being "closed" and "proprietary" are becoming less relevant. I think if developers approach Flex/FP with an open mind that they would really be impressed with how it all fits together.
This comparison table was good enough to make me decide what to use . I prefered javascript:)
http://askmeflash.com/article_m.php?p=article&id=11
Related
For a quite long time I was used to use the Flash Builder (previously called "Flex") enviroment to build complex applications, and in my current project (cant say what project is, sory) Im part of a RIA made in Flex, using mxml, AS3, some JS, etc.
The performance is below average.
The site feels like u need a powerful PC to run it something close to smooth.
And Im working with very talented ppl here, or at least thats what I can perceive.
So my question is, there is a posibility that the next version of the website will be made in pure HTML + CSS + JS, to obtain a more responsive feeling when u use the site, is something at least close to what FB can do for you in terms of a project-oriented enviroment?
On another hand, this general laggy and low performance thing is a programmer related issue, or it cant be avoided since "its just Flash" ?
Thanks!
(Im a big fan of flash tbh, but I try to keep my mind open in this)
Everything depends on what you're trying to do and if your programmers know how do to their jobs. If they don't take care, then it's very easy to create an application in Flash, and especially Flex (as you really need to know the internals of Flex to understand what it will do and when), that saps memory and power so that you need a beast of a machine to run it. Optimisation is a large topic, but fortunately, the web is covered in links on what not to do, or tips on how to use Flash to it's full potential.
As a quick test, open up the task manager, then run your app (close down all other programs using flash, including gmail, web radio etc), then watch the memory usage. If it's continually climbing, then there's a problem in your code.
Alternatively, if you have a bit more time, build some debug tools into your app so you can see what's going on in terms of framerate and memory usage - try the FlashPreloadProfiler for a quick fix: http://jpauclair.net/flashpreloadprofiler/
If your app shouldn't be complex but it's lagging (by complex, I don't mean the actual purpose of the app, but rather what it's showing on the screen, effects etc), then the problem is that there's misuse somewhere.
Go the HTML5 route if you feel it's the best solution for your site/app, but you'll probably encounter the same problems. In some situations, it's slower, in others Flash wins by a country mile. Again, it comes down to the devs
We built Dedoose in Flash Buidler 4, check it out... the performance is freaking great, and it's is a GIANT web app that handles an enormous amount of data. Flash Player in general does have performance problems, but with great engineering and knowledge of how to squeeze good performance out of it, I personally do not see a better alternative, excerpt for maybe silverlight if your requirements fit. For guidance on performance improvements a good place to start is all of Grant Skinner's articles over at http://gskinner.com/blog
Additionally, I can't really see what the actual question your asking is, what are the alternatives? HTML5+CSS is good, but good luck getting any good productivity out of your team developing a large scale web app in it. Silverlight is pretty dang good if you can force plugins down the users throat, Java is suffers the same dilemna. Personally I would read up more on getting good performance out of flash, then learn exactly how the flex framework works in terms of what it builts upon flash with, then... if u want real performance, ditch most of the flex framework and use things like MinimalComps and custom built components. Have you used the Flex Builder Profiler to analyze where your slow downs are occuring?
~ JT
If it's just an IDE you want, I'll give a nod to Flash Develop: http://www.flashdevelop.org/wikidocs/index.php?title=Main_Page
Not all the power of Flash (Flex) Builder, and without the design view. But it's free, open source, and community driven. I personally prefer the style of context highlighting and code completion hints in Flash Develop.
I'm looking into creating a Rich Internet Application. For the interface, I want something smooth, fast, and robust. I realize there are several technologies out there to do just that (Flex, standard HTML/Javascript, Silverlight).
After using Grooveshark, I am very impressed with its interface (written in Flex). Personally, I don't think I have seen an interface written in standard HTML/Javascript that is that visually stunning, smooth, and fast.
However, I have heard many arguments against using Flex with many believing Flash will eventually fade away.
Anyway, I have seen solid applications built with each, and I know a decision can depend on many things. But, in general, what are the pros/cons for each technology and which one would you ultimately choose for your RIA?
NOTE: This would be an open web application with the intended audience being anyone. It's not being built for specific client(s).
I would make the decision based upon my client(s). For general "web stuff", I still am opposed to RIAs (I think they have more of a purpose in a rich client to a particular market, e.g. business -- or filling out online taxes returns -- and not general pleasure/browsing/navigating/site).
As far as Flash "fading away" -- haha. Yeah, right. We still have COBOL and Shockwave. A product with 99%+ market dominance (depends on market, of course) is hardly bound to "fade away" overnight. When the "eventual" does come, nobody will care about this next RIA project of yours anyway :-)
with many believing Flash will eventually fade away
Sure, just like any technology, Flash will fade out at some time. But that won't happen in the near future, so it would be a stupid argument not to use Flash (in the same way you could stop developing things for »insert any technology here«).
I know this won't be a real answer as you want some more comparison of the current RIA technologies, but it is hard to do that anyway. In some way, you can build any application with both Flash and JavaScript. For more complex application both will require quite a lot customization to get the application running the way you want it. At that point Flash might have a small pro point given that you have a bit more powerful language with it than JavaScript (which still has performance problems depending on the browser, while Flash is more or less stable), and generally don't need to build anything on HTML's elements. But in the end, you can stil do it with both, so maybe you should decide based on your actual knowledge with the respective language instead (or base the decision on the client).
I think you are right in saying that Flex/Flash applications far outshine their HTML/JavaScript counterparts as far as UX is concerned. However, the main drawbacks are mobile and accessibility. Flash currently has poor reach on mobile platforms, but that shows signs of improving. Also I don't think most screen readers can deal with Flash. Silverlight is probably just as good, but it's not used as much and does not have nearly the user base of Flash.
I don't think I have seen an interface
written in standard HTML/Javascript
that is that visually stunning.
I'm not a big fan of writing raw HTML/JavaScript because it's SO much effort to make it look as slick as some of the Adobe stuff. However, there are some pretty decent frameworks and abstraction layers that let you get a visually stunning front-end, and let you write the while thing almost exclusively in Java. I've had success with SmartClient/SmartGWT in the past to make an iGoogle-esque portlet web application.
Pros: Google Web Toolkit + Eclipse is free, don't have to write much raw HTML/JavaScript, saves a TON of dev time, aren't locked in to an Adobe product, GWT compiles to HTML+JavaScript and is absolutely universal
Cons: the high-end professional and enterprise versions are not particularly cheap (~2K USD)
HTML+CSS+Javascript is a good solution. And maybe you should consider your RIA can across device and platform. Test some javascript framewoks first, especially those with RAD UI Tools, For example, CrossUI.
Nowadays, RIAs should migrate to full JavaScript UI with CSS skinning.
The task of building the UI should be analogous with these of the old tools like Visual Basic or Borland Delphi. This means almost entirely configuration instead of hand-writing the interface code.
You should also consider choosing a consistent widget set the follows the way of web components, i.e. inheriting from Element to always stay in sync with browser technology changes.
Here is a tool to help you evaluate several frameworks:
https://sourceforge.net/projects/jul-designer/
Remember, following the standards and eventually anticipating them, is the best way to go.
I would like to know, how powerful/viable are JavaScript only clients based on say, GWT/gxt/vaadin, when compared to DHTML clients such as those made with wicket, tapestry, click etc?
My boss has insisted on using GXT (due to its nice colors and theme) on a project that will most likely become very big with lots of screens. I am against the idea of a javascript only client, especially when the javascript is generated from Java code. I have tried to advice him that we use something like wicket whereby we construct the screens with html but put in ajax where and when neccessary.
How viable is such a JavaScript client? I understand that JavaScript was intended for minor web page enhancements, and not all browsers, especially mobile devices have complete support for JavaScript.
Yes, it is viable for certain applications. Consider Gmail, Google Docs and Google Maps as typical applications where this works, and is probably the most feasible approach.
Some rich UI JavaScript frameworks, such as Ext JS also rely on this technique.
I've built javascript only web apps for ages.
First in SAP projects for big multinationals. And now on a new project:https://beebole-apps.com?demo
So yes it is powerful and viable.
Javascript-only webapp can be extremely powerful, and it's viable for certain applications, say, an Instant-Messenger webapp?
You mentioned that there are lots of screens in your web-app. One of the advantages from GWT/GXT is the fact that you can unit test your UI-layer with JUnit. This is an extra testing you can do on top of, say, Selenium. This is essential if you'd like to make UI testing a part of the continuous integration process, and, as the team grows, you'll definitely want to have tests around to make sure everything works (At least in theory.)
However, if what your boss meant to do is to build an in-house, custom Javascript engine using GWT's JavaScript Native Interface (Link), then I'm not sure...
Another advantage with GWT-like-engine over Wicket is that you can rely on HTML-code-gen to generate standard-compliant (In theory) HTML code. With framework like Wicket, it is hard to ensure every single developer on the team to author good HTML code - Especially when the team gets bigger.
Disclaimer: I'm a member of the Vaadin team.
Our Timeline demo is a good example of what can be achieved with Vaadin and GWT in client side, but I think all of the options presented in this discussions are viable given enough time.
Since you are going to start a big project you should build a simple proof-of-concept app with each of the relevant frameworks. If your PoC includes at least some of the more complex use cases you'll probably can make a pretty informed choice based on the experiences you get while building them.
I urge you to at least evaluate Vaadin. With it you write only server-side Java code and Vaadin will create a slick and professional browser UI for you. Client side can be easily extended using standard GWT (also pure Java), and there are no HTML templates, tag libraries or XML configuration involved at all. A Vaadin UI is fully Ajax'ed and lazy loading out of the box, and it easily integrates with any server side technologies, eg. Spring.
In addition to the development model advantages you get top-notch documentation, a bi-weekly update schedule, a very lively community filled with helpful experts, 100+ useful open source add-ons, and a 10 year old backing company with help on hand should you need it.
I have started using ajax/jQuery in our websites / application. There are many plugins that support degrading the javascript to browsers that dont have javascript enabled and techniques to support this. What are peoples thoughts on javascript support, we build applications rather than just websites and are looking to just support javascript enabled browsers as a pre-requisite assuming that most people or companies have javascript enabled.
Do you find most people have javascript? do you monitor the percentage of javascript/non-javascript browsers (I guess this can be done with website stats) and what are the numbers regarding this?
Whether you should be worried about this really depends on what sort of website you are creating. For instance, if you're creating a rich javascript app, you have to ask yourself if it's worth your time & effort to worry about javascript disabled browsers, as these users are probably not too concerned with using rich user interfaces anyway. Also do you have time to put in the extra work for these browsers as there will be little extra traffic and profit gained (if it's profit making website).
Also note that if javascript is disabled in these user's browsers, there will be much on the web these people cannot use. So in all likelihood they're not heavy users.
According to these metrics, the following percentages of users have JavaScript disabled:
EU: 1.4%
US: 3.05%
But the numbers are from 2007, so they are rather old. I would think the percentages are a bit smaller by now, but who knows?
I know this is a very old thread, but I thought I'd post this for reference:
According to this website, only 0.4% to 2.4% of users had JS turned off. The first test they ran was with about 13,500 users, which is admittedly small for the interwebs, but it's still quite a large amount of people. This data is from 2009
I really feel quite strongly that a well designed web site should remain functional with or without JavaScript switched on. JavaScript, in most cases, is there to enhance existing functionality.
This can usually be achieved by following a few simple rules.
Use unobtrusive JavaScript, avoid in-line (certainly) and in-page JavaScript whenever possible.
Anchors should always link to somewhere, not to # or to JavaScript. If you can't get around it, the link should be created dynamically.
Use forms correctly. A button should always be wrapped in form tags, this way the your functionality can always degrade to the server.
I believe that following these rules makes for a more robust site that is more accessible across multiple platforms. Not to mention the benefits to search engine optimisation, if you rely on JavaScript, the search engine will only see half your site.
I prefer the idea of progressively enhancing rather than planning for degradation. I'm absolutely not developing for the minority that intentionally sabotage their Internet experience by switching JavaScript off. A site built for progressive enhancement will work better on mobile platforms, screen readers and search engines.
Rich
As a whole, I think you can expect any browser that supports CSS will have JavaScript enabled.
However, it's not always a question of JavaScript being enabled/disabled on the browser entirely. Most of my friends/coworkers use NoScript to only allow JavaScript on specific sites.
It depends on what you are doing.
Is it a website or web application?
A website can be done with just static html and, if needed something a little more complex, a little bit of server side programming.
A web application, today, is all about javascript.
So if your visitors have js disabled, they are likely not interested in your application nor any other. So why bother with them?
Just concentrate in the other 98%, where your potential customers/audience is.
It deppends on the size,
Big applications like Gmail often have 'basic html' versions to support old and secured browsers. If you code your ajax with this in mind, you might be able to reuse most of the code.
Medium sized applications, especially if the user uses them regular, will probably not find it worthwhile to support the few percentages.
Small sites / sites that mostly uses basic html navigation, should try to do without javascript. Most of the time, modern css tricks will do better, faster and make more sense codewise.
There are a lot of flash effects that can be achieved with jQuery.So when do you really need to use Flash instead of javascript?
Quite simply, when you need to do something that jQuery can't do. This includes video/audio, complex animations, cross-browser vector graphics, multi-file uploads, etc. The list goes on.
Of course, you could always write your website in HTML/jQuery and only use Flash for the necessary parts. That way it's a win-win situation, and your application degrades gracefully for those that don't have Flash.
Flash should be considered a 'last resort' in my opinion, and it's one that is shared with many others. Some people use flashblock, so they'll never see it. Users on mobile devices won't see it either.
There are few areas left for flash currently, and HTML5 will likely eliminate one of them.
Only when I have no choice...or asked by my boss
Flash features:
Compiled byte code versus interpreted
2D and 3D geometry libraries
Animation and audio libraries
Total control over Fonts/layout/design
Binary network calls as well as Xml and JSON
I'm not crazy about Flash for brochure or forms sites but it sure is nice for online games.
If your dislike of Flash comes from a dislike of Adobe, check out the Haxe programming language. It can target the Flash runtime.
if you need something which cant be done by JQuery then go for flash. otherwise stick to JQuery.
It is good for times when you want to make screen scraping harder. A major real estate site I worked with used Flash to make it much more difficult for a competitor to scrape agent data.
Sure this could of been done with images but Flash was just easier for us to implement.
Flex, which runs on top of Flash, is a very nice platform for building applications. In my opinion, it's far better than trying to coerce HTML and JavaScript into being a platform for GUIs. Also, if you have a graphics designer, they will have a much easier time designing the look and feel with the WYSIWYG tools available in the Adobe tools.
However, for traditional web sites, I'd stick with HTML/CSS/JavaScript. Don't use Flash if all you need is simple effects.
Flash is a frontend tool that should be considered when there are requirements that make a project much easier to develop. I know that there are alot of Flash haters, and I understand the reasons. However, each developer should use the tools available to them that would allow the job to get done effectively and quickly. PHP, HTML and JS have its limits, just like AS3 does as well, but each has something that can help deliver a project.