Update: I have new written a short article about JSXP2.
When Oliver Szymanski and I started to work on JSXP it was not the first web framework. Or the second. Or the … you get the point. In fact we had the idea when we driving home from a JSF conference. We were discussing Apache Wicket on the train. There were plenty of web frameworks for Java, and there were lots of other nice technologies for creating web pages (PHP, Ruby on Rails, ASP.net, …).
When I started to work on gclimbing.com I did not use JSXP. Well, I did use it, but I re-wrote a large part of it. The web framework that powers gclimbing.com (for now I just call it “jsxp2”) now has very little in common with the published version of JSXP. So, why would I re-invent the wheel? Twice?!?
We had the idea for this project on the train from Vienna to Linz. Oliver and I had just visited the “JSF Days”, a 2-day conference about Java Server Faces. On the train we were talking about how JSF was way too complicated. We wanted to be able to create simple solutions - at least for simple problems. We wanted to design with plain vanilla HTML+CSS and also define the navigation in the HTML files (or in Java code when the navigation rules require some processing) - No need to write additional XML here.
During this time I was learning to develop web applications with Apache Wicket. Although it is a quite cool web application framework (I was working on a Wicket-Webapp for a customer later) for me it was not the solution. On the train I talked about what bugged me most with wicket: That one has to duplicate - define components in HTML and Java code - a lot of things and that one has to get literal string idenifiers right in both files. If the identifiers are not identical the application will fail at runtime.
So, in Wicket one has to write a lot of code just so the Java code knows the components that were already defined in the HTML templates. And one has to write even more code (unit tests) just to make sure that all the “wicket:id”s are identical in the Java code and the HTML templates - otherwise design changes can have fatal consequences. This is unacceptable, so we have created the JSXP generator which ensures that all components that were defined in HTML are available in the Java code - with compile-time safe identifiers.
But the most important reason is: For the fun of it. Working with Oliver is great. He is one of the best hackers (there, I said it) I know. He gets things done and is a great person. But we could have worked on any project.
Working on JSXP was fun for another reason too: I learned a lot about a couple of things. I learned some things about DOM parsing (and SAX-parsing in jsxp2) that I didn’t know (althoug I had worked quite a lot with XML before). We used reflection in a couple of places and had to resolve performance issues. We had to deal with problems caused by sequences of views in multiple tabs/windows. There was a ton of other little things we had to solve. And solving these things is fun.
Even more fun was presenting JSXP at conferences. We always did it in live coding sessions, and the audience was always impressed how much functionality we could implement in 45-60 minutes. The frameworks ability to find and fix errors was another thing the audience liked. And again, I learned a lot during these presentations.
Still, for a company, developing a new web framework would almost always be a complete waste of time. I normally would not suggest this to one of my customers (although I can imagine scenarios where it might be a good idea to re-invent the wheel). But in a hobby project, “wasting” time (as in spending money with low ROI) is not an issue. The time was not wasted because I learned a lot, had a lot of fun and created something I am proud of.
All of this does not explain why I re-wrote so much for JSXP2 and gclimbing.com - I’ll leave that for a future blog post.