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
we are currently evaluating the use of AngularJS in a Enterprise Application (e-Banking) as a Single Page Application.
Many of the devs#work are already convinced that there no other way to go. It is the trend, it is future proof (html, css and js) it is easy to do, less burden on the server etc etc.
Despite the interesting part of this framework, i am not convinced that there are factors that must be considered before going this road. These can be:
Maintainability of code
Testability of code, not only the ui part
Continuous integration (like TeamCity or TFS)
Developer friendliness like debugging, navigating through code
Security (if there is a risk)
Has anyone any experience on enterprise apps build like that? I would rather go with Asp.Net MVC4. Please no hypothetical answers, i don't want to start a war. Real life experience is really appreciated.
Regards
I had thought about this when incorporating Angular into our enterprise application. First, some optional background information. I really needed to keep all my page state on the client side since recreating it on the server side is a very resource intensive task. I started off with building it with just JQuery, since I only needed a few things, but soon I found myself having trouble keeping track of the callbacks I wrote just last week. Hence, I wanted to refactor. While I was at it, Angular looked like the best fit for my programming style.
To address your concerns:
I think that it is more maintainable, since it encourages you to split things up. This, however, depends totally on your team and your discipline to keep things maintainable.
The Angular team definitely thought about testing when they were making it. Things are very easy to test, from unit testing to e2e testing. Others have even found a middle ground in between.
We use Jenkins at our Microsoft shop for continuous integration since it was easier for us to plug in our own programs to make it work with our complex environment setups. However, I don't think this relates much to which framework you decide to go with.
Coming from Visual Studio, I find JavaScript in general leaves something to be desired. I love edit and continue, unwinding the stack, and dragging that yellow arrow around. That stuff is just pure magical bliss. Debugging on the browser just doesn't give you all of that.
Security is pretty good. Looking through the docs, you can see that the team is concerned with security issues such as XSS and CSRF attacks. However, anything done over the browser is hard to secure. There are new attacks and bugs discovered every other day. If you are really concerned about security, you wouldn't have an online app. You would make sure that your customers only banked in the branch with multiple forms of ID. With that said, I don't think Angular is any less secure than any other JavaScript solution.
I would like to raise another issue with all of these JavaScript frameworks/libraries. They're all fairly new and constantly evolving. Look at how many functions JQuery has deprecated recently, and you'll get a sense of how hard it is to keep on top of your libraries. Many of these are also forgotten and left to rot. Angular being one of Google's products also makes me a little scared, since they have been cancelling waves of their projects. Hopefully, Angular does not become one of those.
The documentation is also lacking. Although the community is good, the documentation is not. Many pages are half done. Again, compared to the latest stuff from Microsoft, the documentation is pretty sparse.
This being one of the new things, it is harder to hire someone to help/take over this stuff.
Despite all these drawbacks, I really like it, and I'm definitely going to push my company towards adopting it.
Yes I have used Angular with Asp.net WebAPI along with MongoDB .Pls find my findings
1)Testability is absolutely fantatic .You can easily test you unit test using karma and jasmine
2) CI. Integration of Jenkins is available with Karma
3) Easy to debug similar to Javascript debugging can use chrome extension Bartrang to debug angular apps easily
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
This is going to be more of a opinion question because I can't find any answer on Google or any SME's within my company that really have a opinion on this.
I wasn't sure if a opinion question is appropriate, so if its not please feel free to delete this, ban me or whatever the rules may dictate.
I'm work on a large set of very old Workbooks that are used for math calculations, these are not used in Production they are for check the results of the Production service. The Workbooks are very old (some 12+ years) and are now what I would call a 'mess' from the last decade of patching/fixes.
I've been researching Handsontable (https://handsontable.com/) a JS library that provides a spreadsheet interface like Excel that would handle all of the setting of the values of the cells etc... Then use Python (or Java if the company prefers for use J2EE) to do some of the heaver calculations (data lookup and projections) on the server side, or client side, I feel that just moving from VBA and Excel itself will provide a performance boost which Operations would just love.
I feel that the initial work would be a lot of hours, but I believe that I can create a common set of library's either in JS/Python/Java that will once completed reduce a lot of the re-coding that would need to be done on the VBA to JS/Python side as 80% of the VBA is common financial formulas.
My fear is that if we continue on the path with the current Workbooks in another 2-3 years they will become completely un-maintainable, alot with the fact that with VBA we don't have proper version control or the use of modern automated code review tools which we can benefit from by using newer technologies and in the long wrong will, hard work aside will prove to be the best option for our developers now and for my future colleagues.
If this question is ok by the rules and moderators, does anyone have any opinion on this? Is this worth while? Is it a waste of time?
Note: I'm not a manager, director or anyone with the power to make a decision as proposed above, I'm just a developer that feels I.... We can do better.
Thank you for your time.
So this may not be the answer for everyone, but I'm going to give you what we decided to invest time in first since this method was already used on another application to move it from a an old language to Java.
We have found several opensource projects online for the conversion of VB/VBA code to Python.
Examples:
http://vb2py.sourceforge.net/
https://pypi.python.org/pypi/vb2py
Once we have the Python code working using the native package to allow MS Interop access we will begin to refactor the Python code into a Django project (this choice isn't firm, but its my preferred choice; <3 Django) including creating the wrapper models for DB access. We feel we can make a wrapper for the MS Interop part to allow it to run as a Django project.
The plan in the end is to have the Django project act as only a REST Web Service for doing the 'heavy math/calculations' functions to Python and also could be on a much more powerful server increasing performance all around. This REST Service would answer calls from a Handsontable (https://handsontable.com/) JS Spreadsheet with the required plugins to handle all the current Excel formulas so we can do a direct 1:1 copy of our cell values/styles (convert Workbook to xlsm makes all the data stored as XML) to a Handsontable 'layout array'; which I think we will put in a DB. So in the end we have now given out Workbooks 15+ years of life and have removed Excel from the equation all together.
The current (mine) reasons for using Django are:
ORM
Independent Django packages makes reducing reduent code easier (I know this could be done with just pure Python but I feel its a good reason to put in my answer for others)
Easy to implement a Web Service using one a few very popular REST packages.
There are others but I believe everyone will get my points.
And the reasons for Python:
Runs on Linux, running VBA Macros server side requires Windows (bad: VM Cost when compared to Linux and less OS overhead).
Very easy to learn (I feel anyway)
Custom method decorators will make apply such things as standard interests rate to the return amount of a method without needing the interest rate code in the actual function that calculations amounts (as an example)
Thanks
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 needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Background
I need to create a potentially very large HTML/JS mobile web app that will be delivered as a mobile web site and natively using Phonegap. I'm currently working to determine the best way to organize the app itself.
The basic plan is to have many modules that will each focus on a different subject of interest . Some of these modules will be very basic (ie, announcements / news) and some will be very complex (ie, sports: team players, schedules, video, etc). There will be a side-drawer navigation that will apply to most pages so users can quickly navigate to a different module. There needs to be the ability to deep-link within modules. These modules will be created by a variety of developers and vendors.
Single Page App
Most of the mobile solutions I see involve Single Pages, which seem like a bad idea to me in this case, since there is the potential for so much memory use. It also seems like it would be difficult to reconcile hash navigation between modules and hash navigation between section within modules. Module development would have to be done with the app framework in mind and limits how things can be done by vendors and developers. On the other hand, things aren't getting loaded as often and everything can easily communicate with each other.
Multiple Page App
Using multiple pages, it seems like each module could easily be created in whatever technology a vendor was comfortable with (and could do quickly and cheaply). It would cut down on memory use, but also remove the ability for modules to communicate (a feature that I don't know is necessary for us at this point). I could see making a javascript library every module would use for common handling of various events (like logging errors, navigation, etc). Each app navigation between modules would be a new page call, resetting the DOM. Each module could use a single page design if it wished.
Help Me Please
So, is there any common or new knowledge about how things like this should be designed? I'm eager to begin work, but don't want to be rewriting things that may already exist. Do I have any glaring flaws in my reasoning? I'd love to hear from anyone that has insight.
Honestly, if you are considering building any app that you believe will be high volume and of high complexity, you really ought to consider doing native development, or at least use something like Appcelerator where the application will be "compiled" down to native code for better performance. If you are intending to just let any number of developers build their own javascript components that may or may not do a good job of managing limited system resources, so are going to quickly run into application performance issues.
On the other hand, if you are just going for proof of concept and don't mind potentially having to greatly refactor your application architecture when and if you get a sufficient level of complexity, then you may want to simply go with the web app approach.
Really, you need to also be considering your backend service architecture as much or more than the frontend architecture. that is really where you are going to run into problems down the line in trying to integrate offerings from other developers.
I had a similar architectural problem to contend with a couple of years ago. It wasn't mobile, but it wasn't entirely web-based either. The target applications were a mix of web sites and desktop apps, with the potential to go mobile in the future.
The interesting part was that there had been two prior attempts at creating a framework that could be used in a variety of situations. The problem, and the reason both attempts failed, was that the developers saw it as a UX problem space. They approached it using several different technologies, but became mired months down the road because they had made assumptions up front and flown the project by the seat of their pants.
My approach was to eschew all the UI discussion completely and focus on a backend architecture that could be approached from any standpoint. To this end, I created a web service that had data going in both directions, and was ultimately serving a mathematical model. The service is being accessed from a variety of sources using different technologies: Flash, Unity, a Google Earth plugin, and finally, from an unrelated web architecture serving up good ol' HTML.
My advice to you, is don't concentrate on the front-end mapping so much as get your back-end right. Once you have a data structure in place, you can build outward, and several issues such as memory management, monolithic app or not, i.e. one page versus many, will almost resolve themselves. Work on creating a great API with lots of good interfaces and you won't fall into a "many chefs" hole. Give a bunch of dispersed developers enough rope, on the other hand, and you'll never find where all the knots are!
The decision whether to ultimately go native API over HTML5-based technology such as Sencha Touch, jQuery Mobile, or Phonegap is an evangelical black hole that will be played out over the coming months and years. Native apps may be more fluid and speedy in some cases, but the investment in resources is something that should be considered. On the other hand, JavaScript developers are lurking around every corner and are not in short supply.
Your first step is to nail down those requirements.
If you're doing this for yourself or for your own company, then nail down how these modules (co-)operate.
If you are doing this for your employer, then somebody there ought to have a clue what they want to see, otherwise, how are you going to build it?
A solution which supports multiple pages, opening and closing modules with no communication is going to require different things than a framework which is responsible for maintaining multiple widgets at the same time, which may or may not communicate through system-calls or services.
There's no way around that -- building services/sandboxing/etc for modules is going to take more work than treating each like a page-change (or making them be literal page-changes).
When you figure out what you want your program to do, start building out an idea of the API you'd like other people to have.
Are you going to provide them with an API for building UI components, or are you going to leave that to their own whims?
Personally, I'd avoid a situation where each module change just replaces iFrames, and then the end-user can do whatever they want in there.
Likewise, I'd avoid situations where you're allowing module-creators to run whatever they'd like in a non-sandboxed environment... It ends poorly for your end-users (or you, in UK court).
But that's not a concern, yet.
First-concern is what does your platform do.
Then figure out what your back-end communication is going to look like, and what interfaces you're going to provide to module creators, and how you're going to get data from your end to theirs (http-based API, REST or whatever else... ...but work it out WELL, if you don't already have it).
THEN, when you know what your platform is expected to do, AND you have a backend which can serve all kinds of tasks well, figure out what services you're going to provide to content-creators, to make their widgets, and to upload/download data from your service, and sandbox, and the like.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I am a java-programmer and a few months ago I discover frontend programming with javascript and html, and it is absolutely cool. So here is a js newbie's question.
Is there any IDE, default workflow or maybe best practices for javascript libs development? I didn't mean coverage and unit testing or something like this. I mean is there any tools or techniques which should I use while developing html control with some js-logic, for example? Should I write small test page in text editor and open it in dozen of browsers pressing F5 each minute and watching at browser's console or maybe there is some magic IDE which will on button press reload all browser instances and collect reports from browsers?
JavaScript Fundamentals
Be sure that you know the language. JavaScript is a bit tricky in this regard: you can easily think that you understand the language, but there are weird things that can sneak up on you. I highly recommend JavaScript: The Good Parts by Douglas Crockford. He also has some talks on Youtube with the same name that are definitively worth watching.
JSLint
Integrate JSLint or a similar tool in your workflow. It is a style checker and static analysis tool for Javascript and helps catching subtle bugs.
Avoiding F5
Check out live.js:
Just include Live.js and it will monitor the current page including
local CSS and Javascript by sending consecutive HEAD requests to the
server. Changes to CSS will be applied dynamically and HTML or
Javascript changes will reload the page. Try it!
Browser Developer Tools
Get familiar with them. I personally strongly prefer Chrome's developer tools over Firefox/Firebug, but regardless which one you choose, learn how to use the debugger.
Node.js
You should also be aware that you don't have to test Javascript logic in your browser: you can use it as any other scripting language using node.js.
As a seasoned programmer here are the steps you should follow for JS lib production.
Separate the UI from the application logic. In this case create one component for the application logic that is completely separated from all API access. API access, which means DOM and WSH and Node.js, should be separated out. I go so far as to use different files to force and ensure separation.
Create UI environments to access your logic. Have a production UI control for access by your audience and also a separate internal UI control for your sandboxed development. For example I have written my application at http://prettydiff.com/ to work from commandline, and from a browser. I have also written access methods to the application access similar to the published HTML but different for my own development for more rapid unit testing. In a sandboxed UI can use a recursive setTimeout to refresh the page in intervals for automated test plan verification as you are writing and saving code.
Focus on availability and distribution. People can get my libraries directly from my website, Github, and NPM for Node. I have a regimented process where by I upload code to the site during a production release and then perform a quick verification in the browser. If the release did not break the application then push to Github and then push this exact same location to NPM.
Distributed access to code operation is even better. Its nice having rapid and even automated access to libraries online, but being able to access unit testing via request is even better. I can remotely unit test my application's code by accessing code samples online directly by telling my application request a code sample via URI. This means that not only is my static code available for distribution and testing, but so is its operation.
Good documentation is everything. I will never even bother to examine a lib if the documentation is weak. I am not talking about code comments, though these are important. I am talking about end user documentation. I want to be able to read documentation and know everything about the subject. Node.js became popular because even before the codebase was stable it's documentation kicked ass. Get other people to QA your documentation before they QA your code. Without stunning documentation your lib is less than worthless to me.
Know your mission. Each and every lib should have a clear, simple, and well stated purpose. If this is not established then the lib is not ready for release. If an enhancement confuses the lib's purpose then it may be time to divide one library into multiple smaller libraries. Focus on precision, clarity, directness, and only the sole stated mission of the lib.
Independence is vital to adoption. I don't like libs dependent upon other libraries or frameworks. Its great that your jQuery library may be the best thing since slice bread, but I won't be looking at it. Independence means greater portability and freedom it mix and match it with other libraries that you are not aware of.
Style is important. This is touchy subject, but style is important. Keep the logic in your lib as simple and declarative as possible. If your code is absolutely declarative in nature then your algorithmic patterns are awesome. Avoid use of the new keyword unless you are an experienced JavaScript badass and severely limit use of this keyword as it will fail you in future maintenance operations. Do not algorithmically build out large strings with concatenation and continually watch the execution speeds of your code. Because even trivial changes to style or seemingly minor enhancements to the logic can destroy execution efficiency I put a timer on all my UI controls. In your development use profilers, such as Chrome's web tools to track down long operations in JS execution.
Be open about your failures. Software is never perfect and other developers will always respect this. If you encounter a bug before anybody else then be open about the existence of the bug. If it will take more than a week to get the solution out then don't delay notification. Notify your users immediately so that they are aware. I recently rolled back a major enhancement to the logic of my diff algorithm because additional unit testing showed heavy slippage. I rolled back the same day I made a decision the prior release or two was flawed and was open about the rollback. If you want people to contribute to your code base or provide bug reports then openness is critical.
I know you may have explicitly said that you didn't mean unit testing, but that is precisely the way I recommend you write javascript libraries.
If you're a Java developer, you may be familiar with jUnit. If so, qUnit may be more natural to you. Otherwise, I recommend you take a look at Jasmine or Mocha. While I prefer Mocha, my experience with Jasmine has generally been better for in-browser development thanks to the awesome Jasmine-Jquery plugin.
If you're writing qUnit tests, take a look at IntelliJ IDE which allows you to execute tests in addition to providing code coverage.
If you're developing on the browser, take a look at LiveReload. It'll watch files for you and auto-refresh your browser - great for instant feedback.
For browser compatibility, I would recommend you just get it to work on one first reasonably before worrying about the others. Check in from time to time to see if you find issues. See if jQuery can abstract some of that mess for you. Otherwise, take a look at Adobes BrowserLab.
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.