timjowers at gmail.com
Mon Dec 15 09:54:12 EST 2008
Flash today. These are the two paradigms with legs.
Silverlight/ActiveX is just too darn Microsoft proprietary so I doubt
it will ride for long. So, your question as it relates to TriJUG is
This is the question of this year and next. One answer might be
"both". I believe you will find one of the base reasons for Java's
decent tools and is closing the UI technology gap on Flash/Flex like a
My gut call is Adobe lost the day by charging ~$600 per dev IDE. I
might be wrong. But you look at how BEA went into the stratosphere
selling what others give away and their model was "free IDE" and price
gouging on the server components. Contrast this with Borland who
inarguably had the best early Java IDE but is little more than toast
today. So, for this reason one might project Flash(Flex) will not win.
Bad marketing strategy. Companies are accustomed to forking over
$70,000 to $1,000,000 for servers and server software but have freezes
on spending on desktop software except for the Microsoft Office
(ironic, stupid, and costly, but true).
if I write a portal solution and a hugeco wants to plug it into their
Cost? My belief is the net cost with Flash/Flex is probably less.
Today, the potential for an incredible user interface is far more
tractable in Flash. Graphical designers know how to use Adobe tools.
This is what they train on in college. The standard level of UI is
higher in flash apps. The cost is less when starting from scratch; but
most companies have to build on their existing systems.
these can be added INCREMENTALLY to existing website. This is THE
KILLER FEATURE. This is why they are the default and de facto choice
for the industry.
Sure, network admins killed client server and peer to peer but network
communications are a requirement for dynamic and operational business
apps. This class of apps cannot be accomplished with plain HTML. The
app demands are maturing and the technologies must also. Consider a
call center project I did for a major auto company. The retarded
consulting company SW "Architects" did everything as a form POST based
website. I almost fell over laughing when they did alpha testing and
the 60+ call center folks were trying to support callers but had 3-5
second delays for each lookup. These things HAVE to be done via AJAX
who thinks differently is not a skilled software engineer. I didn't
laugh but did tell the business managers the solution needed to
support the interaction times demanded by real call center staff and
suggested some architectural changes.
Finally, the other mega question for 2009 is JSON or SOAP. 9 years ago
we were doing what is now called AJAX and everything was XML and what
was then called "data islands". Lots of XML and XSLT. Then the thought
was XSLT was the new panacea. Sort of like POJO or Ruby today. The
webdev guys tend toward quick and dirty solutions and are tending
instantiating them). This slams against the SOA initiatives in the
industry. I've not seen any SOAP/JSON converter but I've not looked
either. Anyone? The move of J2EE toward POJO and REST and away from
EJB and WebServices clearly is a vote for JSON and against XML. Flex,
OTOH, probably is geared more towards XML/Webservices IMO but actually
Adobe is trying to push their own object protocol - "Yet another
proprietary technology" - and thus present another con against using
I've been thinking alot about this issue and it is very important.
What happened to Swing and JNLP? I've just not seen them being
considered at all in the webapp space. In small tech groups where they
are working in a lab people make apps with these but once you start
talking to hugecos with webapp integration concerns, then Swing is not
even considered and Flash is considered bad form at best, an
integration nightmare in general, and a definitive security issue in
P.S> I totally agree with Kevin's and Steve's points too. You can only
build brochure apps without some dynamic communication such as AJAX.
their risk is much smaller than the other security risks out there.
The easy solution is to have a confirm page for any major business
transaction and this solution is common practice.
On Sun, Dec 14, 2008 at 11:59 AM, Steve Litt <slitt at troubleshooters.com> wrote:
> On Sunday 14 December 2008 02:44:18 am Maxwell Spangler wrote:
>> A question to the full time web developers out there: Why so much
> I'm not a fulltime web developer, but I'll be glad to tell you why I used
> Somewhere in the early to mid 00's I decided that Troubleshooters.Com's main
> page, which had been a table of graphics, each of which links to a subsite,
> was too gaudy and unprofessional. I wanted to change it to a hover menu.
> Hover menus are a dime a dozen, but most involve very compex code with many,
> many browser #ifdefs. I wanted something simpler, and something useful even
> hovermenu you see at http://www.troubleshooters.com/troubleshooters.htm.
> A few years ago I made pricing principles for my courses and courseware
> logical enough to provide price calculators to would-be customers. I used
> http://www.troubleshooters.cxm/utp/courseware_cost_calculator.htm and
> http://www.troubleshooters.cxm/utp/onsite_cost_estimator.htm. Although I
> could have performed the calculations on the server each time the person
> entered a field, I'm old enough to remember how nice instantaneous field
> When I instituted Paypal on my site in early 2006, I found Paypal's standard
> buttons unacceptable because, for those on dialup, in certain situations,
> clicking on the buttons produced absolutely no feedback for several seconds.
> I'm a firm believer that every user action should be immediately acknowledged
> so that the user knows the computer program "heard" him, and so the user
> that, upon clicking, instantly grow bigger, turn into a table, and display a
> message to please wait 4 to 60 seconds for the Paypal page to display. Upon
> return to the original page, the table reverts to a button.
> way, THAT I KNEW OF, to accomplish what I needed accomplished. All pages in
> I find plain HTML sufficient, efficient and secure for giving information to
> people. My next Linux Professional Magazine will deal with the subject of
> plain html.
> Steve Litt
> Recession Relief Package
> TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
> TriLUG FAQ : http://www.trilug.org/wiki/Frequently_Asked_Questions
More information about the TriLUG