Two year ago I used to laugh at Javascript, but the more I play with it these days, I find myself enjoying the experience. It cant be compared to Delphi on any level, but there are some features that just blows your mind. I find myself spending a lot of time in Besen, a javascript interpreter and bytecode compiler written in Delphi – just for the sheer fun of it.I like the way dynamic parameters (what we would call array of const) are implemented and that they remain hidden to the entrypoint. This allows you to do do a form of undercover overloading. Unless the method is aware of _the calling interface_ (not the other way around like we are used to) then it could support only a sub-set of the intended functionality. By patching the original function and chaining to it you basically can “emulate” overloading based on condition rather than explicit call. This opens up for some clever API designs.I love the ability to pick values based on conditions, but compacted into a single line without having to invoke a equating entity:[sourcecode language=”javascript”]someValue = (backwards ? (100-percent) : (percent-100)) + "%";[/sourcecode]Having said that there are some aspects of javascript that makes me ponder the collective wisdom of W3C. As a fail-safe i usually add an “if” section to thoughts like this, because otherwise mother nature will go out of her way to disprove me. I can only imagine the work of cleaning up after Netscape and Microsoft, trying to play ball with Opera while Webkit came sneaking in the back door.
Media mayhem
The factors are many, yet the organization of the latest HTML5 multimedia functions is neither fish nor foul. It’s not truly object(ive) in the C++/Delphi sort of way, nor is it linear like basic or old school pascal. It’s both, and none of them at the same time . which makes it difficult to set up generic rules that would apply everywhere in our object model. The only solution is to let go of what the W3C has marked as “legacy features”. Which is hard to do when they produce results so easily 🙂
Threading, security and overkill
Another feature that seems like overkill, is the javascript notion of threads (read: blue threads), referred to as web-workers in the W3C specs for HTML5 (actually better info on Apple’s docs for safari). Im not sure what i was expecting, but i was sort of hoping to use threads to crunch pixel data. You can do that, but you are unable to hook the reference since it runs in a different context.
- All communication between a worker and the DOM is through a message pipe
- The only datatype you can pass to and from is a blob
- All bindings are late-binding
- Worker code cannot reside in the main document
Thankfully I found a “loophole”, I’ll document it later – but it wont make it into OP4JS because it’s basically a hack. You can use TW3GlobalStorage (one of our classes) as a mirror cache for the data – and it’s actually faster than creating, populating and moving a blob into the thread context. Although it does require initialization ofcourse. But i suspect that loophole will be closed in the next release.
External references
- Besen – SourceForge project page
- Web workers – W3C documentation