Archive for the ‘javascript’ Category

Steve Yegge’s NBL

April 27, 2007 2 comments

Most readers of this blog would have read Steve Yegge’s prediction on the Next Big Language (NBL). In his post, Steve refused to actually name the language but he dropped hints on the language (languages?) he had in mind. Commenters on his blog tried guessing the language – JavaScript2, Erlang, Scala, Perl6 etc were mentioned. If I had to guess I would have guessed JavaScript2; but I am no expert in programing languages, so my strategy is to wait and watch.

But today, I was re-reading an old blog post and I was reminded of Steve’s prediction. Jarosaw “sztywny” Rzeszótko, a young Polish blogger, had send 10 questions to 8 famous programmers and he had posted their replies (I had written about it too). Here are some excerpts from that post:

Q. What do you think will be the next big thing in computer programming? X-oriented programming, y language, quantum computers, what?

Steve Yegge:
I think web application programming is gradually going to become the most important client-side programming out there. I think it will mostly obsolete all other client-side toolkits: GTK, Java Swing/SWT, Qt, and of course all the platform-specific ones like Cocoa and Win32/MFC/etc.

It’s not going to happen overnight. It’s very slowly been going that direction for ten years, and it could well be another ten years before web apps “win”. The tools, languages, APIs, protocols, and browser technology will all have to improve far beyond what you can accomplish with them today. But each year they get a little closer, and I’ve finally decided to switch all my own app development over to browser-based programming from now on.

Microsoft and Apple definitely don’t want this to happen, so a necessary first step will be for an open-source browser such as Firefox to achieve a dominant market position, which will in turn require some sort of Firefox-only killer app. (A killer app would be something like iTunes, something that everyone in the world wants to use, badly enough to download Firefox for it.)

Q. If you had three months to learn one relativly new technology, which one would You choose?

Steve Yegge:
I do happen to have 3 months (part-time), and I’m spending it learning Dojo ( and advanced AJAX and DHTML. I’m learning it by writing a fairly ambitious web application. Dojo’s really cool, and I’m sure it will only improve with time.

sztywny made this post on Oct 16th 2006 and Steve made his NBL post on Feb 19th 2007. From the above snippet, I think Steve had JavaScript2 on his mind as the NBL.

Categories: browser, javascript, software, tech

Should my JavaScript-heavy enterprise application support IE?

March 17, 2007 9 comments

At work we are developing an application that makes heavy use of JavaScript (yeah, like everyone else these days!:). The application is still under development, but we have made some alpha releases for our sales folks to demonstrate it to potential customers. The application, right now, is sluggish and has memory leaks in IE – in FF it works beautifully well!

Sales, QA and business analysts use IE, but developers use Firefox. Firefox respects CSS, it has a fast JavaScript runtime and supports better development tools (Firebug, in particular, is god send!). IE6 is sluggish and has quirky CSS support.

Within the development team we often joke that we might have to show a splash screen with “Detected IE; launching in slow-mode” when a user launches the application on IE. But Giles Bowkett’s post “The Business Case For Firefox” had me thinking seriously – should we really support IE?

Our application is targeted at businesses; a fixed number of users (employees of our customers and their customers) would be using it daily to get their job done. Productivity is very important under this circumstance, so any sluggishness in the user interface is not acceptable. Speed of the application, as perceived by the user, is much dependent on the speed of execution of JavaScript. I admit that we can definitely tune our JavaScript code to run faster – but shouldn’t we also be looking at getting a faster runtime too?

Since the users of our application are a captive audience, we might also be able to convince them to use a particular browser – you can take the stance that “this website, viewed with this browser is the application“! Will this work in practice? Would we be able to convince our customers to switch (if they are not already using it) to Firefox?

The development effort has budget considerations too. The project stakeholders need to be aware that supporting IE properly is an activity that is going to take some cost – do they really care to have it, or will they like some other feature in the application instead. Giles make some excellent arguments on this, and I think I should be making them to my bosses too; let them be aware at the least.

PS: I don’t have any experimental data to prove that the IE JScript runtime is sluggish. I have that empirical impression from my experience using IE. Please drop me a comment if you have data for or against my conjecture.

Categories: javascript, tech

Rethinking Mockups

January 17, 2007 Leave a comment

At work we are writing an application which is delivered in a single webpage with heavy use of JavaScript. Lately, I have come to realise that writing a web application using JavaScript does have effects in the way we work as a team. The rest of this post explains what I mean.

Initially, web pages had static content – the users requested a resource from a server and the server served out an HTML page it had. Then came dynamic web pages and web applications. The widely accepted way to create dynamic web applications was to use a template language eg: JSP, Velocity, XSLT, erb etc.

Two kinds of people collaborate when a dynamic page is built using a template language:

  1. designers who are good at deciding the user interaction and look n’ feel of the page
  2. programmers who are good at writing programs that generate the dynamic bits on a page.

The designers would design a static HTML page – a mockup – and get it reviewed by the business analysts. The analysts get an early chance to see how the web page would look like eventually; they can detect deviations from expectations early and might be able to correct them at this stage. Hard-coded data would typically be used in a mockup; it is the programmers job to replace it with dynamic content, resulting from some computation database query typically. Frameworks like Tapestry and Rife take great pains to make sure that designers and programmers can work together smoothly in creating dynamic web pages.

This is roughly the model we have been following so far at work – designers make mockups and deliver it to the programmers, who annotate those mockups to create the actual web pages. Throwing in JavaScript to the mix changes this workflow.

Designers when they work out a mockup use a series of HTML pages to show a dynamic interaction which in the actual application should be done with JavaScript. Writing JavaScript is a programmers job and it is unfair and unwise to expect designers to deliver the mockups with functional browser-side JavaScript interactions. Also, to decide the user interaction and look n’ feel and for analysts to set expectations a series of HTML pages would do. But such HTML mockup pages cannot be directly used by programmers as a starting point for writing the application. This is different from the way we have been working so far.

The solution would be to have another set of mockups created by programmers. This would retain the user interaction and look n’ feel designed by the designers, but would have functional browser-side JavaScript interactions. The data displayed on these mockups are still hardcoded ones though. The actual application can be built starting from these mockups. This essentially creates three kinds of roles (instead of the two earlier):

  1. designers who decide the user interaction and look n’ feel of the application
  2. client-side programmers who code the user interaction into JavaScript
  3. server-side programmers who code the computations, database fetches etc.

In many situations, more than one of these roles might be handled by a single person; but the existence of these distinct roles would help manage the project better.

Categories: javascript, software, tech

Splash screen for a javascript application

January 6, 2007 3 comments

At work we are developing a web application that is delivered in a single-page (like GMail, Yahoo! Mail etc). We use the Dojo javascript framework.

Our homepage has multiple javascript widgets. When a user gets to the homepage, the browser downloads the HTML, javascript and CSS files and there is a delay before the DOM elements are decorated and laid out properly. During this delay the user gets to see a partially loaded page. The user can’t start using the application unless the whole page is laid out well, so showing a partially loaded ugly page is not desirable. Yahoo! Mail shows a splash screen of Liam, their mascot, while the application is being loaded – I wanted to implement the same feature for my application.

Searching the Dojo mailing list, I was able to figure out how do this. Essentially you have two DIVs on the homepage – one with the splash screen and one with the real LayoutContainer holding the application widgets. Initially the splash DIV is shown, and the real DIV is hidden. When the page finishes loading and after all widgets are laid out properly, the splash DIV will be hidden and the real DIV would be shown.

function show_main_gui() {
    dojo.byId("splash").style.display = "none";
    dojo.lfx.fadeShow("real", 100);
<div id="splash" style="position: absolute; top: 200px; width: 100%;z-index: 100;">
   <div align=center>
        <img src="images/throbber.gif"/>

<div id="real" dojoType="LayoutContainer"
    style="opacity: 0.01;filter:progid:DXImageTransform.Microsoft.Alpha(opacity=1);">

I got the throbber built at – it is a great site for making throbber images.

Categories: browser, dojo, javascript, tech

Handling session timeouts in an application with HTML IFrames

January 4, 2007 2 comments

In the application I am working on now, we load portions of the application as HTML documents into an IFrame. If the user does not act on the application for some time, the session times out and the user need to be redirected to the login page. We had set up this redirect using Acegi. But when the user performs an action on an IFrame after a period of inactivity, the login page would be shown in the IFrame. This is, of course, ugly and I have been looking for a workaround for this. Today I got this fixed, but I am unsure how proper this solution is.

We now have a page called redirectToLogin.html with:

<script type="text/javascript">

All this page does is redirect the browser to login.jsp page, but this prevents the login page being shown in the IFrame.

Kindly drop me a note if you know of a better solution.

Categories: html, iframe, javascript, tech