Writing Web-Browser Math and Physics Demos

[lpetrich]

Have any of you people tried writing math and physics demos that can be run in a web browser? The physics demos would have to be simulations, of course.

I myself have done so:

http://homepage.mac.com/lpetrich/Chatters/GeometryDemo_GMap.html - Spherical Delaunay triangulation, convex hull, Voronoi diagram. Yes, all in JavaScript, which I'd ported from my original in Python.

http://homepage.mac.com/lpetrich/ColorBlindnessSim/ColorBlindnessSim.html - has a standalone Java version and a version that you can load webpages into: http://homepage.mac.com/lpetrich/ColorBlindnessSim/WebpageCBSim.xhtml . These work by calculating new color-channel values for each pixel as functions of the original ones.

A page on http://homepage.mac.com/lpetrich/Science/Symmetries/Index.xhtml - a http://homepage.mac.com/lpetrich/Science/Symmetries/TwoDimPointGroupDemo.xhtml and an http://homepage.mac.com/lpetrich/Science/Symmetries/OrganismSymmetryDemo.xhtml .

My experiences:

One can do a surprising amount with JavaScript in a web browser these days. Its main downside, however, is that it's difficult to debug. alert() isn't a very good way to do logging, not nearly as good as writing to standard output or to a file.

One can do graphics in three ways:

• HTML5 Canvas. Raster graphics; one commands a canvas object to paint various sorts of graphics objects.
• WebGL. OpenGL in a web browser for 3D graphics, as an extension of Canvas.
• Scalable Vector Graphics: SVG. One can do inline SVG objects in a webpage, and then control them the way that one controls other webpage objects. In effect, a controllable scene graph in a webpage. In Firefox, one can even do SVG filtering on non-SVG objects, like in my color-blindness simulator for webpages.

The main downside is spotty browser support. I have the latest OSX versions of Firefox, Safari, Google Chrome, and Opera, and all of them support Canvas, and all but Opera support WebGL and inline SVG. However for Safari, WebGL must be enabled, though doing so is rather simple. I have no recent experience with a recent version of Microsoft Internet Explorer.

Windows, Linux, and various smartphone and tablet versions of these browsers likely have similar levels of support.

Control widgets?

HTML is rather limited in them, having only buttons, checkboxes, radio buttons, popup menus, lists, and text fields. However, there are various libraries available for creating additional widgets, like sliders and color pickers. On the plus side, you can attach functions to various actions, like mouse clicks, mouse drags, mousing over, and changing text.

Resource use?

For memory, web-browser JavaScript has no maximum. It can eat up all the available RAM and swap space, though it is not very good-mannered to do so. It can also hog the CPU, though that will make the browser seem to hang. But HTML5 has "Web Workers", a way of creating threads for compute-intensive tasks. I've never used it, however.

Inlined applets?

Mostly Java and Flash. I have experience with programming for Java, though not for Flash. I'm a bit averse to that for Java, because it can take a long time to load the Java runtime. However, it likely outperforms JavaScript.

 

[chiro]

I've written a fair bit of simulation code in the past but it wasn't web-based.

If you can write something with OpenGL that most browser support, then I would go for that.

Also if you don't get much in terms of debugging what you could do is what was done in the 'old' debugging way: basically at critical points write the outputs to a text file or some other output stream and then when stuff crashes, read the textfile and see what is going on. It's not perfect, but it's pretty useful. You've already mentioned the logging issue though so you probably have been doing programming for a while now. You just got to work with what you got to work with, or create it if it doesn't exist.

I'd be suprised if OpenGL support was not available for JavaScript at the very minimum. Is it available to your knowledge?

The only other alternative is that you would have to use either something like Flash or use the standard framebuffer you get in a Javascript app and write your own rendering routines, but I would advise to look for OpenGL support in web apps before you do this: I am almost certain this would exist: I just can't imagine this not existing particularly with all the content out there and the fact that we have hardware accelerated graphics cards for more than a decade.

 

[lpetrich]

If you can write something with OpenGL that most browser support, then I would go for that.

Here's some stuff on WebGL, OpenGL in a web browser:
https://developer.mozilla.org/en/WebGL
Chrome Experiments - WebGL Experiments
WebGL examples

To enable in Safari:
(menubar) > Safari > Preferences > Advanced > switch on "Show Develop menu in menu bar" at the bottom
then
(menubar) > Develop > switch on "Enable WebGL"

Also if you don't get much in terms of debugging what you could do is what was done in the 'old' debugging way: basically at critical points write the outputs to a text file or some other output stream and then when stuff crashes, read the textfile and see what is going on. It's not perfect, but it's pretty useful.

Except that I can't do that in a webpage. The closest I can come is to create a text box and then stuff text into it, or some container like div or span and then add text to its "innerHTML" attribute.

 

[chiro]

Except that I can't do that in a webpage. The closest I can come is to create a text box and then stuff text into it, or some container like div or span and then add text to its "innerHTML" attribute.

Is there anyway you can store it? What about a cookie? If not a cookie is there another object that is 'like' a cookie where you can put the info? I haven't done hardly any web dev but I do know that cookies are used for this purpose.

A quick google search gave me this:

http://www.nairaland.com/215381/how-store-data-javascript-javascript

 

[georgir]

For debugging - how come you are not using Firefox with the Firebug addon? And even if you are not, the 'console' object pioneered by it, or at least the console.log method, is nowadays supported natively in pretty much all browsers. In some you'd need to first open the console before it becomes defined, make a wrapper function that checks for it before using it to be safe.
And for the more wonky cases you can always include firebug-lite