Java IoT Authors: Pat Romanski, Yeshim Deniz, Liz McMillan, Zakia Bouachraoui, Elizabeth White

Related Topics: Machine Learning , Java IoT, Industrial IoT, Microservices Expo, IBM Cloud, Weblogic, Adobe Flex, Open Source Cloud, Agile Computing

Machine Learning : Article

How and Why AJAX, Not Java, Became the Favored Technology for Rich Internet Applications

We Can't Wait for Sun to Fix All of Java's Problems...The Solution is to Hybridize Parts of the Language

Several of Bruce Tate’s books focused on the flaws in Java and the need to let go of some of the ideas that haven’t worked out. And blogs like this and this have been appearing more frequently. And of course there’s Steve Jobs now-famous quote (referring to the iPhone): “Java’s not worth building in. Nobody uses Java anymore. It’s this big heavyweight ball and chain.”

This backlash has only been necessary because of Sun’s death grip on the idea of ubiquitous, omniscient Java. It was admirable once, but a language only evolves if its designers and advocates can acknowledge problems. Pretending that a language is successful in places where it’s not is just denial.

Some adaptations have occurred. Finally admitting that EJBs have cost the world enormously, the EJB3 team took lessons from Hibernate and Spring, but not enough to really fix the problem. Most people seem to find that Hibernate and Spring are still simpler and more straightforward than EJB3, so the lack of a rush back to a technology that had such a heavy cost in the past shouldn’t be a surprise.

Java 5 was a tacit admission that Microsoft was doing some very interesting things with C#, and proposed features in Java 7 support the idea that Java is now playing catch-up with C# 3.0. Competition is good, and Java is not dead. It continues to evolve, and the appearance of new languages built on the JVM, like JRuby, Scala and Groovy, is a sign of vitality in the world of Java.

The Web is a Mess

Seeing possibilities is great, but the downside is that it can be hard to acknowledge when something isn’t working. The concept of the web was visionary, but much of the web is a failure. Yes, we’ve been able to force it to work. But it could hardly be said to “work well.” In particular, applications of any complexity using HTML, CSS and JavaScript are difficult and expensive to develop, and it seems virtually impossible to get identical appearances across browsers. Even simple pages look different because of font issues.

If you use Firefox, how many sites do you visit that are at least partially unreadable because they’ve been created only for Internet Explorer (IE)? It seems to me that things are getting worse; I’m seeing more, not less sites that don’t work right with Firefox…to the point that I’m seriously considering going back to IE.

The noble promise of CSS has not panned out. After years, it’s still implemented inconsistently across browsers. As long as you’re using HTML and CSS, you’ll always wonder if what you’ve created is going to produce an unpleasant effect on different browsers. Browsers other than IE or Firefox can often get it even worse.

JavaScript has been around since, effectively, the beginning of the Web, but the browser wars made JavaScript inconsistent and thus painful to use. A key part of Ajax is that someone has gone to the trouble of figuring out cross-platform JavaScript issues so you can ignore the often radical inconsistencies between different browsers.

There are two problems with this approach. The first is that JavaScript is limited in what it can do. Although Ajax is an excellent hack that gets the last bit of mileage from JavaScript, it is nonetheless a hack, and the end is in sight. The second problem is that you are relying on Ajax libraries to handle cross-browser issues. If you want to write your own code, you must become an expert on those issues, and at that point much of the leverage of Ajax goes away. Ajax improves the experience a lot, but it has limits and I suspect we’ve already seen most of the tricks that Ajax is going to offer.

Even more impressive is the Google Web Toolkit (GWT) which translates type-checked Java into cross-platform JavaScript in order to speed the development process. You write code in Java, and GWT compiles it into cross-browser JavaScript. JavaScript, then, becomes the intermediate code that will run on all platforms. But it took Google’s brain trust to solve the problems that shouldn’t have happened in the first place. And if the library you need isn’t there, you must, again, be a cross-platform JavaScript expert in order to write new code. As brilliant as GWT is, I think it will still run out of gas due to the inherent limitations of JavaScript and browsers.

We do see relatively amazing Ajax-based tools like GMail and the other Google tools which are slowly seducing me (but I repeat: it took Google to create those, not Joe garage-programmer). Very nice, but is this the best you ever want to see on the web? You’re seeing, if not the limit, then very close to it in those applications, and even then they don’t work consistently (yes, I know Google tools are “still in beta”). In GMail, for example, you’re supposed to be able to press keys like ‘r’ to reply to a message. Sometimes this works, often it doesn’t, to the point where it’s maddening. And more and more often, when I use web applications like GMail, my “control-c” copy operation stops working. It could be Windows, Firefox, JavaScript or something else but it seems to be associated with web apps and it’s been happening for at least a year. And frankly I don’t care why it’s happening, and neither does any other consumer. When things this simple are broken, the outlook is not promising.

How much effort must we expend to compensate for the long sequence of misguided decisions that has produced today’s web?

Rich Internet Applications

At some point we must ask why Java applets haven’t become ubiquitous on the internet as the client-side standard for RIAs (Rich Internet Applications).

This is an especially poignant question because Gosling and team justified rushing Java out the door (thus casting in stone many poorly-considered decisions) so that it could enable the internet revolution. That’s why the AWT and Applets were thrown in at the last second, reportedly taking a month from conception to completion. Bill Venners quotes Patrick Naughton as saying: “It was a timing issue, there was only about a three-month window in which the whole Java phenomenon could have happened. We barely made it.” I’ve heard that argument before,[1] and this attitude always seems to be a mistake when building programming languages. You’re creating the fundamental architecture that you hope people will adopt and use for many years. This is the place that requires careful thought, not rushing.

I can see why the Green Team took this attitude: it’s the Microsoft Way. Throw a product out there in order to get your foot in the window. The product doesn’t have to be perfect; it just has to hold the market space. Over time, you can fix up any flaws that occurred from rushing the thing out. It’s the marketing version of agile methods.

This approach is workable for dynamic languages. One of the most popular languages ever, Visual Basic, has evolved over the years. Python has fixed some things that would even break old code, in order to clean up the language. Reportedly Ruby is planning to do the same thing.

But for static languages with a large code base (verbose languages in particular), fixing things up doesn’t seem to work so well. All the code must be recompiled and possibly changed—although I would argue that Java could have taken the Python approach: just don’t upgrade if you don’t want to change. There are lots of companies that don’t upgrade to newer Java versions, anyway.

The Installation Problem

So Java has been around for 10 years and applets are not the primary way that we interact with the web. I think the main reason for this is the installation problem, another area of Java that wasn’t well thought-out. In fact, why do we like Ajax?

It’s clearly not because JavaScript is so easy to work with—JavaScript cross-platform problems are the reason people have avoided it in the past. Ajax is popular because we know that the necessary software for the client side is already installed. Someone had to figure out how to deal with the cross-platform issues for JavaScript first, but if JRE installation was trivial, everyone might have just created Java applets. But they didn’t, applets are not ubiquitous, and everyone got excited about Ajax instead. So Ajax became the favored technology for RIAs.

Although it’s gotten significantly better with ECMAScript standardization, I would still rather program with Java than JavaScript, the main reason being inconsistency. Maybe in eight years the current version of ECMAScript will be standard across almost all browsers. But the current version of JavaScript, despite the random implementations, is already available, and there are zero installation issues. I think that’s a fairly good proof that the reason Java hasn’t taken over as the RIA language of choice is the installation problem.

Various fixes have been attempted for Java over the years, but I think the basic issue is that whoever is trying to solve the installation problem is someone who has a more inward technical focus rather than what’s really needed: an outward user-experience focus.

For example, I was stymied by early Linux distributions because of the challenge of installation. About once a year, I would try to install Linux, and it would immediately start asking me questions. Only a hard-core Linux geek would know the answers to these questions. I couldn’t even fake my way through, so I would give up and try again the next year. Then Red Hat came along (at least, I think they were the first to focus on the installation experience) and set it up to install Linux without asking questions, or at least to give me reasonable defaults. That’s when Linux started becoming popular (more recently, Ubuntu seems to have taken the lead in solving the Linux friendliness problem).

Installing the JRE requires the end user to answer questions. To a techie, the answer to these questions is easy or obvious, but to the rest of the web users, questions frighten them during installation. Here’s an article, and comments, that illustrates the problem with Java installations. Although this article is primarily complaining about updates, there is also a lot of confusion about keeping old versions of Java around. Here’s another “installation matters” blog.

JNLP, a.k.a. Java WebStart, was supposed to solve some of these problems to create easy-install desktop applications. I think the reason that JNLP hasn’t become commonly used can be summed up by looking at https://aerith.dev.java.net/, a page for one of the flagship “Cool JavaOne Demos.” If you click on the JNLP version link on that page, it will appear to start up, downloading a bunch of stuff and asking you questions. And then it does nothing. No error messages or any information to tell you what happened. Repeated attempts yield the same results, only faster because the requisite files have already been downloaded. At least, that was my experience. If it worked for you, I’d say that’s even worse—it randomly works on some platforms and not others. How do you debug such a thing?

It’s not impossible to build GUI applications with Java, but it’s been 10 years and there are still installation hiccups with applets, Java WebStart, and regular applications. After 10 years, people don’t trust it anymore. If it’s not there after 10 years, then I’m going to go out on a limb and say that someone doesn’t consider this problem important enough to fix. And even if they did, there have been so many bad experiences among consumers that it would take years to get the trust back.

Experience with Java Applets and Applications

The initial user experience with AWT did a lot to dampen the enthusiasm about Sun’s Java fanfare, and I don’t think applets ever recovered. As a result, Java never became mainstream for RIAs.

Even now, I’ve had bad experiences trying to run Java applets from a web site. They just fail, with no clue as to what’s gone wrong. Worse, they can sometimes leave cruft behind that has even prevented Firefox from opening new windows, until I reboot the machine.

A common response to the “applets are dead” statement is “No they’re not. I still use them.” Applets aren’t useless; people still create very impressive things with them. The Java Posse highlights one or more applets each week. The statement should instead read, “Applets are dead for Web RIAs.” The installation process for the JRE and for any particular applet is not reliable enough for anyone to depend on them for a general-purpose website.

Desktop applications have also suffered, and left bad marks on Java in general, further sullying applets by association. I had an experience with a Java product called Memorex exPressit. The UI was terrible and buggy. I had a contrasting experience with the Logitech IO pen support software (written in .NET), which worked cleanly and looked nice. You could argue that the Memorex programmer(s) were just inexperienced, but the Logitech software was just a small application that worked well without, it seems, any Herculean efforts on the part of the programmer(s), whereas it’s hard to think of any application that I use on a regular basis that’s written in Java. Eclipse is a brilliant piece of software, but I think “Herculean effort” applies.

Consider Corel’s attempt to create a word processor using Java (I don’t remember whether they were trying to port WordPerfect or write something from scratch). It was obviously too early to try it, since all they had was the AWT. But only obvious in hindsight—if you were listening to Sun’s marketing hype at the time, it was the right choice. Shrugging it off as no big deal doesn’t work, because this kind of failure scares people away from doing things in Java.

OpenOffice is not written in Java, but in C++. I don’t believe it was because the programmers wanted to struggle with the cross-platform issues presented by C++. It was speed, and perhaps the need to more directly control the underlying platform. Despite the party line that has always come out of Sun (Many years ago, I attended a press conference where Gosling stated that “Java has always been as fast or faster than C++,” something that puzzles me to this day), Java is not the right solution for all problems.

Not Cross-Platform Enough

I struggled for years to deal with cross-platform problems for products like the Hands-On Java CD. It’s effectively the same as the RIA problem, because I want installation to be as easy as possible, I want everything to work seamlessly the first time, and I don’t want to be forced to deal with platform issues. Often my solutions would work, but sometimes customers would email saying that it wasn’t working on their machine, and I had no idea what the problem was. The best I could do is say “try it on a different machine,” and often that solved the problem…whatever the problem was. I never want to hear things like this; I just want everything to work.

My primary goal has been to create a slide-and-audio content delivery system, like you see in the Hands-On Java CD ROM or Thinking in C.

Java, with its promise of write-once, run everywhere, was an attractive contender. Unfortunately there were, at least at the time, significant delays in Linux support (and to a lesser degree, Mac support). Linux and Mac users may be in the minority, but they are vocal.

The show-stopper was Java’s lack of support for MP3s and multimedia in general. As Dick Wall of the Java Posse has pointed out numerous times, the Java Media Framework (JMF) has been virtually ignored for many years. At the time I made my initial decisions, there was no support for any kind of compressed sound format (I would have been willing to use something other than MP3). Even now the only support for MP3s is through open-source software, which is great in concept, but I don’t want to test it and discover platform issues—again, I just want it to work; the only thing I want to hear from customers is “great!”

It seemed like the only thing that might work was the RealPlayer, so I used that for the HOJ CD, 2nd edition. But the RealPlayer installation process is always trying to trick you into buying the paid version; I must tell people how to find the free version. And it’s intrusive—it takes over MP3s even though you tell it not to.

And for all that, the RealPlayer is unreliable. The installation occasionally causes problems, and I get emails from people. I generally have no idea what’s causing the problem—which is frustrating—and the customer is usually convinced that there’s something wrong with the CD. The Daily Show, for years, used RealPlayer and it was not only painful because it was always starting and stopping (you couldn’t download everything beforehand; it forced you to stream), but it always had these streaks on the left side of the picture. Now Comedy Central has changed to a new system but that only works intermittently. So I end up just waiting for them to be posted on YouTube.

The Flash Solution

So here’s my question. Allow for a moment the possibility that, after 10 years, Java is not going to take over the world of RIAs. Further allow that Ajax is just “how JavaScript was supposed to work in the first place,” but that the limitations imposed by browsers, HTML and CSS committees seem unlikely to let it expand beyond its current bounds. What are we going to use to build RIAs?

In my own search, I’d really like such a system to solve not just some, but all of my UI problems. If I’m going to go to the trouble of learning it, I don’t want to run into a wall just when I start to develop some speed. That’s happened plenty of times already.

The only obvious solution is Flash. Flash has always been all about cross-platform multimedia experiences and user interfaces. People are very familiar and comfortable with Flash, and it is installed on almost all machines in the world. It’s trusted, stable and reliable.

Installation is a no-brainer for everyone. You don’t have to answer questions or do anything special; it just works. That’s why it’s already ubiquitous. Current and future versions of Flash are now released concurrently for the three main platforms (yes, except for 64-bit Linux, but they’re working on it and that user base typically has more than one computer, and so has alternatives in the meantime). The standard Flash installation plays MP3s and various types of video, so you’re not stuck with “write-once, run everywhere…except for multimedia.”

And you can’t deny that Flash produces very pleasing user interfaces. What did Flickr and Picasa both use? Not Java, not Ajax, but Flash. Google videos, written with Ajax, must not have been going anywhere because they bought YouTube, which uses Flash. Even the most die-hard Swing fan secretly wishes their UI could look this good, especially without all the extra work Swing would require.

There’s a very impressive Flash web app called Gliffy that imitates Visio (this was created with OpenLaszlo, which I’ll mention later). No one could even think of creating something like that with Ajax, although someone did an imitation of the much simpler Microsoft Paint using HTML, CSS and JavaScript. Very impressive, but you get the sense that this is close to the limit of what those technologies can do, whereas Flash would just be getting started. Plus the Paint clone is a bit slow and clunky and the UI is inconsistent across browsers.

While amazing things have been accomplished within the confines of JavaScript with technologies like Ajax, JSON, GWT etc., these are nonetheless confines. We bump up against their limits every day, and those limits are not going away.

Solving the UI problem

One of the difficulties of GUI programming is choosing a GUI library. Sometimes there’s a standard library, but that can change. In Java, we started with AWT, which turned out to be a mistake so we had to be patient as Swing was developed, until IBM and Eclipse came along and offered us the additional choice of SWT. In Python, there are many GUI libraries, including the built-in Tkinter (which reduces the installation problem), WxPython, Qt, and more. Windows-specific libraries have similar choices, but if you want to create cross-platform applications, those libraries aren’t available.

If you explore these GUI libraries, as I have, you run the risk of getting broad knowledge that is not particularly deep. Each library requires significant effort to learn, and each seems to have its own philosophy regarding the activities that should be easy, and those that should only be possible. Each one looks at the world of GUI programming in a different way.

I’d like to be able to learn one solution and use it for all my applications. That way I could stop learning about GUI solutions and start acquiring some depth. Ideally, this will be a real programming language with consistent results across all platforms.

I believe that to solve the user interface problem, we need the equivalent of a domain-specific language dedicated to the user experience. For me, Flash-based technologies like Flex are the best solution to this problem. (Full disclosure: I’m in the process of working out a consulting contract with Adobe, to help them teach people about Flex. But long before this, I became convinced that Flash, and Flex in particular, was the best solution for the user-interface problem, and I began writing this article long before Adobe expressed interest in my assistance).

What is Flex?

Traditionally, Flash content and applications have been created with the Flash authoring tool, currently called Flash 8 Professional (it’s confusing, but the decision to give the name of the tool the same name as the runtime was made ten years ago). There was also a tool called Macromedia Director, a multimedia production tool for CD-ROMs, which predates Flash and outputs a format called Shockwave that runs in a Plug-In/ActiveX control much like Flash content, but is an entirely different control. Shockwave had its heyday, and it is still widely used, especially for games, but Flash is much lighter weight and achieved mainstream adoption far beyond Director.

Flex is a way to develop Flash applications by programming. It includes a declarative XML language called MXML for laying out user interfaces, and a programming language called ActionScript, which is a superset of ECMAScript (that is, standardized JavaScript), with extra features like optional static type checking. ActionScript is a single language that works across all platforms, so you don’t have to worry about differences. Because it is based on ECMAScript, your JavaScript knowledge is not lost. All MXML components are actually written in ActionScript, which is what you use if you want to write your own components. Flex applications compile directly into SWFs (Flash binaries), which are then Just-In-Time (JIT) compiled by the Flash runtime, for extra speed.

Cost was one of the main things that originally held me back from using Flex, primarily because of readers who were unwilling or unable to pay it. In the initial versions of Flex, you had to buy the server edition just to create static SWFs. The server edition is designed for dynamic content, and is certainly worth the money for larger organizations that are creating dynamic SWFs from databases and the like. But there was no reasonable entry point for people who just wanted to experiment with it. It was hard for me to recommend it if the average person didn’t have a reasonable experimentation path, including creating static SWFs to deliver from their own server.

Now, however, you can download the free command-line Flex compiler to create static SWFs, and you can deliver these from your web site without paying any fees. The compiler, framework, and debugger are all free, so there’s no reason to avoid using Flex.

You can buy the Flex Builder IDE to help you create Flex apps. This is built on top of the Eclipse platform (instead of creating a new GUI development system from scratch—a wise approach). It has the usual sorts of things we’ve come to expect, like auto completion, context help, debugging, and even a GUI layout tool. The layout tool can give you a quick start when you’re beginning a design, although I found it more valuable to hand-tune the code once the rough draft of the design was in place.

Here’s something else that caused me trouble in the past: although the Flash player for Windows and the Mac have always been on the same release schedule, Flash for Linux has formerly been released quite a bit later. I didn’t know this until I put out the first beta of the Thinking in C eSeminar, and got complaints from Linux and Mac people about it. After some investigation, I decided to back-port the application (which isn’t that fancy, and doesn’t make use of any features that don’t exist in Flash 7). This seemed to be the best solution for me, because I didn’t have to wait for a final release of the newer version of Flash, and in particular I didn’t have to worry about Linux. One of my main goals for using Flash in the first place was to make the use of this application transparent across platforms, and to reduce any installation issues to a minimum.

However, with Flash 9 and beyond, all the players will be released within weeks of each other, and this policy should hold for future versions of Flash. So now you don’t have to worry about complaints from anyone. Build your UI with Flex, and it will “just work.”

Flex as a DSL for Graphics

One of the most appealing things about Flex is that Flash was created with the idea of UI first. In a very real sense, it’s a domain-specific language (DSL) for graphics, multimedia, and UIs, whereas most other solutions have been languages with UI libraries tacked on afterwards.

Because of this design goal, Flex and Flash provide a complete, unlimited, flexible tool to build user experiences. From the standpoint of a programmer’s time investment, you can learn a single language for building UIs without worrying about running into problems or limitations later—issues like:

  • Installation problems
  • Constraints on what you can create
  • Sudden steep climbs in the learning curve

There are plenty of fancy components that you can just drop in and use—the Flex Framework (part of the free download) comes with over 100 components. There’s an active marketplace for component creators, both open-source and payware. One such library comes from Adobe: the Flex Charting Components (in the few hundred dollar range), but there are also competing charting components.

One of the more interesting aspects of Ajax, of course, is the “A” for “asynchronous.” This allows information to flow between client and server without doing a whole page refresh. For Flash, a much more sophisticated version of this is provided by Flex Data Services, a publish/subscribe API for data management. Flex Data Services automatically performs caching and updating between client and server, to produce an optimal experience without forcing you to write extra code. This allows you to work with real-time data, build collaborative applications, and perform enterprise messaging integration. You can use Flex Data Services on a single CPU for free; if your application requires multiple CPUs you’re considered an enterprise and the licensing fee kicks in. You can learn more about Flex Data Services here.

Earlier I mentioned Gliffy, which was built using OpenLaszlo. OpenLaszlo was especially attractive before the Flex compiler and framework became free. However, the OpenLaszlo group has decided that they will accommodate the lowest common denominator technologies by targeting DHTML combined with Flash, and this incorporates the limitations of DHTML. The reason Flex is compelling to me is that it allows me to take advantage of things I can’t do in the normal browser and those things produce the same results, everywhere. On top of this, Flex is magnitudes faster than OpenLaszlo because it takes advantage of the JIT compiler in Flash 9. Since Flex is now free, there’s no reason not to go to the source.

Flex on the Desktop

Of course, if my dream is to be able to learn a single GUI system in depth, is Flex the right tool, since it was originally designed for web RIAs?

A Flex UI can initiate communication with its server, or any other server it chooses. A server cannot initiate communication with a Flex UI, which makes sense because of security (it would be effectively the same as having an open port on your machine).

However, a Flex UI is not limited to communicating with a server. It can also communicate with a local application. Thus, you can create an application in any language you prefer, even a dynamic language like Python or Ruby, and use Flex to build a beautiful UI.

Adobe is developing a new tool called Apollo, a cross-OS runtime that allows you to use Flex to create desktop RIAs. This means that your Flex skills can be further employed for creating smooth desktop applications, but it also means that you can more easily build applications that will work on both web and desktop (I’ve seen expensive and difficult-to-use tools that allow other languages to do this).

Hybridizing Java

It’s clear that we can’t wait for Sun to fix all of Java’s problems. Open-sourcing Java might, eventually, have a huge impact on repairing Java’s deficiencies. For example, work on the JMF might get resurrected. Maybe installation issues will even be fixed someday. The possibilities might be limitless, but if you need to solve problems now, then the solution is to hybridize parts of the language.

We do this already. You don’t insist on using a Java database for an application; you use a specialized system like MySQL or Oracle. Sun is directly supporting the development of JRuby for hybrid Java/JRuby programming. We are seeing other special-purpose languages arise to solve specialized problems. Why insist on using a Java library for UI if a specialized system solves the problem better?

As shown in the TurboGears-Flex demo I created with James Ward, it’s possible to use a language like Python (or Java, Ruby, C#, etc.) as a back-end and build your user interface using Flex. This can even be achieved for desktop applications (even more so with the upcoming Apollo tool).

You can learn all about Flex, and download it, at http://www.flex.org/. This is an incredibly comprehensive site with lots of examples, tutorials and screencasts. They even have an online Flex compiler for instant experimentation. There’s an in-depth presentation that James Ward gave about developing with Flex. There’s another screencast in production, showing how to use Flex as a front-end for Java server applications; I’ll announce it here when it’s ready. You can now create a low-cost, powerful combination of Java on the server (which can of course be running Linux on commodity hardware) and an interactive Flash interface on the client.

[1] In particular, when I took the necessary time to write Thinking in Java, many, many people said “there are hundreds of Java books out already, you’ve missed the window, it’s not worth it.”

This weblog entry is Copyright (c) 2007 Bruce Eckel.  All rights reserved. Republished at SYS-CON.com and associated sites by kind permission of the author.

More Stories By Bruce Eckel

Bruce Eckel (www.BruceEckel.com) is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences. He provides public and private seminars & design consulting in C++ and Java.

Comments (38) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
5tein 04/11/08 03:15:20 PM EDT

I take issue with this hyperbole: "The noble promise of CSS has not panned out. After years, it’s still implemented inconsistently across browsers. As long as you’re using HTML and CSS, you’ll always wonder if what you’ve created is going to produce an unpleasant effect on different browsers."

CSS _has_ panned out. It has only _minor_ inconsistencies across current browsers if written correctly. A well-informed CSS author does _not_ have to worry, because s/he knows the few inconsistencies and is prepared for them. Saying that "Browsers other than IE or Firefox can often get it even worse" suggests that there is a large user base for browsers other than IE or Firefox, and then neglects the fact that Safari gets CSS right too!

DR 10/25/07 07:12:34 PM EDT

If you are trying to sell widgets to masses, you need something that can run in any browser. In this situation scripting languages are attractive and Java is not.

But this is not what we do, and I don't care about applets, or browsers. There are many reasons to write software that can take advantage of the Internet, and they do not all require your system to be able to talk to some kid in Bangladesh.

Many applications are written to support large, complex business operations. They need to be secure, and must be supported for many years. From our perspective, browsers are unnecessary overhead, and full of their own performance, compatibility, and security problems. Forget the browser and learn to write a Java socket server and you will immediately lose a ton of weight, gain complete control over your environment, and be able to build maintainable, industrial strength applications with Java, that are faster and more responsive than any of the these other technologies.

I cringe when I look at javascript / Ajax to do what we are already doing in Java. I don't want to be the poor fool that has to maintain that type of system across different platforms, over a significant period of time. Flash is nice for what it does, but even if it had the range and depth of Java, which it doesn't, it is too expensive.

If you plan to develop a system that will last, you need a platform with a substantial foundation and long term vision. Java is the only thing out there that fills the bill for us.

Hans-Dirk 03/15/07 07:03:41 AM EDT

I fully agree to Bruce's comments about the deficiencies of Ajax - especially for large enterprise applications. But there are also some strong arguments in favor of a pure Java based RIA solution that Bruce missed to mention. One is the maturity of Swing's widget set, another is that focusing on one technology allows for much more cheaper development and maintenance than working with a mix of technologies. Have a look at http://www.indicthreads.com/interviews/501/swing_ui_mature_ajax_infancy.... for a more detailed discussion of this topic.

Larry W. Virden 02/20/07 02:02:54 PM EST

Today, I read in computerworld that Sun is promoting "SAMP" - Solaris, Apache, MySQL, and Perl/Python/PHP as their answer to the LAMP open source stack.

My first reaction - where's the J (for Java) in that discussion? Why in the world is PHP being promoted over Java for web applications?

Stefano Pogliani 02/20/07 11:51:59 AM EST

I hope that the solution will come from a new generation of Browser technology, something that will be able to properly deal with staeful applications delivered over the web.
I think that AJAX is just a temporary workaround, unless
1. it will be standardized (it is ridicolous to see in excess of 300 toolkits for AJAX)
2. It will be able to live its life outside of the browser.

On the other hand, if this does not happen, I think that the browser will be dismissed by business in favour of Microsoft WPF or Adobe Apollo.

vmatters 02/16/07 05:49:38 PM EST

O, here we go again!
It's seems to be en vogue to question the viability of Java these days. The mine-is-better-than-yours
wagon is moving in full swing and all who has had a bad experience with Java is ready to jump on board. Today it's Flex, before, it was Ajax, then before that Ruby, before that C#/.Net, and the list goes on.

Eckel made some valid points that are absolutely true. However, others needs to be placed in proper context. Java was never meant to be domain-specific platform. Java was never meant to be the killer language for the web. The Java Applet, IMO, was more of a marketing move to get the Java platform noticed early during the days of the web browser's explosion.

One of the the problems with Java is its lofty goal of being everything to everybody on any
OS platform (with some efforts). While that goal is still being redefined, one has to admit that having the ability to run an app on Windows, Linux, Mac, Unix, and wherever Java
is ported (with minimal effort) has been accomplished (yes it has, don't roll your eyes).

Although Java has the ability to be ported from one hosted environment to another, it has not been that easy:
- The debacle with Applet plug-in which was exacerbated with Microsoft having different version of the VM and the plugin
- Launching An App: Until version 1.4 launching a desktop app was a chore which required shell scripting, or use special launcher apps.
- Infidelity of Host OS Look & Feel: Yes this was big with me. The Java application always looked odd and out of place on the desktop. However, Swing in 1.6 solved that nicely by having the underlying OS draw the widgets
- No Hooks to Underlying Host OS: There were no easy way to hook into the desktop environment itself unless you resorted to JNI. Again, in 1.6, the engineers started to offer programmatic hooks to the targeted desktop to include things such as system tray icons and popup menus, etc.

I like Flex and was very impressed by its abilities (plan to use it for some of my offerings). It is great for very specific content-rich multi-media applications. I want
to see more data-/form-driven business solutions solved with Flex (not just audio/video players, or animated panels). Not saying that a complex business problem can't be implemented in Flex, but I have not seen an order entry, or backoffice, or sales automation tools implemented in Flex.
Demoware is great until you try to solve a real world problem with it and then it shows its limitations (that's how we all found about Java's limitations, by trying to solve real world problems).

Another thing that no one has pointed out (or I have not seen), is that while most of Eckel's views are valid... and Sun and the rest of the Java community should take them seriously ... his views are not unbiased. They are part of Adobe's massive marketing campaign to get Flex in front of more developers. His article about Java's limitation is part of a well-calculated and paid ad campaign from Adobe...

Anyway, I hope this discussion will lead to better Java features and not just senseless pointless discussions. Yes Java is dethrone-able (all languages, platforms, frameworks are). But I think Java still has a lot more to offer... Java and Flex will co-exit with no problems... and level-headed managers will select the proper technology base on merit and what solves their problems not based on hype and FUD.

sky 02/16/07 11:21:18 AM EST

The dilemma that is posed by Flex vx. AJAX vs. Java (applets) is as old as the computer industry itself. I'll briefly comment on what I think are the two primary themes of the posts I've read:

1. Flex is propriatary (propriatary vs. standard)
2. Flex costs money.

1. Flex provides a solution to a problem now. If it provides a good one (something that the market will determine), why not use it? This is a business, not a religion. Should we go back in time and invalidate all of the useful applications (and the business they enabled) created with Powerbuilder, Visual Basic, Natural, Easytrieve, Forte, Filemaker Pro, and the plethera of other vendor specific tools and languages? I think not. Would it have been nicer if every one of those tools used the same standard language? Probably, but the bottom line is, they didn't, and that does not diminish the value they brought. All tools have a lifecycle, and companies would still bear a cost to upgrade. That still holds true even if the underlying language is a "standard".

2. Who said a company can't make money selling a product? Flex costs money. So what? It cost Adobe money to develop it. Perhaps all those who use open-source and free (or very low cost) tools would then perform their services for free also? Nuff said.

I reiterate my position: If Flex provides a good solution to the current problem and makes people successful, that is a good thing.

Thanks to Bruce for starting an important dialog and getting people to think about it.


Bruce Petersen 02/16/07 10:33:35 AM EST

Bruce's points are interesting and well taken. Flash is a compelling UI platform to consider. I would comment on the "bait-and-hook" title of the article that seems to have been designed to lure any readers who may have otherwise skipped yet another article on Flex / Flash. Also, any paragraph that opens with "The only obvious solution is ..." MUST meet a formal objection according to the laws of skepticism. After a careful analysis of the choices, I certainly can't agree that is is the "only obvious solution". I'm convinced Bruce believes in Flash and Flex as the RIA platform of our times, but this writing seems much more like an infomercial than an objective article.

Haig Evans-Kavaldjian 02/15/07 01:52:40 PM EST

Two points to make...

1. Flash is ubiquitous on full-blown computers, but it isn't widely available on more esoteric devices, like my Palm PDA and my Motorola cellphone. Why isn't it, one has to wonder, and will it ever be? A relentless trend, gaining steam daily, is away from the desktop and further and further into a brave new world of ubiquitous computing far removed from the traditional desktop (or even laptop) computing environment.

2. Flash, to my knowledge, has always been and still remains an accessibility nightmare. Again, another trend/truth: we all benefit from a focus on accesibility. Almost anyone stuck in a traffic jam has thgouht, "Gee, wouldn't it be great if I could access my email (or newsfeed, or calendar, or whatever) via voice while I'm sitting here in my car?" You don't have to be blind to have a need for accessible software, you just need to be in a specific context. I understand Adobe, and Macromedia before them, have said they are committed to making Flash accessible -- but what's the reality? Is Flash really more accessible now, both in terms of inherent capability, but even more important, in the mindset of the developers who employ it? My gut feeling is -- at least for the latter concern -- the answer is no, Flash developers don't rank accessibility high on their list of concerns. Too bad for us all.

disclaimer 02/14/07 09:44:11 AM EST

Note that there is no disclaimer, like the Artima blog where this originally was pulled, that Bruce Tate got a fat contract teaching Adobe Flex stuff. Huge conflict of interest

John C. Bland II 02/12/07 03:16:02 PM EST

Very thorough work. I expected a badly biased article but, in my brief scroll through, you seemed to be open and pointed out the issues that are there and how to get around them without pushing one thing over another (although Flash Platform applications win 85% of the time anyway; IMO).

In response to "FLGuy commented on the 12 Feb 2007:", the SDK is free so you could totally create full blown Flex applications without needing to spend 1 dime...well...penny either. ;-)

Curtis Cooley 02/12/07 01:47:32 PM EST

Interesting article, though quite the misleading headline. Something more like "Why you should drop AJAX and Applets and move to Flash." Of course, at a site like ajaxworldmagazine.com, not a friendly headline, even if more accurate.

While the basic content of the article is sound, most of the referenced links are juvenile at best. "I can't install Java on my BSD machine so it must suck" doesn't really go a long way to convince me that Java as an RIA is in its final death throes.

Andre Untiedt 02/12/07 01:43:22 PM EST

Great article with poignant commentary - really made me think.

Regarding the installation of Java, however, my experience for the last few installs has been a smooth, question-free download and install which then worked seamlessly.

up2U 02/12/07 11:28:58 AM EST

very good analysis

FLGuy 02/12/07 11:25:02 AM EST

Thanks for a very well thought out and interesting article. You raise a lot of good points about the issues with other 'cross platform' solutions.

Unfortunately, (imho) there are still at least two (possibly 3) major reasons to avoid using Flex:

1) Single vendor source for tools.

Clearly, this is a major problem. (As we have all learned, sooner or later this will be a problem - from a cost perspective if nothing else, and also when a vendor breaks something, doesn't add the necessary new functionality or upgrades in a timely manner, sells or discontinues the product ... etc. Not a good situation to tie ourselves to.)

2) As far I as can tell, the cost of an IDE/modern development environment is still prohibitive for evaluation, learning, and developing of small, inexpensive apps.

3) Users increasingly equate flash with ad - hence the many flash blocking tools for FireFox and other browsers. And just telling users that this app requires that you enable Flash is a problem.

It's (a little) like ActiveX - no matter the justification for a particular app, many people will not enable it (with some good reason).

Until these problems are solved, I will very likely avoid adopting Flash or Flex.

I would be interested in follow up articles addressing alternative/second sources (open source or third party) support for development of Flash apps - and apps using other cross platform languages/technologies.

Thanks again for a very interesting and thought provoking article.

Chris M 02/12/07 12:51:35 AM EST

What I don't get about any of this is why I want to go from a GUI tool that I can easily use to "draw" the interface to creating it declaratively through XML. Tools like VB became popular for a reason. "Rich-client" apparently means creating a robust tag engine for the GUI part and a better javascript interpreter to make it do something useful. Why? The browser IS the problem and it's still here for some reason. Flash is really popular because the runtime is small and fast and there is a RAD tool for creating UIs with it. Is tagifying it really a good idea? Java applets would have been where Flash is now had the technologists trimmed down the applet engine to provide Swing capabilities on more the size of the Flash runtime. Class files loaded over the network seem more sane then a bunch of tags that have to be emitted then parsed again on either end, but what do I know. Unfortunately, the tag lovers pushed everything to the server-side and rich Java client development was cast aside. Wonder what will happen to Flash? Instead of evolving as it has, I'm afraid it will die as some horrible DHTML/AJAX mutation. I'm not looking forward to a future of "scriptable XML-cruncher runtimes" but I guess that is where we're headed. However, the latest features I've seen in tools like NetBeans give me hope that Java can thrive in a world of true rich clients.

Chris M 02/12/07 12:51:03 AM EST

What I don't get about any of this is why I want to go from a GUI tool that I can easily use to "draw" the interface to creating it declaratively through XML. Tools like VB became popular for a reason. "Rich-client" apparently means creating a robust tag engine for the GUI part and a better javascript interpreter to make it do something useful. Why? The browser IS the problem and it's still here for some reason. Flash is really popular because the runtime is small and fast and there is a RAD tool for creating UIs with it. Is tagifying it really a good idea? Java applets would have been where Flash is now had the technologists trimmed down the applet engine to provide Swing capabilities on more the size of the Flash runtime. Class files loaded over the network seem more sane then a bunch of tags that have to be emitted then parsed again on either end, but what do I know. Unfortunately, the tag lovers pushed everything to the server-side and rich Java client development was cast aside. Wonder what will happen to Flash? Instead of evolving as it has, I'm afraid it will die as some horrible DHTML/AJAX mutation. I'm not looking forward to a future of "scriptable XML-cruncher runtimes" but I guess that is where we're headed.

Blog::new 02/11/07 03:27:47 PM EST

Trackback Added: Ajax sux; I’m reading this inflamatory, yet spot-on post by Bruce Eckel, and while its main topic is about why Java failed on the web (because applets are fugly and java is a PITA to install - no grand revelations here), the part which I really want to &#8...

Mike McManus 02/10/07 11:32:40 AM EST

Excellent article...should be required reading for all developers.

Nicholas 02/10/07 06:29:29 AM EST

Isn't it a little ironic that Flash uses a dialect of Javascript internally which is then compiled into bytecode? Furthermore, the user interface is defined in XML!

Doesn't this sound familiar? Don't Ajax applications have a user interface defined in XML (XHTML), and use Javascript as the programming language?

I would suggest that the problem is twofold:

1/ Microsoft's business choice of creating incompatibilities in their version of Javascript.

2/ The interpreted nature of Javascript creating an inefficient, power hungry runtime.

The solution to these problems?

I cannot imagine a solution to the first problem, other than the hope that people stop using IE.

On the other hand, the solution to the second problem is easy: develop a byte code Javascript standard in order to improve runtime efficiency.

The solution is certainly not standardising on a proprietary version of XML+Javascript, just because it happens to currently work better than the current open standard.

Rob 02/09/07 11:37:42 PM EST

I agree with the article concerning the assessment of the problem, but not with the solution. When you get down to it, what is the core problem? Lack of consistent and usable standards. This article wouldn't exist if the web had decided to follow standards, but greed and power struggles caused companies to do their own thing. The web runs off of web browsers. And who is most to blame for the dividing of the web? Not Sun, but Microsoft and Internet Explorer. IE development and standards support stagnated, thereby crippling the web for the years to follow with non-standard extensions, bad CSS support, and general stubbornness to ignore anything better that didn't come out of their own company.

But the *real problem* is that people wanted something to "just work" and they wanted it NOW. So they decided to be "pragmatic" (i.e. short sighted) and forsake the future for the sake of the present. Tying the web to the future of a single company is what broke the web, and now you suggest that we adopt Flash? Flash is not an open-standard. It is a product decided by Adobe. You're suggesting as a solution the very root of the problem you're criticizing. If we neglect improvements in other areas simply because we have Flash today, the result will be that in the future if Adobe does something we don't like or something better comes out, we're stuck. And the other web technologies would have stagnated in the meantime. No thanks. The long term fix is not Flash. If we want to fix the web, chasing amorphous vendor-tied solutions isn't going to do it. I don't like the fact that AJAX is just a hack either, but at least it's vendor neutral. We don't really have a choice, standards must be open in order to be true standards. And the fact that AJAX has annoyances is due to its relative immaturity, but the demand for a consistent experience is what will spur on better libraries and interoperability efforts. In the future, I would much rather have browsers have consistent Javascript and dynamic SVG support, but then again, with Microsoft in control of IE I'm not holding my breath.

Peter Colijn 02/09/07 10:43:19 PM EST

I just read your article, and while I really liked your description of all the problems with applets (totally bang on!) I take issue with the suggestion of flash. I think another reason people are excited about AJAX is that AJAX apps can behave properly within a browser. Yes of course you *can* break things like the back button, but you don't have to. I have no issues with calling AJAX complicated, difficult to use, and a mess. It is all those things. Unfortunately, it is also the only way to build dynamic web apps that lets you integrate properly with the browser, an application with which most users have over 10 years of familiarity. With flash, you're forced to break everything. Keyboard shortcuts. The back button. Bookmarks. etc. You're essentially giving the browser the finger and using it as the window to display your app. In other words, it has all the same problems as applets, except that it looks, well, flashier. And maybe it's easier to install, but I'm not convinced. The last few times I installed the JRE it was pretty bloody painless. The main reason the JRE is "harder" to install than flash is because MS screwed Sun back in the day, so it isn't installed by default.

So if you essentially want applets v2, fine. Go build your apps that will infuriate people every time they try to use control-t to open a new tab, control-l to select the URL in their browser, want to use the back button to see the previous page or would like to bookmark the current page. Personally, I like those features of the browser, have been using them for 10 years, and you will not find me eager to start using apps that throw all of those features out the window.

I propose instead that we work on cleaning up the mess that is HTML, CSS and AJAX. No, it's not going to be easy, but with the increased interest in these technologies it will move quicker than it has before.

In addition, your facts for the article could use some checking: PicasaWeb, for example, uses lots of AJAX and only a little flash [to show videos]. Google Video on the other hand *does* use flash [the same one as PicasaWeb actually], so its lack of popularity compared to YouTube cannot be blamed on the merits of AJAX vs. flash.

Finally, your "flash is already installed everywhere" argument doesn't really apply, because you're talking about a new version of flash with the flex stuff that has yet to be installed everywhere.

Carl "The Truth" Williams 02/09/07 10:18:35 PM EST

Is it 1998? That is when all the rest of us realized Java was dead in the browser, and invested all our money in Java taking over the server. Which it did, and still owns. I can't believe anyone even remembers the Corel thing 8 zillion years ago. What a strange funny little Flex man. :-)

John Kucera 02/09/07 09:35:39 PM EST

Asperon has been making compatible Java applet RIA clients for many years now, long before the term AJAX was made popular. The trick is to have a widely compatible UI toolkit that does not care what version of Java you have.

Because Java is more of a strongly typed language and because it is compiled (just in time) it is faster and easier to maintain than JavaScript RIA clients.

The world just got a bad first impression of Java because it did not initially live up to the hype and because Sun did not make sure it really was compatible across browsers.

Just fix that problem and Java is the best RIA client choice around!

Stan Berka 02/09/07 06:41:55 PM EST

And why Java had a bigger "installation problem" than JavaScript? I'm surprised that the author didn't mention the most obvious reason: JavaScript was always deployed on Windows machines together with IE and Java wasn't. Please, prove me wrong! Because, I may be wrong very well.

Chris Volk 02/09/07 05:30:51 PM EST

AJAX is insecure, and actually, it's a huge hack. 99% of mobile devices use Java (over a billion of them!). Java is the biggest requirement on job sites for developers, sells the most books of any language, and is used in virtually every enterprise out there. Steve Job's comments mean nothing, just competitor FUD. Java is robust, secure, purely OO, extremely mature, and easy to create really well designed software in. AJAX can claim none of this.

Frankly, the comparison is more ridiculous than anything.

Just because this new generation of developers is extremely lazy given that the most common complaints from people like Tate are "it's soo hard". Awww. Software development is a complex process. It's not supposed to be easy. If it were easy, we'd all be out of work. I've been developing software for 25 years, and I never expected "easy". Though with good tools, and a good brain in your head, it's quite easy and fun in the end.

I take these comments within their context: FUD, laziness, etc.

Anonymous 02/09/07 05:19:25 PM EST

While support for Flash on alternate platforms (such as Linux) is improving, it is still not available on non-x86 alternate platforms like Linux PPC. Yes I am in the minority, but until it is readily available on ALL platforms, I will not commit to using it.

Russ 02/09/07 05:16:27 PM EST

The aerith demo requires JDK 6. The JNLP file should specify this, but is configured for Java 5...

Flash is compelling for creating relatively simple UIs, but what if I need to stream multimedia that isn't in the format flash supports? Java applets and jnlp appear to be the only option.

skid 02/09/07 05:06:01 PM EST

I just downloaded the Flex2SDK, oh wait it needs Java, oh wait I'm on Windows XP64, oh wait, Sun aren't interested.

As for copy and paste problems, Win32 platform developers will be well familiar with the difficulties of co-existing with MSWords clipboard helper, I'm guessing someone needs to lend a hand to the poor, work for free, firefox team.

All in all, the publishing of this authors diatribe is the first evidence of any Java backlash I'm aware of, opinionated programmers can stay at the bottom of the heap in my book.

RLD 02/09/07 04:10:32 PM EST

I find it amazing the claims that the web does not do UI well. By all measures, the web and it's simple page-based model has been the most successful UI model ever. Usability can be measured by the number and type of people that are able to use the application. My grandmother has figured out how to use the web. That's a huge measure of success.

The web might not do "complex" UI well, but it was that complex client-server type of UI in the 90's that made it so difficult for the common user to use computers. Grandma had no interest in computers then. With the simple web model, designers were forced to simplify interfaces. Applying a complex UI model to the web is not going to guarantee and easier-to-use interface (with exceptions like Google maps, designed by phenoms).

We'll see. Is this time different than all the other attempts to re-make UI development? In the end, all the old rules of keeping it simple will still apply.

Steve 02/09/07 03:35:15 PM EST

Stop whining and get back to work. Whenever somthing gets popular, and especially as ubiquitous as Java, people find they can make a name for themselves but cutting it down. Good job.

James Ward 02/08/07 08:02:37 PM EST

> Flex is good, I would like to see it win. But the
> question is, how will you convince customers to go for
> a "buy" solution when you get HTML/CSS/AJAX for free.

The Flex SDK is free! Many people are using the free Flex SDK to build some amazing Flex applications. Sure you can buy the Flex Builder tool or Flex Data Services if you need them, but they are optional.

daisychain 02/08/07 04:38:52 PM EST

For a long time, I have had same opinions about cross platform/development UI development technologies, but I could not have structured my thoughts like Bruce. Nice writing.

Flex is good, I would like to see it win. But the question is, how will you convince customers to go for a "buy" solution when you get HTML/CSS/AJAX for free. Plus how is the Flex solution going to affect their existing investments on Struts/JSF/other UI server side UI framework technologies.

One possible solution is to show them the difference in maintenance costs - between AJAX and Flex based solution. If we cannot quantify the advantage, it will be hard to sell.

nobodyman 02/08/07 08:51:55 AM EST

The IT industry tends to have a single-minded obsession with The Next New thing. I suppose it's partially motivated by a hope that some new technology will be the silver bullet to solve problems that have plagued the industry for ages - projects get missed and go overbudget.

Pxtl 02/08/07 08:10:33 AM EST

Java is, from a language design standpoint, a joke. It was designed by cutting chunks off of it's predecessors and not supplying any viable substitutes.

People always brag about their million-line .net1.1 and Java2 projects, claiming that such million-line monstrocities are proof the language is maintainable. What they don't tell you is that 900 000 of those million lines are spent on simple get/set wrappers, typecasting containers, re-implementing containers missing from the library, and recoding functions for different datatypes, giant class-based switch statements, and various other workarounds to avoid the languages' limitations.

Java is a nice VM and a solid, mindbogglingly featureful library - but a mediocre language.

dnoyeb 02/08/07 07:58:52 AM EST

Just because the hype has died off does not mean the language has. In fact this could be an indication that the run-up is over and people are receiving their dividends now.

rdean 02/08/07 07:05:11 AM EST

The pace of "exciting" Java development has slowed down, so they've moved on to technologies where they can get that feeling of new and exciting again. I don't begrudge them. They have that right....but their departure doesn't automatically make what they're working on any better than current technology.

vectorian 02/08/07 07:02:53 AM EST

Yes, Java is no longer the buzzword of the day, but that doesn't mean that it is obsolete, dying, or anything like that. This is (at least partially) highlighted by the fact that MS is aggressively developing C# and the .NET framework. Java has its own niche.

hat being said, today's buzzwords seem to be RoR and AJAX, though I don't think either will be knocking any of the competition (completely) out of the picture.

IoT & Smart Cities Stories
Early Bird Registration Discount Expires on August 31, 2018 Conference Registration Link ▸ HERE. Pick from all 200 sessions in all 10 tracks, plus 22 Keynotes & General Sessions! Lunch is served two days. EXPIRES AUGUST 31, 2018. Ticket prices: ($1,295-Aug 31) ($1,495-Oct 31) ($1,995-Nov 12) ($2,500-Walk-in)
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by ...
DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed...