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:
Related
I have been working with node JS for about two weeks and I am liking it a lot. I came cross something called Cappuccino; it sounds like what I want to use to develop a web application. As a beginner, can someone assist with explaining what exactly Cappuccino is and how it fits into node?
Really my hold up with developing an application is that I come from a VB background and I am use to forms to design my desktop apps. I do not want to be limited with a WYSIWYG type of IDE, that is why I started with node.
What sort of web application? There are... many JS libraries/frameworks. It's a jungle.
My strong advice is to build several things, from very small to less small, using pure Javascript. Otherwise you will, I promise, remain forever cloudy on what the language is vs. the frameworks layered on top. JS is very mutable and frameworks have a tendency to create new semantics on top of the core language. The downside of learning by using these is you ever fully understand the complexities and subtleties of the language itself, nor do you ever really understand what those frameworks are giving you (in many cases, things you don't need or that artificially constrain you). Be wary of framework entanglement.
As you get used to writing simple scripts in a text editor (try Sublime Text if you want something much better than that), you'll begin to appreciate when and why you might want help from a framework. Move on to jQuery, as it's the most widely used library and is either a dependency or heavily informs the style of many other libraries out there.
I'm working on a blog post about the topic of frameworks, by no means comprehensive as there are hundreds of them it seems. Specifically, breaking down about 20-30 major players by their intended domain (e.g. DOM manipulation, Single Page Applications, data-binding, MVC, etc.) and strengths and weaknesses.
There are some great books and YouTube videos going into many aspects of modern JS. Anything by Douglas Crockford I recommend (especially book or video "Javascript: The Good Parts". He's pedantic but wise and generally on the money. Then for more inspirational stuff about recent/upcoming changes to the language, watch some stuff from the Google I/O events. Check out HTML5rocks.com for articles on some cutting edge features available in the browser. There are many many more resources, but these are some good ones.
Oh and be sure you are familiar with the dev tools in the browser. I personally recommend Chrome as best of breed. Learn the keyboard shortcut to open it on any page, inspect, and noodle. There are some fancy things such tools support like live editing/saving of source, profiling and debugging, DOM/CSS inspection, and on and on. There are other free and non-free IDEs but IMHO they are too much overhead for someone just learning (and many advanced JS developers use Sublime Text).
P.S.: jQuery, per its design goals, is still going strong but is aimed for obsolescence as browsers increasingly are converging on true standards (ES5, HTML5, CSS3). Even so, for many apps, its shorthand semantics are much better than even the newly supported standards for many things. And it's not going away any time soon, just becoming less important. Like IE. Ignore IE unless you need to build things for work.
As far as I can see, Cappuccino is a client-side framework of some kind, in the same kind of vein as Backbone.js or Angular.js, and is in no way comparable with Node.js. They run in completely different environments (Node on the server, Cappuccino in the browser).
A client-side framework like Cappuccino would be used to implement web apps that needed to do a lot of work on the client side. For instance, if you implemented a real-time web app with Node, you might use it to simplify inserting new content into the DOM.
I haven't used Cappuccino, and it doesn't seem to be all that popular. It seems to be squarely aimed at people with a background in Cocoa development on Mac OS X, so if that's not what you're after I would recommend you look elsewhere. Client-side MVC frameworks are very useful for some use cases, and the big four seem to be Angular.js, Ember.js, Backbone.js and Knockout.js, so I would check out one of them before considering Cappuccino. Knockout is very easy to learn, but lacks routing, which was a deal-breaker for me, so I switched to Backbone. Considering how much mindshare it seems to have, I would probably now go for AngularJS.
Cappuccino is a client side framework built on top of Objective-J which in turn is a complete language built on javascript. It's intended solely for building desktop class applications that happen to run in a browser.
Objective-J adds features to javascript (like classical inheritance) in the same way Objective-C adds them to C. You can use Objective-J with node but probably not most of Cappuccino. Cappuccino is the framework that lets you build rich user interfaces in a way that allows you to completely ignore that you're working with html.
I would not recommend Cappuccino as a first foray into web development unless you really only want to build a business application and you are already a proficient Mac OS X or iPhone developer. It will not help at all to teach you about the web.
Cappuccino is (imho) head and shoulders above everything else in its league, but it is intended (or most useful) for a very tiny niche.
If you're still interested in Cappuccino (or Objective-J) you should really check out the learn section of the Cappuccino project website
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.
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.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I'm fairly new to this whole web-development thing (2 weeks maybe, my 1st scraping of code exists here, I quite like it) and I ended up learning to use Adobe's Flash Builder 4, which I have come to quite like (although Action Script annoys me at times).
Recently however I've been reading a lot about "the future" of web development, RIAs, web 2.0 etc, and it appears the whole Flash/Flex/ActionScript frame work's main competition will be the HTML/CSS/JS stack (or "HTML 5").
So obviously I don't want to take the time to learn a language (Flash/Flex/AS3) that will end up dead in a couple of years and end up having to learn another one (HTML/CSS/JS), when I could just move over now.
My main interests are fairly information rich (database orientated) web sites, with high levels of user interactivity for customisation, uploading, etc. I like the whole mobile web aspect, and would like to have the capacity to also develop for that platform, as well as mobile apps etc. I love the whole "live" aspect (like the tour de flex light up map that shows user activity), not particularly bothered by uber complex animation and obviously want things to be responsive and user friendly.
So yea, any input on this would be much appreciated, I'd just like some advice for overall direction for my personal learning and development.
Thanks!!
You're making some basic mistakes in the question. The HTML/CSS/JS combination is different from HTML 5, That combination works just fine with current implementations (ignoring some of the annoyances of IE for the moment.) HTML 5 is a new extended definition of HTML with a number of new features like local storage.
HTML 5 is also not completely settled, nor completely supported.
You should learn HTML and CSS to start with; in general, you still need a web page in which to embed your Flash stuff. You should get some basic knowledge of Javascript for much the same reason.
Conveniently, the Javascript will carry over to Actionscript, which is a variant of the same ECMAscript standard.
Flash isn't going anywhere for a long time, and given the glacial pace that the HTML5 committee is working at, the HTML 5 spec won't be fully standardised for a while yet either.
Plus before all these lovely HTML5 web apps can become commonplace, the world's windows users will need to have a better browser than internet explorer 8. Given that 10-20% of web users are still stuck on IE6, i don't think we'll be seeing html5 becoming dominant for quite a few years. Of course then by that time we'll be seeing HTML6 and the slow painful process of getting the world to upgrade will start again.
Personally i don't do flash, because for what i do i really don't need it, but flash is a really useful tool outside of web development too. Lot's of triple A Games have flash built menu's and user interfaces for instance.
But really, become good at either/both technology, and you'll probably not be short of work
Learning a language like Actionscript can never be a waste of time , the mindset you will develop from it will enable you to understand the concepts of programming and it'll be easier for you to move to other languages if/when you so desire. Learning HTML & CSS is essential if you plan to develop for the web but it will not bring you the same type of knowledge, as it uses a very different logic. If you like the idea of developing web applications, one day you may want to develop desktop applications, HTML won't be of much use then, whilst the programming knowledge acquired with AS3 will not be lost.
Is this just for the fun of learning, or do you have any specific tasks to accomplish? I like to use the correct tool for the job. If you don't have a specific job to accomplish, or any constraints to work under, I would just pick the most marketable skill and go with that. Unfortunately, I'm not exactly sure which is the most marketable skill.
My recommendation would be to check out some JSON type stuff in JavaScript. That seems to be a pretty stable (might I even say fad-resistant) AJAX evolution which is pretty wide spread and likely to stick around for a while. If you focus on the high level theoretical concepts, the specific comings and goings of implementations won't be as important (in my opinion).
I think learning AJAX (using JSON rather than XML) is a good way to go so you learn about implementing asynchronous information rich sites. If you have to redraw the site entire site when you pull information, you're doing something wrong. The AJAX concepts will come in handy regardless of your platform.
Good luck!
-Brian J. Stinar-
Don't bother with flash.
Yes, it's pretty and powerful and fairly ubiquitous. It's also on its way out the door, as you observed in your question.
Let's compare Flash and its newly-arrived competitor, the HTML5 canvas element.
Flash is only supported by Adobe; if you want quality development tools or resources you'll have to buy from them (for the most part).
HTML5 canvas doesn't need proprietary development tools. HTML5 canvas is supported by every major browser vendor -- Mozilla, Apple, Google, Microsoft. All vendors will provide documentation and competition for each other, which should result in a more refined product.
When OpenGL support (direct gfx card access) was in discussion for HTML5 Canvas, guess who was the only holdout? Adobe, of course. Everyone else wanted hardware graphics support for canvas.
In other words it's Adobe against everyone else here, and Adobe's not going to win. They might keep the status quo for a while, but eventually they'll lose their foothold and canvas & co will take over.
tl;dr: No use learning the dying proprietary technology when you can learn the modern open technology that's going to replace it.
HTML5 is still very unstable, so you shouldn't try it.
For me, HTML5 is great, but some business haven't moved off of IE6, given its current state. Flash, while useful, can be very very tedious at times and other times it doesn't even work on some computers or makes some computers truly a pain in the "insert word here".
It's better to start with CSS and HTML4. Get the basics, then start going for more.
By then, you'll know what to want.
Personally I think all the answers here are overcomplicating things. Here's my take:
Use whichever technology excites you, and is best for what you want to build right now.
If the app you want to build right now feels perfect for Flex, use Flex. If something about HTML5 has caught your fancy and won't let go, dive into it. You can always change technologies in a year or three, and You'll be taking everything you've learned about design and architecture and usability with you - learning a new scripting language and some new tools won't be that bad. The only way you can make the "wrong" choice here is if you, for whatever reason, pick a technology that you wind up not enjoying enough to get anything built.
The reason I feel this is the best way is, nobody here can tell you anything useful about what technologies will or won't be around in a few years' time. Adobe could go bankrupt; Steve Jobs could die; Google could get broken up in an antitrust suit. Hell, Flash could be on the iPhone next year for all we know - or HTML6 could adopt a new, strongly-typed JITable programming language. Or a hundred other things could happen to render your (and our) predictions moot.
I mean, personally I expect that both Flash and HTML5/6/7 will be vibrant and flourishing in five or ten years - because they both have successful organizations behind them investing in their futures, and because I've never heard a whit of a meaningful argument why the success of one should require the failure of the other. But that's just a guess, and my guess is no better than yours. Focus on getting good stuff made now, and the technology road map of the future will come when it comes.
In my opinion – everything is worth learning, especially when it comes to HTML/CSS/JS/Flash, which are each completely different systems/skill pools tailored to entry-level developers.
HTML is tagged markup, and very important because it outlines XML usage. CSS is writing visual formatting rules. JavaScript is a scripted language, and a great way to get your feet wet with simple programming logic. And Flash is a great system in which to get into object-oriented programming within a compiled language.
As you keep venturing out, you'll find that a lot of technologies are really just different flavors of the same ice cream. While different languages have their own nuances, there are fundamental similarities between –say– most compiled languages. I came from Flash and got into iPhone development... while Objective-C is a way bigger and uglier system to dive into, I still generally knew my ass from my elbow while building my first app after several years experience with AS3. The same goes for .NET and Java. Also, I would second the notion that Flash is not dead, despite loosing traction in the wake of the iPocalypse. Whether it dies in a few years or not, it doesn't make AS3 any the less valuable to have learned in addition to HTML/CSS/JavaScript.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I manage a group of programmers. I do value my employees opinion but lately we've been divided as to which framework to use on web projects.
I personally favor MooTools, but some of my team seems to want to migrate to jQuery because it is more widely adopted. That by itself is not enough for me to allow a migration.
I have used both jQuery and MooTools. This particular essay tends to reflect how I feel about both frameworks. jQuery is great for DOM Manipulation, but seem to be limited to helping you do that.
Feature wise, both jQuery and MooTools allow for easy DOM Selection and Manipulation:
// jQuery
$('#someContainer div[class~=dialog]')
.css('border', '2px solid red')
.addClass('critical');
// MooTools
$('#someContainer div[class~=dialog]')
.setStyle('border', '2px solid red')
.addClass('critical');
Both jQuery and MooTools allow for easy AJAX:
// jQuery
$('#someContainer div[class~=dialog]')
.load('/DialogContent.html');
// MooTools (Using shorthand notation, you can also use Request.HTML)
$('#someContainer div[class~=dialog]')
.load('/DialogContent.html');
Both jQuery and MooTools allow for easy DOM Animation:
// jQuery
$('#someContainer div[class~=dialog]')
.animate({opacity: 1}, 500);
// MooTools (Using shorthand notation, you can also use Fx.Tween).
$('#someContainer div[class~=dialog]')
.set('tween', {duration: 500})
.tween('opacity', 1);
jQuery offers the following extras:
Large community of supporters
Plugin Repository
Integration with Microsoft's ASP.NET and VisualStudio
Used by Microsoft, Google and others
MooTools offers the following extras:
Object Oriented Framework with Classic OOP emulation for JS
Extended native objects
Higher consistency between browsers for native functions support.
More easy code reuse
Used by The World Wide Web Consortium, Palm and others.
Given that, it seems that MooTools does everything jQuery does and more (some things I cannot do in jQuery and I can in MooTools) but jQuery has a smaller learning curve.
So the question is, why did you or your team choose jQuery over another JavaScript framework?
Note: While I know and admit jQuery is a great framework, there are other options around and I'm trying to take a decision as to why jQuery should be our choice versus what we use right now (MooTools)?
That's an odd question... I get the impression that...
you are very familiar with mootools and take full advantage of its OOP model, making your code easier to manage and support already.
you realise that jQuery's purpose is somewhat different and tweaked towards DOM manipulation and AJAX and that mootools does do everything jQuery does AND then some.
sounds as if you do not need to be using much in the way of 3-rd party plugins which makes the points of jQuery's popularity and support a bit less important.
Bottom line, is it the hype? jQuery is turning into one of these magical marketing buzzwords like 'AJAX', .NET and Web 2.0 — which is great for them but why do you need to justify staying with the framework that works so well for you? There's also the business considerations which I imagine will cover things like:
framework longevity, or is mootools likely to go away in the face of the ever growing jQuery — very doubtful, seeing as they just released 1.3 beta 1 and have 2.0 is in the pipelines for release by the end of the year.
cost of staff and their training (I imagine finding mootools programmers will be more difficult than these that slap jquery on their C.V / resume).
time (and cost) taken to maintain and extend your systems under each framework given your resources.
Both frameworks are great but I believe your interests are best served in staying with mootools.
Personally, jQuery does exactly what I need.
I try to do most of my stuff in my server-side code, which is well structured: it has proper OOP, layers, and an MVC architecture. When I need to do something with Javascript, I have found (so far) that jQuery has what I need. Frankly, that falls into three categories:
Simple DOM manipulation, usually showing/hiding stuff without hitting the server.
Ajax calls, nuff said.
UI perks, including modal popups, animations, fading transitions from/to hidden/shown. I am a hardcore backend coding guy, and I suck at UI stuff. I really like that jQuery lets me programmatically make stuff that looks appealing.
On top of that, the jQuery plugin library is huge, and I've found quite a few libraries that simplify my client-side work. Good stuff.
MooTools introduces OO thinking, which is nice, but not what I need. I want to keep my structuredness all on the backend, and not have to introduce that thinking to my client-side code. To me, client-side code is a very small piece of the emphasis and thinking about it from a Class-point-of-view is way overkill, and way more work. I feel like I'd be building two applications instead of one if I were to use what I'd think would be best practices for MooToools.
I think that sums up why its so popular, especially around here. By and large, we're backend code-y type people, and jQuery lets us make an appealing UI programmatically, and lets us focus on our backend core.
I'm not a fan of imposing classical object orientation onto JavaScript. There are so many ways to do it that one JavaScript Programmer might be using Base2 for OO, while another uses Prototype or Moo or JS.Class or Joose. Resig deliberately decided not to add classes to jQuery, and that has encouraged people to find more native JavaScript ways to solve problems.
As a result, it's easier for me to read JavaScript other jQuery writers write, and to write jQuery code that's easier for others to read. I typically don't try to emulate class OOP in JavaScript. Instead, I create objects on the fly and pass them around, and I have lots of arrays of objects. It's so easy to understand that I've even found myself carrying that thinking over to OOP languages!
For all I know Moo may very well have caught up with jQuery or surpassed it. But I can't spend my time tracking the 6 or 7 great JavaScript libraries to see which horse is ahead.
I think it's was largely a matter of timing. When masses of programmers jumped into AJAX, jQuery was the hot new cool thing that solved their problems.
Other libraries have largely caught up. YUI, ExtJS, Dojo, Moo--they're all great. But I can't use them all.
I work hard enough trying to figure out the ramifications of the new features of the library I do use. For instance, jQuery added Live events as of 1.3. This actually let me cut code from many pages. Does Moo offer that now too, and how am I supposed to know it happened, if it did?
I'm sure Moo is awesome. I'd love to have the time to learn it. But have you looked at Dojo? I had to use it on one project and found that it had pulled in most of the great ideas from jQuery as well. And it has pubsub and good support for Comet.
I sympathize with you. But your programmers are talking sense. Learning jQuery is good for their careers, and there are more books, examples, and fellow programmers to ask for help if they use jQuery.
If you decide to go jQuery after all, think hard before deciding whether to tack on an OO library. There are some cool ones (like JS.Class or Joose), but taking that step means isolating yourself from how most JavaScript programmers code.
I've been asking myself this very same question for a while now, by means of just trying to wrap my head around the argument. And with ever discussion I read, the overwhelming response has been "More widely adopted - therefore better".
I am one who uses both extensively. JQuery at work (adopted because it was "more widely adopted") and Mootools on personal projects. As a result, I constantly find myself feeling crippled when using JQuery; Be it with JSON support, element creation, event handling... and so on. At work, I find myself writing chains 75 events long... and I feel dirty as a result.
My main overall beef with JQuery though, is that there's a lack of consistency or practice where plug-ins and 3rd party developers are concerned. The anecdotal "More plug-ins are available" really doesn't help me when there's no consistency between the plug-ins, structurally or otherwise. It took me several weeks to learn the "accepted" plug-in model, and even then, I've adapted my own pragmatic style into it, as I find error and inefficiency within the current structures. It can be said that it's a 'Pro' that anyone can jump in and start JQuerying it up. However, I am more inclined to call that a 'Con', in that you will see 30 different ways to accomplish something, and it's difficult to pin an accepted standard.
So what does it mean to "Know JQuery", Does it mean you know how to rock a little .hide().show().fadeIn().fadeOut()?
When I have to get gangster on my JS at work, I miss me some Mootools. I mean no Native JSON support? C'mon......
In response to the "Widely adopted" response, we all know OSCommerce is the most "Widely Adopted" shopping cart, and we all know what a pile of shit that is. I'm in no way comparing JQuery to OSCommerce. I'm simply pointing out the faulty of "Widely Adopted" response.
As for plugins, the App store for apple has what... 100k apps? 50,000 are fart apps. Sure there's a lot of plugins to JQuery, but the ratio of trash to worth-while is great.
jQuery gives you access to crisp and concise functional programming methods. Since the release of method chaining in (LINQ) in C# 3.0 this works very well for .NET programmers. So the flow from one language to the next is easy. To be able to query the DOM for an object, or a list of objects, works much better for us. It is jQuery's selection power first that makes it so attractive, then the extendability of it, and of course all the built in features that come with it are nice. Also, the community behind is wonderful in that I first look to see if someone else did something and then attempt to do it myself if a solution was not found. And last...but certainly not least...the fact that Microsoft is going to include in in Visual Studio 10 and support it is great. Moo Tools, Prototype, etc. just can't compete with all of the above.
JS frameworks are so much alike, anyway. If you've been working with mootools for some time, stick to it. Knowing your framework is much more important than choosing one because of this or that.
In my opinion, mootools is better for advanced javascript programmers, while jquery is better for non-javascript programmers. That's what I think after reading both documentations, mind you, I didn't use any of them. jQuery lacks support for the core of javascript, function binding, object cloning, thread stacking, to name a few.
jQuery, like any framework, does what it does and if it doesn't fit your needs you should use something else. I don't use jQuery to do complicated programming in javascript, I use it because it makes DOM manipulation and CSS3 style stuff simple and 95% of the time that is what I need.
I have not looked at MooTools in a while either. But here are my points for JQuery:
Consistent programming model (there is a JQuery way that works)
Excellent documentation. When I started JQuery had the best documentation out there.
Extensive 3rd party plugings
Microsoft support -- I am an asp.net developer, this helps ease clients minds. Plus it ships with my tools now.
Lots of getting started guides.
JQuery's website looks nicer than MooTool's web site. I'm sorry that matters, but it does. Remember, many of these tools need to appeal to designers as well as developers.
YAGNI.
Yes, it's kinda out of place here, but that's the main reason jQuery has a larger base than MooTools. All those extras MooTools brings to the table are nice, but YAGNI.
It's not about best, it's about satisficing -- finding the adequate solution to the problem at hand. jQuery is easy to use, its primary aim is DOM manipulation. Since 95% of the people picking up javascript are doing so just to manipulate the DOM, there's no point in going through the longer MooTools learning curve. MooTools simply doesn't bring anything to the table for them that jQuery doesn't deliver with less effort.
MooTools demands more from you before you use it, jQuery lets you throw something together quickly. If you start writing large, heavy-duty js apps, you might run into some of the drawbacks of that approach, but again 95% of the folks writing js don't do that, so those things don't matter to them. They use a server-side language for the heavy-lifting and javascript for the DOM.
For that matter, they may not matter to your team, either. To take you through the lists, point by point (jQuery first):
Large community of supporters -- only slightly relevant to the project. Of more relevance to the team personally, because it speaks to life after you. If misfortune strikes (please, God, no) and your firm is gone, jQuery gets them more jobs than MooTools.
Plugin Repository -- very relevant, as it helps keep from reinventing the wheel.
Integration with Microsoft's ASP.NET and VisualStudio -- very relevant if you're a .NET shop. In fact, this alone should be the reason to switch if you do .NET.
Used by Microsoft, Google and others -- who cares?
Now for the MooTools list:
Object Oriented Framework with Classic OOP emulation for JS -- irrelevant, unless the nature of your projects makes that a plus. I don't know what you're building, but for web shops, this is only rarely relevant. Most web shops don't have enough code to make this a plus.
Extended native objects -- again irrelevant for most web shops
Higher consistency between browsers for native functions support. -- Relevant
More easy code reuse -- This conflicts a little with the jQuery advantage of a large repository. A large repository by itself speaks to reusing code. I suspect you're using a narrow definition of code reuse, here, that may not be relevant. I've reused a lot of the jQuery code I've built, as well as MT code.
Used by The World Wide Web Consortium, Palm and others. -- Irrelevant. The only relevance about who else is using what is if you're wanting a job there. There's more relevance in how many shops use it than in any particular shop using it.
There is no One True Way to approach javascript coding. Get your bias out of the way, and sit down with your team and get their bias out of the way as well. Talk turkey about the specific types of projects you're undertaking (and want to undertake) and the strengths of each library as applied to those cases. (How they might handle other cases doesn't matter, because those other cases don't exist.) You should arrive at a consensus from that.
(YAGNI = You Ain't Gonna Need It, if I need to explain it.)
I choose to use jQuery as our default UI library precisely because it does not extend or otherwise monkeypatch native objects, unlike prototype.js or mootools. Kick in the documentation angle and there really is no question as to which framework to use.
You kinda say it yourself:
Given that, it seems that MooTools does everything jQuery does and more (some things I cannot do in jQuery and I can in MooTools) but jQuery has a smaller learning curve.
Most of the extra stuff that MooTools does is stuff that we just don't need.
As you say yourself jQuery is easier to learn, which is actually more important for most people when choosing a framework.
What I DON'T need in JavaScript is definetely OOP and some ugly object emulation.
Last time I checked MooTools (maybe 1,5 years ago :-), it had browser incompatibilities with manipulating multiple select.
So jQuery is completely looks OK to me.
Not only is jQuery a nice library, but its creator, John Resig, also has some street cred as the author of Pro Javascript Techniques.
We have 2-3 copies of this book around our office.
jQuery is small (intentionally so) but can have functionality added to it through plugins.
The thing that made my experience with mootools a rather unpleasant one was the documentation and the stability of the API:
I simply wasn't able to find a documentation that related to the mootools-Version in use. Won't be that much of a problem if the API defined was stable. But due to some functions that disappeared in the newer Version (a ChangeLog was found after hours of searching) a migration wasn't possible either. After that, mootools was out of the race for me.
Like many others, I don't want to introduce class-based OOP into simple user-interface manipulations. Thats what I use jQuery for: not so complicated user-interface stuff.
When I have to build rich browser-side applications, I'd always switch to the big solutions (ExtJS, YUI, qooxdoo) that offer a variety of ready to use widgets.
Larger User Community and more wide-spread adoption makes a big difference when comparing tools/libraries that offer similar functionality and concepts. Larger community means more support, more examples, more good ideas, and more reusable code snippets, which is especially important when you're working on a rare scenario -- more likely someone else has encountered it before.
Secondly, in benchmarks I've seen, jQuery is faster than MooTools.
I also really like their emphasis on keeping a small core and adding functionality through plugins. Prevents the core library from getting really big and unwieldy.
I've never used MooTools personally but I have no doubt that its a fantastic library that offers some acceptable equivalent to most any jQuery feature or concept, but point #1 takes the cake for me.
Another reason: It's easier to sell jquery to management. Doing internal, asp.net based developement in a corporate environment the magic words are "it's supported by Visual Studio".
For one thing, that's not all it does. There are quite a few other features as well. For another, not everyone uses it. But I don't want to interrupt a good rant.
I have to second a lot of the answers...great documentation and community support is crucial. I used to hate js programming and would avoid it like the plauge, but now I've completely embraced it because of jquery and the quick learning curve.
It's not always about who has the best technology!
Mootools, does not function properly or does not function at all when using jquery prototype etc. Agreed there is absolutely no reason to use them simultaneously, but once in a while they do land up on the same page (ex. plugins, slideshows, widgets etc) and things stop working.
That in itself is unacceptable. So all props for jquery to not create unnecessary headaches!
Why did people start using fax machines? At a certain point the benefit increases exponentially.