Develop Reference

AngularJS and Enterprise applications [closed]

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

What are some empirical technical reasons not to use jQuery? [closed]

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 9 years ago.
Context:
I am astounded by the number of front end developers that hack at HTML, Javascript and CSS all day long and that ignore tools like jQuery ( or other equivalent helper frameworks ) and refuse to use them. I am not talking about JavaScript gurus, I am talking about in the trenches every day Joe production developers. I get a lot of arguments that are more like excuses or personal opinions that I don't think have any technical merit, I want to make sure I am not missing something.
Question:
What are some empirical technical reasons not to use jQuery?
I am not looking for religious or dogmatic arguments or subjective opinions "like some other framework is better", consider jQuery the straw man for all comparable frameworks in the question.

Update 2015:
In this answer from 2011 I'm talking about libraries like jQuery, YUI
or Prototype. Today in 2015 that reasoning is still applicable to
frameworks like Angular, React or Ember. In those 4 years the
technology progressed tremendously and even though I see considerably
less prejudice against React or Angular than I saw against jQuery or
YUI, the same kind of thinking - though to a lesser extent - is still present
today.
Update 2016:
I highly recommend an article published few days ago:
Why jQuery? by Michael S. Mikowski, author of the Single Page Web Applications book
That article is basically a very detailed answer to this very
question. Had it been available when I was writing the answer below - I would have definitely quoted it.
Original answer:
I'll answer about jQuery but those are the same arguments that I've heard against using YUI, Prototype, Dojo, Ext and few others. Main arguments that I've heard:
file size, which in fact is 84.6 KB in case of jQuery 3.2.1 - probably smaller than the logo on an average website and can be served from Google's CDN which is likely to be already in the cache of most of your visitors. As using jQuery always means smaller file size of your own JavaScript files, it can actually mean smaller download, even if not already in the browser cache.
speed - writing pure JavaScript may be faster, but writing portable JavaScript seems to be impossible for most of the people. A website that is faster but doesn't work on every popular browser is useless in the real world. Besides jQuery uses some pretty heavy optimizations to actually be pretty damn fast and keeps getting even faster with every release, so it's actually not so easy to write faster code by hand for anything other than trivial examples.(*)
"intellectual property" - a company is scared using someone else's code - while in fact jQuery is open source and free software that is used everywhere from your grandma's blog to Amazon, from Twitter to Bank of America, from Google to Microsoft - if they can use it then any company can use it.
I can't remember hearing any other argument being used seriously.
(*) Here's a trivial example: getElementById('someid') vs. jQuery('#someid')
Is using getElementById faster? Yes. And of course everyone always checks the parentNode to catch when Blackberry 4.6 returns nodes that are no longer in the document, right? jQuery does. And everyone handles the case where IE and Opera return items by name instead of ID, right? jQuery does. If you don't do it then your code is not portable and you introduce subtle bugs that can be very difficult to find. And getElementById is the most trivial example that one could possibly find - don't even get me started on events and AJAX and the DOM...
Update:
There is actually a fourth result of asking why someone doesn't want to use jQuery. I forgot to put it on this list because it is not really an answer but rather the lack of any answer. The comment I got yesterday reminded me about it. This is hardly a "technical reason" to be added to the list but may be interesting nonetheless and may actually be the most common reaction.
What I personally suspect to be the main underlying reason to all of those reactions, though, is what I believe to be the biggest obstacle to progress in computer science: "I don't want to use it because I never did, therefore it must not be that important."
It was once the reaction to optimizing assemblers, compilers, structured programming, higher level languages, garbage collection, object oriented programming, closures or pretty much everything that we now take for granted — and today it's AJAX libraries. Maybe some day no one will remember that we once used to manually interact with the raw DOM API on the application level like now no one remembers that we once used to write programs using raw, unadorned, inscrutable hexadecimal numbers.

jQuery expresses everything in a DOM-centric paradigm which can be misleading and doesn't require any need to express things in an application pattern.
Many developers wind up programming themselves into a corner with this DOM-centric pattern and eventually realize they haven't created anything extensible or reusable.
Rebecca Murphey has a great write-up of her own switch to Dojo from jQuery - the blog post is more about why not jQuery versus why Dojo.

One reason not to use a framework - and this is an extreme edge case - is when writing embeddable code for another website, such as a banner. Arbitrarily inserting some complicated library or another will be polluting the namespace and potentially breaking someone else's site. Not that I wouldn't put it past some advertisers to try anyway, the pond-sucking scum, but I digress...
I disapprove of adding a framework when one is already present and equally capable. I see it all too often and it's my pet hate, I see it as unwarranted bloat. That is another question entirely.
Other than that I cannot think of a justified reason not to.

filesize - but really, beyond that, it's an absolute god-send for cross-platform javascript and browser differences. You would have to have some very good reasons not to want it in your toolkit (or be a fundamentalist developer idiot).

They can't justify the filesize (even though it is probably less than script which doesn't utilise the abstractions provided).
They don't want to rely on third party tools.
Their business does not want to run any libraries (for whatever reasons).
Their business does not want to run any JavaScript code not written by their employees.

Learning: To actually code everything, and learn more. (Rather than using pre-coded stuff)
Size: jQuery has TONS of features you might not need, why make the user download so much code if it's not going to be used?
Alternatives: at this point, there are dozens of more powerful, well structured web frameworks out there.
Flexibility: Although jQuery is really flexible, you might need something it doesn't provide.

By all means, I like jQuery, but there are some reasons not to use jQuery:
Download size/bandwidth: jQuery 1.5 is now over 200K uncompressed, for some the size of the library is too much to justify the benefit.
Performance: Writing native JS will always be faster than abstracting it behind a library.
Added complexity: Many people will download the entire jQuery library when really they only need a few neat features from it.
Application Dependencies: Introducing dependencies always has its hang ups. If there is a bug in jQuery, you can debug and edit the file, but upgrading later introduces problems. You could leave the bug, but now you are dependent on jQuery's time table for a fix, not your own.

Because quite often it's just unnecessary.
if all I want to do is validate some input, or hilight some field then it's just as easy to write simple javascript / dom code. And jQuery doesn't really help in such simple cases, so the question should be why use it?
Clearly there are many cases where it is very useful, but sometimes people seem to use it for no real reason too.

I would prefer to use jquery for dom manipulation or traversing the dom , which is really easy with jquery . Moreover, attaching an event or event delegation are so easy using jquery or other framework otherwise you have to write custom event attachment for IE or non IE browsers etc.
But it has some performance penalty when you use $.each instead of vanilla JS for and array.push()...
other issues like if you bind an event and remove that without unbind it will have memory leak....
My conclusion is only use any framework for complex dom manipulation and rest use vanilla JS

Why not use jQuery?
I can't think of a good excuse to use vanilla JavaScript over jQuery (aside from the intimidation factor of learning something new), but some people prefer other JavaScript frameworks (like the excellent MooTools) due to the philosophical differences between them.
Some people simply don't like jQuery's DSL-ish syntax, but they recognize the importance of using a robust JavaScript framework.
Personally, I love jQuery, but I know people who use other frameworks and are no less productive.

How should I create a web interface for my application? [closed]

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 8 years ago.
Improve this question
First, a little background: I have written a little application in python with SQLAlchemy, which is roughly an improved RSS reader: it selects links that should interest the user, and shows them to him. I already have a very simple command-line interface, and I envision a variety of interfaces: web, instant-messaging, desktop...
For now I'd like to create a simple web interface, but I have absolutely zero experience in the matter (appart from making a simple php forum 5 or 6 years ago...). So I'm comming here for advice on where to start:
Is there a good tutorial on HTML/CSS/Javascript focused on making a website look good simply? I know about w3schools, but it's a terrible tutorial IMHO, since it teaches you about HTML/CSS but doesn't show you how to use them.
Should I use a javascript library? Which one?
Should I use a web framework? I'm guessing either not or a very lightweight one, since I already have an application core with a database and SQLAlchemy, and I don't want to drop it.
Any other advice?
Thanks!

I recommend that you use some kind of web framework, it will make things a lot easier. Since you already know Python you should look into Django framework. It seems that you can use SQLAlchemy with Django, see djange-sqlalchemy project.
I recommend using JQuery framework/library for Javascript stuff. It greatly simplifies coding and takes care of most web browser incompabilities.
This CSS tutorial seems to give you the basics.
I would start by reading the Django tutorial and start trying things out. I wouldn't worry too much about HTML stuff, you should be able to pick up enough from Django tutorial. Make your site first functional with HTML, Django and SQLAlchemy. Only then start worring about Javascript. Who knows, maybe you do not need Javascript at all?
Do not try make your site work and look good at the same time. When you are making your site work, use simple and ugly HTML pages. When you are making you web site look good, work only with static HTML pages and CSS files. It is easier to combine the two in the end.

Just like everyone else here, I'll chime in with "Use my favorite framework, because it's what I use...."
I would start with small goals for a web interface. Get something simple up and running that to make sure you understand how things work.
Write an app that responds to the following url and returns something.
http://localhost:8000/my_links
Once you understand the little bit of machinery it takes to make that possible, what is handed to you as far as information about the request, and what you need to produce to return to the caller, it should be come clear how to fill in the blanks to get from your existing application to data thrown at the web browser.
Learn WSGI for no other reason than most of the libraries that will help you build a web application utilize this to some degree.
One of the links from the above page that I found extremely beneficial in understanding how all this works. was Ian Bickings article "A Do-it Yourself Framework"
Once you get a grasp of that stuff, you may find that dealing with WSGI at such a low level is maybe a little too cumbersome. That's when you'll probably want something like WebOb
which is just one of several ways people have come up with for abstracting away the low level details of the request/response cycle into some convenient objects. In a sense encompassing the HTTP protocol without trying to make it make sense to someone who doesn't want to know what HTTP is.
Depending on the complexity of your application you may decide that handling a request, looking at the path and dispatching off to one of many functions is a drag you'd rather not deal with. This is where everyone's favorite framework starts to be beneficial. And I would suspect that you would know enough by this point to better assess the frameworks that are out there and determine which fits your needs and goals.
Lots prefer django, maybe you will too. Others prefer Turbogears, and or Pylons, maybe bfg, maybe grok, maybe zope, maybe plone. But no one here knows what you want your application to do.

It's an interestingly common mistake: all of the above answers provide technological advise on what's the best technology to do ... what exactly? You should work the other way around.
I think that if you want your application to be successful, you have to make sure it enables its users to get the most out of it in the most natural way to them.
Therefore, i suggest you first "storyline" how things should happen from a user's perspective. Use paper and pen, or more sophisticated wireframing tools such as balsamiq mockups.
So, first lay out what the experience should be, and this will tell you which technology will be the best choice to enable that experience.
Oh, and don't forget to read this.

HTML, CSS and JS Book: DHTML and CSS for the World Wide Web
Javascript Library: JQuery
Web Framework: Not sure, DJango?
Other Advice: Learn to write HTML, CSS, and JS in a a simple text editor with syntax highlighting. Complex IDE's are cool, but for this stuff, they will make you learn slower.

Web applications are not simple.
HTML and CSS: Head First HTML is probably a good starting point. The Head First series are usually excellent tutorials. As Josh said, write your pages by hand.
Javascript: you don't need this to get started. Maybe in a later version. When you have a better idea what you'll need Javascript for, you'll be better equipped to pick a library that suits your needs.
Web framework: You should probably start with Django. That's the opposite of a "very lightweight" framework, but in this context "lightweight" requires more expertise to make something polished. So it's a good idea to aim for "feature rich and well supported" instead.

Here is another option, I feel it's worth mentioning before making any decision.
As web framework I would advise web2py, it is very easy to setup and yet powerful. Here is a document showing the differences between Django, web2py and some others. It is somewhat old but will give you a good overview.
Since you have legacy code, if you really want to keep it there is a fair compatibility between the two although you should double-check. The easiest would be to adapt your code, of course, the differences aren't so big. But that's your call :-)
Regarding the Javascript library, probably jQuery.

The best introduction you could follow is the opera web standards curriculum. Some of the information will be too basic - but a full understanding of all the topics covered will give you a very good grounding.
http://www.opera.com/company/education/curriculum/
Alternatively team up with someone who specialises in front-end development.

What are the arguments against using a JavaScript Framework for a Web site development company? [closed]

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.

Why would I want to use jQuery? [closed]

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 2 years ago.
Improve this question
(I understand that someone else asked a similar question and it was closed as 'argumentative', but I'm really interested in understanding the arguments around this.)
I know JavaScript really well. I've been writing it professionally for years. I've internalized a lot of the cross-browser incompatibilities and sketchiness, know DOM manipulation like the back of my hand, have worked with some of the best web developers in the industry & picked up a lot of their mojo.
I've been checking out jQuery. I understand the point of a javascript library (how many times have I written animation, getElementsByClass, and hide/show functions?). But to be honest, it seems like a waste of time to learn an entirely new syntax that isn't less complex. It seems like I'd be bashing my head against a wall to learn an entirely new interface to the same old JavaScript.
I'm not technically an engineer, so maybe I'm missing something. Could someone spell out the tradeoffs of jQuery? Is it really faster to learn and understand jQuery syntax than to just learn JavaScript?

There are a few big benefits to using a framework over homegrown/handwritten code:
Abstractions. I'm sure you're very proud of the fact that you've slung enough JS to be able to write animations from scratch. You should be! However, abstracting common functionality away from yourself is actually very liberating. You just call the method and know the innards will be executed, and executed well. Even if you're very fast at writing the low-level stuff yourself, that's still time you've spent on that instead of solving today's problems.
Common language. Using a common framework is like speaking a common language. You can collaborate with other developers very easily, and each can pick up where others left off without friction. (Compared to stepping into an application which uses a homegrown library for the things jQuery can do.)
Experts. The people working on jQuery are JavaScript gods. I am really, really good at JavaScript, and you probably are too, but there's a big difference between normal good and jQuery good. A team of insanely good people are constantly poring over a small set of common functionality - tuning it, tweaking it, enhancing it to make it the best it can possibly be. That represents a huge number of man-hours a single person like you or me simply cannot reproduce, no matter how good we are. And if you are as good as the jQuery guys, you can only benefit by combining your talent with theirs and contributing to the jQuery codebase. It's a melting pot of insane talent.

I'm not technically an engineer, so maybe I'm missing something. Could someone spell out the tradeoffs of jQuery? Is it really faster to learn and understand jQuery syntax than to just learn JavaScript?
jQuery is more than "just another interface" to Javascript. It allows you to express yourself in ways that are more compact and succincter than the corresponding Javascript implementation. At the same time, it's clearer and much more powerful. Specifically, the benefits you get include:
Expressiveness. jQuery is essentially a DSL for DOM manipulation and querying. This specificity is a major source of its utility and effectiveness.
Cross-browser. To a very large extent, jQuery is "write once, run anywhere". Even in 2009, this is still a surprisingly rare feat for web-based platforms. It's gratifying and relieving to know that you won't have to waste time debugging obscure problems on IE6 (well, most of the time).
Highly complete documentation. As a developer, I prize APIs and frameworks that have taken the time to spell out what all the moving pieces are supposed to be doing. Nothing is more encouraging than knowing that (1) things are stable enough that writing documentation isn't an attempt to hit a moving target and (2) things are useful enough that they've attracted enough people to flesh out the documentation fully.
In sum, the difference between Javascript and jQuery is analogous to the difference between assembly and higher-order programming languages. Although they're both technically both "an interface to machine language" and can both do similar things, the latter is considered far more powerful because of how easy it is to represent things and develop rapidly.

One thing I don't see mentioned is that the library is written to work cross browser on a wide range of popular browsers and platforms: IE6+, Firefox 2+, Safari 3+
That alone is reason enough to use jQuery then to write your own JavaScript and have to worry about cross browser issues yourself.

You can't learn jQuery without learning JavaScript, and you can't be a jQuery guru without being a JavaScript guru.
That said, it really is much faster to do things with jQuery than with "bare metal" JavaScript. Moreover, the way one works with jQuery is at a far more abstract level than the way one works with "bare metal" JavaScript. In addition, the jQuery syntax is very basic and not at all hard to learn, although the way you think about jQuery is very different from the way you think about "bare metal" JavaScript but enables you do to much more, much more rapidly.

community support
other developers writting and testing code, make it possible for you to do things you simply do not have time to do. Its not about doing anything you do not know how to do, its about doing things quickly, efficiently, and of very high quality (its already been tested).

From the sounds of it, you know much of the same stuff that jQuery knows about the DOM, and I can only assume you've built-up a nice DOM toolset for yourself over the years that incorporates all of this knowledge. In short, No, you don't need to use jQuery. However, some of the rest of us do not know as much about the DOM, and jQuery levels the playing field so we can get on with getting work done for our clients.
That is not to say you should not learn jQuery (as opposed to using it). You may pickup a few things you didn't know. The 3 main features that distinguish it from other DOM libraries (including your own probably) are:
built-in support for CSS selector syntax, useful for finding elements
methods that operate on the set of wrapped elements
chaining. Every method in jQuery.prototype (with "setter" behaviour) returns this
Personally, 1) and 3) don't hold a high premium. But 2) turns out to be huge for me. I never realized until jQuery how much my code tended towards operating on a set of nodes rather than a single node (if someone would have asked me I would have guessed the opposite tendency). 2) virtually eliminated all for loops from my code (or .forEach or however else I tended to abstract it), which was actually quite liberating. Now I notice it's the rare occasion where my code must operate on some single element.

Speed of development and turnaround of code.

One thing I haven't seen mentioned in the other answers is that, eventually, someone else is going to have to maintain your code. If it's all custom, they'll have a rougher time of it than if a more standard library is used. If that's not of any concern to you, and you don't think you're likely to need any of the really slick jQuery modules, then keep on with what you're doing.

For me, there are several benefits, like speed of development, etc.
But at the end of the day, it boils down to one thing:
It removes a HUGE amount of the cross-browser BS that can eat up so much time and resources, so I don't have to deal with it

jQuery allows you to write shorter, cleaner code that's easy to understand. Many people use it, so there are many plugins that work along with it, minimizing bloat. The same may not be true of your own personal library.

If you know JavaScript really well you should also know that jQuery's syntax isn't different from JavaScript's syntax.
What you might be referring to is the chaining idiom (used everywhere in jQuery) which seems to make things look very different from other sort of code. Well there's a reason for that, it's because it bonds really well with how the DOM works.

If you truly know JavaScript, you'll be at running speed with jQuery in under a week's time. If you don't already know your way around JavaScript, adding a layer on top might do more harm than good. But that's just like anything else!
You're going to be writing better looking and easier to understand JavaScript at a faster pace and only once — not once per browser. Downside? You're going to tack on another ~50KB of JavaScript. That's what caching is for :)

Jquery is javaScript in the hand of the designer.
It is as easy as writing CSS styles on an element.
Also Jquery is the easiest to understand, write maintain, add plugins.

I was working on a gallery program for a client (which is now exhibiting inexplicable behavior in IE6 and 7 - surprise, surprise - but I found that when I switched from bare-metal Javascript to jQuery a lot of the work got much easier. To me, it makes available the CSS view of the DOM while writing Javascript - which makes traversal and manipulation much more intuitive. Also, the cross-browser compatibility and brevity is wonderful.

It doesn't really matter if jQuery is great or awful. It's the powerhouse JS library now, used on a huge number of pages, and future browsers will have to accommodate it or be seen as themselves buggy.
What I don't like about jQuery: I'm not that thrilled about how it ignores mobile phone browsers in its test suites. It gets pulled in on all kinds of pages on mobile phones, and yet it makes no effort to ensure it works well on them.

jQuery degrades gracefully and it's one of the fastest (not THE fastest anymore though):
http://mootools.net/slickspeed/
There are many other frameworks out there, and whichever you choose, you probably wouldn't go wrong, but having uses jQuery myself, I'd definitely recommend it.
:)