As you might be aware of by now, the term Ajax sprung onto the Web development scene in 2005. One could even make the case that the concepts behind Ajax have taken hold faster than any other paradigm shift in Web development since the inception of the Internet. The reasons for this explosion continue to be discussed; but whatever the outcome turns out to be, the fact is that Ajax has and continues to transform Web development in ways unimaginable previously.
Suddenly, it has become trendy and acceptable to hack the browser and make it do things that it was never intended to do. Interestingly enough, the vast majority of the concepts behind what we now call Ajax go back to as early as 1997, when Microsoft released a version of Internet Explorer with Dynamic HTML (DHTML) support. Because then, crafty developers had been pulling off some pretty interesting things in the browser; but ultimately it took a large-scale use of those techniques by Google in 2005 to demonstrate that such techniques were now ready for the mainstream.
Although the story behind the rise of Ajax involves a lot of interesting facets, for our purposes it's suffice to say that if you are not using Ajax in your applications yet, you most likely will be in the next year or two. The first wave of adoption has mainly been within public-facing portal applications or small-scale Web sites that have limited requirements. In particular, Ajax in the enterprise has been adopted more gradually. This gradual adoption has a lot to do with the extra burden Ajax can place on the development process and the fact that expertise in the subject is still in its growth stages. This is where ThinWire can save you a significant amount of time and effort. ThinWire was designed from the beginning to be as pragmatic as possible. We very much believe in the idea that a framework should stay out of your way and let you get your work done. Unfortunately, the state of Web development has been somewhat cumbersome for awhile now. For years, I've been amazed that with every subsequent Web development advancement we are essentially adding another layer stacked onto the prior layer. Although I understand the practicality of that patchwork approach, at some point you have to tear things down and refactor!
In many ways, we're drowning in layers of abstraction, many of which are just there to account for the 1 percent use case. This is especially true in the Java world. Have you tried to build a JavaServer Faces (JSF) application recently? Granted, frameworks such as Spring and Struts have simplified things greatly when compared to the monstrosity that is Java EE (J2EE), but even with those, I've often felt like there is simply too much work required to get a simple Web application done. And clearly I'm not the only developer who feels this way. Just look at the success of Ruby on Rails and scripting languages in general. It's like we're rediscovering the Keep It Simple (KIS) principle all over again. So, what does this all have to do with ThinWire. Well, when we started playing with Ajax concepts, we decided to build a framework that embodied Ajax at its very core. We didn't just create a layer that could be stacked onto existing Web development models. We had a pragmatic need to make it possible for developers of varying skill level to build incredibly interactive and dynamic Web user interfaces. Therefore, it was impractical to make it a prerequisite to understand HTML, CSS, JavaScript, DOM, DHTML, servlets, JSP, the JSF component model, and this little thing called EL (expression language), all before they could get started building high-quality Ajax applications. Obviously that's a slight exaggeration, but I think it gets the point across.
With ThinWire, we take away all that complexity. You focus on a single development environment that conceptually only exists on the server. The end result is still a full-blown Ajax application, but the framework does all the heavy lifting, letting you focus on creating great solutions for your users and not wasting your time fussing around with all the layers of complexity. Although it's not the Holy Grail by any means, we think the framework takes a giant leap in the right direction.
