Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
We are trying to decide if to use Dart for building a web app. We are looking for a technology that will stay highly relevant roughly for the next 5 years.
Now that EcmaScript 6 specs are around the corner (should be out by the end of 2014) we can't make up our mind if Dart is really here to stay for the long run.
This is because as far as we know there is a missing piece to Google original plan for Dash (now Dart). As Google originally planned in its leaked memo:
What about the existing code bases for large Google Apps? Won’t they have to rebuild everything to take advantage of Dash? The Dash Cross Compiler should be capable of taking typed Closure code (with some restrictions) and converting to Dash. Although the migration process won’t be fully automatic, it should make moving over to a Dash codebase somewhat easier.
Therefore, this is the reason for this question.
Is there any effort to date from Google to build a Closure (or GWT) to Dart compiler or translator? In addition, do you know if Google started using it for any existing or new production web app?
In other words, our worry is that Dart will only be a language that is there to fill a transition period and to push Javascript to iterate a bit faster, but as soon as the major browsers will support ES6 (and ES6+) it will be abandoned.
We don't want to start any arguments on the pros and cons of Dart, we just need some factual info that could help us in this key decision.
Thanks
So far I have been mostly developing with GWT (scientific web-apps) but recently I also started to work with Dart.
Google is heavily invested in Dart (look at all the I/O talks) so I can't really imagine them dropping it. Also ES6 will solve some problems (modules, classes, etc) but it still is Javascript with all its problems and drawbacks.
While working with GWT there were two aspects, which make developing large scale web-apps actually feasible:
structured language (Java) & static types
compiler
1.) Java is a statically typed language and thus allows you to easily catch errors during development. Furthermore it is much easier to refactor your code when your IDE understands the structure of your code. The same advantages also apply to Dart.
2.) Both the GWT compiler as well as the Dart compiler are quite sophisticated They can do global optimizations (https://plus.google.com/111739836936169749229/posts/DSUgfWefyR3) and tree shaking (https://plus.google.com/110412141990454266397/posts/VK8URgZiLbS). If you develop web-apps with a 100.000 LOC, this is quite important and crucial.
Dart has one big advantage over GWT concerning the development story: Dartium has the DartVM baked in. This makes development and iterations as convenient as with Javascript
(GWT has SuperDevMode but that's not as fast).
You can checkout Java2Dart which could be used to transpile GWT code to Dart
I haven't heard of a Closure to Dart converter. I think this is obsolete because Dart can just make use of JavaScript by Dart-js-Interop. This helps to migrate existing apps to Dart by migrating the code part for part.
You can ask as many questions as you want, you won't get a guarantee that Dart will stay but I love to work with Dart and what I have heard many others do as well. I think this shows that Google created a great product. It will stay if enough developers jump on the bandwagon.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am starting a new project that has planned to use a large of Oracle components BEPL, SOA Suit, Oracle Spatial and Oracle ADF. I am trying to convince the team that a Javascript framework like EmberJs or AngularJs would be better. I feel like I might not be comparing apples to apple with EmberJs vs ADF. The goal of the project is to expose a large complex database to both our Web Front end and as an API. I think that a Javascript framework would work well with the data being exposed as an API instead of thought ADF where it might use a more proprietary connector.
Well.. comparing cars to bikes always look crazy. However sometimes you choose bike over the car. And sometimes you might want even reinvent the wheel.
However mostly it just shows lack of particular knowledge and very bad decision is trying to get rid of native, supported solution and start repeating it with the tools, you know better.
All oracle stuff now driven with ADF. There should be VERY strong reasons to abandon it. And you didn't provided any.
I'll be subjective with my answer here, as ADF is a very big framework and CAN be used along with EmberJS if you want to ditch the ADF Faces part, however here is my 5 cents into this
Using EmberJS from a Java Developer point of view
Pros
If done right, a great User Experience can be generated.
Very flexible front end development for your front end team.
More options when it comes to Deployment on servers as you don't need to work with Java EE container (I'm excluding the Service part of course).
Cons
Developers will need to learn EmberJS, Backbone or AngularJS
Developers will have to provide a great service layer, and controller in a way that all this JS Frameworks can interact with.
Developers will have to consider security constraints themselves as JS is not secure by default.
Development time will increase greatly and if you are under a deadline it'll be very hard to be met since developers will have to take care of everything themselfs.
This question interested me, so I made a tiny research. If you make a search on tags javascript + oracle, you'll notice that there are only 74 questions tagged. So these technologies do not actually intersect quite often in a real world and it's doubtful if anyone would provide expertise.
I'm learning AngularJS now and I'm quite certain that it's worth every minute I spend on it, it will be there for a long time and that it provides one of the quickest an intuitive developing experiences on the market. It requires learning, though, and even hair-pulling at times if you're a novice, like I was.
PS One of the killer arguments are the numbers for the tags in this question in the top-right corner.
Comparing ADF to JS is like comparing Servlets/JSP to JS. Makes no sense.
ADF generates JS as part of its page rendering, but also allows you to incorporate JS and JS libraries to extend and augment the ADF JSF page functionality.
I suggest you read a bit about JSF before making this decision...or comparison.
AND, if you're working with Oracle, specifically Fusion Apps, which is written in ADF and SOA Suite, (BTW: BPEL is one component of SOA Suite, not a separate product), then you have no choice but to use ADF.
Seems you have some study ahead of you.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I want to create a custom UI framework in JavaScript for web applications (like Google Docs ui) (do not confuse with web application that deploy using languages like PHP, Python, etc.). However, after reading several books about web development, I understand that the best website is layered as follows:
Structure in HTML
Presentation in CSS
Behaviour in JavaScript
So there are several approaches to creating my own HTML document and control it in JavaScript. However in this approach HTML and CSS will be mixed, like in case of extJS UI. I am confused now, and I need some answers from experienced developers on how to write this kind of framework.
If HTML, CSS, and JavaScript is mixed.
What was advantages?
What was disadvantages?
Is there are other methods?
What was the usual type of creating UI frameworks?
I apologize that this answer is extremely long and at times may seem somewhat off-topic, but please keep in mind that the question was not very specific. If it is improved, or made less general, then I will gladly remove the superfluous parts, but until then, just bear with me. This is somewhat of a compilation of the other answers here, in addition to my own thoughts and research. Hopefully my ramblings will be at least somewhat helpful for answering this question.
General Tips for Frameworks
Frameworks are a ton of work, so don't spend all of that time for nothing. Work Smarter, Not Harder. In general, you should remember these things when creating a framework:
Don't Reinvent the wheel: There are tons of great frameworks out there, and if you create a framework that does the exact same thing as another framework, you've wasted a ton of your time. Of course, understanding what goes on inside another library is a great way to make your own library better. Quoting #ShadowScripter, "knowledge -> innovation." However, don't try to rewrite jQuery by yourself. :)
Solve a Problem: All good frameworks (and programs) start with a problem they are trying to solve, then design an elegant solution to solve this problem. So don't just start writing code to "create a custom UI framework," but rather come up with a specific problem you want to solve, or something you want to make easier. jQuery makes selecting and manipulating the DOM easier. Modernizr helps developers identify the features supported by a browser. Knowing the purpose of your framework will make it more worthwhile, and may even give it a chance of becoming popular.
Fork, don't rewrite: If the problem you aim to solve is already partially solved by another framework, then fork that framework and modify it to fully fit your needs. There's no shame in building of the work of others.
Optimize and Test: This is kind of a no-brainer, but before publishing version 1.0 on your website, test every single part of the function, under every single possible scenario, to make sure it won't crash and burn in production. Also, another no-brainer, minify your code (after testing) for performance benefits.
DRY and KISS: Don't repeat yourself, and keep it simple, stupid. Pretty self-explanatory.
Stick to Stable: (This is mostly my personal opinion) Unless you're trying to create a framework specifically targetted to HTML5 in Chrome 31, using experimental features and unstable code will make your framework slower, uncompatible with older browsers, and harder to develop with.
Open Source: (Another of my opinions) It takes years for huge companies like Google with thousands of dollars invested to create frameworks (e.g. AngularJS) so it is an excellent idea to make your source openly available. Having a community of developers contributing to your project will make development faster, and will make the end product faster, bug-free, and better all around. Of course, if you're going to sell it, that's another story...
For more information about best practices when making libraries, take a look at these links:
Javascript Library Design
Javascript Module Pattern: In Depth
Best Practices in Javascript Library Design
Building a Javascript Library
Types of Frameworks
The first thing you need to think about, as mentioned above, is what functionality you want your framework to provide. Here are is the list of types of frameworks/libraries (thanks to #prong for the link). For a much more comprehensive list, see jster, which has 1478 libraries, put into 8 categories, each with several subcategories.
DOM (manipulation) related
GUI-related (Widget libraries)
Graphical/Visualization (Canvas or SVG related)
Web-application related (MVC, MVVM, or otherwise)
Pure Javascript/AJAX
Template Systems
Unit Testing
Other
As you can see from the link, there are already dozens of libraries and frameworks in each of these categories, so there's not exactly much room for something new. That being said, I don't want to discourage you- who knows, you could create the next bootstrap or jQuery. So, here are some resources about each type of framework.
Note: you can't say that any type is better than the others, they simply are designed for different goals. It's like comparing apples and oranges.
DOM (manipulation) related
These types of libraries are designed to interact with, modify, and control the DOM of a website. Here are just a few of the things they do:
Select Elements in the DOM ($("div#id .class"))
Add/Remove Elements in the DOM ($("div#id .class").remove())
Edit Attributes of Elements in the DOM ($(div#id .class).height("30px"))
Edit CSS of Elements in the DOM ($(div#id .class).css("property","value"))
Add listeners for various events taking place in the DOM ($(div#id .class).click(callback))
The most notable of these, of course, is jQuery, and it has one of the largest user bases of any Javascript library. However, it is by no means perfect, and if your library wants to compete, the best thing to do would be to make it excel in the areas that jQuery fails- speed, fragmentation, and "spaghetti" code. (The last two aren't completely in your control, but there are certainly things that you can do to make it easier for users to use the most update version, and keep their code maintainable)
GUI-related (Widget libraries)
I think that this may be the type of framework you're looking to create. These types of libraries provide widgets (datepickers, accordians, sliders, tabs, etc.), interactions (drag, drop, sort, etc.) and effects (show, hide, animations, etc.). For these, people are looking for quantity- the best frameworks out there have several useful widgets/effects that work well. This is one case where it's "the more, the merrier," of course, if it works properly.
Graphical/Visualization (Canvas or SVG related)
The purpose of these libraries is to control animations on the page, specifically on an HTML5 Canvas. These feature animations and sprites for games, interactive charts, and other animations. Again, successful graphical libraries have many, many sprites/animations. For example kineticjs has over 20 different sprites available. However, make sure that quantity does not compromise performance and overall quality.
Web-application related (MVC, MVVM, or otherwise)
Basically, the idea is to provide a layout for the users to put their code in, typically separating the model (data) from the view(what the user sees), with a small controller to provide an interface between these two. This is known as MVC. While it is by no means the only software pattern to base a framework off of, it has become quite popular recently, as it makes development much easier (that's why Rails is so popular).
Pure Javascript- AJAX
This should really be two categories. The first, AJAX libraries, are often paired with a server side library and/or database (though not always) and are designed to make connections with a server and get data asynchronously. The second, "Pure Javascript" are designed to make Javascript easier to program in, as a language, provide helpful functions and programming constructs.
Template Systems
This might also be the type of framework you're looking to create. The idea is to provide components that developers can use. There's a thin line between Template Frameworks and Widget Frameworks (which twitter bootstrap, one of the most popular template frameworks, crosses a lot). While widget frameworks just give a bunch of little elements that can be put in a site, template frameworks give structure to a website (e.g. responsive columns), in addition to making it look good.
Unit Testing
This type of framework is designed to let developers test, or systematically ensure the correctness, of their code. Pretty boring, but also really useful.
Other
This type of framework is for really specific purposes that don't really fit into any of these other categories. For example, MathQuill is designed for rendering math interactively in web pages. It doesn't really fit into any other category. However, these types of frameworks aren't bad or useless, they're just unique. A perfect example is Modernizr, a library for detecting a browser's support for features. While it doesn't really have any direct competitors, can't be put into any of the other categories, and does a very small task, it works very well, and is very popular as a result.
More Types
There are a bunch of other types of libraries. Below are the categories (I'm not listing subcategories because that would take half an hour to copy down) that JSter puts their 1478 libraries into:
Essentials
UI
Multimedia
Graphics
Data
Development
Utilities
Applications
It depends on what you really want. The first distinction that needs to be made is between a Javascript UI framework (which provides structure to the app), an HTML UI Framework (Presentation) and Widget Libs.
Javascript Frameworks such as backbone, angular, ember, and knockout provide MVC-like structure to the app.
UI frameworks such as YUI, bootstrap, and Foundation provide a consistent HTML and CSS base.
Widget Libraries such as jQuery UI, Fuel UX, and Kendo UI provide ready made widgets.
There are also fully-fledged frameworks which provide things across the board, such as Google Closure tools, Dojo with Dijit.
This Wikipedia list pretty much sums it up, and here is the comparison.
In order to find the best way to create a framework, first ask this question: Can any of the above frameworks/libraries solve all or some of the problems/requirements I have?
If something solves all the problems, you can use it right away.
If something solves your problem partially, you can start by extending/forking that project/framework.
Follow DRY and KISS rules. Only solve a problem which nobody has solved as of now.
Fortunately, there is already a good solution: Google Closure Library. This is what Google uses. It shows the approach of mixing HTML, CSS and JS. I wouldn't say it's perfect, but I believe it's one of the best ones at this moment. Its architectural principles rely on proven component based and OOP concepts, and it's accompanied with a static compiler for Javascript. It's definitely worth of studying before baking your own solution.
I'd like to say that cloudcoder2000's answer sums it up nicely. I'm just writing this answer because it didn't seem right in the comment section :P
If you are thinking of making another framework, my suggesting is to stop thinking.
First find the thing in current implementations which troubles you the most, and try to find how you can improve it. Contribute to existing projects, nearly all of them are open source anyways. Also, you don't really need to be a JS-ninja to get into their midst. Take a fork, and get started. Once you're done, and feel that you're code is good enough, make it known to the original repo's maintainers that you have done improvements, and are looking for it to be merged into the project.
Keep in mind here that I'm not discouraging you from solving the problem at all.
I'm just pointing out that there are so MANY frameworks out there, wouldn't it be better if you went ahead and contributed to one of them instead of going for complete glory and implementing a full framework yourself? Making a framework is hard, but getting people interested in your framework is HARD. Really Really HARD, even for Google! Only once Angular got a very good documentation (which itself took quite some time, and resources, of Angular evangelists), that it has gathered so much steam. So, I'm just saying that instead of creating your own monument, perhaps lending a hand to others would be a more worthwhile exercise.
Most importantly though, is the fact that since you are just starting out, I presume you wouldn't have much experience designing frameworks, or thinking in those design terms even. It would of immense value if you contribute to existing projects. Then you will be gathering knowledge and experience of how things are built. Then, you'll be more confident. Then, you can go ahead and make your own framework! Then you'll be more equipped to tackle mammoth projects such as designing a framework. And Then, my friend, will you make something which would be worth the time of countless developers.
Short answer
Build a skinny DOM and only focus on JS code to make it more efficient.
Long answer
A good architect always replies with "it depends." You can't have one single framework that enjoys all others' benefits and suffers from no disadvantages, all at once. There's always a trade-off.
In order to create a framework that is really lightweight, you would probably want the lightest DOM (HTML) structure. However, having a skinny DOM might have the cost of more JS code. So you would probably try to write the most efficient code. You can start here.
Needless to say, you should be keeping the open-close principle, and have the stylesheets separated from HTML, using only classes and never inline styling. I would suggest using less. It makes the implementation faster, and the result is pure css so you suffer from no performance issues around it.
I must respectfully disagree with cloudcoder2000,
From a young age I have been being told don't re-invent the wheel, but why?
During the last 3.5 years, I have re-invented almost all of my web controls using javascript/html/css. From the extremely complex; for example a grid, rich text editor, tree view, dialog. To the very simple, like a progress bar, dropdown. What I gained is a better understanding of html/js/css.
No pain, no gain. I'm so happy with what I was doing these years as I learned more than others.
Some of the controls I re-invented, I think, are much better than the popular ones, like telerik, jquery mobile, extJS. For example, my tree view is fully customizable, with it one can build very complex trees.
So, I encourage you re-invent the wheels, and you will definitely get more than you expected. But also, from the beginning, you need to learn the source code of the popular controls, and re-invent them. You will be very happy when you find yourself be able to make the controls better.
Then the tips on creating HTML controls:
1. use jquery;
2. write jquery plugins(jQuery.prototype...) for simple controls, while define classes for complex controls;
3. separate css from html and js files. Define the html template in js, don't use html files, which make using the controls hard.
Regards,
Leo
For best performance in your UI design, you need to use a lightweight JavaScript framework like angular or backbone, Twitter Bootstrap for the UI, AJAX for base script load and use gzip compression in your app to make it lightweight and help the UI render faster.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Our company builds websites and web applications. We are a small firm and our team of developers are always building the javascript functions from scratch or copying from other websites built by us. Every time I bring to the table the word standardization and using a JS framework like JQuery, Prototype or any other, I am told Frameworks have the three points below as arguments against them:
Mainly for people that don't know enough JS
Frameworks limit Javascript developers
Frameworks bloat the actual development code with a lot of things that are not used.
We don't use enough Javascript in our applications for us to need JS framework
In my mind it seems that Frameworks, give our team a good starting point, documentation, a community and always the option to grow on top of the framework. Could some Framework users elaborate further?
EDIT 1:
Thanks to all of you for your great responses. I really did not think that this was going to be such a hot topic. I am glad I asked the question. I posted another similar question in the following link in case you might think you want to add something. The topic of the new question is CSS related. Thanks.
By your coworkers point of view, .NET and JAVA are for people who don't know enough assembly.
Frameworks exist for a reason. They allow you go focus on the problem instead of dealing with repetitive code. They allow you to be confident (assuming you use well tested frameworks) that certain pieces of your code are reliable and well tested.
If your coworkers are against frameworks, I would seriously consider moving on.
Since no one has mentioned it - a Javascript framework rapidly becomes one more project dependancy, and in general terms, dependencies are bad as they represent points of failure.
As for this:
Mainly for people that don't know
enough JS
Without elaborating, I will say that if one of our team said something like that in my presence, I would try to shrug it off as a joke. If I thought they were being serious, I would probably have to kill them.
And as for this:
Frameworks limit Javascript
developers
That could translate to "Frameworks make it marginally harder to write spaghetti code, and that's what I do best"
Those are not arguments, they are excuses.
Arguments against:
Frameworks prevent you from re-inventing the wheel
Frameworks generally contain well tested code
Frameworks are well supported by the community
Frameworks force you to focus on the business problem you're trying to solve
</sarcasm>
Frameworks may have a license you don't agree/can't work with
A few positives for javascript frameworks (like JQuery).
They provide standardization in ui
elements.
Reduce time to develop complex
interfaces and effects.
Normalize efforts by providing
functions that are already
cross-browser compatible.
Due to efforts in cross
compatibility documentation is more
useful in a framework as you can use
the framework's api as canon
instead of searching for obscure
support for various/proprietary
javascript functions.
Reduced learning curve for new
developers making them productive on
your software quicker.
I completely disagree that a framework limits javascript developers. Quite the opposite actually. Most frameworks provide extensive plug-in mechanisms where the framework can be extended using raw javascript utilizing hooks in the framework itself.
I'll use jQuery as an example, but what I'm saying here could apply to most JavaScript frameworks.
Many frameworks (notably jQuery) are far too monolithic and not modular enough.
While depending on well-tested 3rd party software is often more than justified, "frameworks" tend to give you a lot more functionality than you need at the moment.
In many projects, I very much like the convenience that jQuery gives me for selecting sets of elements (using $(".classname"), for example). But, if I'm not using any significant amount of AJAX, I don't need the AJAX utilities provided by jQuery.
Software should do one thing and do it well, and software written in JavaScript is no exception. Most of the frameworks you refer to try to do everything, resulting in unnecessary complexity.
One place this can bite you is when you're considering upgrading to the next version of the framework. That involves crawling through jQuery's changelogs for backwards-incompatible changes and searching your project for areas where that code is used. This can be quite a nightmare, especially if you don't necessarily have a comprehensive list of which jQuery features you use and which ones you don't.
Also, jQuery (and other frameworks) tends to cause developers to start depending on new features of jQuery without even thinking about it, making it harder to determine which features of jQuery your project uses and which it doesn't.
If you use a utility which does one thing, then you know exactly which features of that utility you're using. There's only one. (If you aren't using that utility at all, it's easy to determine. Such a determination would mean you could safely remove it from your project.)
I'm all for using well-tested 3rd party code. But if it tries to do too much, (that is, if it's a framework rather than a utility), you should probably look for an alternative. If it tries to do too much (like jQuery tries to do too much), then it's got some serious, foundational design flaws that will probably come back to bite you.
I'm surprised no one has already mentioned it:
A lot of web developers default to using JQuery without considering the alternatives
And end up including it on a web page to do a few trivial tasks which could easily be done in pure JavaScript
The result is that users have to wait for the whole library to download and it slows down web browsing
Also:
Some web developers get carried away with the design of web pages, and end up developing unnecessarily complex web pages because of the power of JQuery
Just because JQuery enables you to create scripts with good cross-browser compatibility it doesn't mean that the end result is usable on different devices / interfaces
I'd also argue the cross-browser compatibilty because I've seen instances of webkit not playing well with JQuery
JQuery encourages "fast" scripting - but if you rush it you are likely to have missed something out
Writing in JavaScript from scratch is slower - but I believe that you end up with a more complete solution which more closely matches the users needs
Using JQuery can shift the focus of the web developer to creating web sites which are highly graphical and visually appealing, whereas the focus should be on functionality and usability
JQuery is not a silver bullet for web development
I am biased here because I don't use JQuery, but it is because I haven't found a need for it yet - maybe it's because I focus more on usability and functionality rather than making the user interface look pretty (sorry I know JQuery can do more than that).
An argument against libraries is BROWSER SUPPORT most libraries support only a subset of browsers out there .
Here is an example of BBC rolling out their own instead of using something like jquery .
I liked the answer of pb +
Mainly for people that don't know
enough JS
I believe it is too complicated for them, so they use this excuse. FW allows you to build much more complex applications.
Frameworks limit Javascript developers
bullshit
Frameworks bloat the actual
development code with a lot of things
that are not used.
what is it today extra 100k-200k? especially if you use the CDN versions (at google for instance). And this is assuming you use nothing in the FW.
There are plenty of good reasons to be suspicious of frameworks in general, balanced of course by lots of reasons why they are worthwhile.
I use jquery now, and frankly within an hour of learning it realised that it fits the job so well that if it didn't exist I'd only end up reimplementing something very similar myself, only it wouldn't be as good or as cross platform.
There isn't much bloat there, it's very small and well designed and does nothing at all that stops you writing any javascript you want for specific cases that don't fit your needs.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm currently using the Yahoo YUI javascript library in a couple of my projects.
However, I'm a little concerned about three things. First, they laid off 10% of their employees. Second, their stock price keeps falling: especially after ignoring the MS takeover earlier this year. Third, what if someone does buy them?
The only reason I bring this up is that I tend to build applications that are going to be around for 8 to 10 years.
What would you do?
As a member of the YUI team, I would add the following to this conversation: Almost everyone who has ever worked on the team is still with Yahoo and still working on YUI -- a remarkable consistency for a project that is now almost four years old. No one can predict the future of Yahoo at this point (or of any other company), but you can bank on the code you're using today. It's free, open under BSD, and no one can prevent you from using it regardless of what may happen in the future.
We continue to be excited about YUI and we think its next four years will be better than the last four.
Regards,
Eric
Yahoo is a major company that won't end in the next couple of year.
The Yahoo! library is open source so you will have other people to continue to improve it IF Yahoo would go bankrupt.
No technology is 100% safe for 10 years perspective, I think you aren't in danger with it.
In 10 years Javascript will be completely difference and most framework will not be the same so I think whatever you choose you will need to change a lot of thing in 10 years ;) Just be sure to keep a version of the code in you repository to always have the latest version that work for your system and you will be fine.
Everyone else here has already mentioned that YUI is open source (and thus, can be extended, forked, etc)
But the important thing to note is that Yahoo USES YUI on their own web properties. It is a valuable project to them, not just as an internal component library, but as a standardized way to write JavaScript code. Once you wrap your head around that, you'll realize that if Yahoo is still on the internet, it'll probably still be putting resources into YUI.
Also, albeit a huge fan of jQuery, a levelheaded developer cannot seriously recommend a particular framework over another without having a project context and design considerations.
You can't just assume that your square peg is going to fit in everyone's round hole, no matter how hard you try to jam it in.
I switched to jQuery a while back and have been much happier since doing so. You should consider the fact that YUI is open source, so you could always make any needed updates you need in the future.
Switch to jQuery?
I learned YUI prior JQuery, and the problem with YUI is (in my opinion) is over engineered, meaning that is more complex. JQUery is fun to code and at the same time you can do everything with it.
My advice would be to use JQuery, and if you need some YUI component then use both. However i don't see any particular advantage of YUI over JQuery.
Even if Yahoo! goes under, their library is open source. The community will most likely pick it up and continue its development.
I've switched over Jquery recently, and the boost in productivity is noticiable.
YUI does have better docs, but it will break compatibility on 3.0.
Leave your legacy code on yui, and switch to jquery for new devs.
I don't think its ever safe to say "one library for all solutions".
Its always best practice to analyze each project you do and then decide which library to use. Whether that be jQuery, YUI, mootools,etc.
To answer your question a bit more bluntly - don't worry. The web is one of the fastest growing and evolving sectors out there. I would be surprised if your projects don't get re-developed (by you or someone else) in the next 3 - 4 years.
If your web app exists for more than 4 years in it's current form, then that's amazing. That will mean it's dealt with new browser technologies and possibly loss of existing ones. It also means that the site will not need major modifications in that time.
Most web applications I have worked on have been nearly completely rewritten after 3 years. Usually this is because requirements change; usually there are so many additions in that time that it's a completely different piece of software.
Also, in 8 years, I'm sure the YUI will have changed so much that it won't even be the same. 8 years ago it didn't exist; 8 years from now it maybe something completely different. This doesn't mean you can't continue to use the existing libraries exactly as they are.
The only thing you might think of doing is keeping versions yourself. I don't mean loading them from your own server, but just keeping them somewhere. Even just incase YUI changes something and ends up breaking something you were using--not likely.
I think any library is subject to these same concerns: YUI or jQuery, etc.
Well, Yahoo is still a profitable company with over $3 billion in the bank. I don't expect it to go bankrupt anytime soon unless they do something really awful.
However, Yahoo still needs to cut costs and they could just stop developing YUI to move the developers to other places. Just something to keep in mind on whether or not you choose to continue on w/ YUI. At it's current state, I don't see YUI being a revenue generator which is what Yahoo needs right now.
I've used YUI on a project 1 year ago.
I was pretty satisfied with the library even if I found really hard to grasp the way it worked.
After I while I discovered jQuery and tried it on another project.
Man, that was another world.
These days I am doing some changes to the old YUI project.
I wanted to port everything to the 2.8 (from 2.4.2).
I expected it to be easier but it wasn't.
After having spent few months on jQuery I must admit that YUI is overly complex.
You can do almost everything and configure every aspect of your App but, well, it takes ages to understand things, or at lease for me.
jQuery is much better and faster.
The plugin system is amazing.
I didn't try YUI 3 cause I've decided jQuery is good enough for me.
If the library does what you need it to do today, I see no reason not to use it. 8-10 years is a long time for a web-app but I'd like to think Javascript will still be around.
If you are using it with the expectation that it will have great advancements in the future then your concerns are valid but I think the same can be said for almost any technology/language/library. And since it's open source you or others could continue the development.
Here are your options:
1. Build your own Javascript library
2. Use the existing YUI library
3. Use some other 3rd party Javascript library
You can download the entire YUI library and run it from your own web server, so you don't need to depend on Yahoo servers. The code is open source, so you are free to make enhancements yourself if Yahoo stops building it. Given that, I personally think using YUI is much better than trying to roll your own Javascript library. I see a ton of benefits with virtually no risks.
The question that remains is whether you should use YUI or some other 3rd party library. Just about all the other open source libraries share the same future risk as YUI. I would personally look at the features each library supports and pick the one that currently supports everything you want (or the most of what you want).
First, It's open source so you can continue to use it no matter what happens to Yahoo. Besides, no one thinks they are going anywhere anytime soon.
Second, no matter what third party library or tool you use, you're always faced with the risk of them abandoning the product at some point, or even worse, the company going out of business.
Regardless of either, you can still use it after either of which happens. And not until then do you really need to switch? Also, the way the web has been changing, you may not want to use YUI in a few months either way, who knows?
jQuery is for coding, YUI is for learning.
jQuery is more widespread than YUI because it is easy to sprinkle it on web pages that need simple DOM manipulations and basic AJAX or animations.
YUI is an extremely popular library that has historically been a favorite of more advanced developers and application builders.
jQuery is too small and tiny, so that you have to find other frameworks/libraries to working together. You have to take a lot time of investigating test framework, ui framework. MVC frameworks...
But if you choose YUI, it's enough!!! test frameworks(browser and headless), ci tools, widgets, css grid/architecture, AOP, MVC... all the fancy features you want in one Framework! that's really kool.
So if you start a enterprise project, I suggest to use YUI, though it's learning curve to be a bit steep.