Matt RaibleMatt Raible is a Java Champion and Developer Advocate at Okta. developer.okta.com

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

Lessons learned building a 130+KLOC JavaScript application by Scott Dietzen, CTO of Zimbra

Scott Dietzen is the former CTO of BEA. Apparently he was one of the original founders of WebLogic, before it was bought by BEA. Scott's hope tonight is to share his experiences from developing Zimbra. Why does Zimbra use JavaScript and Ajax?

  • Richly interactive UI
  • Rich client/server communications
  • Zero-cost administration
  • Web security
  • Web look and feel (back button and bookmarks)
  • Multi-browser "standard"

All of the above features where things the Zimbra team expected. They also got lucky in a number of areas.

  • SAO/Mash-ups and Ajax authoring
  • RIA winner? Big sites voting with their feet: Google, Microsoft, Yahoo, Amazon, etc.
  • It really works

They started building Zimbra 2.5 years ago, long before Ajax was possible. Scott actually tried to talk his team out of using JavaScript when they first started architecting the application.

Zimbra's tools are good for Java programmers. If you're not familiar with OO concepts, it might be a bit difficult to understand. Now Scott is showing some demos, basically grids and trees - all built using the "Zimbra toolkit", whatever that is. Now he's moved on to demoing the Zimbra application itself. I used Zimbra as my primary e-mail client for a couple weeks and it's by far the best web application I've ever used. Not only does it look awesome, but everything works just as it would in a desktop application. The unfortunate thing about Zimbra is it has two licenses: an open source one and a pay-for version that has all the features you really want.

Zimbra = "Pure" Ajax. All UI behavior specified in JavaScript. The *entire* UI is written in JavaScript, no HTML. It's more like a typical GUI application from a programming perspective (think JavaScript SWT). Result is "husky" client 3-tier architecture. All UI on client, server-side Java code for UI operations. This is very different from HTML "design center" where you start with an HTML page and augmenting with Ajax. The Zimbra toolkit actually doesn't fit very well into most applications, where folks enhance HTML pages. It's more designed for programmers who want to write their entire application in JavaScript.

Ajax is finally giving us a clear partition between client logic and server logic. The dividing line is up to the developer, that's the challenge for web developers today. It's basically a user-defined SOA Endpoint. Before Ajax, in the Java world, JSPs and Servlets were considered the client-side, even though they were really more server-oriented.

Ajax applications are cheaper on the server/network than Web 1.0/HTML apps. Modulo the initial download (gzip is essential). Ajax is much more expensive on the client CPU. Tend to be finder grained in their client/server interactions. They tend to be more stateful. Rule #1: Pick your service bindings well! For modularity and re-use/mashups.

"There's a special place in heaven for whoever had the patience to get all of that JavaScript right." - Paul Ambrose, WebLogic Founder on Zimbra

Ajax Challenges: Browsers and Toolkits. Browsers render the same HTML differently, they have different event models, different levels of DOM supported, they have different APIs that do the same thing, as well as many issues. As far as toolkits for Ajax, there's too many rather than too few. Consolidation would definitely be a good thing.

Zimbra's Ajax Tookit (AjaxTK), Apache Kabuki* is modeled after SWT. It's a JavaScript OO class library and open source (Mozilla or Apache licensed).

Another big challenge is lack of integrated tooling. There's lot of technologies to deal with concurrently: HTML, CSS, JavaScript, etc. The initial stab at a solution is the Open Ajax Initiative. This is largely a set of technologies from Eclipse, Mozilla and Apache. There's 30-odd companies involved with the initiative, including: IBM, Zimbra, Eclipse, Firefox, Apache, Google, Yahoo, Oracle and Red Hat (or at least that's the logos Scott has on his slides).

The proprietary Ajax Landscape consists of MS Visual Studio (Tooling) and MS Atlas (Toolkit). On the open source side, there's Eclipse+Mozilla for tooling and all kinds of frameworks for toolkits (i.e. Zimbra/Kabuki, Dojo, Scriptaculous). Scott's opinion is there's really no room for any proprietary vendors to provide solutions outside of Microsoft.

Now Scott is doing a demo of mash-ups in Zimbra. He's showing how you can mouse-over many things in an e-mail message to get the information you're looking for w/o switching to a new page/context. Mash-ups he showed include: real-time flight information, displaying schedule for a particular day, dragging a message to an SMS sender, viewing a map by mousing over an address. The latest thing they're working on is dragging an appointment from a calendar to a "travel agent" that books your flight.

Zimbra also includes a WYSIWYG authoring environment for documents. It allows you to do HTML editing (in design view) as well as embedding spreadsheets within pages.

Zimlets: extensible mash-ups for e-mail, calendaring, IM, etc. They're a merge of "pull" and "push". There's zero-client install and they're secure because they're managed by the server administrator. To create a Zimlet, you develop a declarative XML template (Regex, ActionURL, XSLT, CSS, Menu). JavaScript can be used to override Zimbra client-based classes. JSPs can be used on the server-side for customization. Ajax Linking and Embedding (ALE) is Ajax components that are embeddable in editable HTML (simple docs, spreadsheets, etc.). Views are read-only HTML and WYSIWYG Ajax authoring (Ajax cod is the "authoring" application).

Practical Tips for Ajax:

  • Use an Ajax toolkit
  • CSS is your friend
  • Use JSON (as well as XML)
  • Use asynchronous network programming
  • MVC paradigm worked for us
  • Tooling better, but rough edges remain
  • _all.js -> jsmin (saves ~ 1/4X)
  • _all.js, _all.css -> gzip (saves ~ 3-4X)
  • Mercury's QuickTest-Pro (QTP) [IE + FF*]
  • Pick your fights - not all applications need to be Ajax enabled
  • No such thing as secure client-side business logic in Ajax
  • Dedicate some top UI OO talent (or wait for tech to catch up)

Ajax Sweet Spots:

  • Richly interactive UI desirable (HTML simplicity is ideal for many applications - for example, you'd rather use Amazon's one-click than drag a book to a shopping cart)
  • Combine with web look and feel and deployment
  • No client-side data/resources (but is changing, stay tuned)
  • Perfect for on-demand services

Recipe for Ajax Success: Ajax is not a business model, compelling and appropriate innovation is essential.

Next Ajax Steps: In open source land, try the OSS toolkits, Eclipse ATF and participate in Ajax communities (Apache/Zimbra, Eclipse, Mozilla, Dojo, Scriptaculous). Scott moved to fast for me to catch his recommendations for Microsoft developers. He did have positive things to say about Microsoft though.

Hardest Ajax problem of all? Recruiting. According to Scott, it's incredibly hard to recruit people that know Ajax.

Update: Additional coverage of this talk is available at Ajaxian.com.

Posted in The Web at May 11 2006, 09:54:26 PM MDT 7 Comments
Comments:

Zimbra is interesting in demonstrating what the technologies can do when pushed to their fullest, but for now it's way too heavy and the response is is sluggish. It's trying to be a client-side app in the browser, and I'm not sure that doing it in such a heavy way is where the future lays.

Who knows. "The only people who predict the future are astronomers and idiots," so we'll see. But while I've seen some interesting Ajax apps demoed at this conference, this one was actually less interesting to me simply because it was so heavy.

Although for the likes of me I can't find the links....

Posted by James Childers on May 12, 2006 at 12:21 AM MDT #

In my opinion, Zimbra is a brave try in field of no future. I'm amazed of its developers' belief in the future of something as fragile as a UI based on an unsuitable platform for UIs (HTML, which lacks crucial components like a tree view and a combo box), where interaction is added with an insufficient set of events (DOM events for HTML input elements are a ridiculuous set for real use). You can't add anything new to HTML by yourself. You don't have a concept of namespace in CSS which would protect the styling of your components form flowing out of their proper use and, on the other hand, you can't block your components styles from style rules outside your CSS. In practise, you can't develop your own *robust* components with HTML/CSS/Javascript.

Ajax is starting to show that the past years of form-based interaction have been a grand mistake, a fact which is not new, since it has been known for more than ten years by all those who have tried to design user interfaces from the users' point of view, i.e. "what is needed", not the technology point of view, i.e. "what can be done with this limited technology and our limited skills". XMLHTTPRequest is a wonderful technology that has clear advantages, but on the other hand it makes clearly evident the antique state of HTML, browsers, the DOM and the DOM event model. I'm really surprised, if a technology like Java web start don't make a breakthrough in the following 5 years - after all, the investment needed to write a robust client-side Java program is significantly less than trying to do the same based on JavaScript + HTML + CSS.

I also find it amazing that someone would take having the web back button as benefit for creating user interfaces.

Posted by Karri-Pekka Laakso on May 12, 2006 at 02:49 AM MDT #

Ahem.

Hardest Ajax problem of all?

Accessibility for the disabled. This is serious, folks.

Posted by john on May 12, 2006 at 07:18 AM MDT #

The only potential group of disabled affected by Ajax is probably the blind. The fact that less than 1% of all user's are blind should not bend the design to be significantly worse for the 99%. I guess Ajax puts web software in the same problem domain as programs like Word, Excel etc. - I wonder how the blind get on with them?

Posted by Karri-Pekka Laakso on May 15, 2006 at 09:05 AM MDT #

For "think JavaScript SWT", http://j2s.sourceforge.net/ is providing the exact thing -- JavaScript version of SWT by converting Java to JavaScript.

Posted by josson smith on June 11, 2006 at 08:49 PM MDT #

"They started building Zimbra 2.5 years ago, long before Ajax was possible." Ajax has been possible since 1998, at least if you focused on IE. Outlook Web Access for Exchange 2000 was the first app to really use these techniques and while the term Ajax is new within the last couple of years, the underlying techniques have existed for much longer.

Posted by Alex Hopmann on June 15, 2006 at 01:09 PM MDT #

i love this site it is educative pls i want to know more about oracle,vc++,visual basic,and javascript pls can u be sending me codes an books? i will be glad if my request is granted a favourable consideration. Thanks.

Posted by manfred on June 20, 2006 at 10:31 AM MDT #

Post a Comment:
  • HTML Syntax: Allowed