When I first started to work with web applications, it was just servlets and then came JSPs. At the time, I didn't like JSPs (and to this day I still don't). They seemed like a necessary evil that got the job done. The thing I found repulsive about them was the mix of server and client code together. The switching of contexts just made both look ugly and hard to maintain. But, it was easier than generating pages directly from servlets by hand. Of course, there were other solutions that I looked for, but nothing got away from the horrid markup. Then, I fell in love with Seaside which did away with markup and generated content through a custom DSL. It felt better to me and loved it until I realized that it was only for the developer, not the web page designer. It made their life harder. Now, we all know we should use minimal content and have CSS do the layout. But, in this modern world, you need folks who are experts at web page design. You can not and should not alienate them.
Fast forward to now. Currently, I've been using Javascript frameworks and working mainly from the front-end. The project I'm currently working on is pure HTML/Javascript/CSS for the front-end with RESTful calls to the backend. I must admit, I had my reservations about this arrangement, but after working with it; it is the right thing to do. No more ugly markup. The separation of concerns is well in place. And finally, the web designer is allowed to concentrate on making a rich user experience and the developer to concentrate on business logic. Perfect.
My feeling is that the days of template engines are over. It's a waste of time and all of them are a pain to debug. A pure Web 2.0 AJAX solution allows each to utilize their tools and do things separately. To me that is exciting and I will gladly leave ugly code behind.
Subscribe to:
Post Comments (Atom)
Posts
4 comments:
Hi Blaine,
This is the best approach which allows the almost total separation of concerns of the three disparate roles - CSS designer, JavaScript developer and the server side developer. This has been made possible really when Microsoft made XmlHttp available. I have been using it at least since 2002. Good luck with your mobile app.development venture.
- Ram Nukala
Yes, Ajax has been around a long time, but I think it's only been in the past couple of years were the Javascript engines could handle complex tasks. Now, we have Dojo, jQuery, MooTools, etc that give us the power to write powerfully rich clients. I just thought to myself why would anyone want to deal with templates any more? We have the power to do more.
Hi Blaine,
I agree; I've been doing (basically) the same thing lately with GWT client-side handling all UI generation in JavaScript and then REST(-ish) calls to the server for data operations.
I have two caveats/clarifications: one is that I think, client-side, templating is still handy. GWT's UI widgets are very component, which can be nice, but also a PITA to layout (think Swing). They recently added the ability to layout components with HTML-ish templates, which end up being a bunch of DOM.create calls. I've seen a similar approach in other JavaScript libraries too, and it seems much nicer to work in HTML as much as possible.
Second, doing all HTML/UI operations client-side means you end up with a fairly large REST API. While this isn't bad, in my experience, it takes more work than a server-side-only solution that can "cheat" and just slosh out HTML and not worry about providing a nice API. So, for smaller/simpler/Web 1.0-style projects, I think server-side templates can have a (potentially large) productivity win.
This productivity difference probably varies wildly depending on the client-side/server-side technologies and developer abilities/experience. I just know I'm on the wrong side of it right now. :-)
My problem with the current HTML/CSS/JavaScript/Random-Server-Technology stack is that it is a huge CF and every level/layer requires you to learn a different "language". There aren't any good IDEs (that I have found -- haven't looked recently) that support this stack. Personally, I also find that the JavaScript side starts to become difficult to maintain very quickly.
I still prefer my old frameworks that were all in one language (C++, Smalltalk or Java -- I built a framework for each) where I had Document objects that could contain Table objects and other Component objects, etc. After your document was built, you called a method and it emitted HTML/JavaScript/CSS (well, most of my frameworks were before the CSS craze). It did exactly what I wanted to do, completely supported the MVC pattern, scaled beautifully and I could run a debugger on the whole damn thing if I wanted.
But, from the other comments I see, maybe I've just become an outdated curmudgeon.
Post a Comment