Real-time collaborative rich text editing - javascript

I would like to have a real-time collaborative rich text editor for my webapp. So far i've done a LOT of research and i'm really a bit frustrated that there is nothing fitting out there.
The thing is, that every solution out there is tightly coupled to an editor (Firepad for example uses CodeMirror/ Etherpad uses Etherpad).
There are only two other solutions i found interesting:
ShareJs -> works only for plain text
Webstrate -> This was the MOST promising to me. It can handle DOM synchronization and therefore it can handle every contenteditable - great!
But the problem with Webstrate is, that it is in an alpha Version. So for me it was too buggy - didn't work out. Tried to get it working for about 2 days. The text synchronization was easy. But it didn't work with iframes or other stuff.
My claims are pretty high for a collaborative RTE - it should support:
Images
Iframes
Video
Text (of course)
While i'm searching for about 3-4 days now for a solution - maybe someone of you has a hint? Would be very gentle ;)

You can try http://swellrt.org, is a complete framework to develop real-time collaborative apps including rich-text support and an editor for Web.
It provides a JS API, analogue to GD Real-time API, plus rich-text editting.
The editor can be extended to support any attachment.
It's a fork of Apache Wave that generalizes the original code.

The closest thing I found is http://quilljs.com/ - it has an API for getting and updating text deltas and also for getting and setting multiple labeled cursors. It doesn't manage the real-time editing for you, but it gives you enough to work with (more than any other project I found). However it is not as comprehensive as other editors in formatting (for example, it doesn't support tables and nested lists). It is somewhat extensible, so you may be able to add support for additional HTML elements.

Robust collaborative rich text editors are still somewhat bleeding edge. Most web based text editors fall into of two categories.
Those that are compatible with real time collaboration but have fairly limited functionality (e.g. no tables, no nested elements, etc.).
Those that are very robust web based rich text editors, but lack that API to integrate with real time technologies.
Then there are the collaboration engines like ShareDB, Google Drive Realtime API, SwellRT, and Convergence (full disclosure I am a founder at Convergence Labs). These types of systems each have their own opinion on data models and how to mediate collaboration. It may be the case that the way your favorite rich text editor works internally is incompatible with the API of the collaboration engine.
The technologies out there that simply sync the DOM are interesting because they are often portable across editors and are less dependent on the editor API, but they tend to lack a lot of the required real time editing capabilities that are required for good collaboration (shared cursors, shared selections, etc.). This can be very hard to implement on top of a DOM syncing approach from outside of the engine itself. Unfortunately, without these features, the collaborative editing experience is not that great.
There are several projects out there that are attempting to remedy this situation. The folks at CKEditor are working on CKEditor 5 which has collaboration in mind. Also, over at Convergence we are trying to work with the authors of many of the popular editors to enable real time collaboration.
The reality is that it is still a pretty new space and evolving quickly. There is no tested, scalable, slam dunk solution that provides and out of the box fully capable, collaborative, free and open source editor. The situation looks to be improving over 2018. Hopefully in the next 12-24 months this becomes a much easier problem.

Related

HTML equivalent for Flex

I am faced with a unique problem and probably need some external help and advice.
In my current company, I am set to develop a product that in broad terms is something similar to say Photoshop or Flash ( much much simpler than that.. But that should give us an idea! ).
Now I can develop both in JS/ HTML and AS3 / Flex.
Given the current scenario which would be the best environment to develop this app? By the way this app will be deployed only internally currently and will not be opened to our clients until say for another year. Even if we do the number of people who will use this app wont exceed 100 (That's over estimating under the current situation, but still..).
I am quite comfortable working with flex and to me Flex seems like a good way to approach this. But the popular vote has been to produce this with HTML 5, since apparently "Flash is dead" or dying.
Now.. If I am going to be using HTML in this scenario, which framework do I use so that I dont have to build all the UI elements again?
Any help or advice in this regard would be greatly appreciated.
I've been developing Flex applications for several years now while also experimenting with HTML5 since its inception. The correct answer to your question is a complex one and really it depends on YOUR comfort level on which route to take. That being said, here's my take...
"Flash is dead" is the biggest lie in the industry. Flash is a multi-billion dollar industry with tremendous momentum. There's a reason why game companies like Zynga choose Flash- it's got the horse-power and language features to drive an immersive experience.
HOWEVER, a better saying is "flex is dead". In my book, there's no reasons today to choose Flex over HTML5 for interactive applications. Flex is vastly slower in performance versus HTML5 (I don't have benchmarks but I know how Flex works under-the-hood). Google can index information in your application way better if it's HTML5. I would also argue that HTML5/js has way more open-source components available to use than Flex. This being said, choosing Flex to develop your application won't mean project failure... it's just not as good on paper than the alternative.
For working in HTML5, I would HIGHLY suggest leaning CoffeeScript (coffeescript.org). Javascript is a horribly broken language that have been further mutilated by a standards committee that can't make up their minds. CoffeeScript eases this pain by providing an "idealist" perspective on where Javascript should have evolved to. The language simple converts your app into a compressed library of javascript for use on the web.
Hope this helps!
The "Flash is dying" debate has been around for quite some years now, but it's still around and kicking:)
Back on topic. In my opinion, for medium to large scale applications, especially internal ones, Flex is a good choice, due to its capabilities. However, you should be willing to accept some trade-offs regarding cross-platform performance. HTML5 is great if you're looking for cross-platform compliance, also it's easier to implement.
Basically it comes down to choosing power (Flex offers a wide range of ready-made components and controls) over convenience (HTML).
Have a great day.
Fear not, use Flex you should.
It's an application for internal use, not the internet. In that case why would you care about it's "indexability", been more cross-platform?
I work within a bank, yes the $$$ kind, and there every computer has at least flash 9, all I have to care about is compiling my flex apps to flash 9.0.0.
It seams that you are more comfortable with Flex, use it.
I have finally decided to go with GWT since it is the next closest thing I can find.
I am currently evaluating GWT and Dojo and seemingly it provides me with a good IDE support ( since its java ) and apparently it supports all the new HTML 5 stack. More importantly it can work with other javascript frameworks where necessary ( like jquery? ). Apart from all this it is going to do some really cool code optimization and compression that will supposedly improve performance over direct hand written code.

RIA Technology of Choice

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.

Pure JavaScript-based clients

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.

JavaScript/CSS vs. Silverlight vs. Flex

We currently have a quite complex business application that contains a huge lot of JavaScript code for making the user interface & interaction feel as close to working with a traditional desktop application as possible (since that's what our users want). Over the years, this Javascript code has grown and grown, making it hard to manage & maintain and making it ever more likely that adding new functionallity will break some existing one. Needless to say, lots of this code also isn't state of the art anymore.
Thus, we have some ongoing discussion whether the client-side part of the application should be written anew in either Flex or Silverlight, or written anew with some state of the art JavaScript framework like jQuery, or whether we should simply carry on with what we have and gradually try to replace the worst bits of the existing code. What makes this even harder to decide is that writing the UI anew will probable cost us 6-12 person months.
I'd like to hear your thoughts on that issue (maybe some of you have already had to make a similar decission).
EDIT: To answer some of the questions that came up with the answers: The back-end code is written in C#, the target audience are (usually) non-technical users from the companies we sell the software to (not the general public, but not strictly internal users either), the software 'only' has to run in desktop browsers but not necessarily on mobile devices, and the client app is a full-blown UI.
In all honesty, I would refactor the old JavaScript code and not rewrite the application. Since you are asking about which platform to put it in, I would guess that your team isn't an expert in any of them (not slamming the team, it's just a simple fact that you have to consider when making a decision). This will work against you as you'll have double duty rewriting and learning how to do things on the new platform.
By keeping it in JavaScript, you can slowly introduce a framework if you choose and do it iteratively (Replace on section of code, test it, release it, and fix any bugs). This will allow you to do it at a slower pace and get feedback along the way. That way too, if the project is canceled part way through, you aren't out all the work, because the updated code is being used by the end users. Remember the waterfall model, which is essentially what a full swap out of will be almost never works.
As much as I hate to admit this, as it is always the most fun for developers, shifting platforms, and replacing an entire system at once rarely works. There are countless examples of this, Netscape for one. Here is the post from Spolsky on it. (I would also recommend the book Dreaming in Code. It is an excellent example of a software project that failed and how and why). Remember to rewrite a system from scratch you are essentially going to have to go through every line of code and figure what it does and why. At first you think you can skip it, but eventually it comes down to this. Like you said, your code is old, and that means there are most likely hacks in it to get something done. Some of these you can ignore, and others will be, "I didn't know the system needed it to do that."
These things spring to mind:
As you have a .Net backend and you have some ability to force your customers onto a specific platform, Silverlight is an option;
Since your client is a full-blown UI you want widgets and possibly other features like Drag and Drop;
I haven't seen any requirements that to me would justify starting over (which often doesn't work out) in Flex/Silverlight (eg streaming video, SVG support. Added to your team's familiarity with Javascript, I think you can't make a compelling case for doing it in anything other than Javascript.
But of course Javascript is lots of things and there are [lots of Javascript frameworks1. The most important divider is whether your intent is to "decorate" a set of Web pages or you need a full set of Widgets to create a desktop-like application on the Web. Your question indicate it is the latter.
As such--and I may get downvoted for saying this--I don't think jQuery is the answer and I say this as someone who loves jQuery. jQuery (imho) is great to enhance Webpages and abstract cross-browser low-level functionality but the most important factor for complex UI developer is this:
It's all about the widgets.
And yes I'm aware of jQuery UI but it's a lot sparser than the others when it comes to widgets. I suggest you take a look at the samples and widget galleries of some frameworks:
YUI Examples Gallery;
ExtJS demo; and
SmartClient feature explorer.
The others (jQuery, Dojo, Mootools, Prototype) are more "compact" frameworks arguably less suited to your purpose.
Also consider the license of each framework when making your decision.
My thoughts on the above three are:
ExtJS has somewhat angered the community in that it started out as LGPL but had a controversial license change (that thread is at 76 pages!) to GPL/commercial at version 2.1. The problem with that the community no longer has an active participation in the framework's development. Not the mainline version anyway. This means it's being developed and supported by a small team (possibly one person) rather than the community. IMHO it's not worth paying a commercial license for that and GPL is probably prohibitive in your situation;
YUI is supported by Yahoo and available under a far more permissive and far less invasive BSD license. It's mature, well-used and well worth serious consideration; and
SmartClient impresses me a lot. It has perhaps the most permissive license of all (LGPL), is roughly seven years old, has an incredibly impressive array of widgets available. Check out their feature explorer.
Your decision should be based on how you get as much of your application "for free" as possible. You don't want to spending valuable developer time doing things like:
Coding UI widgets like trees and accordions;
Testing and fixing cross-browser Javascript and CSS issues;
Creating homegrown frameworks that greatly duplicate what existing frameworks do and do well.
I would seriously look at one of the above three as your path forward.
This decision is usually less about the technology, and more about your skill sets and comfort zones.
If you have guys that eat and breathe Javascript, but know nothing about .net or Flash/Flex then there's nothing wrong with sticking with Javascript and leaning on a library like jQuery or Prototype.
If you have skills in either of the others then you might get a quicker result using Silverlight or Flex, as you get quite a lot of functionality "for free" with both of them.
My opinion on this one's pretty simple: unless the app needs to be accessible publicly, unless it needs to be search-engine optimized and findable, and/or there's an otherwise compelling case for its having to remain strictly text-based, then the chips are stacked in favor of rich-client runtimes like Flash or Silverlight right out of the gate.
A big reason, if not the biggest, is that they eliminate the complexities of developing for multiple browsers and platforms. Again: they eliminate the runtime-environment variable. No more debugging old versions of Netscape and IE, no more object detection and consequent branching, no more wacky CSS hacks -- one codebase, and you're done. Offloading the runtime environment to Adobe or Microsoft will save you time, money and headaches, all else equal. (Sure, there's YUI, JQuery, etc., but they don't eliminate that variable -- they just abstract it. And they don't abstract all of it, either -- only some of it; ultimately, it's still up to you to test, debug, retest, debug, repeat.)
Of course, your situation's a bit more complicated by the existing-codebase problem, and it's difficult to say definitively which way you should go, because only you've got the code, and we're just geeks with opinions. But assuming, just by your asking the question, that a refactoring of your existing codebase would involve a significant-enough undertaking as to warrant even considering an alternative (and probably comparatively foreign) technology in the first place, which it sounds like it would, then my response is that your curiosity is well-placed, and that you should give them both a serious look before making a decision.
For my part, I'm a longtime server-side guy, ASP.NET/C# for the past several years, and I've written many a text-based line-of-business app in my time, the last few with strong emphasis on delivering rich soverign UIs with JavaScript. I've also spent the last couple of years almost exclusively with Flex. I've got experience in both worlds. And I can tell you without hesitation that right now, it's everyone else's job to beat Flex: it's just an amazingly versatile and productive product, and for line-of-business apps, it remains leaps and bounds ahead of Silverlight. I just can't recommend it highly enough; the data-binding and event-handling features alone are incredible time-savers, to say nothing of the complete freedom you'll have over layout, animation, etc. The list goes on.
So, my advice: take a long, careful look at Flex. In the end, you might find a ground-up rewrite is just too massive an undertaking to justify, and that's fine -- only you can make that determination. (And to be fair, you've just as much ability to make a mess of a Flex project as you do with a JavaScript project -- I know. I've done it.) But all told, Flex is probably the least-limiting, most flexible, most feature-rich and productive option out there right now, so it's certainly worth considering. Good luck!
Any javascript you have that has been developed 'Over the years' probably doesn't look anything like what's possible today. You undoubtedly have a lot of useful code there. nonetheless. So my recommendation would be re-write in javascript using jQuery and make use of one of the available GUI add-ons, perhaps look at Yahoos stuff. You will also be targeting the widest audience this way.
The GUI technology should be first and foremost determined by your target audience. For instance, if you target englobes iPhone users, I would not recommend Flex, because iPhone doesn't have a flash player at the moment.
Bear in mind that if you switch to a full fledged GUI toolkit like Silverlight, your users may find the L&F unnatural, since the usual request-reply cycle is not so evident with client-side frameworks.
After that, it is your developers that should have a word to say. Every toolkit needs maintenance, and if you are switching to a whole new toolkit the developers will have to familiarize with the new toolkit, which can be costly.
My suggestion is that you stick to javascript, since your devs are familiar with it, and gradually replace the old javascript with a new toolkit like prototype, jQuery or any other. You will probably redo some of the old stuff faster using a state-of-the-art toolkit. Remember that you can build beautiful apps with any tookit.
We have developed an extremely rich application using EXTJS with C# and a some C++ on the server. Not only do we have clients who are happy with the interface in their desktop browsers but with very little tweaking to the Javascript we were able to provide web browser support. Also, we have clients in third-world countries who cannot use Flash or Silverlight apps due to their field personnel using kiosks in internet cafes (many of which don't have Flash installed - forget Silverlight!). I think these issues and others make up for the difficulty of coding a complex app in javascript...
Check this comparison table for Flex vs Javascript:

Why should I use Flex?

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

Categories