Will HTML Force You to Lie?
OK, our company, Farata Systems has created this nice application using Adobe AIR, and our customers are happy. It’s not a simple CRUD though. We’ve implemented some cool stuff replacing tons of paper forms with PDF documents processing. PDF documents are being scanned, the OCR software processes them to automatically figure out what type of document is it to properly save it in a database. Customers’ checks are scanned, digital signatures are flying, reports are being created… All is integrated into one Adobe AIR application. No external Acrobat Reader, no nothing. I’m not saying that it’s not doing some traditional grid/form processing, but there is something to be proud of.
Yesterday, one perspective customer asked me if we have an HTML5 version of this application. I said, “We can create one for you”. The next moment I realized that I lied and added, “I mean, most of it can be turned into HTML/JavaScript, but some heavy duty stuff we’re doing now would be too expensive to re-create in HTML/JavaScript”.
I didn’t start questioning why they even wanted to do a pure HTML5 version. I know what the answer would be: “Everybody goes HTML5, we want it too, and we want it now”. You can’t piss against the wind. You shouldn’t attack windmills unless your name is Don Quixote.
In my 25+ years in IT I always stuck to one rule – give your customers an honest technical opinion, but if they decide to overrule it for whatever reason, do what they want. This strategy allows me sleep well at night knowing that I didn’t lie. I also know that I would have won more project bids if I wouldn’t stick to this rule.
After thinking of this yesterday’s conversation I felt like deja vu – it was happening in the past and will be happening all over again. I’ll be saying to our perspective customers something like this, “We can do it in HTML5/JavaScript, but it’s going to be a lot more expensive than if we’d in Adobe AIR”. But the next day a salesman from another consulting firm will meet with the same perspective client and, without thinking twice, will answer, “Yes sir, we can do it in HTML5 at the same or even lower cost. Promise.”. After that the salesman will give a strong handshake looking straight in the eye of a customer for about three seconds. They’ll win the bid… Said I loved you, but I lied.
Only six months later it’ll become obvious to everybody that the entire project budget is drained, because of “some unforeseeable technical difficulties”, and they’d need to substantially increase the budjet of this project. But hey, they’ll figure out something. And what do I get? I didn’t lose self respect and sleep well at night, which are not a bad things too, don’t you think?
Learning English with Google
English is my second language, but the last 20 years I live in the USA and my English is fluent. I almost never have to refer to a dictionary. But blogging and book writing forces me to look for help once in a while – readers (a.k.a. angry birds) are quick to point fingers if someone uses THEIR language improperly. I’m not talking about spelling errors – any text editor has a spell checker. I’m talking about phrases and, especially, articles – “a” vs “the” vs no articles at all, which is the most difficult part to comprehend. The funny thing is that most of the Americans raised and born here can’t explain WHY you should use “a” or “the” in this particular context. They just know what to use and do it.
If you are an ESL-person like myself, I’d like to share with you how Google helps me finding the right usage of the phrases much faster than any thesaurus. If I want to write a phrase, but am not sure which article to use, I do a Google search of each version of the phrase and see how many results come back. Important: you must put the phrase in quotes! This istructs Google to look for only those online documents that contain your words if they’re placed next to each other and in exactly the same sequence as in your search criteria.
Usually you can clearly see a big difference in result counts. Pick the version that majority uses and move on.
Oops! That majority uses or that THE majority uses? Google gives three thousand for the first version and 127 thousand for the second one. The right way is “that the majority uses”.
Let’s take another example. If you’re not sure what’s the right way to write “and the God made” or “and God made”. It’ll take you 5 seconds to find out that 16 million documents contain the second version of the phrase, and only 2 million the first one.
This method works for me almost all the time. But today I was not sure how to write – “the Eastern Europe” or “Eastern Europe”. I got 54M vs 134M. These two numbers were too close to each other, and I suspected that all occurences of the second phrase were accounted for in the results for the first phrase too. So I modified the criteria a little bit: “and the Eastern Europe” vs “and Eastern Europe”. I got 2 mil vs 90 mil. Now we’re talking! I’m sure Google has some special characters to specify more sophisticated search cases like the sentence must begin/end with the phrase in question or these option may exist in the Advanced Search panel, but we need it quick, and Google delivers!
There is another great side effect in using my method. Seeing that millions of people don’t know how to write correctly means that I’m not alone! So don’t even try to read this blog hoping to find language imperfections here. There are millions of people out there who’d made the same mistakes. Be positive and learn English any way you want!
Reading another funny document by Adobe
Today Adobe released another document that brought tears into my eyes. Why they think that people are dumb? Why not just say, “We couldn’t figure out how to monetize Flex and we’re getting rid of the ballast”? Adobe is a public company, and, beside developers they have investors and their stock went more than 10% up since last (infamous) November. They’ve chosen investors over developers. This is understandable, but why keep lying to developers?
Today’s doc contains lots of words, but the most important section is this:
Adobe runtime support of Flex
Flash Player 11.2 and Adobe AIR 3.2, which are anticipated to ship in the first quarter of 2012, will be tested
with applications built using Adobe Flex 4.6. Adobe will test future releases of Flash Player and AIR against the
Adobe Flex 4.6 SDK and maintain backwards compatibility for five years.
While Adobe will ensure that the Adobe Flex SDK 4.6 and prior will be supported in future versions of Flash
Player and AIR, it will be the responsibility of the Apache Flex Project to test future versions of the Apache Flex
SDK against released Adobe runtimes to ensure compatibility and proper functioning.
In the past, features were added to Flash Player and AIR specifically to support the needs of Flex applications.
Going forward, features will be added to the runtimes to support Adobe’s vision for the Flash Platform. The
Apache Flex Project may choose to take advantage of those features; however, new features will not be added
to the runtimes specifically to support the Apache project’s efforts.
Let me re-write it in plain English:”We’ll release the new version of Flash Player, and we ‘ll test our past versions of Flex against it. We love (kinda) Apache Flex, but we don’t give a shit about what these guys will come up with. Flash Player is OUR runtime, and you’d better make sure that your smart-ass next generation Flex works with it, or else… In the past, every release of Flash Player would accommodate for the new features of Flex. From now on, ” We are not adding new features to Flash Player to support whatever you come up with”. Or as we say it in New York City, “Fuggeddaboudid.”
Keep reading Adobe’s doc. Their version states, “Flash Catalyst CS5.5 is the last release of Flash® Catalyst®“. BTW, why do they even add these ® signs to Catalyst? Anyone wants to reuse this lousy brand? OK, maybe. Let me translate it into simplified Chinese: “It was stupid in the first place to work on such a tool, and we wasted two years of our Flex team re-writing the FLex Halo components into Spark architecture just to accomodate the need of this still born baby – Flash Catalyst” .
Keep reading – it’ll get even funnier: “Development of Flash Builder continues. Adobe plans to maintain support for Flex projects in updates to Flash Builder 4.x, including additional work to ensure Apache Flex based SDKs can work within Flash Builder“. This is what it means in Bengali language, “During six years we tried hard, but couldn’t create a stable and performant version of Flash Builder for our own Flex SDK. For some weird reason, Flex developers would spend half of their time waiting for Flash Builder’s workspace to finish rebuilding itself. Design mode never really worked for Spark components. We are off the hook now, yay! Noone would even expect us to fix this for some Apache product. Just use IntelliJ Idea, will you? “
The only product that was not mentioned in this doc was LiveCycle Data Services. What’s the fate of this highly overpriced monster? Is it dead in the water? I don’t really care about this one. During the last six years I ran into one client who bought its licenses. On multiple ocasions I was trying to convey to Adobe that they should lower LCDS price, but they didn’t give a damn.
Adobe has inspired these T-shirts. Still, it’s sad. I’m going to miss Adobe Max conferences. They knew how to put up great events, really.
Starting blogging on JavaScript and Ext JS
Our company, Farata Systems, started publishing a series of technical blogs on JavaScript and Ext JS framework at http://flexblog.faratasystems.com/. Since Farata Systems is not affiliated with Sencha, these materials will highlight both good and bad things (if any). Trust me on that.
I’ve started writing my blog on comparing JavaScript with more traditional (read O-O, strongly-typed, compiled, Java, ActionScript3) languages.
If you’re interested to jump start your Ext JS project, consider attending our hands-on 2-day workshop in New York City on April 19-20.
To get $100 off the enrollment fees, enter yakov as your promo code.
Java: Passing by Reference With a Twist
Currently I’m teaching a Java class online, and Vitaly O., one of my students, ran into an interesting situation. He sent me the program below, which, to his surprise, printed 1.
public class Main {
public static void main(String[] args) {
Integer t = new Integer(0);
t=1;
test(t);
System.out.println(t);
}
public static void test(Integer t) {
t=2;
}
}
The topic of passing by value vs by reference is one of the difficult topics to understand for Java beginners. The code above can confuse junior Java developers, because the author of the program above ran into a bouquet of Java features, which I’ll explain (slowly) in this blog.
All Java textbooks (mine included) will tell you that objects are being passed by reference and primitives by value. That’s fine and understandable – nobody wants to copy large objects in memory . But what about the variables that point at an object and are being passed to a method as arguments like in test(t) line above?
First, let’s take care of a simpler case. Let’s replace the Integer with the class Car that looks like this:
public class Car {
int salesmanWhoHasKeys;
}
Imagine a tiny car dealership with two salesmen that has a room only for one car. When a customer pops in, one of the salesmen takes the car keys to test drive THE car. The class TestCar will look similar to the class Main, but is not exactly the same.
public class TestCar {
public static void main(String[] args) {
Car t = new Car();
t.salesmanWhoHasKeys=1;
test(t);
System.out.println(t.salesmanWhoHasKeys);
}
public static void test(Car t) {
t.salesmanWhoHasKeys=2;
}
}
The program TestCar prints 2. Why? What makes it different from the program Main? Just bear with me for a moment. Let’s completely understand what the phrase “objects are passed by reference” means. There is only one car, remember? And Java doesn’t create a copy of the one and only instance of the object Car just to pass it to the method test(). But it does create a copy of the original pointer t inside the method test for method argument, which (to add to the confusion) is also named t.
Get used to the fact that we have one object in memory with two different pointers to it (t and ttt). To make things easier to understand, modify the method test() to look as follow:
public static void test(Car ttt) {
ttt.salesmanWhoHasKeys=2;
}
The program still prints 2. So what’s the difference between dealing with the instance of a Car vs Integer? The wrapper class Integer is immutable. This means that you can’t change its value once it was assigned, which is not the case with the Car.
To make things worse for comprehension, the Java feature called autoboxing kicks in and the original program quietly creates instances of new wrapper Integer objects when it sees something like t=2. This line gets converted into t=new Integer(2)! Got it? So the value 2 has been assigned to a different Integer object via a different variable t.
And just to make sure that you clearly understand the whole confusion of the program Main, please answer my final question, “How many instances of the class Integer were created during the lifespan of the program Main?”
Who said two? Mary? Wrong! The right answer is three! The first one had the value of zero, the next line caused the creation of the another instance if Integer with the value of 1, and the third instance was created by the method test() with the value of 2. Don’t believe me? Step through the Main program in a debugger, and you’ll see three different ids assigned to the variable t.
Don’t you love Java? I do.
Enterprise Development: Flex or HTML5?
This article is a transcript from a recorded conversation I had with Anatole Tartakovsky and Victor Rasputnis – my business partners at Farata Systems. This conversation took place on the mountain after the day of skiing.
Yakov. There are many ways of creating Web applications and creating them for the enterprises is not the same as developing a Web site for a pizzeria in your neighborhood. During the last five years we’ve been using mainly Adobe Flex for development of the front end of Web applications. Flex applications work in a well known and predictable run-time environment called Flash Player. The code is compiled and you have convenient tools for development.
Flex is undergoing “Under New Management” transformations these days. Even though Flex remains the best framework for development of Web applications, you can feel the pressure of HTML5. But using just HTML5 is not enough for development of Web applications – you’ll need the same old Dynamic HTML – HTML, JavaScript, CSS, and XMLHttpRequest object.
Anatole, we did it in the past and it seems that we’re entering the same waters again. Is it still the same river 7-8 years after?
Anatole. DHTML has been introduced in the Internet Explorer 5, and several years later it was renamed to AJAX.
Y. Back in 1999 Microsoft created XMLHttpRequest object to allow their Web version of the mail client Outlook to update the browser’s window without the need to refresh the entire page. Is this right?
A. Partially. IE5 also had the XSL transformation tool for HTML generation and sopported development of custom plugins. The market share of IE5 was about 90%, but in enterprises it was literally the only approved browser.
Victor. At the same time, IE5 supported the model of HTML components called HTC. It allowed you to create htc files containing your own custom components with properties and methods, which were visible in the Web browser’s DOM with all these properties.
A. In fact, this was a more progressive model than what’s offered by today’s frameworks supporting HTML5, because you could use a markup language combined with JavaScript to support your components. This model was similar to what Flex offers. Today, we see some kind of a plugin environment (a lowest denominator between the Web browsers) that allows using various frameworks. The situation is this field didn’t get any better.
On the positive side, the Web browsers have changed and performance of JavaScript improved substantially. The browsers support 6-8-12 connections per domain (as opposed to 2 five years ago), which gave a performance boost to AJAX applications.
Y. But let’s get practical. Say, I’m an enterprise IT manager with a limited budget and a 5-men team that has to develop a Web application. If I’d be using a predictable VM-based environment like Flex or Java with good tooling (IDE, compilers, debuggers, profilers) my job would be easier. But with JavaScript, the situation is different. First, the development cycle with JavaScript is longer (read more costly).
Second, not only I need to find skilled AJAX developers, but they’d need to know a bunch of modern JavaScript frameworks. Third, compilers are not catching programmers errors so I’ll need to allocate more time for testing. Victor, what’s your take on this?
V. If you ask me what has changed the most – it’s perception. In the beginning of this century we worked in the DHTML environment. Only a small number of developers was involved with this “suspicious” development. Enterprise architects had hard time adopting this pre-AJAX model and often asked the same question, “This is not J2EE, right?” We’d answer, “No, it’s not”. Then it was clear to the architects that it’s some amateurish offering that could be ignored.
During the last six years, development with Flex slowly became an approved enterprise technology – it’s compiled and controlled environment with good performance, testing tools, and internationalization support. Then, Adobe turned its back on Flex.
Y. And the way they did it could be included in the Bad PR section in textbooks. Instead of starting Adobe MAX conference in October of 2011 with a proud announcement that Adobe is donating Flex to Apache Foundation, which would get a standing ovation, they waited a month and made the same announcement right after declaring that they wouldn’t support Flash Player (Flex runtime) on the mobile devices. This sounded as if they wanted to kill Flex. But we know that Flex is alive!
V. Yes, it’s alive. Technically it remains the best environment for development of Web application, but politically it became the product of the past.
Y. And now many enterprise architects will say, “We told you to stay with JavaScript 5 years ago…” But I’d like to get your opinion about the cost of development using Flex vs. JavaScript. What’s more expensive?
V. It depends on the type of the person who’ll be managing this project. Is it a corporate or a startup manager? A corporate manager is a temporary person. He works 6-12 months and the either gets transferred to another position or leaves the company. He’s not really interested in the end result. He can stay within the budget during specific period of time, but the project may fail in the long run.
The hourly rates of JavaScript developers are smaller than of those who know Flex. And development with Flex is easier, the results usually look better comparing to today’s JavaScript-based applications. Development with Flex may be more costly initially, producing better results, which is not that important to the corporate managers.
Y. Yes, the main goal of the corporate managers is to climb up the corporate ladder and earn good bonuses and pensions rather than creating advanced applications.
V. They don’t always climb up the ladder. Sometimes they move sideways to another firm, where the same position brings more money or other career opportunities. That’s why the success of a specific project may have a lower priority to these managers.
Y. So what’s more expensive – Flex or JavaScript projects?
V. As you know, we develop in Flex all internal projects at Farata Systems. But if the clients are ready to open their wallets for JavaScript development, we gladly help them.
A. If you want to develop two identical projects in Flex and HTML5, there is a high probability that the HTML5 project will be more expensive. But I doubt that anyone will even try to reach the Flex-level quality in an HTML5 project. Any HTML5 enterprise project will have lower requirements in the first place. From the very beginning parameters like reliability, ability to adapt to different the screen sizes and densities will be simplified. Instead of implementing these features, the functional specification will include testing under seven browsers, and developers will spend most of their time in the debugger.
You’ll save on the compilation time but will spend more time testing during the runtime. The final deliverable of an HTML5 project may have as low as half of the functionality comparing to the same project developed in Flex. But you’ll gain a little better Web adaptability, easier implementation of full text search and mashups. The integration with other technologies will also become easier with HTML/JavaScript. You have to decide if all these advantages are important to your application. If they are – choose HTML5.
But often the HTML part this is just a tip of the iceberg. The base functionality is usually developed in Java or .Net, and back-office applications should be using Flex for UI anyway.
Y. All these people marching undwr the HTML5 flags will gladly start new JavaScript projects because it’s available everywhere, it’s free, the frameworks are open sourced and don’t belong to these filthy rich corporations like Adobe. In the past, it was cool to hate Microsoft, and in early 2012 is cool to hate Adobe. Do anything you can, cut any corners, lose functionality but don’t start a new project using Flex. This way we’ll belong to the mainstream – we’ll develop in JavaScript.
A. Yes, but JavaScript will enforce its limitations on any serious and complex enterprise project. You can develop a number of fairly independent windows, but creating a well debugged application (not a site) in HTML won’t be easy.
Now let’s return to the premise that performance of the browsers is substantially improved. Since JavaScript frameworks have to support various browsers from the same code base the size of their code increases, which lowers the performance and overall user experience if you compare similar Flex and JavaScript applications. I recommend establishing well defined boundaries between front and back office applications. You don’t worry that much about the productivity of the external end users. But if we talk about the internal enterprise users (back office), each of them is a salaried employee and they’d better be productive.
We spent more than six years in DHTML. We wrote our own framework and implemented DHTML enterprise applications for the Fortune 100 companies. We know all the loopholes in these environments and which ones still remain unpatched. As of today, you can’t compare Flex and DHTML. But there are some narrow fields, where you must complement Flex applications with DHTML.
Most enterprise applications have front end, back end, and back office (support, error fixes, et al.). The front end tier can consist of DHTML and Flex parts because today it’s hard to develop front and back office application in the same environment.
Y. Let’s talk about the situation on the market of JavaScript frameworks. There were about 200 such frameworks five years ago. In 2012 the situation is a little bit different – we’re talking about dozens of JavaScript frameworks. But still, there is no one framework that could cover all the needs of your Web application. Victor, what’s your take on this?
V. After Adobe has shaken the Flex world, I was shocked for a while. But then I realized that any good tool or environment should be replaced with the newer one some day. After spending some time researching the modern market of JavaScript frameworks I noticed that there are two main categories of frameworks:
a) Those that allow you to take an existing Web site and, by a magic wand, add new attributes to all
b) The frameworks that are similar to Flex in that they offer high-level components, which may be based 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.
Immersing into JavaScript Frameworks
During the last month my colleagues and I were immersing into the world of modern JavaScript frameworks. We didn’t start from scratch though. My business partners spent the first 5 years of this century porting PowerBuilder, a used-to-be-popular client server tool, to a JavaScript framework. That product was called XMLSP and you can still find its 5-year old version online. The word AJAX was not even invented back then. In 2006, a killer UI framework Adobe Flex 2 was released and we started using it. It was clearly better than any AJAX offering, and I was not shy in publishing blogs and articles explaining its superiority to any AJAX solution available at the time.
Flex remains a great solution for developing UI for the enterprise Web applications, and our company,Farata Systems, is committed to support any client who decides to hire us for any Flex/AIR Web/Desktop/Mobile project. But the world of software and hardware is hugely different in 2012 comparing to 2006. And we are stepping into the same JavaScript river once again.
Well, it’s not exactly the same river. It was renamed. The authorities replaced the old road sign AJAX with HTML5, but let’s not get fooled. It was DHTML ten years ago, and it remains DHTML now: HTML, JavaScript, XMLHttpReuest object, and CSS. But the modern Web browsers employ faster JavaScript engines, CSS is a lot more flexible, smart phones come with dual core CPUs, the speed of WAN is faster too (ok, just a little bit).
More and more enterprises are adopting HTML5/JavaScript, but software architects and developers are still looking for the features available only in the VM-based clients. Will an XYZ JavaScript framework manage client state, support atomic transactions and provide server-side push? Will it offer declarative UI programming, flexible layouts, rich component library, good event model? How many extra kilobytes has to go over the wire to the client if you use this framework? Will the XYZ step up to MVC, modularity, and reliable communications? What are the requirements for the developers’ skills? Is the learning curve steep?
Sounds familiar, isn’t it? We had to solve these issues in the past, and we’ll do it again. Promise. After spending some time trying to pick THE JavaScript framework that can address all these demands of serious Web applications, I can report that you won’t be able to find THE framework. But the good news is that by combining more than one framework you’ll be able to create a well performing and reliable Web application.
Based on on the research conducted in the underground labs of Farata Systems, I can report that our JavaScript framework of choice is Ext JS by Sencha. This framework can serve as a solid foundation for any serious JavaScript development. We’ll also use a couple of more lighter frameworks on as needed basis.
I’m also happy to report that we’ve created an alpha version of our Clear Data Builder (CDB) tool that will offer automatic code generation for JavaScript/Java CRUD applications with transactional support and other goodies that will substantially increase the productivity of JavaScript developers. CDB won’t be an alternative, but rather a compliment to any JavaScript framework.
In a couple of months we’ll publish the first demo that will show an automated generation of a CRUD application using use Ext JS, CDB, MyBatis, and Java. Why MyBatis? Because we like writing SQL, but the demo that uses Hibernate will come shortly after. We already started a new consulting project to prove that we can eat our own dog food, and this food has a good taste.
Technology pushes customer service down the drain
Five years ago, when you called your credit card company or any other customer service you had a choice: either punch in your selections in the automated menu or hit the O-button to get to a live operator. Back then everyone hated those annoying automated menus. Little did they know what was going to happen in the future thanks to technological advances…
Today, most of the customer service departments use some voice recognition software, which supposed to collect all required information (e.g. your credit card info, address, the reason of call et al) before the live customer service representative would start talking to you. The goal is noble, but implementation sucks.
After spending 5 minutes repeating like a parrot the same answer several times, you may not be understood anyway. The old trick with keying in the O-button doesn’t work any longer and just pushes you back to this cold-blooded machine, which keeps asking you politely, “Did you mean to say…”
Finally, it understood what you wanted to talk about, validated your credit card number, spent another minute announcing your balance on the account, which you never asked for, and when you’re almost ready to throw your phone against the wall, a pleasant voice of a human being says, “Hello, this is Adriana. For security reason, could you please tell me your credit card number?”
WTF, didn’t I go through all this already talking to your stupid machine?
I’m sure, the CEO of these companies receive good looking reports stating that “our company was able to substantially minimize the time spent by our agents on the phone with customers, which allowed us to lay off 100 employees resulting in $5M of annual savings.” These reports don’t account for losing business because some customers just hated this type of phone experience and went to competitors that operated in an old fashioned way with live service representatives. Mediocrity an incompetence in enterprises disappoints. But there’s not much we can do about it other than learn how to live with it.
The Future of the Flex Framework in Enterprise IT
Disclaimer. Everything posted on this blog is my personal opinion and does not necessarily represent the views of my employer.
Part 1. Emotions.
Three days ago I’ve received the following email from an enterprise architect of one of our former clients (we’ve conducted two Flex training classes there):
“Adobe has been in the news lately with Flash not being developed for mobile devices and then the Flex SDK being donated to Apache. With all these things going on I was thinking if it still makes sense to develop using Adobe Flex for RIA applications. There are several opinions out there on the web but would like your take on the future of Flex and Flash. Is it still a safe bet to develop in Flash for RIA applications. Does HTML5+CSS+jQuery come close in terms of functionality that Flex offers? Please let me know.”
I’ve quoted this email because it described well what many of enterprise IT shops are talking about after Adobe simply decided to change their priorities. It started with that infamous blog of November 9th stating that Adobe didn’t care about Flash Player in mobile devices. But they didn’t stop there. Now they’re donating Flex framework as well as BlazeDS to Apache Software Foundation. Flash Catalyst was a mistake. It seems that Adobe decided that enterprise IT shops extinct. Apparently someone invited Adobe’s executives to a wild orgy, and the morning after one of Adobe leaders said, “How about changing our vision? I clearly see us in digital marketing and digital media! Enterprises are soooo boring, right hun?” Then Adobe went berserk.
Five years ago no one in the enterprise IT considered Adobe capable of anything but making nice tools for designers. They put tremendous effort into getting their foot in the door and be treated seriously by most (if not all) Fortune 100 companies. Back in 2006 enterprise developers didn’t want to hear about Flex framework. It changed. Very serious applications were developed and deployed into production using Adobe Flex and AIR as a front end tool. Will Adobe respect their existing support contracts with all these customers? For how long? Who’s going to provide such support if Adobe laying off hundreds of people second year in a row? As of today (Dec 14, 2011) Adobe didn’t care to make a clear statement about support of their enterprise customers.
Adobe’s executives keep silence. Santanu Narayen, the CEO was always the man of few words. But is Kevin Lynch, the CTO, in town? On Earth?
A couple of technical managers and evangelists are trying to fix the ugliness of the situation, but there is not much they can do. They can’t speak up for executives. Their words like “we’re absolutely committed to…” can’t be trusted anymore. These nice professional people are not being invited to decision-making orgies.
One of the very respected software engineers (a former Adobe employee) twitted, “Watching Adobe remove engines, wings, drop fuel, seats while in midair flight with customers aboard is truly fascinating.”
I see the situation similarly: today’s Adobe is a plane driven by pilots who lost control and are trying to press random buttons hoping to find the way home.
Part 2. Business.
Coming back to the original question, “Is it still a safe bet to develop in Flash for RIA applications?” This was the question of an enterprise architect of a mid-size IT shop, who’s not into politics and honestly tries to make the right technical decision.
The short answer is yes, you have nowhere else to go if you’re planning to deploy applications in production in 2012-2013. Flex is the best Web framework available today, and the fact that Adobe is donating it to Apache is better for everyone. The same applies to BlazeDS. As a matter of fact, Adobe stopped supporting BlazeDS two years ago, anyway.
I’m sure, under Apache Flex framework will go strong. My main concern is if Adobe will be willing to keep their future releases of Flash Player in sink with the future releases of Apache Flex?
What about HTML 5 (a.k.a. JavaScript)? At least for the next two years HTML5 should be used only by the early adopters. But we are in the enterprise development and have to deliver a number of cross-browser Web applications under limited budget and with a team of regular developers, not geeks. Six month ago I joined the project that was developed in Java/Swing by a team of 4 developers. There seniors left the firm. The person who left had 2 years of Java experience but was a quick learner. This week the new financial Flex/Java application developed by two of us goes to production. I’m trying to be fair to all technologies, but it wouldn’t be possible to pull something like this off with any JavaScript or Java front end framework.
If you are planning to go mobile, the most cost-effective platform is Adobe AIR. Can you afford to hire three teams with three sets of skills to develop for desktop, Android, and iOS? If you can’t, stick to AIR.
Part 3. Political stuff in the large enterprises.
Back in 2006, enterprise architecture groups of large enterprises were the main obstacles for making Adobe Flex an approved tool for development of the Web applications. Now, because of those drunk pilots, it’s their “Told’ya!” time.
They will try to squeeze Flex out of the list of approved tools arguing that Flash Player has too many patch releases, security holes, and, after all, the mankind moves to a no-plugin Web browsing. If I’d be running an application development team of Flex developers in a large enterprise, and an enterprise architect tried to to push me away from Flex toward an XYZ Javascript framework, I’d ask if the suggested XYZ framework would patch these security holes. Most likely, the answer would be “No, but at least we can set the Web browser’s security to the highest level for the JavaScript applications, which is not the case with Flash Player”. This can be a valid argument, and if Adobe cared, they could have created a special JavaScript wrapper for Flash Player to mimic security settings of the Web browser. It doesn’t take a rocket scientist to write such a wrapper, but since Adobe remains the owner of Flash Player, it has to be done by them.
Part 4. What to read next on the subject?
I like this post by Adam Flatter from Roundarch.
Part 5. Summary
1. Flex remains my first choice framework for developing RIA and AIR for developing desktop and mobile applications.
2. I’m also planning to go deep under the skin of one JavaScript framework, and it’s not jQuery. I like to have more than one tool in my toolbox.
3. Our company, Farata Systems will offer commercial technical support for Flex, AIR and BlazeDS both on the desktops and on tablets. We’ll make an official announcement about it shortly.
4. Our company continues offering training in Flex and Java as we always did, but next spring we’ll add a class “HTML5/JavaScript for Enterprise Developers”.
5. Under such management Adobe won’t last long and will have to be acquired by another company.
Happy New Year, everyone! It’s going to be fun.
A Bad Guy Inside my Notebook
This week I’m in Seattle, WA teaching Adobe Flex at the client site. Everyone in the classroom was given a password to the local Wi-Fi router. Everyone but one person successfully connected to the Internet. This unlucky guy was me.
In fact, my notebook was connected to the router, but that was as far as I could reach. OK, I was the only person using MacBook. Can this be a problem? Checked the network settings – everything looked hunky dory. I got a valid IP address. One of the students went to see Da Man – sysadmin, who gladly confirmed that my IP address has been blocked by the router’s software. Why? Yakov’s machine makes lots of connection requests to random IP addresses in a short period of time.
Students started to make fun of me – a minute ago I was explaining how to process financial data feeds from unoccupied Wall Street and students suggested that I must have been involved in a heavy-volume stock trading while teaching the class. I wish! Since May I’m working for another client sitting on a trader’s floor, where I had to sign an agreement that made trading impossible (insider’s information, you know).
Opening Activity Monitor on my machine didn’t show anything suspicious – the only running programs were MS PowerPoint, Acrobat Reader, Eclipse, and Skype. Another student suggested that it might be some virus or antivirus software installed on my machine. Wrong. Ain’t using Windows – me no need antivirus. Me no have viruses.
How to find out who makes all these network calls? Good old Charles network monitor came quite handy, as usual. I started this sniffer, and sure enough, every couple of seconds a connection attempt was being made to some IP addresses…
After shutting down Skype, the problem was solved. Skype was the bad guy trying to make all these connections! This makes me wondering, does Skype tries to poll each of my contacts who’s online? This must be the case. We reported my findings to the system admin, who unblock my IP, and the next second I saw Google!
The lesson learned: always have an HTTP sniffer with you if you ever want to see the light of Google’s home page.
