This isn't really about programming languages, but I still think it is relevant to our discussions,

A lot of Ajax applications have a lot of script (often 10 or 20,000 lines) and without broadband, the download of this can be extremely painful. With broadband and standard tricks for compressing the script, it is a breeze. Even if you could download this much script in 1997, it ran too slowly. Javascript wasn't fast enough to respond in real time to user actions let alone to fetch some related data over HTTP. But Moore's law has come to its rescue and what was sluggish in 1997 is often lightning quick today.

We often tell people that execution speed is less important than code readability and flexibility, which depend on high level abstraction facilities found in HLLs. I guess we should consider bandwidth efficiency instead...

What I predict will drive this change is the advent of truly mobile computing on mobile devices. This is going to force the game to change. It is way too expensive to build solutions for mobile on J2ME and often too poor a customer experience when they are built using WAP (except for super simple things). I think that we're going to rethink browsing around a model which has pub/sub, events, and caching built in..

Languages for mobile code are going to be important for this next phase. I think there are still many interesting language design questions related to mobile code that people should start thinking about (cf. Links). I am sure a savvy language maven can become the next BDFL, or alternatively earn some big bucks, by helping attack this problem.

## Comment viewing options

### Macromedia Flash Lite as an alternative to J2ME

J2ME VMs are notoriously buggy and incompatible. Part of the problem is that plethora of J2ME implementations by different companies.

For example, JAMDAT's hugely successful bowling game for cell phones was written in Java. For that ONE bowling game, they have over 100 different builds and packages to support different J2ME VM bugs and different screen sizes and resolutions.

Macromedia Flash Lite is controlled by one vendor (which has advantages and disadvantages). It uses ECMAScript which is easier for graphic designers than Java. And Flash Lite's vector graphics can scale to different screen sizes and resolutions.

http://www.macromedia.com/software/flashlite/

Full Disclosure: I work for Macromedia. <:)

It's the first time I see a post on LtU that qualifies as spam.

### don't think so

If it were spam there wouldn't have been a full disclosure. It he hadn't put that full disclosure down would you have considered it an ad or would you have considered it a valid viewpoint.

### Vendors/Developers

We doget the occasional post from commercial developers. Solong as there's full discolusre and valid technical contributions, I don't see the harm. In fact, I think it's interesting to hear these view points from time to time.

As to the merits of the specific post in question, I'll let you decide for youself.

### sorry!

sorry! I did not mean to spam LtU. I've been lurking LtU for a couple years and I certainly don't want to spoil it. I'm interested in programming languages and mobile phone software, so this particular discussion of programming languages for mobile phone software is very exciting.

I only wanted to introduce Flash Lite as an alternative programming language/environment for mobile phones. Adam Bosworth was discussing the expense and frustration of J2ME and the poor user experience of WAP. Flash Lite tries to address some of those challenges. DoCoMo and other handset manufacturers currently use Flash Lite as just a multimedia plugin for their iMode browser, but some companies are beginning to use Flash as a "real" programming language to implement their phones' native GUI.

### Don't fret

Don't worry about it. I liked your comment, and I wholeheartedly agree with Ehud.

In my opinion, the biggest thing missing from Java is a truly satisfactory graphics library. I love Quartz, never really tried Flash. Also, I like JavaScript quite a bit better than Java.

My biggest frustration with ECMAScript is the pervasive incompatibilities between implementations. I know Java has its incompatibilities, but they seem to pale in comparison to ECMAScript's.

ECMAScript's DOM isn't too bad for an OO langauge, but it doesn't hold a candle to XML libraries available for Scheme, ML, Haskell, etc.

And just because really cool Flash Lite apps aren't there yet... doesn't mean it's not better than J2ME.

### I've got Flash Lite on my pho

I've got Flash Lite on my phone (a Docomo F505i), and the "apps" (if you can call them that) are not anywhere near as impressive as the Java ones. In Java I've got stuff like a full 3D train simulator; in the year I've had Flash Lite I've seen nothing more than what are basically animated web pages and graphics.

I've heard that Flash Lite is quite restricted in comparison to real Flash. Whether this is Macromedia's problem or Docomo's problem I don't know, but Macromedia certainly has to work on it if they want it to be taken seriously.

I will agree that programming sophisticated mobile applications in Java is a nightmare, particularly when it comes to testing.

### Linux x86_64

Could you make it work on my Linux x86_64 machine. If it so great I want to see it too.

((lambda (lambda) (,lambda ',lambda)) '(lambda (lambda) (,lambda ',lambda)))

### Just Silly

"Even if you could download this much script in 1997, it ran too slowly. Javascript wasn't fast enough to respond in real time to user actions let alone to fetch some related data over HTTP."

That is just plain silly. Javascript did not run too slowly, neither its implementations, nor on 1997's hardware. In 1997 I had all sorts of fun writing widgets drawn with HTML table cells that would highlight on hover, depress on click and cause other actions on release. It ran just fine. I can tell you one thing, however, those widgets were less that 100 lines each and fully reusable. The size of the included .js files were smaller than the images in JPEG would have been to create the same visual effect.

That was the real 1997.

### Unfair quoting

You left out the part that did make sense:

Javascript wasn't fast enough to respond in real time to user actions let alone to fetch some related data over HTTP

Considering the post was about what people call Ajax, the emphasized part of that sentence is what it was all about. Trips to and from the server under real-time user interaction is only feasible on fast networks.

### Unthinkingly Considerate

If the author is flat wrong on Javascript responsiveness to real time user actions in 1997 why should we give him the benefit of the doubt about his other assertions? I quoted him fairly. He was wrong and I gave a detailed description of my experience to the contrary.

And I'm sorry, but if Ajax developers cannot make things work with low bandwidth networks or low speed hardware then it is only because they are not trying hard enough. All of this has been done before and yes, even before XMLHTTPRequest. In 1997 one could target a request to a hidden frame. The content of that frame could be prepared for Javascript and communicated back to the original frame.

None of this needs to take extra bandwidth. If it does then those developers should simply focus on scaling down the amount of content. Pagination, scroll and load more, whatever it takes. If you want it to work, I know for sure you can because we did it back in 1997 with modems and Pentium 90's. It worked fine.

"Considering the post was about what people call Ajax, the emphasized part of that sentence is what it was all about. Trips to and from the server under real-time user interaction is only feasible on fast networks."

### It can be done via http

I make a decent living writing applications with http, dhtml, server side scripting, and database stored procedures. So I'm fully aware that it can be done.

That doesn't mean that the results are elegant or maintainable. Multiple languages and frameworks have to be crossed. Kludges abound.

### Then perhaps "we" should stop?

We often tell people that execution speed is less important than code readability and flexibility

This, despite the fact that customers do care about performance a great deal. Perhaps all that time spent by Microsoft perf teams getting Word to run quicker is not completely wasted...

BTW, ATL was originally created (at least in part) because the MFC DLL was too large for modem download and Microsoft needed a library to help developers write ActiveX controls.

### I don't know why but "ajax" bothers me.

Not the technique (it's one I've been using for a couple of years now and it's great). It's just the hype over it. I think in a lot of ways this reflects on software fads in general.

Ajax is nothing more than one Javascript object put to good use. The method of development is hardly based on any technology that hasn't been around since 97 but for some reason it's entered the collective consciousness of the web developer trend-set.

Mentioning Flash as an alternative to J2ME development is an interesting parallel because I fully expect Flash to be "discovered" for networked/embedded user interfaces (rather than just zippy entertainment site intros) sometime in the next year or so.

I guess this is how all of the Smalltalkers feel when ruby guys go gaga over blocks and method_missing? :-)

### Prozac, anyone?

I guess this is how all of the Smalltalkers feel when ruby guys go gaga over blocks and method_missing? :-)

And if you think that's bad, think of how many years Lispers have been depressed. I believe it started in the early seventies, when closures were relatively available, and in full swing by the eighties when we had decent OO and a kick-ass condition system. Of course, the AI boom of the early eighties helped take the edge off a bit, but since then... Man! Seeing everyone invent the wheel in different colors gets old fast.

### Yeah but the grumpy lisper is

Yeah but the grumpy lisper is so cliched, those guys get bent out of shape over everything ;-)

### Perhaps Its the Security Problems That Bother You

weeksie wrote:
I don't know why but "ajax" bothers me.

Perhaps its the security problems that JavaScript and it's variants incur? There have been so many bugs associated with JavaScript. And the variety in implementations does not help.

It is impossible to maintain security while using JavaScript.

### document.write("Hello, World"

document.write("Hello, World");

Where did the security hole show up again? It's impossible to maintain security if you don't think about it. The language isn't really relevant.