We Keep Coding

Server side javascript with WebGL?

I'm thinking about learning WebGL and the first thing that comes to mind is that JavaScript is client-side; what approach (if any) is used to have server-side JavaScript specifically related to WebGL?

I am new to WebGL as well, but I still feel that this is a very advanced question you are asking. I believe it is an advanced question because of the scope of answers that exist to do what you are asking and the current problems related to proprietary WebGL.
If you have done any research into WebGL you will immediately see the need for Server Side code due to the fact that the WEbGL API code is executed within the browser and thus freely available to any knowing individual. This is not a typical circumstance for game developers who are used to shipping their code compiled.
By making use of server side controls a developer can hide a large amount of WebGL translations, shaders, and matrices, and still maintain a level of information hiding on the client side code. However, the game will never work without an active internet connection.
Since WebGL is still relatively new, and IE does not support it, expect things to change. M$ may decide that they want to build their own web API like WebGL that ends up being an ASP.NET library. All of the required complexity that currently goes into building a solution to the problem you are facing gets condensed into a 3 button Wizard.
With that being said I think the answer to your question lies in the fate of some future technologies. For bigger goals there will more than likely be a large amount of back and forth communication; protocols like HTTP may not cut it. WebSockets or other similar technologies may be worth looking into. If you are attempting to use Canvas for something smaller just an understanding of building dynamic JavaScript may be enough.
The problem with these answers is that OpenGL is an API itself and has a specific order of operations that is not meant to be changed. This means that this approach to building a WebGL applications is very limited. Since changing GL objects may require a whole Canvas restart, a page refresh, or a new page request. This could result in effects not desirable. For now I would say aim low, but ones thing for sure WebGL is going to change the www as we web developers know it.

I'm not sure what you are looking for, probably not this... :)
but...
If you want a server side fallback for browsers not supporting WebGL, lets say for generating fixed frames as png images of some 3D scene, then you could write your 3D veiwer in C or C++, build it for OpenGL ES when targeting your server side fallback, and use Emscripten to target browsers supporting WebGL.

Porting an HTML5 Canvas WebGL game to Flash ActionScript 3.0

I had created an HTML5 Canvas WebGL game in January for the Mozilla Game On 2010 competition (pretty late, I know - I never released it until yesterday). Now I want to port it to Flash ActionScript 3.0 for a college assignment.
I'm well versed with both static languages like C/C++ and Java; and dynamic languages like Python and JavaScript. However I don't know ActionScript, but since it's a subset of ECMAScript it should be pretty easy to understand.
I want to learn programming in ActionScript 3.0 so that I may be able to port my game in Flash. To be more specific, I want to know more about:
How is ActionScript different from Browser and Server-Side JavaScript, and basics.
OpenGL programming in ActionScript (including loading textures, shaders, etc).
How to create a HUD in Flash using a 2D HTML5 Canvas like API (in my game I have 2 canvases, one for the 3D game and another overlaying it for the heads-up display).
Support for vector and matrix calculations in ActionScript.
How to load assets like audio and sprites in Flash.
I would appreciate it if you would provide me a link to a page from where I can learn more about these topics. A more direct hands-on approach would be preferable.
It would be even more helpful if you would check my source code in JavaScript and suggest the best possible way for me to tackle this problem.
The code for the main game engine and the game itself may be found in my Github repository.

ActionScript and JavaScript are very similar at their core. In some ways you can think of ActionScript as more like a robust library layered on top of ECMAScript. There are a few differences (namely ActionScript likes to think of itself as a class-based oop, where as JavaScript is prototype-based), but if you are comfortable with one, then you should be pretty at ease with the other.
ActionScript has a class based inheritance system and supports interfaces (but you can still do some prototypical magic if you want, but its not recommended). It also supports strongly-typed objects.
var object:MovieClip = new MovieClip();
This will strongly type the object variable as a instance of the MovieClip class.
If your game is very 3D intensive, then you'll want to look into the new Flash 11 Stage3D and Context3D classes. These expose a low level GPU accelerated API that before Flash 11 wasn't possible. You can do interesting 3D stuff with Flash 10, but you are usually using drawTriangles(), which was not hardware accelerated. Flash 11 is currently in beta, but it should be out very soon. There are beta versions of the Flex SDK that should let you compile targeting the Flash 11 player.
There are also quite a few 3D libraries that are built on-top of these low-level api. If you goggle around for them, they are easy to find. But I would recommend getting a solid understanding of how ActionScript works before diving into the 3D libraries.
The HUD stuff in flash is simple whether you go with Flash 11 or Flash 10. For "classic" flash, you'll want to get familiar with the display tree concept they use in flash. Just make sure the display order is correct, and your HUD DisplayObject will always be "on-top" of your rendering DisplayObject
For Flash 11, StageVideo and Stage3D objects sit directly above the stage, but behind all normal flash DisplayObjects that are attached to the stage. So in that case, I would let the Stage3D api take care of all of your heavy rendering lifting, and use the traditional display stack for your HUD elements.
You'll probably also want to grab yourself Flash Builder over Flash CS5.5. If you are a programmer (which I am assuming you are since you are posting here), it wont make your eyes bleed trying to code. FB is based off eclipse, and its pretty decent but not perfect. But if you grab yourself the free Flex SDK, and don't mind using the command line, you can get started compiling swfs pretty quick and cheap (aka free).
Also, look into FlashDevelop. I haven't used it in a while, since switching to FB for its built in profiler, but it might be of use to you.
Importing images and audio is pretty straight-forward with the Flex SDK.
[Embed(source="logo.gif")]
public var LogoBitmapData:Class;
and then later instantiate the class:
var bitmapData:BitmapData = (new LogoBitmapData()) as BitmapData;
And then use it where ever you want to.
Just a note about the Flex. Flex is a set of UI libraries built on top of the normal Flash API, the Flex SDK includes the libraries and tools to compile MXML and ActionScript code files. So, despite it sounding like you should use the Flex SDK to compile Flex apps, you can use it to compile straight ActionScript code as well.
There are built in classes for Vector3D and Matrix3D.
As far as tutorials or references, I don't have any to offer really. I've found that most of the information on the internet about ActionScript programming is pretty hit or miss (when you can find something thats not written by a graphic designer). I'd dig around in here and see if you can find anything that makes sense to you.
There is obviously a lot more I could go into about this stuff, but hopefully this will give you a push in the right direction.

Welcome to AS3 :)
#32bitkit beat me to the IDE info, but I'd absolutely recommend Flash Builder. It's a real tool and worth the money if you're going to be doing any real AS3 work.
As far as actual tutorials, Senocular is known for writing some of the best content out there. He has a number of great tutorials here, but the following two are especially excellent introductory tutorials for AS3:
AS3 Introduction in Flash CS3 This tutorial is good because it explains the differences between AS2 (very JavaScript-like) and AS3. Ignore the fact that it's based on using the Flash "IDE."
AS3 Introduction Without Learning Flex This one is useful because it give more of an introduction to the language itself, without all of the trappings of the IDE or the Flex framework. It will help you understand the language itself.
As shown in that second tutorial, an AS3-based project will inherit from the flash.display.Sprite class. You can view the docs for that here. Perhaps it sounds silly, but you'll honestly learn quite a lot about AS3 by just browsing the AS3 Reference docs. Adobe has done a good job with those.
Another thing to be aware of in AS3 is how events are handled. This tutorial explains how the EventDispatcher class functions as the base of the event management. You can use the built-in events or dispatch your own.
HTH!

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:

Processing language vs javascript?

I'm going to develop a comprehensive educational software which runs on the browser and has many visualization and simulation works (electrostatic and electromagnetic visualization, 2D and 3D).
Which language(Processing, javascript or something else) is the best toward my purpose?

The question is indeed broad but I will answer from the experience I've had.
Javascript is not really meant to do mathematical calculations, which is what might be necessary to calculate a lot of E&M phenomenon quickly (Especially if they are not represented as a closed form solution). It really goes into how much detail you want in your graphs as well (More steps = more calculations). You may find yourself needing to do more optimizations to make up for the performance difference.
I did some visualizations of antenna arrays (They had closed form solutions, only simple arrays) in Flash and it worked out ok. Javascript will definitely not be up to par with any 3D simulations you might want to do.
I wonder if Silverlight might be a better solution, because you may find more mathematics libraries for .NET than for Actionscript, that could save you a lot of work of writing the math out yourself (But you might end up doing this anyways because of the performance issues).

As others have suggested javascript is not that strong of a language when it comes to visualization.
Processing is a really good language for what you're trying to do, it's easy to learn and is Java based. Data visualization is built directly into the language, as well as temporal space (ie advance "1 tick" in time and have the visualization react to that.)
Also if you're interested in going that route I'd suggest picking up Visualizing Data which is pretty much a Processing primer.

Flash may be the more common application stack right now for what you are looking for, but Silverlight is looking primed to take the title from them based on the powerful features that it contains.

I would go Flex or Silverlight myself
Plenty of re-usable libraries
Native support for multimedia
Native support for graphics and animation

I'm a little late to the show, but what you want, has been implemented in JavaScript, and you'll find this incredibly useful. I recommend running it under Chrome as the JS processing engine is extremely fast. (You may even want to try Chrome 2 which is even faster)
http://ejohn.org/blog/processingjs/
http://ejohn.org/apps/processing.js/examples/basic/ (91 basic demos.)
http://ejohn.org/apps/processing.js/examples/topics/ (51 larger, topical, demos.)
http://ejohn.org/apps/processing.js/examples/custom/ (4 custom "in the wild" demos.)
See also: http://www.chromeexperiments.com/

I second LFSR Consulting's opinion: Processing is used a lot for educational purposes, it is free, and fast (Java is faster than Flash in general) and easy to learn, so you have faster results. It supports 3D, you can tackle Java libraries for simulation and computing, etc. And it has a great community! :-)
JavaScript is a bit light for such usage. JavaFX is hype, but it hasn't really 3D (although one used Java3D with it) and it is still a bit young.
Flash and Silverlight: no comment, not much experience in the field. OpenLazlo can be an alternative...

You really have two choices ActionScript in Flash or VB.NET/C#/other in Silverlight.
So first you need to decide which of these platforms you will target.

You may be able to split the problem into two parts, the user-interaction and display part, and the heavy calculations part.
If you can move the heavy calculations to a server then you can still show everything in javascript.
One difficulty with javascript is that it is interpreted and you will need to write more of the equations yourself, so there is a performance hit and development time, but it will work without any plugins, unless you don't want to do 3D in the canvas tag.
Flash and Silverlight may have better options, but then you are learning new languages and requiring plugins, depending on what version of Flash you want to use.

Check out processing.js, xcode, and iprocessing!
ProcessingJS is great for data visualization but lacks in interactivity.

You should probably try python. It is a really good language for educational and computational purposes it has a pretty decent community and the syntax is not so tough. Even though it was designed to for command line you can create front end gui's for it using some external package and it also provides packages like Scipy, Numpy and Matplotlib for advanced plotting and data visualization.

Which JavaScript graphics library has the best performance?

I'm doing some research for a JavaScript project where the performance of drawing simple primitives (i.e. lines) is by far the top priority.
The answers to this question provide a great list of JS graphics libraries. While I realize that the choice of browser has a greater impact than the library, I'd like to know whether there are any differences between them, before choosing one.
Has anyone done a performance comparison between any of these?

Updated answer (2019):
The core advice is still the same: for maximal performance use thin wrappers or use raw browser API's, and also avoid the DOM or any DOM-like structure. In 2019 this means avoiding SVG (and any library built on top of it) because it may cause performance issues when trying to rapidly change the DOM.
Canvas is the go-to solution for high performance web graphics, both for the 2d and 3d (webgl) contexts. Flash is dead so no longer an option, but even if it weren't its performance was eventually matched by the native browser API's.
Original answer (2009):
If you're not doing 3d, just use raw canvas with excanvas as an explorer fall-back. Your bottleneck will be javascript execution speed, not line rendering speed. Except for IE, which will bog down when the scene gets too complex because VML actually builds a dom.
If you're really worried about performance though, definitely go with flash and write the whole thing in actionscript. You'll get an order of magnitude better performance, and with the flex sdk you don't even need to buy anything. There are several decent libraries for 3d in flash/flex available.

Raphael JavaScript Library
http://raphaeljs.com

None of them have good performance. It is 2009 and the state of programmable graphics rendering in web browsers is truly depressing. I could do faster interactivity on a vt125 terminal 25 years ago. If you are doing anything interactive, think about using Flash... Else I'd go for some server-side heavy solution depending on your needs

Up to now - is used processing.js (javascript canvas implementation of "Processing" language) and/or raphael.js (tiny and handy VML/SVG javascript library).
The performance recomendations depends on task:
highly dynamic, complex primitives (or huge amount of it) - canvas (pixels, low-level API)
lower amount of primitives, highly scalable, integrated in DOM - SVG/VML (vector, high-level API)

I know you said browser had more influence, so why not stick with using optimized SVG calls? Then, it "could" work in all browsers but...
Chrome is robust enough to do render 3D modeling efficiently:
http://www.chromeexperiments.com/detail/monster/

How about http://www.jsgl.org? It uses SVG/VML.

For basic drawing (such as lines, circles, and polygons), I would recommend Walter Zorn's Graphics Library. It was built with performance in mind and works in a ton of browsers.