JavaScript and server-side languages can work well together ... if you don't set them on the same task.
The programmer's mind is like a kid with a dinner plate - they don't like foods to touch each other. (Ugggh. Terrible metaphor, but what the hey.) Kids have problems debugging food. If they get gravy mixed into the applesauce and it doesn't taste good, there's no way to get them unmixed. Adults probably don't mind it because (1) they know through experience which foods mix well (2) they have given up trying to keep food apart (the "quiet desperation" theory).
I'm not opposed to using more than one language. In fact, that often makes the problem much more decomposable and succinct. What makes me leery of technologies like Google Web Toolkit and Java Server Faces. They try to cover up the language blending, as if a parent can solve the touching-food problem by dousing the whole plate in melted cheese or something. GWT tries to cover up the underlying JavaScript by generating it out of Java. And that's great until you have a problem on the browser side. Is it your code? Is it the translation process? Is it the supporting code provided by GWT? Who knows? You are left with a "this.myProperty is not defined" error, and it's up to you to fix it.
The Dojo Way (tm) is to cleanly separate the tasks of a web application. Styling in CSS. Layout in HTML. Client side logic in JavaScript. Data-providing web services on the server. Now that is like a compartmentalized dinner plate. A little bit of a lot of variety, and nothing touching. You can generally debug these elements as black boxes. Someone works on the web services, writes the unit tests against them without the client. Design gurus do the CSS. The application logic is in JavaScript, and in Dojo you can package them in nice little bite-sized widgets. The app talks back to the server to execute bits of business logic. Very clean. Very nice.
Debugging JavaScript is not a perfect science, unfortunately. And I'll talk about that in my next post.
Saturday, February 23, 2008
Saturday, February 2, 2008
Dojo and Code Separation
I remember my first foray into Dynamic HTML and heavy duty JavaScript. It wasn't making a ball roll across the browser or drag-and-drop tic-tac-toe. We had a real problem.
The company I was working for had a huge catalog. The items were grouped into over 1,000 categories, which rolled up into about 100 mid-level categories, and 10 top-level. We wanted a catalog search where people could ask for parts at any level. Modeling the top and mid-level groups as combo boxes - no problem. The bottom-level ones were a problem -nobody wanted to scroll through 1,000 categories.
Our idea was to make the combo boxes hierarchical. I'm gonna change the items here to protect the innocent, but let's say someone wanted to search Lemon Lime Soft Drinks. They would choose Beverages from the first combo box. The second combo box would narrow down to Beverage choices: Water, Juice, Soft Drinks. Choosing Soft Drinks would constrain the third combo box to Cola, Root Beer, Lemon-Lime, etc. So rather than searching through all 1,000 categories of food, they'd have only about 10 choices. Fair enough. That means we have to remove choices from the other two boxes.
To dynamically add and remove choices, the page needed to load all the top, middle and bottom categories into the page (there was no Ajax back then!) I ended up having to mix JSP and JavaScript like this:
<script>
var c=[];
<% for (c in categories) { %>
c[i++] = <%= c %>;
<% } %>
</script>
Ugggg .... leee. Mixing two languages caused us no end of trouble - for example, what is the relationship between the JavaScript c and the Java c above? (Answer: none). We were forever mixing up syntax. This bilingualism is as annoying in code as it is in "artsy" novels.
This problem is endemic to all server language/client language mixtures, be it JSP+JavaScript or PHP+Silverlight or whatever. The more rich we wanted to get on the browser side (which our customers were pushing), the more problematic the mixture becomes. And Ajax? That made the problem worse.
Then there's the Dojo Way. And by "Way", I mean a paradigm shift - so get ready for some out-of-the-box thinking. To rid ourselves of the mixture, we must rid ourselves of the server-side language. Do it all in JavaScript. In MVC parlance, keep the model on the server and put the view and controller on the client. This looks a lot like Visual Basic, right?
But isn't JavaScript a kiddie language? How can it possibly compete with PHP, ASP and Java? Turns out, it can. Very adeptly. And hence Dojo, a JavaScript-based toolkit, makes it an easy process. So stay tuned!
The company I was working for had a huge catalog. The items were grouped into over 1,000 categories, which rolled up into about 100 mid-level categories, and 10 top-level. We wanted a catalog search where people could ask for parts at any level. Modeling the top and mid-level groups as combo boxes - no problem. The bottom-level ones were a problem -nobody wanted to scroll through 1,000 categories.
Our idea was to make the combo boxes hierarchical. I'm gonna change the items here to protect the innocent, but let's say someone wanted to search Lemon Lime Soft Drinks. They would choose Beverages from the first combo box. The second combo box would narrow down to Beverage choices: Water, Juice, Soft Drinks. Choosing Soft Drinks would constrain the third combo box to Cola, Root Beer, Lemon-Lime, etc. So rather than searching through all 1,000 categories of food, they'd have only about 10 choices. Fair enough. That means we have to remove choices from the other two boxes.
To dynamically add and remove choices, the page needed to load all the top, middle and bottom categories into the page (there was no Ajax back then!) I ended up having to mix JSP and JavaScript like this:
<script>
var c=[];
<% for (c in categories) { %>
c[i++] = <%= c %>;
<% } %>
</script>
Ugggg .... leee. Mixing two languages caused us no end of trouble - for example, what is the relationship between the JavaScript c and the Java c above? (Answer: none). We were forever mixing up syntax. This bilingualism is as annoying in code as it is in "artsy" novels.
This problem is endemic to all server language/client language mixtures, be it JSP+JavaScript or PHP+Silverlight or whatever. The more rich we wanted to get on the browser side (which our customers were pushing), the more problematic the mixture becomes. And Ajax? That made the problem worse.
Then there's the Dojo Way. And by "Way", I mean a paradigm shift - so get ready for some out-of-the-box thinking. To rid ourselves of the mixture, we must rid ourselves of the server-side language. Do it all in JavaScript. In MVC parlance, keep the model on the server and put the view and controller on the client. This looks a lot like Visual Basic, right?
But isn't JavaScript a kiddie language? How can it possibly compete with PHP, ASP and Java? Turns out, it can. Very adeptly. And hence Dojo, a JavaScript-based toolkit, makes it an easy process. So stay tuned!
Subscribe to:
Posts (Atom)