Random DevTools Entry: #005
I’m feeling a mighty JavaScript kick lately.
What’s interesting is that the more C# evolves, the more it starts to resemble JavaScript. What with anonymous methods, type inference (it even uses var), and the LINQ syntax, my JavaScript juices are flowing.
There are a few things that I never wrapped up with my JavaScript development experience. I think the most glaring one is JavaScript inheritance. Some would argue that JavaScript inheritance is purely fluff (see second comment); it’s not needed and JavaScript is probably more powerful for not adhering to OOP principles.
I dunno…it seems like one of those things that would be useful for building certain structures and UI elements.
I’ve been aware of Douglas Crockford’s implementations for quite a while now. I came across it when I first picked up on JSON about a year and a half ago, but I never particularly liked it since it “looked weird”. So today, as I was looking around to see if any alternatives have risen due to the recently revived JavaScript development, I came across a posting on SitePoint. I rather like the simplicity of it all and it looks like it works, so I’ll have to keep that in mind if I need to use it.
As I’m also thinking about writing a major web based rich UI application in the next few months, I’ve also been looking at some of the JavaScript libraries, toolkits, and frameworks that are out there. I came across the Dojo Toolkit today and it looks fairly interesting. I especially like the bind() syntax. However, the toolkit does seem somewhat incomplete at the moment…I’ll have to take a look at it in more detail and see if it has the features I need. It’s currently lacking any demos, which makes it hard to evaluate without a deep dive.
This brings up another interesting issue that has annoyed me with the proliferation of all of these JavaScript and AJAX libraries: instead of pooling talent and building The Best Possible Solution, we have teams going off left and right building 15 different impelementations of the same thing with 15 different design principles and 15 different philosophies. Now this isn’t necessarily a bad thing, as there are times when you would prefer a lighter implementation to a heavier one, for example, but it would make a hell of a lot of sense to have at least a common convention in terms of naming, package layout, and what not. Ideally, what I’d like to see is some of these development tracks merge so that we may have more complete frameworks/libraries/toolkits. Have one mega package that comes in mega-lite flavor, you know?
With so many libraries/frameworks floating around, it makes it difficult to find the exact set that does what you need and if you do, you need to start worrying about whether they’ll play nice.
I’ll stop, because I’m just ranting now 🙂
