I've just read two posts in response to Assembly Java, an interesting list of tips for writing compact code. I think the Assembly Java post takes things maybe a little too far, but basically I'm with almost everything in it because if you write tight code to a good design, you can produce maintainable JavaME (still sounds wrong...) that actually works across the market.
First up we have John Flinchbaugh, who has apparently been reading about JavaEE and JavaME and decided that all this tight coding stuff is rubbish, he's going to just splurge out on objects , I'm sure because most of the handsets his friends have are all top of the line high-spec things, and so everyone must have the same. If you're coding a service entirely for gadget geeks then go for it, absolutely sensible, if not can you risk alienating 40-70% of the owners of phones (depending on how restrictive you want to be)? If you do create a service they can't access, be sure to put that factor into your business plan when you talk of the number of billion phones in the world and how big that makes the potential market.
Secondly we have a post from Thomas Landspurg which basically tempers the one class ascetism of Assembly Java and suggests three or four might be much more friendly (I'd go for anything less than 6-10 as long as each one can be justified by the design goals). Hits it right on the head. I also liked this post for one comment:
"It’s a really strange industry, where on one hand people are talking of “MobileAjax” as the killer app, where the cost of one Ajax line is probably equivalent to the cost (in terms of CPU, memory used,battery) of a full Midp1.0 application"
Which sums up Mobile Ajax nicely, except that it forgets to mention the bandwidth cost and time penalty of downloading an entire app to your browser whenever you want it and then being in constant XML communication with the server, on the flaky 2.5-3G pay per byte connections we use these days. I'll let him off because it would have been less pithy ;)
However, as an aside, maybe it's time we look past yesterday's Web 1.92 beta RC 324 (or even today's more hip-and-with-it Web 1.92 beta RC325) and see what Web 3.0 will look like. To do that we have to consider Ajax. Sure, Ajax is disruptive - I can think of nothing better to drop into a soiled toilet, but that's quite a localised disruption. For real market disruption you want ToiletDuck, with the bendy neck that gets right up under the rim. I confidently predict that when the Web 3.0 bubble begins to expand on the dregs of the burst Web 2.0 bubble, it will be ToiletDuck technology that carries our browsers on to an asymptotic future of tagged user-generated goodness.