From: abc on

Hello all,
I just happened to come across the "Burst Engine" by Alistair MacDonald
(@F1LT3R) for animating svg graphics in an html-5 canvas.

There is a demo and a nifty step-by-step video of how it was created
here: http://hacks.mozilla.org/2009/06/rendering-svg-canvas-burst/

It looked interesting enough to me, to want to download and give it a whirl.

The demo and the video are from mid-2009 though, the package available
for download at http://github.com/F1LT3R/burst or at http://bocoup.com/
is from early 2009, and it seems hard to find even a mention of the
"Burst Engine" that is any newer than those dates.

I am wondering what's up with that project. Has anything happened to it
over the last year or so? Is it dead? Has it been replaced or made
redundant or irrelevant by something newer and better? Forked and being
developed under some other name? Bought up by big bucks and vanished
into the corridors of corporate boredom never to be heard of again? Or
anything else?
From: "Michael Haufe ("TNO")" on
On Jul 4, 9:25 am, abc <a...(a)abc.net> wrote:
> Hello all,
> I just happened to come across the "Burst Engine" by Alistair MacDonald
> (@F1LT3R) for animating svg graphics in an html-5 canvas.
>
> There is a demo and a nifty step-by-step video of how it was created
> here:http://hacks.mozilla.org/2009/06/rendering-svg-canvas-burst/
>
> It looked interesting enough to me, to want to download and give it a whirl.
>
> The demo and the video are from mid-2009 though, the package available
> for download athttp://github.com/F1LT3R/burstor athttp://bocoup.com/
> is from early 2009, and it seems hard to find even a mention of the
> "Burst Engine" that is any newer than those dates.
>
> I am wondering what's up with that project. Has anything happened to it
> over the last year or so? Is it dead? Has it been replaced or made
> redundant or irrelevant by something newer and better? Forked and being
> developed under some other name? Bought up by big bucks and vanished
> into the corridors of corporate boredom never to be heard of again? Or
> anything else?

I believe Raphael is the popular thing at the moment in regards to
SVG. Canvas wise? I don't believe there is anything significant enough
to worth mentioning atm. Processing.js maybe if you like a Java style
of declarative animation.
From: Richard Cornford on
abc wrote:
> Hello all,
> I just happened to come across the "Burst Engine" by Alistair
> MacDonald (@F1LT3R) for animating svg graphics in an html-5
> canvas.
>
> There is a demo and a nifty step-by-step video of how it was
> created here:
> http://hacks.mozilla.org/2009/06/rendering-svg-canvas-burst/
>
> It looked interesting enough to me, to want to download and give
> it a whirl.
>
> The demo and the video are from mid-2009 though, the package
> available for download at http://github.com/F1LT3R/burst or
> at http://bocoup.com/ is from early 2009, and it seems hard to
> find even a mention of the "Burst Engine" that is any newer
> than those dates.
>
> I am wondering what's up with that project. Has anything happened
> to it over the last year or so? Is it dead? Has it been replaced
> or made redundant or irrelevant by something newer and better?
> Forked and being developed under some other name? Bought up by
> big bucks and vanished into the corridors of corporate boredom
> never to be heard of again? Or anything else?

There is a rather strange notion, seemingly beloved of web developers,
that browser scripts are no good unless they are constantly being
updated. Without getting into the specifics of this particular project
(because I don't care), beyond noting that it appears to have a finite
scope, isn't it at all conceivable that the reason that it has not been
updated in the last year and a bit is that it is finished; that it
already does what it was designed/documented to do?

Generally, code that does not need to be constantly updated is a good
thing as it reduces the associated maintenance work (that is,
modifications to the code that surrounds/employs it).

Richard.

From: Scott Sauyet on
Richard Cornford wrote:
> There is a rather strange notion, seemingly beloved of web developers,
> that browser scripts are no good unless they are constantly being
> updated. Without getting into the specifics of this particular project
> (because I don't care), beyond noting that it appears to have a finite
> scope, isn't it at all conceivable that the reason that it has not been
> updated in the last year and a bit is that it is finished; that it
> already does what it was designed/documented to do?

In my experience, software tools are very rarely complete. Almost
always, there is some reason to extend them, to simplify them, to fix
minor or major bugs, to make them compatible with additional systems.
Mature products certainly slow down and have longer release cycles,
but often the end of regular development indicates that the tool is no
longer being introduced into new systems. YMMV, of course, but I tend
to become suspicious of tools that haven't been updated in a year or
more. Often they've been abandoned, and I will have to find and fix
any bugs I encounter.

--
Scott
From: Richard Cornford on
On Jul 6, 2:16 am, Scott Sauyet wrote:
> Richard Cornford wrote:
>> There is a rather strange notion, seemingly beloved of web
>> developers, that browser scripts are no good unless they are
>> constantly being updated. Without getting into the specifics
>> of this particular project (because I don't care), beyond
>> noting that it appears to have a finite scope, isn't it at
>> all conceivable that the reason that it has not been updated
>> in the last year and a bit is that it is finished; that it
>> already does what it was designed/documented to do?
>
> In my experience, software tools are very rarely complete.

Is this a "software tool"? It sounded like a browser script, and it
also sounded like a browser script with a finite scope; to animate SVG
graphics in an HTML 5 Canvas.

> Almost always, there is some reason to extend them, to simplify
> them, to fix minor or major bugs,

But it wouldn't make sense to extend things in an arbitrary way, and
after sufficient time a script that does a finite job effectively will
stand a good change of being pretty much bug free and as simple as it
is needed to be.

> to make them compatible with additional systems.

The odds are that the only systems with which this needs to be
compatible are (ECMA)scriptable web browsers with HTML 5 Canvas
support. So long as that is based on feature detection instead of
object inference or US string browser sniffing (and the script follows
the pertinent standards/draft standards) new environments are unlikely
to be an issue unless/until someone issues (and someone else
implements) a new standard that is not back-compatible.

> Mature products certainly slow down and have longer release
> cycles, but often the end of regular development indicates
> that the tool is no longer being introduced into new systems.

But that does not have to be true for cross-browser scripts. I
regularly use script components that are more than half a decade old,
and the only modification any have seen over most of that time is to
have branches for Netscape 4 and IE 4 removed (as no longer worth the
download overhead).

> YMMV, of course, but I tend to become suspicious of tools
> that haven't been updated in a year or more.

Apparently. I tend to regard something that has been in use for half a
decade and not changed in that time as reliable.

> Often they've been abandoned, and I will have to find and fix
> any bugs I encounter.

People certainly do abandon projects, but it must be possible that
some people just finish them.

Richard.