It would be useful with a client side logging solution written entirely in javascript.  With Html5 comes a client side database.  Already today we have cookies that could be used.

Logging could be done  in a round robin fashion where old logs are dropped so one always keeps the latest x logs in the database/cookie.  One could also send thelog back to the server if needed.

That way we wouldn’t need alert calls.  Especially forgotten alert calls that goes into production.

As I have percieved (all) logging frameworks today work in a synchronous manner.  This means that logging comes with a performance impact.

One could create a logging client that sends its entries to a queue.  This queue is then fetched by another process.  The total processing power required is greater than a synchronous solution and issues might arise when time is a factor.  But for the other cases I believe this could be handy.
And one could build a switch into the framework that forces synchronous logging for the times it is necessary.

Then create a log viewer client with more intelligence than just listing text entries.  I plan to write about this, but don’t hold your breath.

—-

To start with I am thinking of a message queue.  Let the client write to the queue.  Then have another process read the queue, possibly from another machine.  Let the logging entries be identifiable by a guid.  Let the reading process be able to sort these guids to their respective category and present it in a readable way.

Get a spare monitor like a phone or usb and let a program continously show your log with a cool graph.  Add sound and a force feedback joystick and it will be more fun than a barrel load of monkeys.  All without drawing power from the production machine.