Category: javascript

tags, and even allow you to dig deep inside such components whenever you need to know the internals of Flash Player while coding in Flex. But overall, such components are meant to solve different problems – highlighting and CSS are less important here. Mainly these components process some events, offer support of the Model-View-Controller and so on.

After further analysis I’ve learned that the framework Ext JS by Sencha is close to what Flex offers, but without compilation, data binding, and with less control.
I often use an example of a cat running over the keyboard of my laptop while a JavaScript file was opened in a text editor. Even if I didn’t notice this, I could successfully check in this file into a code repository, but it may not work afterward. Un-compiled environment is a dangerous place to be.

Y. Would your example work the same way for developers who have dogs?

V. Yes, but the number of errors will increase.

Y. Currently, the legions of developers are moving in the direction of JQuery framework. But we are moving perpendicularly. As you stated earlier, JQuery is good for improving an existing JavaScript site. With Ext JS you start with designing your application’s UI as close as possible to object-oriented principles. Ext JS has rich set of UI components, loader, offers an event model – it’s a different and better approach, right Anatole?

A. Today I lead projects that use both frameworks. JQuery is a light framework (code wise) and it can be used to program about 80% of a Web site. You should use it for the look and feel support, which is what it’s meant for. But you can’t use it for building your application component model. The component model of Ext JS is applicable in about 20% of a Web site, which includes an application piece rather than just being a set of Web pages. Typically it’s a serious view navigator or a wizard to implement a serious business process or a workflow that includes a client’s part.

Y. Data grid, of course…

A. Yes, high-level components and a workflow because often the user needs to perform several steps to complete a business process. And these 20% of an application will require 80% of the project time of complex development. So you won’t need to choose between these two frameworks. My main problem with AJAX projects is not how to pick THE best framework for development, but finding the right software developers. It’s hard to find people who don’t have cats around and can concentrate.

V. Absolutely, an extreme concentration and attention is a must.

Y. Or you can use one more framework that will take care of testing.

V. Absolutely everything must be thoroughly tested over and over again. Refactoring in JavaScript is a nightmare.

A. A software developer has to remember everything – all unfinished pieces of code. Many things that we take for granted in a compiled language are simply not supported in JavaScript.
It’s worth mentioning another type of frameworks that use Java for development with further generation of JavaScript, which is a controversial idea, because after writing the code you’ll need to debug it. This is when you’ll meet JavaScript, which is a foreign language for you.

Y. I guess, you mean GWT. There is one more reason of why this is a stillborn idea. The ideology and psychology of programming in JavaScript and Java are different. Five years ago I’ve written an article demonstrating how Cobol, Java, and Lisp programmers solve the same task differently. I guess, it’s time to add a JavaScript version to this example.

A. A person who writes in Java/GWT has to know how to read and interpret the JavaScript code in the debugger. Besides, GWT hides a large portion of JavaScript functionality.

Y. Plus Java doesn’t support dynamic programming…

A. Not too many people use dynamic programming, but it would be nice to change the language. Twenty years ago there were mixed languages that would allow using the dot notation to request some code fragments to call dynamically and some statically. We had a choice to either compile an operator or interpret it during the runtime. It was up to the developer. I won’t have peace of mind until JavaScript will support this.

V. Anatole, how many years should pass till people will accept the notion of compiled language running inside the browser (JavaScript, ActionScript, et al) along with an interpreted language?
A. These questions were raised many years ago – remember the languages like curl? These languages were in R&D…

V. But they never became standardized for the use in Web browsers.

A. Exactly! Apple didn’t let Flash Player in their popular devices, and this became a huge obstacle for the evolution of Flex. The same thing may happen if some vendor decides to not allow any other language or environment in their devices killing these new ideas. For example, Google came up with a new language called Dart, but Microsoft says, “No, we’ll be improving JavaScript.”

Y. JavaScript frameworks promise to hide from you all incompatibilities and take care of the cases when a vendor won’t let some features in their environment.

A. I don’t think anyone will be able to translate the world literature into the language of the tribe Tumba-Yumba with very limited expressiveness. There are reasons why some languages are better then other for different tasks or application sizes. JavaScript is a very basic language.

V. But if you take Ext JS, their documentation suggests to use ext.create instead of the operator new. Technically they are extending or replacing the constructs of the JavaScript itself extending the alphabet. Any framework architect who wants to create a controlled environment will run into a JavaScript wall.

A. Partially this is correct. If you want to create a real dynamic or static language with the error checking and runtime compilation, you’ll have to substitute their constructors with the strongly-type ones that can throw exceptions.

C++ supports operator overloading and people used this feature for some time. But it didn’t last long – they realized that it’s hard to read and understand their own code. If a language allows you to write a code fragment that’s hard to understand – it’s better to remove this code.

V. I’d like to add to the subject of comparison of the JavaScript and ActionScript… I feel uncomfortable thinking that someone else will read, support, and refactor my JavaScript code. Actually, I’m not comfortable refactoring my own JavaScript code a couple of months later. In a non-compiled environment it’s tough. I don’t remember what’s the type of the parameter that’s given to the particular function.

In the compiled environment I’d always known each type and if an object still had certain properties or they were removed. But there is nothing like this in interpreted environment.

A. You can research the code, open each base class and check the references and find out what the properties are – the language will help you with this. I liked dynamic languages when I was 26 years old. A development manager will also have to hire young and very enthusiastic but inexperienced developers.

V. Today’s labor market consists of such people – inexpensive, enthusiastic, and inexperienced.

A. On AJAX projects such a developer will spend the first two months studying, on the third month he’ll start working, and in six months he quits for a simple reason – development is hard and the project arrived to a dead end. When the code base of such project reaches critical mass, the development process gets stuck.

V. The developer will quit not necessarily because the project got stuck. This developer will get more rewarding offers on the job market.

A. In other words, the project stops in 5-6 months – it becomes unmanageable because of its size. That’s why I’d like to stress that there is big difference between AJAX projects and those that are being developed in a compiled environment like ActionScript.

Y. I’d like to return to the question of JavaScript frameworks and browser compatibility. I like the analogy with TV sets. Even if I have the latest and greatest 3D LCD HD TV set and you have a 30-year old black and white television, we both can watch the same movie even though the quality of the picture will be different. In modern terms, you can say “The user experience will be different.”

Now let’s talk about the browsers. You use the latest Google Chrome, but I’m a corporate user who must use IE 6. Is it possible to ensure that the same JavaScript application works in both browsers?

V. The core part of frameworks try to address browser compatibility. They try to ensure that the page works as good as possible in every browser within its limit. But the script will work.

A. I don’t agree. In my opinion you can achieve browser compatibility not on the framework level, but by testing and adjustment of your application in different browsers. The statement that it’ll work somehow is an exaggeration. The chances are that you’ll have to fix the framework.

V. True. I already started making some changes in the framework even without developing overly complicated code. Maintaining compatibility is a huge challenge for any vendor that supports a framework. I remember our XMLSP framework that we created in the beginning of this century. We had a client form Great Britain who said, “This product is bigger than your company”. If I’m not mistaken, there were five of us who worked on XMLSP.

I’m sure, Sencha has more developers who work on Ext JS, but the framework is a lot bigger than we had. Most likely the code base and the task they are trying to achieve are comparable to Adobe Flex. No wonder that any such framework will always need some fixes and improvements.

I have no hard feelings when I make fixes in someone’s framework. I understand that these guys simply didn’t have time to fix everything. You need to form an attitude that a JavaScript framework is similar to a good Legos set that will require your creativity too. Don’t get angry. Cure the framework. Spend some time working on the framework, and then work on your application code. At least this is how I see the current state.

A. To rephrase what Victor said, either work with the simplest framework components that don’t give you compatibility problems or get ready to roll up your sleeves, learn what’s under the framework’s hood and staff your project with not not only application developers, but with systems engineers too who will spend half of their time on customizing the framework.

V. At this point the framework becomes your product too. I wouldn’t agree that half of the time should be spent on customization of the framework. It all depends on the long term plans. If you bet on a particular framework and plan to use it for years, than invest into its improvements But if this framework just had to address the needs of one project, just apply some patches and move on. In most projects patching a framework will suffice.

Y. To summarize, JavaScript developers will need to solve the same task as Java, JavaFX, Silverlight, or Flex developers face:

– Reliability of communications. What if the data never arrive from/to the server? Is it possible to recover the lost data? Where they got lost? Can we re-send the lost data? What to do with duplicates?
– Modularization of your application. If a user never clicked on a certain menu item on the main screen, don’t even load the code that should process this menu.
– How quickly the main window of your application is loaded to the user’s computer? How heavy is the framework’s code base?
– Where to store the application state – on the server or on the client?
– Does the framework offer a rich library of components?
– Does the framework support creation of loosely coupled application components? Is the event model well designed?
– Does the framework of your choice cover most of the needs of your application or you’ll need to use several frameworks?
– Is well written documentation available?
– Is there an active community that can help you with technical questions?

I can keep adding items to this laundry list. So if the words HTML5 easily get you excited, calm down. It’s not just about adding a tag video to a Web page. It’s a hard work with JavaScript. It seems that our company will have a lot of interesting and challenging projects in the foreseeable future, and we don’t complain.