We Keep Coding

Accessing GPU via web browser

I came across this proof of concept earlier today (on TechCrunch.com) and was blown away and intrigued as to how they had managed to accomplish the end result. They state that they don't use webGL or any plugins yet they are able to interact directly with the GPU and render 3D visuals at up to 60 fps using nothing but Javascript. Any ideas how this could be done, or how to access the GPU from Javascript in general without the use of plugins?
Site Address is: famo.us
ps: Try using your arrow keys to shift orientation its far out!!

They're using standard HTML5 Javascript APIs to achieve this.
I saw several references to requestAnimationFrame in their code. This method allows one that uses a compatible browser, to display more fluid and optimized animations, with far better frame rates than setInterval based animations will ever allow you to have. This is certainly achieved by using the GPU and the available hardware background.
GPU or every other hardware component cannot be accessed directly using any Javascript routines. Instead, the browser, based on the called JS directives and the execution context, will use the GPU if possible to optimize some specific treatments, calculus and renderings.
EDIT
For future references, I recently found out (7 years after the original answer) that a new initiative - the W3C GPU for the Web Community Group, has recently been created in 2020 to do just that. It describes itself as follow.
The mission of the GPU on the Web Community Group is to provide an interface between the Web Platform and modern 3D graphics
and computation capabilities present in native system platforms. The
goal is to design a new Web API that exposes these modern technologies
in a performant, powerful and safe manner. It should work with
existing platform APIs such as Direct3D 12 from Microsoft, Metal from
Apple, and Vulkan from the Khronos Group. This API will also expose
the generic computational facilities available in today's GPUs to the
Web, and investigate shader languages to produce a cross-platform
solution.
In the long-term, this initiative might allow developers to directly interact with the GPU from all web browsers. You can track the implementation status of the WebGPU API Spec on Github here.

Concerning famo.us: they did analysed the bottlenecks of the Webkit rendering pipe and then found a way to bypass them while building the pages. Basically: the DOM tree construction, the Render tree construction, the Layout of Render Tree are bypassed. Take a look on this article for a whole explanation.

They're using CSS 3D transforms. Web browsers are increasingly using hardware acceleration to do these kinds of CSS3 things.

i think the webGL glsl.js library might be good for this, though i havnt seen benchmarks...
https://github.com/gre/glsl.js/
also this approach seems viable;
basically to use the gpu in the way we like to, hardware optimised functions (have a little look into "blas") are used, you do not want to write these! strangely it seems that people still use the old fortran blas.... there is some stuff with compiling via llvm and then using emscripten to turn it into javascript.
Use Emscripten with Fortran: LAPACK binding
the emscripten way seems the most versatile, im just about to check it out, but it looks like a mountain, also this topic seems to be somewhat of a call to arms, emscripten only works with fortran if you hack it (see links from the second link). i think what we are looking for is blas support in javascript, this is not a closed issue by any means, and for a few of us out here it is very frustrating! hopefully someone has a link to these blas libraries we cant find...
please let me know if i dont quite have my head round this issue, js is new to me.
also, suggesting html5 is sufficiently "optimised" to use the hardware, how can we trust this!? we need gpu optimised blas (basic linear algebra subprograms) e.g. dot product.
i think maybe also that these old fortran blas arnt actually the right thing for a modern gpu? node-cuda seems very likely the best thing i have found...

HTML equivalent for Flex

I am faced with a unique problem and probably need some external help and advice.
In my current company, I am set to develop a product that in broad terms is something similar to say Photoshop or Flash ( much much simpler than that.. But that should give us an idea! ).
Now I can develop both in JS/ HTML and AS3 / Flex.
Given the current scenario which would be the best environment to develop this app? By the way this app will be deployed only internally currently and will not be opened to our clients until say for another year. Even if we do the number of people who will use this app wont exceed 100 (That's over estimating under the current situation, but still..).
I am quite comfortable working with flex and to me Flex seems like a good way to approach this. But the popular vote has been to produce this with HTML 5, since apparently "Flash is dead" or dying.
Now.. If I am going to be using HTML in this scenario, which framework do I use so that I dont have to build all the UI elements again?
Any help or advice in this regard would be greatly appreciated.

I've been developing Flex applications for several years now while also experimenting with HTML5 since its inception. The correct answer to your question is a complex one and really it depends on YOUR comfort level on which route to take. That being said, here's my take...
"Flash is dead" is the biggest lie in the industry. Flash is a multi-billion dollar industry with tremendous momentum. There's a reason why game companies like Zynga choose Flash- it's got the horse-power and language features to drive an immersive experience.
HOWEVER, a better saying is "flex is dead". In my book, there's no reasons today to choose Flex over HTML5 for interactive applications. Flex is vastly slower in performance versus HTML5 (I don't have benchmarks but I know how Flex works under-the-hood). Google can index information in your application way better if it's HTML5. I would also argue that HTML5/js has way more open-source components available to use than Flex. This being said, choosing Flex to develop your application won't mean project failure... it's just not as good on paper than the alternative.
For working in HTML5, I would HIGHLY suggest leaning CoffeeScript (coffeescript.org). Javascript is a horribly broken language that have been further mutilated by a standards committee that can't make up their minds. CoffeeScript eases this pain by providing an "idealist" perspective on where Javascript should have evolved to. The language simple converts your app into a compressed library of javascript for use on the web.
Hope this helps!

The "Flash is dying" debate has been around for quite some years now, but it's still around and kicking:)
Back on topic. In my opinion, for medium to large scale applications, especially internal ones, Flex is a good choice, due to its capabilities. However, you should be willing to accept some trade-offs regarding cross-platform performance. HTML5 is great if you're looking for cross-platform compliance, also it's easier to implement.
Basically it comes down to choosing power (Flex offers a wide range of ready-made components and controls) over convenience (HTML).
Have a great day.

Fear not, use Flex you should.
It's an application for internal use, not the internet. In that case why would you care about it's "indexability", been more cross-platform?
I work within a bank, yes the $$$ kind, and there every computer has at least flash 9, all I have to care about is compiling my flex apps to flash 9.0.0.
It seams that you are more comfortable with Flex, use it.

I have finally decided to go with GWT since it is the next closest thing I can find.
I am currently evaluating GWT and Dojo and seemingly it provides me with a good IDE support ( since its java ) and apparently it supports all the new HTML 5 stack. More importantly it can work with other javascript frameworks where necessary ( like jquery? ). Apart from all this it is going to do some really cool code optimization and compression that will supposedly improve performance over direct hand written code.

Should I be learning Flash/Flex/ActionScript or HTML/CSS/JS ("HTML5")? [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 12 years ago.
I'm fairly new to this whole web-development thing (2 weeks maybe, my 1st scraping of code exists here, I quite like it) and I ended up learning to use Adobe's Flash Builder 4, which I have come to quite like (although Action Script annoys me at times).
Recently however I've been reading a lot about "the future" of web development, RIAs, web 2.0 etc, and it appears the whole Flash/Flex/ActionScript frame work's main competition will be the HTML/CSS/JS stack (or "HTML 5").
So obviously I don't want to take the time to learn a language (Flash/Flex/AS3) that will end up dead in a couple of years and end up having to learn another one (HTML/CSS/JS), when I could just move over now.
My main interests are fairly information rich (database orientated) web sites, with high levels of user interactivity for customisation, uploading, etc. I like the whole mobile web aspect, and would like to have the capacity to also develop for that platform, as well as mobile apps etc. I love the whole "live" aspect (like the tour de flex light up map that shows user activity), not particularly bothered by uber complex animation and obviously want things to be responsive and user friendly.
So yea, any input on this would be much appreciated, I'd just like some advice for overall direction for my personal learning and development.
Thanks!!

You're making some basic mistakes in the question. The HTML/CSS/JS combination is different from HTML 5, That combination works just fine with current implementations (ignoring some of the annoyances of IE for the moment.) HTML 5 is a new extended definition of HTML with a number of new features like local storage.
HTML 5 is also not completely settled, nor completely supported.
You should learn HTML and CSS to start with; in general, you still need a web page in which to embed your Flash stuff. You should get some basic knowledge of Javascript for much the same reason.
Conveniently, the Javascript will carry over to Actionscript, which is a variant of the same ECMAscript standard.

Flash isn't going anywhere for a long time, and given the glacial pace that the HTML5 committee is working at, the HTML 5 spec won't be fully standardised for a while yet either.
Plus before all these lovely HTML5 web apps can become commonplace, the world's windows users will need to have a better browser than internet explorer 8. Given that 10-20% of web users are still stuck on IE6, i don't think we'll be seeing html5 becoming dominant for quite a few years. Of course then by that time we'll be seeing HTML6 and the slow painful process of getting the world to upgrade will start again.
Personally i don't do flash, because for what i do i really don't need it, but flash is a really useful tool outside of web development too. Lot's of triple A Games have flash built menu's and user interfaces for instance.
But really, become good at either/both technology, and you'll probably not be short of work

Learning a language like Actionscript can never be a waste of time , the mindset you will develop from it will enable you to understand the concepts of programming and it'll be easier for you to move to other languages if/when you so desire. Learning HTML & CSS is essential if you plan to develop for the web but it will not bring you the same type of knowledge, as it uses a very different logic. If you like the idea of developing web applications, one day you may want to develop desktop applications, HTML won't be of much use then, whilst the programming knowledge acquired with AS3 will not be lost.

Is this just for the fun of learning, or do you have any specific tasks to accomplish? I like to use the correct tool for the job. If you don't have a specific job to accomplish, or any constraints to work under, I would just pick the most marketable skill and go with that. Unfortunately, I'm not exactly sure which is the most marketable skill.
My recommendation would be to check out some JSON type stuff in JavaScript. That seems to be a pretty stable (might I even say fad-resistant) AJAX evolution which is pretty wide spread and likely to stick around for a while. If you focus on the high level theoretical concepts, the specific comings and goings of implementations won't be as important (in my opinion).
I think learning AJAX (using JSON rather than XML) is a good way to go so you learn about implementing asynchronous information rich sites. If you have to redraw the site entire site when you pull information, you're doing something wrong. The AJAX concepts will come in handy regardless of your platform.
Good luck!
-Brian J. Stinar-

Don't bother with flash.
Yes, it's pretty and powerful and fairly ubiquitous. It's also on its way out the door, as you observed in your question.
Let's compare Flash and its newly-arrived competitor, the HTML5 canvas element.
Flash is only supported by Adobe; if you want quality development tools or resources you'll have to buy from them (for the most part).
HTML5 canvas doesn't need proprietary development tools. HTML5 canvas is supported by every major browser vendor -- Mozilla, Apple, Google, Microsoft. All vendors will provide documentation and competition for each other, which should result in a more refined product.
When OpenGL support (direct gfx card access) was in discussion for HTML5 Canvas, guess who was the only holdout? Adobe, of course. Everyone else wanted hardware graphics support for canvas.
In other words it's Adobe against everyone else here, and Adobe's not going to win. They might keep the status quo for a while, but eventually they'll lose their foothold and canvas & co will take over.
tl;dr: No use learning the dying proprietary technology when you can learn the modern open technology that's going to replace it.

HTML5 is still very unstable, so you shouldn't try it.
For me, HTML5 is great, but some business haven't moved off of IE6, given its current state. Flash, while useful, can be very very tedious at times and other times it doesn't even work on some computers or makes some computers truly a pain in the "insert word here".
It's better to start with CSS and HTML4. Get the basics, then start going for more.
By then, you'll know what to want.

Personally I think all the answers here are overcomplicating things. Here's my take:
Use whichever technology excites you, and is best for what you want to build right now.
If the app you want to build right now feels perfect for Flex, use Flex. If something about HTML5 has caught your fancy and won't let go, dive into it. You can always change technologies in a year or three, and You'll be taking everything you've learned about design and architecture and usability with you - learning a new scripting language and some new tools won't be that bad. The only way you can make the "wrong" choice here is if you, for whatever reason, pick a technology that you wind up not enjoying enough to get anything built.
The reason I feel this is the best way is, nobody here can tell you anything useful about what technologies will or won't be around in a few years' time. Adobe could go bankrupt; Steve Jobs could die; Google could get broken up in an antitrust suit. Hell, Flash could be on the iPhone next year for all we know - or HTML6 could adopt a new, strongly-typed JITable programming language. Or a hundred other things could happen to render your (and our) predictions moot.
I mean, personally I expect that both Flash and HTML5/6/7 will be vibrant and flourishing in five or ten years - because they both have successful organizations behind them investing in their futures, and because I've never heard a whit of a meaningful argument why the success of one should require the failure of the other. But that's just a guess, and my guess is no better than yours. Focus on getting good stuff made now, and the technology road map of the future will come when it comes.

In my opinion – everything is worth learning, especially when it comes to HTML/CSS/JS/Flash, which are each completely different systems/skill pools tailored to entry-level developers.
HTML is tagged markup, and very important because it outlines XML usage. CSS is writing visual formatting rules. JavaScript is a scripted language, and a great way to get your feet wet with simple programming logic. And Flash is a great system in which to get into object-oriented programming within a compiled language.
As you keep venturing out, you'll find that a lot of technologies are really just different flavors of the same ice cream. While different languages have their own nuances, there are fundamental similarities between –say– most compiled languages. I came from Flash and got into iPhone development... while Objective-C is a way bigger and uglier system to dive into, I still generally knew my ass from my elbow while building my first app after several years experience with AS3. The same goes for .NET and Java. Also, I would second the notion that Flash is not dead, despite loosing traction in the wake of the iPocalypse. Whether it dies in a few years or not, it doesn't make AS3 any the less valuable to have learned in addition to HTML/CSS/JavaScript.

JavaScript/CSS vs. Silverlight vs. Flex

We currently have a quite complex business application that contains a huge lot of JavaScript code for making the user interface & interaction feel as close to working with a traditional desktop application as possible (since that's what our users want). Over the years, this Javascript code has grown and grown, making it hard to manage & maintain and making it ever more likely that adding new functionallity will break some existing one. Needless to say, lots of this code also isn't state of the art anymore.
Thus, we have some ongoing discussion whether the client-side part of the application should be written anew in either Flex or Silverlight, or written anew with some state of the art JavaScript framework like jQuery, or whether we should simply carry on with what we have and gradually try to replace the worst bits of the existing code. What makes this even harder to decide is that writing the UI anew will probable cost us 6-12 person months.
I'd like to hear your thoughts on that issue (maybe some of you have already had to make a similar decission).
EDIT: To answer some of the questions that came up with the answers: The back-end code is written in C#, the target audience are (usually) non-technical users from the companies we sell the software to (not the general public, but not strictly internal users either), the software 'only' has to run in desktop browsers but not necessarily on mobile devices, and the client app is a full-blown UI.

In all honesty, I would refactor the old JavaScript code and not rewrite the application. Since you are asking about which platform to put it in, I would guess that your team isn't an expert in any of them (not slamming the team, it's just a simple fact that you have to consider when making a decision). This will work against you as you'll have double duty rewriting and learning how to do things on the new platform.
By keeping it in JavaScript, you can slowly introduce a framework if you choose and do it iteratively (Replace on section of code, test it, release it, and fix any bugs). This will allow you to do it at a slower pace and get feedback along the way. That way too, if the project is canceled part way through, you aren't out all the work, because the updated code is being used by the end users. Remember the waterfall model, which is essentially what a full swap out of will be almost never works.
As much as I hate to admit this, as it is always the most fun for developers, shifting platforms, and replacing an entire system at once rarely works. There are countless examples of this, Netscape for one. Here is the post from Spolsky on it. (I would also recommend the book Dreaming in Code. It is an excellent example of a software project that failed and how and why). Remember to rewrite a system from scratch you are essentially going to have to go through every line of code and figure what it does and why. At first you think you can skip it, but eventually it comes down to this. Like you said, your code is old, and that means there are most likely hacks in it to get something done. Some of these you can ignore, and others will be, "I didn't know the system needed it to do that."

These things spring to mind:
As you have a .Net backend and you have some ability to force your customers onto a specific platform, Silverlight is an option;
Since your client is a full-blown UI you want widgets and possibly other features like Drag and Drop;
I haven't seen any requirements that to me would justify starting over (which often doesn't work out) in Flex/Silverlight (eg streaming video, SVG support. Added to your team's familiarity with Javascript, I think you can't make a compelling case for doing it in anything other than Javascript.
But of course Javascript is lots of things and there are [lots of Javascript frameworks1. The most important divider is whether your intent is to "decorate" a set of Web pages or you need a full set of Widgets to create a desktop-like application on the Web. Your question indicate it is the latter.
As such--and I may get downvoted for saying this--I don't think jQuery is the answer and I say this as someone who loves jQuery. jQuery (imho) is great to enhance Webpages and abstract cross-browser low-level functionality but the most important factor for complex UI developer is this:
It's all about the widgets.
And yes I'm aware of jQuery UI but it's a lot sparser than the others when it comes to widgets. I suggest you take a look at the samples and widget galleries of some frameworks:
YUI Examples Gallery;
ExtJS demo; and
SmartClient feature explorer.
The others (jQuery, Dojo, Mootools, Prototype) are more "compact" frameworks arguably less suited to your purpose.
Also consider the license of each framework when making your decision.
My thoughts on the above three are:
ExtJS has somewhat angered the community in that it started out as LGPL but had a controversial license change (that thread is at 76 pages!) to GPL/commercial at version 2.1. The problem with that the community no longer has an active participation in the framework's development. Not the mainline version anyway. This means it's being developed and supported by a small team (possibly one person) rather than the community. IMHO it's not worth paying a commercial license for that and GPL is probably prohibitive in your situation;
YUI is supported by Yahoo and available under a far more permissive and far less invasive BSD license. It's mature, well-used and well worth serious consideration; and
SmartClient impresses me a lot. It has perhaps the most permissive license of all (LGPL), is roughly seven years old, has an incredibly impressive array of widgets available. Check out their feature explorer.
Your decision should be based on how you get as much of your application "for free" as possible. You don't want to spending valuable developer time doing things like:
Coding UI widgets like trees and accordions;
Testing and fixing cross-browser Javascript and CSS issues;
Creating homegrown frameworks that greatly duplicate what existing frameworks do and do well.
I would seriously look at one of the above three as your path forward.

This decision is usually less about the technology, and more about your skill sets and comfort zones.
If you have guys that eat and breathe Javascript, but know nothing about .net or Flash/Flex then there's nothing wrong with sticking with Javascript and leaning on a library like jQuery or Prototype.
If you have skills in either of the others then you might get a quicker result using Silverlight or Flex, as you get quite a lot of functionality "for free" with both of them.

My opinion on this one's pretty simple: unless the app needs to be accessible publicly, unless it needs to be search-engine optimized and findable, and/or there's an otherwise compelling case for its having to remain strictly text-based, then the chips are stacked in favor of rich-client runtimes like Flash or Silverlight right out of the gate.
A big reason, if not the biggest, is that they eliminate the complexities of developing for multiple browsers and platforms. Again: they eliminate the runtime-environment variable. No more debugging old versions of Netscape and IE, no more object detection and consequent branching, no more wacky CSS hacks -- one codebase, and you're done. Offloading the runtime environment to Adobe or Microsoft will save you time, money and headaches, all else equal. (Sure, there's YUI, JQuery, etc., but they don't eliminate that variable -- they just abstract it. And they don't abstract all of it, either -- only some of it; ultimately, it's still up to you to test, debug, retest, debug, repeat.)
Of course, your situation's a bit more complicated by the existing-codebase problem, and it's difficult to say definitively which way you should go, because only you've got the code, and we're just geeks with opinions. But assuming, just by your asking the question, that a refactoring of your existing codebase would involve a significant-enough undertaking as to warrant even considering an alternative (and probably comparatively foreign) technology in the first place, which it sounds like it would, then my response is that your curiosity is well-placed, and that you should give them both a serious look before making a decision.
For my part, I'm a longtime server-side guy, ASP.NET/C# for the past several years, and I've written many a text-based line-of-business app in my time, the last few with strong emphasis on delivering rich soverign UIs with JavaScript. I've also spent the last couple of years almost exclusively with Flex. I've got experience in both worlds. And I can tell you without hesitation that right now, it's everyone else's job to beat Flex: it's just an amazingly versatile and productive product, and for line-of-business apps, it remains leaps and bounds ahead of Silverlight. I just can't recommend it highly enough; the data-binding and event-handling features alone are incredible time-savers, to say nothing of the complete freedom you'll have over layout, animation, etc. The list goes on.
So, my advice: take a long, careful look at Flex. In the end, you might find a ground-up rewrite is just too massive an undertaking to justify, and that's fine -- only you can make that determination. (And to be fair, you've just as much ability to make a mess of a Flex project as you do with a JavaScript project -- I know. I've done it.) But all told, Flex is probably the least-limiting, most flexible, most feature-rich and productive option out there right now, so it's certainly worth considering. Good luck!

Any javascript you have that has been developed 'Over the years' probably doesn't look anything like what's possible today. You undoubtedly have a lot of useful code there. nonetheless. So my recommendation would be re-write in javascript using jQuery and make use of one of the available GUI add-ons, perhaps look at Yahoos stuff. You will also be targeting the widest audience this way.

The GUI technology should be first and foremost determined by your target audience. For instance, if you target englobes iPhone users, I would not recommend Flex, because iPhone doesn't have a flash player at the moment.
Bear in mind that if you switch to a full fledged GUI toolkit like Silverlight, your users may find the L&F unnatural, since the usual request-reply cycle is not so evident with client-side frameworks.
After that, it is your developers that should have a word to say. Every toolkit needs maintenance, and if you are switching to a whole new toolkit the developers will have to familiarize with the new toolkit, which can be costly.
My suggestion is that you stick to javascript, since your devs are familiar with it, and gradually replace the old javascript with a new toolkit like prototype, jQuery or any other. You will probably redo some of the old stuff faster using a state-of-the-art toolkit. Remember that you can build beautiful apps with any tookit.

We have developed an extremely rich application using EXTJS with C# and a some C++ on the server. Not only do we have clients who are happy with the interface in their desktop browsers but with very little tweaking to the Javascript we were able to provide web browser support. Also, we have clients in third-world countries who cannot use Flash or Silverlight apps due to their field personnel using kiosks in internet cafes (many of which don't have Flash installed - forget Silverlight!). I think these issues and others make up for the difficulty of coding a complex app in javascript...

Check this comparison table for Flex vs Javascript:

Best Technologies for AJAX Web Development

I have some experience in AJAX development, mostly on .NET and MooTools. However, I want to learn more and see what others out there thought about the various other options available. I am looking more for advice about the front end. The back end, I will most probably be coding it in .NET using c# and WCF services.
Please feel free to provide me as much information as you can. Also, I would appreciate any links to resources.
List of Options (feel free to add)
Write my own Javascript
Use a framework like MooTools, JQuery, etc. Which one is better?
Use Google Web Toolkit. Am I tying myself to the limitations of GWT? Or are there not limitations?
ASP.NET AJAX
WPF (Will this run on non-IE browsers?)
Flash (it'll be a pain to learn action script)
Thanks
Jaspreet

Writing your own Javascript often means reinventing the wheel when it comes to trying to attain cross-browser compatibility. Frameworks such as jQuery and MooTools take care of much of that grunt work for you.
Personally, I would suggest picking a Javascript framework or using GWT, but really it's just a matter of personal preference at that point, much like choosing a programming language. Pick that one that is best for your purposes, or that you're most familiar with.

I'd go with jQuery.
jQuery will be bundled with the next version of Visual Studio. Google uses jQuery. jQuery has the largest user-base of any of the frameworks out there.. And speaking of not re-inventing the wheel: jQuery also has the largest plugin-repository of any of the frameworks out there.. Including its own official UI library which is in constant development.
.. And if you're a fan of books; there's 3-4 books about the framework out currently.
Oh, yeah! Check out Douglas Crockford's website for great vanilla JavaScript tips and tricks.
Just my two cents :)

jQuery
prototype
MooTools
dojo
GWT
ExtJS
Those will all have you working with very solid code, which is usually the best way to improve your own skills. And don't forget all their extensions/plugins.

I would recommend jQuery. It's more extensible and light-weight than most other JavaScript libraries I've seen (and you can have it Google-cached with the AJAX APIs).
For Flash-based AJAX web apps, Flex is a better solution.

Since this is a fairly subjective question I will put in my 2 cents.
I've developed using the Dojo toolkit and found it very well rounded. However, if you don't do a custom build on your library it slows everything down. It has a steeper learning curve than other frameworks, but seems to sit pretty close to heart of Javascript.
But this isn't an advertisement for dojo. I'm working on a Ajax web app currently and my goal is to try and avoid using a framework. Why? A few reasons.
The biggest reason is complete control over the code. Not that I don't trust toolkits, I just like my custom code. I don't have any code that I don't use, and all of my abstractions are custom made for my purposes. At times I am in fact reinventing the wheel*, but its always a bit different because it's purpose built.
The other big reason is the amount of knowledge I gain. I'm confident that I could pick up any framework much faster, because of not using one for a project. I understand so much more than I did previously. Before It was more like a voodoo mystery box, and now even frameworks make more sense to me.
The fact of the matter is if you do any non-trivial javascript you will end up with a framework (or a mess). In reality it may not be the fastest way to write web apps, but it isn't all that hard with a little practice. You can be amazed at what creative things you can come up with that didn't exist before.
*Reinventing the wheel is a terrible analogy that we all use. We reinvent wheels all the time. First made of stone, then lighter wood, tires, etc... My truck doesn't have the same wheels as my sedan.

Like other responders I prefer to use frameworks, but my favorite is dojo -- clean and well-designed architecture, good books (my favorite being Matthew Russel's), and a particularly impressive approach to using browser extensions (such as Google Gears or Microsoft Silverlight) if the user has them installed, while falling back gracefully (e.g. to Ajax-interfaced server-side storage) if no suitable browser extensions (or sufficiently advanced browsers, with HTML5 support) are present.
Dojo is, currently, slightly less popular than jquery (e.g., [jquery ajax] has 8.4 million hits on Google Search, vs 4.3 million for [dojo ajax]), but that's still way popular enough to ensure it won't go away any time soon;-).

You must check ExtJS.
Most libraries I've seen have usable core but lack the widget/control library that will blend-in with each other. Sure you can get a vast number of controls for jQuery, but do you have the time to find out which ones have intended functionality and tweak their visual appearance to match the rest of controls? ExtJS gives you just that. Core is core. It works and it works great. But the vast selection of compatible and functionality rich controls is the main driver that will make your life easier.
I've used ExtJS with Asp.Net and WCF services and it was a really nice experience overall. You will need some time to get to know ExtJS component model to extend it even further (as you would need to do the same with other libs), but when you do, you start loving it even more.
One more thing: since MS ships jQuery with MVC it doesn't mean it's the best. It only means it's one of the best (and much better than Microsoft's in-house Ajax) but with the most relaxed open source license.
Edit: Now that Silverlight 3 has shipped it became apparent it will shake things a bit with its offline support and rich graphics support. As well as standalone desktop like web apps. Definitely something to consider...

Please note that WPF has nothing to do with ajax.
AJAX = Asynchronous javascript and xml
WPF = a windows-only UI display technology. The only option there for in-browser use is to create an Xbap. The more-suited-for-the-web counterpart is silverlight (say, like flash but from microsoft), so perhaps you should look into that as well... it's like using flash, but with familiar MS technologies.
Concerning your question about which framework to use in case of ajax: I prefer jQuery. It's short syntax and chaining allow you to reach your goals very fast in an intuitive way.
Also, GWT is a Java framework that also renders stuff on the client, as far as i know. So you would have the limitation of Java as backend language...

GWT has made considerable leaps and bounds over the past 7 months. The mutiple GWT widget libraries have received a good deal of attention, and Google's work on the library has been impressive. Going GWT limits you to:
Using GWT widgets
Possibly becoming a GWT widget developer
The benefits include:
Coding in Java
Debugging in Java
Skipping the parts of JavaScript that make you pull your hair out
GWT is the step past AJAX. It buries the HTML / JavaScript so that you don't need to deal with it, but also provides access in case you do want to deal with it.
Overall, you will spend less time trying to get small things working, and more time adding awesome to your application.

there is also prototype.js

Try the Yahoo! User Interface Library (YUI)

Pick a library to learn, then pick up the others--but I don't think I'd reinvent the wheel.
I picked MooTools and have picked up jQuery/Prototype since. (Picked Mootools because their site, at the time, was the only one that validated, figured clean html meant clean javascript).
Side note about MooTools:
An often overlooked feature of MooTools is the download builder. You can download just enough of the framework source to get your AJAX working, and nothing else.

There's the BBC's open source javascript library called Glow